Re: [Xen-devel] What is the target CPU "topology" of an SMP HVM machine?

[Eric Shelton <eshelton@xxxxxxxxx>]

On Wed, Aug 14, 2013 at 4:06 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> On 14/08/13 20:23, Eric Shelton wrote:
>> In doing some work to run OS X under Xen on my MacBook Air 2012 (Ivy
>> Bridge), I ran into some issues in Darwin's probing of what it refers
>> to as the CPU topology.  Although the Darwin kernel may make certain
>> assumptions about the platforms on which it is being run, it
>> nevertheless appears the various values Xen returns via CPUID and MSR
>> are not wholly consistent.  For example, when I configured the domain
>> to have only 1 vcpu, Darwin was still able to infer that the system
>> had multiple processors (maybe even the correct numbers of cores and
>> processors).
>
> The extended model name is passed through from the real CPU, so Darwin
> could easily be working on logic such as "I have found a CPU which
> claims to be this type of IvyBridge - I know it has these details"

In this case, I do not have that kind of a table lookup problem.  The
kernel source indicates that values obtained via CPUID and MSR are
being used to make these determinations.  The Ivy Bridge model id also
triggers reading from MSRs 0x35, 0xCE, and 0x194; and CPUID leaf 7.
MSR 0x35 is the one that affects the topology calculations.

> Xen by default advertises all VCPUs as separate sockets, to try and
> dissuade "clever" schedulers from doing dumb things based on false
> information.

I think OS X has such a scheduler, and I imagine moreso with the next
rev (10.9), which has some new emphasis on power consumption.

>> In addition to CPUID and MSR, does any of this get reflected in the
>> ACPI tables?  Also, is there a presumed relationship between the
>> number of dies or cores and the number of HPET comparators to be
>> concerned with?
>
> There is a distinct lack of consistency between the various mechanisms.
> The ACPI tables are essentially static from build time.

Although it may be nontrivial to do runtime generation or modification
of the ACPI tables, are there any specific items in the ACPI tables
that come to mind which maybe should vary according to the number of
CPUs for better consistency?  Having 256 CPU entries seems to be
harmless.

> From a quick glance at the documentation, there are several different
> generations of processors which use MSR 0x35 for different purposes,
> although it does appear to be somewhat common as performance counters of
> one form or another.
>
> What reference are you using to find out that this msr provides topology
> information?

From review of the kernel source (osfmk/i386/cpuid.c), which indicates
for MSR 0x35 that on Westmere bits 19-16 are the core count, and bits
15-0 are the thread count; on Nehalem, Sandy Bridge, and Ivy Bridge
bits 31-16 are the core count, and 15-0 are the thread count.  There
is no indication as to what the other bits are (eg, the performance
counters you mentioned).  My Core i5 returns 0x00020004 in the lower
32 bits.  It sounds like in an HVM both of these bit ranges should be
equal to the number of vcpus.

> It would certainly be a good project to try and make this information
> more consistent and easier to configure.

I'm looking at least to have a few more of the CPUID and MSR values
line up with the number of vcpus and their simple topology, and see
where I end up.
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/
appears to give a good amount of information as to what values are
involved.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel