Re: [Xen-devel] [PATCH][retry 2][1/2] new platform hypervisor call to get APICIDs

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Two major comments:

Firstly, if dom0_vcpus_pinned then you do *not* need a hypercall to fetch
the APICIDs. You can use CPUID on each VCPU to find the true underlying
APICID for that CPU (as enumerated by Xen). That is, unless you need the
apicid-cpu mapping before the VCPU is brought up. If you do keep the
hypercall then it would be a simpler interface to get one apicid at a time.
And I'd make it a vcpu_op, and error return could imply that vcpus are not
pinned (i.e., !dom0_vcpus_pinned, so use our existing bogo apicid-cpu
mapping). Actually, I quite like that interface...

Secondly, what about ACPIID-to-APICID mappings: doesn't
drivers/acpi/processor_core.c rely on that mapping array being set up? But
this patch doesn't introduce any setup of that array.

 -- Keir

On 3/3/08 21:40, "Mark Langsdorf" <mark.langsdorf@xxxxxxx> wrote:

> Some AMD machines have APIC IDs that not equal to CPU IDs.  In
> the default Xen configuration, ACPI calls on these machines
> can get confused.  This shows up most noticeably when running
> AMD PowerNow!.  The only solution is for dom0 to get the
> hypervisor's cpuid to apicid table when needed (ie, when dom0
> vcpus are pinned).
> 
> Add a new platform hypercall to Xen to allow dom0 to query the
> hypervisor for the actual cpuid to apicid table.
> 
> The second patch adds the dom0 call to this platform hypercall.
> 
> I have tested this on my 4p/16 core machine and it works.  I
> would appreciate testing on other boxes.



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