From 471383ddd1843700fdd7d74242ba0e5f314dc678 Mon Sep 17 00:00:00 2001 From: Jan Beulich Date: Mon, 19 Jul 2021 12:28:50 +0200 Subject: [PATCH] x86/AMD: adjust SYSCFG, TOM, etc exposure to deal with running nested In the original change I neglected to consider the case of us running as L1 under another Xen. In this case we're not Dom0, so the underlying Xen wouldn't permit us access to these MSRs. As an immediate workaround use rdmsr_safe(); I don't view this as the final solution though, as the original problem the earlier change tried to address also applies when running nested. Yet it is then unclear to me how to properly address the issue: We shouldn't generally expose the MSR values, but handing back zero (or effectively any other static value) doesn't look appropriate either. Fixes: bfcdaae9c210 ("x86/AMD: expose SYSCFG, TOM, TOM2, and IORRs to Dom0") Signed-off-by: Jan Beulich Reviewed-by: Julien Grall --- xen/arch/x86/msr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 650d060b12..b834456c7b 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -367,7 +367,8 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) goto gp_fault; if ( !is_hardware_domain(d) ) return X86EMUL_UNHANDLEABLE; - rdmsrl(msr, *val); + if ( rdmsr_safe(msr, *val) ) + goto gp_fault; if ( msr == MSR_K8_SYSCFG ) *val &= (SYSCFG_TOM2_FORCE_WB | SYSCFG_MTRR_TOM2_EN | SYSCFG_MTRR_VAR_DRAM_EN | SYSCFG_MTRR_FIX_DRAM_EN); -- 2.30.2