[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH] x86/AMD: adjust SYSCFG, TOM, etc exposure to deal with running nested
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 13 Jul 2021 09:22:33 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YGOrdCOMlh6d+dkgExNRzWBXwcOU2OHQ/LG4J2hiiWs=; b=j/8Sjhf1ejpXy6HWlhZIWWspJX1z1ZJ5kw9SvW19+mCWrmFQyhtfrTu1UkakcWX4AO1n4C6J0Y1yUclT8r3qFzW/nbkdlSIZnLlQkpVEgSwgSAH790sXeTxBAiK6Uj0/Kk3do6HoAsGhskdq4OPvDCzdbryyFwoivHRQ9HY9Kxs+BAqYinU5vGheEy0BMN5NtH5ITYCKpMvdFlSBJXzPkGoJpI4xNlhJ8wZAkQP7sxJWBeuse7lsBl8WZzcsQD7Y9PTY5XMxrYZWiLwyQyMk5IMbMz2BbJoyd+LJpFm7LKuVbqtww2TIOUDWPtXYHTYbpj+hwOnrNX6G7m6q7oQn2Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LdhKHY3PW+71sqJ4yTILHf+KO+y32UQINGuv0diXdfM2krUWHwMQWvQdlxcQmpi3k26oALUKQXgXaoeXHrGQcYYm/b0QwhjmYKXbUMftD9fjEKRTWWXdQzxaPSgzWWCiaJm8/6m6u9qXI9KphFsYZtdQMWZeRoilsjRigfmz9Ez+oEeyGuVcmLUv4JxbavuzlDIOAE/xQ/e9S40kuK6Exi43918Yomh+NYt+5fSSDg5pR6WkjR6BtmuWflqUEd+M9pvaM0LoSmemKLfDalxDYhyMJf+779ojw3EziXbRxojeJfkUxS/+YS/2RteyLbD2hCpmFjTxT65hDqRxQGdCSQ==
- Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 13 Jul 2021 07:22:51 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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>
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -367,7 +367,8 @@ int guest_rdmsr(struct vcpu *v, uint32_t
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);
|
