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

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

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Saturday, October 25, 2008 10:50 PM
>
>On 25/10/08 04:01, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>>> 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.
>
>Sort by LAPIC ID. The LAPIC ID is defined to be hierarchical, 
>so this would
>automatically get us sorting by thread then core then socket. 
>This could be
>as simple as arranging for the calls to mp_register_lapic() to 
>happen in the
>correct order.

calls to mp_register_lapic are initiated from acpi_parse_lapic,
which is a callback when one ACPI LAPIC entry is found. To
make it sorted, either delayed calls are required by caching
all found lapic entries, or re-order within mp_register_lapic.

Also how about BSP? If BSP is not thread0/core0/package0,
then all the rest sorting effort is just meaningless. :-(

>
>> 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?
>
>The mapping between flat identifier and socket/core/thread 
>should be made
>available, and/or modify tools to accept a hierarchical cpu 
>identifier in
>addition to the old-style flat identifier.
>

This is necessary information. Is there any existing interface reporting
similar info? If not, could you suggest which interface to carry? Tools
like xenpm may need to query such infro to construct a better summary.
If it's not there, we can consider to add.

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