From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH v2 1/2] x86/AMD: expose SYSCFG, TOM, TOM2, and IORRs to Dom0
Date: Fri, 28 May 2021 08:56:54 +0200 [thread overview]
Message-ID: <c6952f53-aecb-542d-94a5-a1547dd4d6c4@suse.com> (raw)
In-Reply-To: <ebc58213-f68a-e060-83f5-c9c89a87f074@suse.com>
Sufficiently old Linux (3.12-ish) accesses these MSRs (with the
exception of IORRs) in an unguarded manner. Furthermore these same MSRs,
at least on Fam11 and older CPUs, are also consulted by modern Linux,
and their (bogus) built-in zapping of #GP faults from MSR accesses leads
to it effectively reading zero instead of the intended values, which are
relevant for PCI BAR placement (which ought to all live in MMIO-type
space, not in DRAM-type one).
For SYSCFG, only certain bits get exposed. Since MtrrVarDramEn also
covers the IORRs, expose them as well. Introduce (consistently named)
constants for the bits we're interested in and use them in pre-existing
code as well. While there also drop the unused and somewhat questionable
K8_MTRR_RDMEM_WRMEM_MASK. To complete the set of memory type and DRAM vs
MMIO controlling MSRs, also expose TSEG_{BASE,MASK} (the former also
gets read by Linux, dealing with which was already the subject of
6eef0a99262c ["x86/PV: conditionally avoid raising #GP for early guest
MSR reads"]).
As a welcome side effect, verbosity on/of debug builds gets (perhaps
significantly) reduced.
Note that at least as far as those MSR accesses by Linux are concerned,
there's no similar issue for DomU-s, as the accesses sit behind PCI
device matching logic. The checked for devices would never be exposed to
DomU-s in the first place. Nevertheless I think that at least for HVM we
should return sensible values, not 0 (as svm_msr_read_intercept() does
right now). The intended values may, however, need to be determined by
hvmloader, and then get made known to Xen.
Fixes: 322ec7c89f66 ("x86/pv: disallow access to unknown MSRs")
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Also permit IORRs and their TSEG counterparts to be read. Drop
K8_MTRR_RDMEM_WRMEM_MASK.
---
TBD: For PVH, we might grant Dom0 direct read access to the MSR (maybe
except SYSCFG).
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -468,14 +468,14 @@ static void check_syscfg_dram_mod_en(voi
return;
rdmsrl(MSR_K8_SYSCFG, syscfg);
- if (!(syscfg & K8_MTRRFIXRANGE_DRAM_MODIFY))
+ if (!(syscfg & SYSCFG_MTRR_FIX_DRAM_MOD_EN))
return;
if (!test_and_set_bool(printed))
printk(KERN_ERR "MTRR: SYSCFG[MtrrFixDramModEn] not "
"cleared by BIOS, clearing this bit\n");
- syscfg &= ~K8_MTRRFIXRANGE_DRAM_MODIFY;
+ syscfg &= ~SYSCFG_MTRR_FIX_DRAM_MOD_EN;
wrmsrl(MSR_K8_SYSCFG, syscfg);
}
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -224,7 +224,7 @@ static void __init print_mtrr_state(cons
uint64_t syscfg, tom2;
rdmsrl(MSR_K8_SYSCFG, syscfg);
- if (syscfg & (1 << 21)) {
+ if (syscfg & SYSCFG_MTRR_TOM2_EN) {
rdmsrl(MSR_K8_TOP_MEM2, tom2);
printk("%sTOM2: %012"PRIx64"%s\n", level, tom2,
syscfg & (1 << 22) ? " (WB)" : "");
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -339,6 +339,25 @@ int guest_rdmsr(struct vcpu *v, uint32_t
*val = msrs->tsc_aux;
break;
+ case MSR_K8_SYSCFG:
+ case MSR_K8_TOP_MEM1:
+ case MSR_K8_TOP_MEM2:
+ case MSR_K8_IORR_BASE0:
+ case MSR_K8_IORR_MASK0:
+ case MSR_K8_IORR_BASE1:
+ case MSR_K8_IORR_MASK1:
+ case MSR_K8_TSEG_BASE:
+ case MSR_K8_TSEG_MASK:
+ if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
+ goto gp_fault;
+ if ( !is_hardware_domain(d) )
+ return X86EMUL_UNHANDLEABLE;
+ rdmsrl(msr, *val);
+ if ( msr == MSR_K8_SYSCFG )
+ *val &= (SYSCFG_TOM2_FORCE_WB | SYSCFG_MTRR_TOM2_EN |
+ SYSCFG_MTRR_VAR_DRAM_EN | SYSCFG_MTRR_FIX_DRAM_EN);
+ break;
+
case MSR_K8_HWCR:
if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
goto gp_fault;
--- a/xen/arch/x86/x86_64/mmconf-fam10h.c
+++ b/xen/arch/x86/x86_64/mmconf-fam10h.c
@@ -69,7 +69,7 @@ static void __init get_fam10h_pci_mmconf
rdmsrl(address, val);
/* TOP_MEM2 is not enabled? */
- if (!(val & (1<<21))) {
+ if (!(val & SYSCFG_MTRR_TOM2_EN)) {
tom2 = 1ULL << 32;
} else {
/* TOP_MEM2 */
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -116,6 +116,21 @@
#define PASID_PASID_MASK 0x000fffff
#define PASID_VALID (_AC(1, ULL) << 31)
+#define MSR_K8_SYSCFG 0xc0010010
+#define SYSCFG_MTRR_FIX_DRAM_EN (_AC(1, ULL) << 18)
+#define SYSCFG_MTRR_FIX_DRAM_MOD_EN (_AC(1, ULL) << 19)
+#define SYSCFG_MTRR_VAR_DRAM_EN (_AC(1, ULL) << 20)
+#define SYSCFG_MTRR_TOM2_EN (_AC(1, ULL) << 21)
+#define SYSCFG_TOM2_FORCE_WB (_AC(1, ULL) << 22)
+
+#define MSR_K8_IORR_BASE0 0xc0010016
+#define MSR_K8_IORR_MASK0 0xc0010017
+#define MSR_K8_IORR_BASE1 0xc0010018
+#define MSR_K8_IORR_MASK1 0xc0010019
+
+#define MSR_K8_TSEG_BASE 0xc0010112 /* AMD doc: SMMAddr */
+#define MSR_K8_TSEG_MASK 0xc0010113 /* AMD doc: SMMMask */
+
#define MSR_K8_VM_CR 0xc0010114
#define VM_CR_INIT_REDIRECTION (_AC(1, ULL) << 1)
#define VM_CR_SVM_DISABLE (_AC(1, ULL) << 4)
@@ -279,11 +294,6 @@
#define MSR_K8_TOP_MEM1 0xc001001a
#define MSR_K7_CLK_CTL 0xc001001b
#define MSR_K8_TOP_MEM2 0xc001001d
-#define MSR_K8_SYSCFG 0xc0010010
-
-#define K8_MTRRFIXRANGE_DRAM_ENABLE 0x00040000 /* MtrrFixDramEn bit */
-#define K8_MTRRFIXRANGE_DRAM_MODIFY 0x00080000 /* MtrrFixDramModEn bit */
-#define K8_MTRR_RDMEM_WRMEM_MASK 0x18181818 /* Mask: RdMem|WrMem */
#define MSR_K7_HWCR 0xc0010015
#define MSR_K8_HWCR 0xc0010015
next prev parent reply other threads:[~2021-05-28 6:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 6:56 [PATCH v2 0/2] x86/AMD: MSR handling adjustments Jan Beulich
2021-05-28 6:56 ` Jan Beulich [this message]
2021-05-28 6:57 ` [PATCH v2 2/2] x86/AMD: drop MSR_K7_HWCR Jan Beulich
2021-06-24 15:29 ` Ping: [PATCH v2 0/2] x86/AMD: MSR handling adjustments Jan Beulich
2021-07-06 7:18 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c6952f53-aecb-542d-94a5-a1547dd4d6c4@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).