Re: [Xen-devel] [PATCH] x86/hvm: add support for MSR 0x35

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.09.14 at 18:02, <eshelton@xxxxxxxxx> wrote:
> On Wed, Sep 17, 2014 at 5:54 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 17.09.14 at 06:08, <eshelton@xxxxxxxxx> wrote:
>> > OS X interrogates MSR 0x35 to determine the number of enabled cores and
>> > threads, and will fail to boot if reasonable values are not returned.
>> > According to the OS X kernel source code (see osfmk/i386/cpuid.c), on
>> > Westmere bits 19:16 are the core count and bits 15:0 are the thread
>> > count, and on later families bits 31:16 are the core count and bits 15:0
>> > are the thread count.  VirtualBox returns similar values (see
>> > CPUMAllRegs.cpp).
>>
>> First of all - the title saying "MSR 0x35" is pretty meaningless.
>>
>> This is even more so that the MSR here doesn't appear to be
>> documented. It's not only not an architectural MSR (i.e. you
>> misnamed it in msr-index.h), I can't find _any_ mention of it in
>> Intel's SDM. Hence a minimal requirement for accepting a patch
>> like this is that you point us to existing (public) documentation.
>> The OS X kernel source is clearly not an acceptable source here.
>>
> 
> Sorry, the IA32 prefix would appear to be incorrect.  Elsewhere (such as
> the OS X Darwin source) the name MSR_CORE_THREAD_COUNT is used.  Is that
> acceptable?

Together with what you say further down, MSR_INTEL_CORE_THREAD_COUNT
would seem okay.

> You correctly note that MSR 35H is not described by Intel's SDM.  On the
> other hand, it is not the only MSR not set out in the SDM.
> For example, the family-specific CPUID masking-related MSRs, such as
> MSR_INTEL_MASK_V3_CPUID1, are not described by the SDM; instead it looks
> like Intel has described them in application notes.  For whatever reason,
> Intel seems to have not publicly documented the MSR, but presumably shared
> the info with Apple.  I have not been able to identify anything describing
> the MSR in greater detail than the Darwin source code (which at least sets
> out the bit fields).  Perhaps you will consider it a bit more authoritative
> that Intel's BITS (BIOS Implementation Test Suite) acknowledges use of MSR
> 0x35, as it does perform a check of MSR 0x35 as shown in the log at
> https://communities.intel.com/thread/30187?start=0&tstart=0 

Not really. We should get clarification from Intel on this - sadly you
didn't include any Intel person (namely none of the VMX maintainers)
on your Cc list, which I now changed.

>> And then, this being - presumably, according to your description
>> above - an Intel-specific MSR, why would we want to also emulate
>> it on SVM?
>>
> 
> After attempting a rdmsr(0x35) on an AMD system, it does indeed appear to
> be Intel-specific.  Code-wise, what do you see as a solution?  My first
> guess would be to review the vendor, family, and/or model info in struct
> cpuinfo_x86, and implement MSR 0x35 on Westmere and later Intel CPUs
> (although perhaps it is enough to just do a check for Intel).

Making it family/model specific would be ugly, in particular when it
comes to migration. Checking just Intel or moving the code into
VMX specific files would seem acceptable solutions.

>> Plus finally - isn't the information available through CPUID leaves?
>> If so, why would OS X not use this architectural way of getting
>> hold of the desired information?
>>
>> I agree that there are more conventional techniques for determining the
> system topology.  However, I cannot address _why_ the OS X developers chose
> this mechanism for collecting the information, nor do I expect it to be
> changed at my request.  I am simply stuck with the fact that they have used
> it, and that OS X fails to boot under Xen on at least a Sandy Bridge or
> newer without being told the number of vcpus via this MSR.  I suppose I
> might be able to work up a binary kernel patch of some sort (the Hackintosh
> folks did similar things for attempted writes to locked MSR 0xE2 on
> Haswell).  However, I assume there is interest in running a commercial
> operating system "as shipped", where reasonably possible.

Yes, certainly, but on the grounds of a little more than hearsay.

Jan

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