From: Mingwei Zhang <mizhang@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, Mingwei Zhang <mizhang@google.com>
Subject: [kvm-unit-tests PATCH v2 2/2] x86: msr: testing MSR_IA32_FLUSH_CMD reserved bits only in KVM emulation
Date: Wed, 17 Apr 2024 23:29:06 +0000 [thread overview]
Message-ID: <20240417232906.3057638-3-mizhang@google.com> (raw)
In-Reply-To: <20240417232906.3057638-1-mizhang@google.com>
Avoid testing reserved bits of MSR_IA32_FLUSH_CMD in hardware. Since KVM
passes through the MSR at runtime, testing reserved bits directly on the HW
does not generate #GP in some older CPU models like skylake.
Ideally, it could be fixed by enumerating all such CPU models. The value
added is would be low. So just focus on testing bits when the KVM force
emulation is enabled. This is in a new helper test_wrmsr_fep_fault().
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
---
x86/msr.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/x86/msr.c b/x86/msr.c
index 3a041fab..17f93029 100644
--- a/x86/msr.c
+++ b/x86/msr.c
@@ -112,6 +112,16 @@ static void test_rdmsr_fault(u32 msr, const char *name)
"Expected #GP on RDSMR(%s), got vector %d", name, vector);
}
+static void test_wrmsr_fep_fault(u32 msr, const char *name,
+ unsigned long long val)
+{
+ unsigned char vector = wrmsr_fep_safe(msr, val);
+
+ report(vector == GP_VECTOR,
+ "Expected #GP on emulated WRSMR(%s, 0x%llx), got vector %d",
+ name, val, vector);
+}
+
static void test_msr(struct msr_info *msr, bool is_64bit_host)
{
if (is_64bit_host || !msr->is_64bit_only) {
@@ -302,8 +312,11 @@ static void test_cmd_msrs(void)
test_wrmsr_fault(MSR_IA32_FLUSH_CMD, "FLUSH_CMD", 0);
test_wrmsr_fault(MSR_IA32_FLUSH_CMD, "FLUSH_CMD", L1D_FLUSH);
}
- for (i = 1; i < 64; i++)
- test_wrmsr_fault(MSR_IA32_FLUSH_CMD, "FLUSH_CMD", BIT_ULL(i));
+
+ if (is_fep_available()) {
+ for (i = 1; i < 64; i++)
+ test_wrmsr_fep_fault(MSR_IA32_FLUSH_CMD, "FLUSH_CMD", BIT_ULL(i));
+ }
}
int main(int ac, char **av)
--
2.44.0.683.g7961c838ac-goog
next prev parent reply other threads:[~2024-04-17 23:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 23:29 [kvm-unit-tests PATCH v2 0/2] Fix testing failure in x86/msr Mingwei Zhang
2024-04-17 23:29 ` [kvm-unit-tests PATCH v2 1/2] x86: Add FEP support on read/write register instructions Mingwei Zhang
2024-04-17 23:29 ` Mingwei Zhang [this message]
2024-04-25 20:05 ` [kvm-unit-tests PATCH v2 0/2] Fix testing failure in x86/msr Mingwei Zhang
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=20240417232906.3057638-3-mizhang@google.com \
--to=mizhang@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).