[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/cpuid: Deal with broken firmware once more





On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:

I found out that my domU kernels invoke the 'apic_disable' function
because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
which would cause the 'smp_found_config' bit to be unset at boot-up.


smp_found_config is not the problem, it is usually zero for Xen PV guests.

What is the problem is that because of your particular config selection acpi_mps_check() fails (with the error message that you mention below) and that leads to X86_FEATURE_APIC being cleared. And then we indeed switch to APIC noop and things go south after that.

-boris


This would cause 'init_apic_mappings' to call 'apic_disable', which
would cause Xen's 'apic' ops structure pointer to be replaced with the
no-op APIC ops structure's pointer.

The use of the no-op APIC ops structure would in turn cause invalid
virtual CPU package identifiers to be generated. Invalid CPU package
identifiers would in turn cause the RAPL module to produce a kernel oops
due to potentially missing error handling.

It looks like I have been ignoring the following kernel warning which I
should have noticed a long time ago:

  MPS support code is not built-in.
  Using acpi=off or acpi=noirq or pci=noacpi may have problem

To all on this e-mail thread, I learned a bit through this exercise, but
I have also taken a lot of everyone's time and created quite a bit of
e-mail traffic because of a kernel configuration issue on my end.

My apologies.

Vefa


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.