[xen staging] x86/AMD: adjust SYSCFG, TOM, etc exposure to deal with running nested

[patchbot@xxxxxxx]

commit 471383ddd1843700fdd7d74242ba0e5f314dc678
Author:     Jan Beulich <jbeulich@xxxxxxxx>
AuthorDate: Mon Jul 19 12:28:50 2021 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Jul 19 12:28:50 2021 +0200

    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 <jbeulich@xxxxxxxx>
    Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx>
---
 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);
--
generated by git-patchbot for /home/xen/git/xen.git#staging