| Message ID | fe4a713b-b6c7-bcd2-b5b5-1359532617d6@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 26/01/17 19:12, Mohit Gambhir wrote: > This patch fixes the following warning message seen when booting the > kernel as Dom0 with Xen on Intel machines. > > [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1] > > The code generating the warning in validate_apic_and_package_id() matches > cpu_data(cpu).apicid (initialized in init_intel()-> > detect_extended_topology() using cpuid) against the apicid returned from > xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid > for the boot cpu but returns 0 otherwise. Hence the warning gets thrown > for all but the boot cpu. > > The idea behind xen_apic_read() returning 0 for apicid is that the > guests (even Dom0) should not need to know what physical processor their > vcpus are running on. This is because we currently do not have topology > information in Xen and also because xen allows more vcpus than physical > processors. However, boot cpu's apicid is required for loading > xen-acpi-processor driver on AMD machines. Look at following patch for > details: > > commit 558daa289a40 ("xen/apic: Return the APIC ID (and version) for CPU > 0.") > > So to get rid of the warning, this patch modifies > xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of > calling xen_apic_read(). > > The warning is not seen on AMD machines because init_amd() populates > cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read() > as opposed to using apicid from cpuid as is done on Intel machines. > > Signed-off-by: Mohit Gambhir <mohit.gambhir@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Thanks, Juergen
On 01/26/2017 01:12 PM, Mohit Gambhir wrote: > This patch fixes the following warning message seen when booting the > kernel as Dom0 with Xen on Intel machines. > > [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1] > > The code generating the warning in validate_apic_and_package_id() matches > cpu_data(cpu).apicid (initialized in init_intel()-> > detect_extended_topology() using cpuid) against the apicid returned from > xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid > for the boot cpu but returns 0 otherwise. Hence the warning gets thrown > for all but the boot cpu. > > The idea behind xen_apic_read() returning 0 for apicid is that the > guests (even Dom0) should not need to know what physical processor their > vcpus are running on. This is because we currently do not have topology > information in Xen and also because xen allows more vcpus than physical > processors. However, boot cpu's apicid is required for loading > xen-acpi-processor driver on AMD machines. Look at following patch for > details: > > commit 558daa289a40 ("xen/apic: Return the APIC ID (and version) for CPU > 0.") > > So to get rid of the warning, this patch modifies > xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of > calling xen_apic_read(). > > The warning is not seen on AMD machines because init_amd() populates > cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read() > as opposed to using apicid from cpuid as is done on Intel machines. > > Signed-off-by: Mohit Gambhir <mohit.gambhir@oracle.com> Applied to for-linus-4.11. -boris
diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c index 44c88ad..bcea81f 100644 --- a/arch/x86/xen/apic.c +++ b/arch/x86/xen/apic.c @@ -145,7 +145,7 @@ static void xen_silent_inquire(int apicid) static int xen_cpu_present_to_apicid(int cpu) { if (cpu_present(cpu)) - return xen_get_apic_id(xen_apic_read(APIC_ID)); + return cpu_data(cpu).apicid; else return BAD_APICID; }
This patch fixes the following warning message seen when booting the kernel as Dom0 with Xen on Intel machines. [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1] The code generating the warning in validate_apic_and_package_id() matches cpu_data(cpu).apicid (initialized in init_intel()-> detect_extended_topology() using cpuid) against the apicid returned from xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid for the boot cpu but returns 0 otherwise. Hence the warning gets thrown for all but the boot cpu. The idea behind xen_apic_read() returning 0 for apicid is that the guests (even Dom0) should not need to know what physical processor their vcpus are running on. This is because we currently do not have topology information in Xen and also because xen allows more vcpus than physical processors. However, boot cpu's apicid is required for loading xen-acpi-processor driver on AMD machines. Look at following patch for details: commit 558daa289a40 ("xen/apic: Return the APIC ID (and version) for CPU 0.") So to get rid of the warning, this patch modifies xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of calling xen_apic_read(). The warning is not seen on AMD machines because init_amd() populates cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read() as opposed to using apicid from cpuid as is done on Intel machines. Signed-off-by: Mohit Gambhir <mohit.gambhir@oracle.com> --- arch/x86/xen/apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)