Re: [Xen-devel] dom0 and apicid not equal to cpuid

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 11/2/08 22:38, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> wrote:

> It appears that the call to GET_APIC_ID() in
> mp_register_lapic_address() isn't legal for dom0, but the failure
> to make that call results in an incorrect cpu_to_apicid[] table
> and that means the acpiid_to_apicid[] table is also wrong.

The code in processor_core.c ultimately wants to convert acpiid to cpuid. I
think we're going to be in a confusing mess if we set up the
acpiid-apicid-cpuid relationships for anything other than a dom0_vcpu_pin'ed
system. So perhaps we should expose that configuration option to dom0 (so it
can tell whether it is pinned or not). If so, it can set up its mapping
arrays just like a native kernel (we can reinstate the code for this
purpose, and backport any fixes to it as necessary). In the non-pinned case
perhaps we should initialise all those arrays to -1 for sanity's sake.

The reason I think this is a rathole for the non-pinned case is that the
cpuid space of a non-pinned dom0 kernel has no consistent relationship with
underlying physical CPUs. So when the kernel decides to make use of that
cpu-apicid-acpiid relationship information, e.g., to change power states, it
will all go horribly wrong. Setting the mapping arrays to -1 is a way to try
and nobble the ACPI code paths in a reasonably well-defined manner.

Do you think you could do the Linux side of this in a reasonably clean
manner? You could provide a Linux kernel command-line option to specify
pinned/not-pinned for now if you like, and I would do the proper plumbing
through from Xen.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel