Xen project Mailing List

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?

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

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).

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?

Jan

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.

Eric

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