>>> Andrew Cooper <andrew.coop...@citrix.com> 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 <jbeul...@suse.com> Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
