[Xen-devel] RE: [osrc-patches] [PATCH] libxc: remove CPUID core information mangling

["Huang2, Wei" <Wei.Huang2@xxxxxxx>]

Few comments on this patch. 

* First, AMD CPUID:0x80000008:ECX[NC(7:0)] should match with the total number 
of cores (VCPUS) assigned to guest VM. Assigning 0xff to NC is a bit scary to 
me. According to AMD CPUID spec, NC represents the "actually implemented or 
enabled on the processor, as indicated by CPUID Fn8000_0008_ECX[NC]". Most OS 
doesn't enforce this check; but I saw our internal test program does that. 
* I am OK 80000008:ECX[15:12] change. But this change has an implication that 
all cores (VCPUS) are on the same physical processor. OS might not care about 
these bits. But this ought to be set correctly in my mind.

-----Original Message-----
From: osrc-patches-bounces@xxxxxxxxxxxx 
[mailto:osrc-patches-bounces@xxxxxxxxxxxx] On Behalf Of Andre Przywara
Sent: Wednesday, August 25, 2010 7:04 AM
To: Keir Fraser; Nitin Kamble
Cc: xen-devel
Subject: [osrc-patches] [PATCH] libxc: remove CPUID core information mangling

Hi,

c/s 18560:782599274bf9ae8857c55856c9c7fdf082967808 introduced CPUID mangling 
resulting in a doubled number of cores/processor exposed to the guest. 
According to comments in this patch the rationale behind this is to match the 
APIC numbering used by Xen.
In my understanding the CPUID leafs dealing with number of cores always talk 
about logical numbers and not APIC IDs. So we don't need to adjust the CPUID 
readout to match the APIC ID enumeration scheme.
If there were any serious reasons resulting in the old patch I'd love to hear 
them.

The attached patch fixes this and solves an issue I saw with certain NUMA guest 
configurations.

Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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