aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/kernel/apic/apic_common.c
AgeCommit message (Collapse)AuthorFilesLines
2024-02-15x86/apic: Remove yet another dubious callbackThomas Gleixner1-5/+0
Paranoia is not wrong, but having an APIC callback which is in most implementations a complete NOOP and in one actually looking whether the APICID of an upcoming CPU has been registered. The same APICID which was used to bring the CPU out of wait for startup. That's paranoia for the paranoia sake. Remove the voodoo. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-02-15x86/mpparse: Remove the physid_t bitmap wrapperThomas Gleixner1-11/+1
physid_t is a wrapper around bitmap. Just remove the onion layer and use bitmap functionality directly. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10x86/apic: Use u32 for cpu_present_to_apicid()Thomas Gleixner1-1/+1
APIC IDs are used with random data types u16, u32, int, unsigned int, unsigned long. Make it all consistently use u32 because that reflects the hardware register width and fixup a few related usage sites for consistency sake. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Zhang Rui <[email protected]> Reviewed-by: Arjan van de Ven <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10x86/apic: Use u32 for check_apicid_used()Thomas Gleixner1-1/+1
APIC IDs are used with random data types u16, u32, int, unsigned int, unsigned long. Make it all consistently use u32 because that reflects the hardware register width and move the default implementation to local.h as there are no users outside the apic directory. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Zhang Rui <[email protected]> Reviewed-by: Arjan van de Ven <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-08-09x86/apic: Sanitize APIC ID range validationThomas Gleixner1-5/+0
Now that everything has apic::max_apic_id set and the eventual update for the x2APIC case is in place, switch the apic_id_valid() helper to use apic::max_apic_id and remove the apic::apic_id_valid() callback. [ dhansen: Fix subject typo ] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Juergen Gross <[email protected]> # Xen PV (dom0 and unpriv. guest)
2023-08-09x86/apic: Mop up apic::apic_id_registered()Thomas Gleixner1-0/+5
Really not a hotpath and again no reason for having a gazillion of empty callbacks returning 1. Make it return bool and provide one shared implementation for the remaining users. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Juergen Gross <[email protected]> # Xen PV (dom0 and unpriv. guest)
2023-08-09x86/apic: Nuke empty init_apic_ldr() callbacksThomas Gleixner1-0/+16
apic::init_apic_ldr() is only invoked when the APIC is initialized. So there is really no point in having: - Default empty callbacks all over the place - Two implementations of the actual LDR init function where one is just unreadable gunk but does exactly the same as the other. Make the apic::init_apic_ldr() invocation conditional, remove the empty callbacks and consolidate the two implementation into one. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Juergen Gross <[email protected]> # Xen PV (dom0 and unpriv. guest)
2023-08-09x86/apic: Remove check_phys_apicid_present()Thomas Gleixner1-5/+0
The only silly usage site is gone. Remove the gunk which was even outright wrong in the bigsmp_32 case which returned true unconditionally. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Juergen Gross <[email protected]> # Xen PV (dom0 and unpriv. guest)
2023-08-09x86/apic: Remove pointless x86_bios_cpu_apicidThomas Gleixner1-1/+1
It's a useless copy of x86_cpu_to_apicid. Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Juergen Gross <[email protected]> # Xen PV (dom0 and unpriv. guest)
2018-04-10x86/apic: Fix signedness bug in APIC ID validity checksLi RongQing1-1/+1
The APIC ID as parsed from ACPI MADT is validity checked with the apic->apic_id_valid() callback, which depends on the selected APIC type. For non X2APIC types APIC IDs >= 0xFF are invalid, but values > 0x7FFFFFFF are detected as valid. This happens because the 'apicid' argument of the apic_id_valid() callback is type 'int'. So the resulting comparison apicid < 0xFF evaluates to true for all unsigned int values > 0x7FFFFFFF which are handed to default_apic_id_valid(). As a consequence, invalid APIC IDs in !X2APIC mode are considered valid and accounted as possible CPUs. Change the apicid argument type of the apic_id_valid() callback to u32 so the evaluation is unsigned and returns the correct result. [ tglx: Massaged changelog ] Signed-off-by: Li RongQing <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Dou Liyang <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2017-09-25x86/apic: Remove unused callbacksThomas Gleixner1-48/+0
Now that the old allocator is gone, these apic functions are unused. Remove them. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Yu Chen <[email protected]> Acked-by: Juergen Gross <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Tony Luck <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Alok Kataria <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rui Zhang <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Dan Williams <[email protected]> Cc: Len Brown <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2017-09-25x86/apic: Add replacement for cpu_mask_to_apicid()Thomas Gleixner1-0/+10
As preparation for replacing the vector allocator, provide a new function which takes a cpu number instead of a cpu mask to calculate/lookup the resulting APIC destination id. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Yu Chen <[email protected]> Acked-by: Juergen Gross <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Tony Luck <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Alok Kataria <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rui Zhang <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Dan Williams <[email protected]> Cc: Len Brown <[email protected]>
2017-09-25x86/apic: Get rid of apic->target_cpusThomas Gleixner1-14/+0
The target_cpus() callback of the apic struct is not really useful. Some APICs return cpu_online_mask and others cpus_all_mask. The latter is bogus as it does not take holes in the cpus_possible_mask into account. Replace it with cpus_online_mask which makes the most sense and remove the callback. The usage sites will be removed in a later step anyway, so get rid of it now to have incremental changes. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Yu Chen <[email protected]> Acked-by: Juergen Gross <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Tony Luck <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Alok Kataria <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rui Zhang <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Dan Williams <[email protected]> Cc: Len Brown <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2017-09-25x86/apic: Move common APIC callbacksThomas Gleixner1-0/+78
Move more apic struct specific functions out of the header and the apic management code into the common source file. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Yu Chen <[email protected]> Acked-by: Juergen Gross <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Tony Luck <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Alok Kataria <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rui Zhang <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Dan Williams <[email protected]> Cc: Len Brown <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2017-09-25x86/apic: Sanitize 32/64bit APIC callbacksThomas Gleixner1-0/+20
The 32bit and the 64bit implementation of default_cpu_present_to_apicid() and default_check_phys_apicid_present() are exactly the same, but implemented and located differently. Move them to common apic code and get rid of the pointless difference. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Yu Chen <[email protected]> Acked-by: Juergen Gross <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Tony Luck <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Alok Kataria <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Rui Zhang <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Dan Williams <[email protected]> Cc: Len Brown <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.