[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.