RE: [Xen-devel] Problems with enabling hypervisor C and P-statecontrol

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] 
>Sent: Friday, October 24, 2008 4:31 PM
>> 
>> Niraj, one more info here. From your log, cpus on your platform
>> are actually indexed by:
>> package 1 (0, 4, 8, 12)
>> package 2 (1, 5, 9, 13)
>> package 3 (2, 6, 10, 14)
>> package 4 (3, 7, 11, 15)
>> 
>> thus cpu0/1/2/3 actually indicates 1st core in each package,
>> instead of 4 cores in 1st package. :-)
>
>We really ought to have code in Xen to make the enumeration consistent
>regardless of the BIOS order. I don't really care whether its
>sockets/cores/threads or threads/cores/sockets, but we really ought to
>be consistent.

If Xen wants to be consistent with one policy, as you suggested, it 
requires core/thread info known before booting APs, and then take 
that info in alloc_cpu_id. However core/thread info can be only 
acquired on AP by CPUID and sibling/core map can be constructed
after all APs are booted. Then you may need a temporary cpu id
allocated and then switch it to a real one later. This looks a bit
messed on some arrays[NR_CPUS]. Is it worthy of doing that way,
or just expose the mapping between xen cpu id and sockets/cores/
threads?

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