[PATCH v3 20/27] KVM: x86: Allow WRMSRNS to be advertised to guests

Xin Li (Intel) posted 27 patches 1 year, 4 months ago
There is a newer version of this series
[PATCH v3 20/27] KVM: x86: Allow WRMSRNS to be advertised to guests
Posted by Xin Li (Intel) 1 year, 4 months ago
From: Xin Li <xin3.li@intel.com>

Allow WRMSRNS to be advertised to guests.

WRMSRNS behaves exactly like WRMSR with the only difference being
that it is not a serializing instruction by default.  It improves
performance when being used in a hot path, e.g., setting FRED RSP0.

Signed-off-by: Xin Li <xin3.li@intel.com>
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
Tested-by: Shan Kang <shan.kang@intel.com>
---
 arch/x86/kvm/cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index c55d150ece8d..63a78ebf9482 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -700,7 +700,7 @@ void kvm_set_cpu_caps(void)
 	kvm_cpu_cap_mask(CPUID_7_1_EAX,
 		F(AVX_VNNI) | F(AVX512_BF16) | F(CMPCCXADD) |
 		F(FZRM) | F(FSRS) | F(FSRC) | F(FRED) | F(LKGS) |
-		F(AMX_FP16) | F(AVX_IFMA) | F(LAM)
+		F(WRMSRNS) | F(AMX_FP16) | F(AVX_IFMA) | F(LAM)
 	);
 
 	kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX,
-- 
2.46.2
Re: [PATCH v3 20/27] KVM: x86: Allow WRMSRNS to be advertised to guests
Posted by Sean Christopherson 11 months, 2 weeks ago
On Mon, Sep 30, 2024, Xin Li (Intel) wrote:
> From: Xin Li <xin3.li@intel.com>
> 
> Allow WRMSRNS to be advertised to guests.

The shortlog and this sentence are incorrect.  Assuming there are no controls for
WRMSRNS, then KVM isn't allowing anything.  Userspace can advertise WRMSRNS support
whenever it wants, and the guest can cleanly execute WRMSRNS regardless of whether
or not it's advertised in CPUID.  KVM is simply advertising support to userspace.

> WRMSRNS behaves exactly like WRMSR with the only difference being

Nope, not the only difference.

  WRMSR and WRMSRNS use the same basic exit reason (see Appendix C). For WRMSR,
  the exit qualification is 0, while for WRMSRNS it is 1.

And the whole reaosn I went spelunking was to verify that WRMSRNS honors all MSR
exiting controls and generates the same exits.  That information needs to be
explicitly stated.

I'll rewrite the shortlog and changelog when applying.