- 09 Aug, 2023 37 commits
-
-
Thomas Gleixner authored
Remove tons of NOOP callbacks by making the invocation of safe_wait_icr_idle() conditional in the inline wrapper. Will be replaced by a static_call_cond() later. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by:
Michael Kelley <mikelley@microsoft.com> Tested-by:
Sohil Mehta <sohil.mehta@intel.com> Tested-by: Juergen Gross <jgross@suse.com> # Xen PV (dom0 and unpriv. guest)
-
Thomas Gleixner authored
Nuke more NOOP callbacks and make the invocation conditional. Will be replaced with a static call later. Signed-off-by:
-
Thomas Gleixner authored
Two copies and also needlessly public. Move it into ipi.c so it can be inlined. Rename it to apic_mem_wait_icr_idle(). Signed-off-by:
-
Thomas Gleixner authored
Replace the undecodable comment on top of the function, replace the space consuming zero content comments with useful ones and tidy up the implementation to prevent further eye bleed. Make __default_send_IPI_shortcut() static as it has no other users. Signed-off-by:
-
Thomas Gleixner authored
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 authored
default_setup_apic_routing() is a complete misnomer. On 64bit it does the actual APIC probing and on 32bit it is used to force select the bigsmp APIC and to emit a redundant message in the apic::setup_apic_routing() callback. Rename the 64bit and 32bit function so they reflect what they are doing and remove the useless APIC callback. Signed-off-by:
-
Thomas Gleixner authored
The operation to set the IOAPIC ID in phys_id_present_map is as convoluted as it can be. 1) Allocate a bitmap of 32byte size on the stack 2) Zero the bitmap and set the IOAPIC ID bit 3) Or the temporary bitmap over phys_id_present_map The same functionality can be achieved by setting the IOAPIC ID bit directly in the phys_id_present_map. Signed-off-by:
-
Thomas Gleixner authored
This is only used on 32bit and is a wrapper around physid_set_mask_of_physid() in all 32bit APIC drivers. Remove the callback and use physid_set_mask_of_physid() in the code directly, Signed-off-by:
-
Thomas Gleixner authored
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 authored
It's a copy of default_cpu_present_to_apicid() with the omission of the actual check whether the CPU is present. This APIC callback should die completely, but the XEN APIC implementation does something different which needs to be addressed first. Signed-off-by:
-
Thomas Gleixner authored
If the system has more than 8 CPUs then XAPIC and the bigsmp APIC driver is required. This is ensured via: 1) Enumerating all possible CPUs up to NR_CPUS 2) Checking at boot CPU APIC setup time whether the system has more than 8 CPUs and has an XAPIC. If that's the case then it's attempted to install the bigsmp APIC driver and a magic variable 'def_to_bigsmp' is set to one. 3) If that magic variable is set and CONFIG_X86_BIGSMP=n and the system has more than 8 CPUs smp_sanity_check() removes all CPUs >= #8 from the present and possible mask in the most convoluted way. This logic is completely broken for the case where the bigsmp driver is enabled, but not selected due to a command line option specifying the default APIC. In that case the system boots with default APIC in logical destination mode and fails to reduce the number of CPUs. That aside the above which is sprinkled over 3 different places is yet another piece of art. It would have been too obvious to check the requirements upfront and limit nr_cpu_ids _before_ enumerating tons of CPUs and then removing them again. Implement exactly this. Check the bigsmp requirement when the boot APIC is registered which happens _before_ ACPI/MPTABLE parsing and limit the number of CPUs to 8 if it can't be used. Switch it over when the boot CPU apic is set up if necessary. [ dhansen: fix nr_cpu_ids off-by-one in default_setup_apic_routing() ] Signed-off-by: -
Thomas Gleixner authored
On 32bit there is no APIC implementing the acpi_madt_oem_check() except XEN PV, but that does not matter at all. generic_apic_probe() runs before ACPI tables are parsed. This selects the XEN APIC if there is no command line override because the XEN APIC driver is the first to be probed. If there is a command line override then the XEN PV driver won't be selected in the MADT OEM check either. As there is no other MADT check implemented for 32bit APICs, this whole excercise is a NOOP and can be removed. Signed-off-by:
-
Thomas Gleixner authored
UV X2APIC uses the per CPU variable from: native_smp_prepare_cpus() uv_system_init() uv_system_init_hub() which is long after the per CPU areas have been set up. Signed-off-by: -
Thomas Gleixner authored
Remove completely useless and mindlessly copied comments and tidy up the code which causes eye bleed when looking at it. Signed-off-by:
-
Thomas Gleixner authored
This per CPU variable is just yet another form of voodoo programming. The boot ordering is: per_cpu(x86_cpu_to_logical_apicid, cpu) = 1U << cpu; ..... setup_apic() apic->init_apic_ldr() default_init_apic_ldr() apic_write(SET_APIC_LOGICAL_ID(1UL << smp_processor_id(), APIC_LDR); id = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR); WARN_ON(id != per_cpu(x86_cpu_to_logical_apicid, cpu)); per_cpu(x86_cpu_to_logical_apicid, cpu) = id; So first write the default into LDR and then validate it against the same default which was set up during early boot APIC enumeration. Brilliant, isn't it? The comment above the per CPU variable declaration describes it well: 'Let's keep it ugly for now.' Remove the useless gunk and use '1U << cpu' consistently all over the place. Signed-off-by: -
Thomas Gleixner authored
apic::x86_32_early_logical_apicid() is yet another historical joke. It is used to preset the x86_cpu_to_logical_apicid per CPU variable during APIC enumeration with: - 1 shifted left by the CPU number - the physical APIC ID in case of bigsmp The latter is hillarious because bigsmp uses physical destination mode which never can use the logical APIC ID. It gets even worse. As bigsmp can be enforced late in the boot process the probe function overwrites the per CPU variable which is never used for this APIC type once again. Remove that gunk and store 1 << cpunr unconditionally if and only if the CPU number is less than 8, because the default logical destination mode only allows up to 8 CPUs. This is just an intermediate step before removing the per CPU insanity completely. Stay tuned. Signed-off-by:
-
Thomas Gleixner authored
No need for an extra variable to find out whether the APIC has been mapped or is accessible (X2APIC mode). Provide an inline for this and check apic_mmio_base which is only set when the local APIC has been mapped. Signed-off-by:
-
Thomas Gleixner authored
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 authored
The boot CPUs local APIC is now always registered, so there is no point to have another unreadable validatation for it. Signed-off-by:
-
Thomas Gleixner authored
num_processors is 0 by default and only gets incremented when local APICs are registered. Make init_apic_mappings(), which tries to enable the local APIC in the case that no SMP configuration was found set num_processors to 1. This allows to remove yet another check for the local APIC and yet another place which registers the boot CPUs local APIC ID. Signed-off-by:
-
Thomas Gleixner authored
Unlike all other SMP configuration "parsers" XEN/PV does not set smp_found_config which is inconsistent and prevents doing proper decision logic based on this flag. Make XEN/PV pretend that it found SMP configuration. Signed-off-by:
-
Thomas Gleixner authored
Convert places which just write mp_lapic_addr and let them register the local APIC address directly instead of relying on magic other code to do so. Add a WARN_ON() into register_lapic_address() which is raised when register_lapic_address() is invoked more than once during boot. Signed-off-by:
-
Thomas Gleixner authored
Split the fixmap setup out of register_lapic_address() and reuse it when the X2APIC is disabled during setup. This avoids registering the APIC ID (setting 'mp_lapic_addr') twice. [ dhansen: changelog wording tweak ] Signed-off-by:
-
Thomas Gleixner authored
Quite some APIC init functions are pure boolean, but use the success = 0, fail < 0 model. That's confusing as hell when reading through the code. Convert them to boolean. Signed-off-by:
-
Thomas Gleixner authored
The device tree APIC parser tries to force-enable the local APIC when it is not set in CPUID. apic_force_enable() registers the boot CPU apic on success. If that succeeds then dtb_lapic_setup() registers the local APIC again eventually with a different address. Rewrite the code so that it only registers it once. Signed-off-by:
-
Dave Hansen authored
From: Dave Hansen <dave.hansen@linux.intel.com> Some truly ancient code had different ways of calculating the 'apicid' but it is long gone. Zap the unnecssary local variablee Signed-off-by: -
Thomas Gleixner authored
This historical leftover is really uninteresting today. Whatever MPTABLE or MADT delivers we only trust the hardware anyway. Signed-off-by:
-
Thomas Gleixner authored
Register the boot CPU APIC right when the boot CPUs APIC is read from the hardware. No point is doing this on random places and having wild heuristics to save the boot CPU APIC ID slot and CPU number 0 reserved. Signed-off-by:
-
Thomas Gleixner authored
boot_cpu_physical_apicid is written in random places and in the last consequence filled with the APIC ID read from the local APIC. That causes it to have inconsistent state when the MPTABLE is broken. As a consequence tons of moronic checks are sprinkled all over the place. Consolidate the code and read it exactly once when either X2APIC mode is detected early or when the APIC mapping is established. Signed-off-by:
-
Thomas Gleixner authored
Put it to the other historical leftovers. Signed-off-by:
-
Thomas Gleixner authored
max_physical_apicid is assigned but never read. Signed-off-by:
-
Thomas Gleixner authored
No point in having a wrapper around read_apic_id(). Signed-off-by:
-
Thomas Gleixner authored
It's a useless copy of x86_cpu_to_apicid. Signed-off-by:
-
Thomas Gleixner authored
Another variable name which is confusing at best. Convert to bool. Signed-off-by:
-
Thomas Gleixner authored
It reflects a state and not a command. Make it bool while at it. Signed-off-by:
-
Thomas Gleixner authored
Tons of silly unused bitmap wrappers... Signed-off-by:
-
Thomas Gleixner authored
It's not longer used outside the source file. Signed-off-by:
-
- 06 Aug, 2023 3 commits
-
-
Xin Li authored
IRQ_MOVE_CLEANUP_VECTOR is not longer in use. Remove the last traces. Signed-off-by:
Xin Li <xin3.li@intel.com> Signed-off-by:
-
Thomas Gleixner authored
The left overs of a moved interrupt are cleaned up once the interrupt is raised on the new target CPU. Keeping the vector valid on the original target CPU guarantees that there can't be an interrupt lost if the affinity change races with an concurrent interrupt from the device. This cleanup utilizes the lowest priority interrupt vector for this cleanup, which makes sure that in the unlikely case when the to be cleaned up interrupt is pending in the local APICs IRR the cleanup vector does not live lock. But there is no real reason to use an interrupt vector for cleaning up the leftovers of a moved interrupt. It's not a high performance operation. The only requirement is that it happens on the original target CPU. Convert it to use a timer instead and adjust the code accordingly. Signed-off-by:
-
Thomas Gleixner authored
Rename send_cleanup_vector() to vector_schedule_cleanup() to prepare for replacing the vector cleanup IPI with a timer callback. Signed-off-by:
Steve Wahl <steve.wahl@hpe.com> Link: https://lore.kernel.org/r/20230621171248.6805-2-xin3.li@intel.com
-
