Messages in this thread | | | Subject | Re: [PATCH v2] x86/smpboot: Make logical package management more robust | From | Boris Ostrovsky <> | Date | Mon, 12 Dec 2016 14:07:54 -0500 |
| |
On 12/12/2016 05:04 AM, Thomas Gleixner wrote: > The logical package management has several issues: > > - The APIC ids provided by ACPI are not required to be the same as the > initial APIC id which can be retrieved by CPUID. The APIC ids provided > by ACPI are those which are written by the BIOS into the APIC. The > initial id is set by hardware and can not be changed. The hardware > provided ids contain the real hardware package information. > > Especially AMD sets the effective APIC id different from the hardware id > as they need to reserve space for the IOAPIC ids starting at id 0. > > As a consequence those machines trigger the currently active firmware > bug printouts in dmesg, These are obviously wrong. > > - Virtual machines have their own interesting of enumerating APICs and > packages which are not reliably covered by the current implementation. > > The sizing of the mapping array has been tweaked to be generously large to > handle systems which provide a wrong core count when HT is disabled so the > whole magic which checks for space in the physical hotplug case is not > needed anymore. > > Simplify the whole machinery and do the mapping when the CPU starts and the > CPUID derived physical package information is available. This solves the > observed problems on AMD machines and works for the virtualization issues > as well. > > Remove the extra call from XEN cpu bringup code as it is not longer > required. > > Fixes: d49597fd3bc7 ("x86/cpu: Deal with broken firmware (VMWare/XEN)") > Reported-and-tested-by: Borislav Petkov <bp@suse.de> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Cc: stable@vger.kernel.org
For Xen:
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
(Note that we still have [Firmware Bug]: CPU13: APIC id mismatch. Firmware: 0 APIC: d but that will be fixed in Xen code.)
-boris
| |