Re: [Xen-devel] [PATCH 2/3] x86/msr: Definitions for MSR_INTEL_CORE_THREAD_COUNT

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 04/15/19 10:30 AM >>>
>On 15/04/2019 09:09, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 04/13/19 6:22 PM 

>>>--- a/xen/arch/x86/msr.c+++ b/xen/arch/x86/msr.c
>>> @@ -131,6 +131,7 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
>>> uint64_t *val)
>>> case MSR_PRED_CMD:
>>> case MSR_FLUSH_CMD:
>>> /* Write-only */
>>> +    case MSR_INTEL_CORE_THREAD_COUNT:
>>> case MSR_TSX_FORCE_ABORT:
>>> /* Not offered to guests. */
>>> goto gp_fault;
>> In a private talk we had, didn't you mention there is at least one OS (was 
>> it OSX)
>> that unconditionally ready this MSR? Despite assuming there are other issues
>> with OSX, wouldn't it be better to avoid giving #GP(0) back here? I realize 
>> we can't
>> yet give back a fully consistent value here, looking at what conclusions 
>> Linux
>> draws from other CPUID output, couldn't 0x00010001 be used as "fake" value?
>
>I did consider that option, but for anyone looking at this MSR, it is
>likely to make the situation worse rather than better.
>
>The other option to consider is retaining the current leaky behaviour. 
>There haven't been obvious problems thus far, and the accurate topology
>information is going to be arriving shortly to mesh in with the core
>scheduling work.

Imo this would still be better than delivering #GP(0).

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel