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/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?


Nevertheless if you're convinced it should be this way, and if this doesn't 
actively
break any guest OS (due to introducing this as the _only_ thing causing their 
boot
to fail)

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


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