From: Sean Christopherson <seanjc@google.com>
To: Yang Weijiang <weijiang.yang@intel.com>
Cc: pbonzini@redhat.com, dave.hansen@intel.com, x86@kernel.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
peterz@infradead.org, chao.gao@intel.com,
rick.p.edgecombe@intel.com, mlevitsk@redhat.com,
john.allen@amd.com
Subject: Re: [PATCH v10 10/27] KVM: x86: Refine xsave-managed guest register/MSR reset handling
Date: Wed, 1 May 2024 13:40:25 -0700 [thread overview]
Message-ID: <ZjKouS2ZyH7cXOqM@google.com> (raw)
In-Reply-To: <20240219074733.122080-11-weijiang.yang@intel.com>
The shortlog is a bit stale now that it only deals with XSTATE. This?
KVM: x86: Zero XSTATE components on INIT by iterating over supported features
On Sun, Feb 18, 2024, Yang Weijiang wrote:
> Tweak the code a bit to facilitate resetting more xstate components in
> the future, e.g., CET's xstate-managed MSRs.
>
> No functional change intended.
>
> Suggested-by: Chao Gao <chao.gao@intel.com>
> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
> ---
> arch/x86/kvm/x86.c | 30 +++++++++++++++++++++++++++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 10847e1cc413..5a9c07751c0e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -12217,11 +12217,27 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
> static_branch_dec(&kvm_has_noapic_vcpu);
> }
>
> +#define XSTATE_NEED_RESET_MASK (XFEATURE_MASK_BNDREGS | \
> + XFEATURE_MASK_BNDCSR)
> +
> +static bool kvm_vcpu_has_xstate(unsigned long xfeature)
> +{
> + switch (xfeature) {
> + case XFEATURE_MASK_BNDREGS:
> + case XFEATURE_MASK_BNDCSR:
> + return kvm_cpu_cap_has(X86_FEATURE_MPX);
> + default:
> + return false;
> + }
> +}
> +
> void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
> {
> struct kvm_cpuid_entry2 *cpuid_0x1;
> unsigned long old_cr0 = kvm_read_cr0(vcpu);
> + DECLARE_BITMAP(reset_mask, 64);
I vote to use a u64 instead of a bitmask. The result cast isn't exactly pretty,
but it's not all that uncommon, and it's easy enough to make it "safe" by adding
BUILD_BUG_ON().
On the flip side, using the bitmap_*() APIs for super simple bitwise-OR/AND/TEST
operations makes the code harder to read.
> unsigned long new_cr0;
> + unsigned int i;
>
> /*
> * Several of the "set" flows, e.g. ->set_cr0(), read other registers
> @@ -12274,7 +12290,12 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
> kvm_async_pf_hash_reset(vcpu);
> vcpu->arch.apf.halted = false;
>
> - if (vcpu->arch.guest_fpu.fpstate && kvm_mpx_supported()) {
> + bitmap_from_u64(reset_mask, (kvm_caps.supported_xcr0 |
> + kvm_caps.supported_xss) &
> + XSTATE_NEED_RESET_MASK);
> +
> + if (vcpu->arch.guest_fpu.fpstate &&
> + !bitmap_empty(reset_mask, XFEATURE_MAX)) {
> struct fpstate *fpstate = vcpu->arch.guest_fpu.fpstate;
>
> /*
> @@ -12284,8 +12305,11 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
> if (init_event)
> kvm_put_guest_fpu(vcpu);
>
> - fpstate_clear_xstate_component(fpstate, XFEATURE_BNDREGS);
> - fpstate_clear_xstate_component(fpstate, XFEATURE_BNDCSR);
> + for_each_set_bit(i, reset_mask, XFEATURE_MAX) {
> + if (!kvm_vcpu_has_xstate(i))
> + continue;
> + fpstate_clear_xstate_component(fpstate, i);
> + }
A few intertwined thoughts:
1. fpstate is zero allocated, and KVM absolutely relies on that, e.g. KVM doesn't
manually zero out the XSAVE fields that are preserved on INIT, but zeroed on
RESET.
2. That means there is no need to manually clear XSTATE components during RESET,
as KVM doesn't support standalone RESET, i.e. it's only cleared during vCPU
creation, when guest FPU state is guaranteed to be '0'.
3. That makes XSTATE_NEED_RESET_MASK a misnomer, as it's literally the !RESET
path that is relevant. E.g. it should be XSTATE_CLEAR_ON_INIT_MASK or so.
4. If we add a helper, then XSTATE_NEED_RESET_MASK is probably unneeded.
So, what if we slot in the below (compile tested only) patch as prep work? Then
this patch becomes:
---
arch/x86/kvm/x86.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b441bf61b541..b00730353a28 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12220,6 +12220,8 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
static void kvm_xstate_reset(struct kvm_vcpu *vcpu, bool init_event)
{
struct fpstate *fpstate = vcpu->arch.guest_fpu.fpstate;
+ u64 xfeatures_mask;
+ int i;
/*
* Guest FPU state is zero allocated and so doesn't need to be manually
@@ -12233,16 +12235,20 @@ static void kvm_xstate_reset(struct kvm_vcpu *vcpu, bool init_event)
* are unchanged. Currently, the only components that are zeroed and
* supported by KVM are MPX related.
*/
- if (!kvm_mpx_supported())
+ xfeatures_mask = (kvm_caps.supported_xcr0 | kvm_caps.supported_xss) &
+ (XFEATURE_MASK_BNDREGS | XFEATURE_MASK_BNDCSR);
+ if (!xfeatures_mask)
return;
+ BUILD_BUG_ON(XFEATURE_MAX >= sizeof(xfeatures_mask));
+
/*
* All paths that lead to INIT are required to load the guest's FPU
* state (because most paths are buried in KVM_RUN).
*/
kvm_put_guest_fpu(vcpu);
- fpstate_clear_xstate_component(fpstate, XFEATURE_BNDREGS);
- fpstate_clear_xstate_component(fpstate, XFEATURE_BNDCSR);
+ for_each_set_bit(i, xfeatures_mask, XFEATURE_MAX)
+ fpstate_clear_xstate_component(fpstate, i);
kvm_load_guest_fpu(vcpu);
}
base-commit: efca8b27900dfec160b6ba90820fa2ced81de904
--
and the final code looks like:
static void kvm_xstate_reset(struct kvm_vcpu *vcpu, bool init_event)
{
struct fpstate *fpstate = vcpu->arch.guest_fpu.fpstate;
u64 xfeatures_mask;
int i;
/*
* Guest FPU state is zero allocated and so doesn't need to be manually
* cleared on RESET, i.e. during vCPU creation.
*/
if (!init_event || !fpstate)
return;
/*
* On INIT, only select XSTATE components are zeroed, most compoments
* are unchanged. Currently, the only components that are zeroed and
* supported by KVM are MPX and CET related.
*/
xfeatures_mask = (kvm_caps.supported_xcr0 | kvm_caps.supported_xss) &
(XFEATURE_MASK_BNDREGS | XFEATURE_MASK_BNDCSR |
XFEATURE_MASK_CET_USER | XFEATURE_MASK_CET_KERNEL);
if (!xfeatures_mask)
return;
BUILD_BUG_ON(XFEATURE_MAX >= sizeof(xfeatures_mask) * BITS_PER_BYTE);
/*
* All paths that lead to INIT are required to load the guest's FPU
* state (because most paths are buried in KVM_RUN).
*/
kvm_put_guest_fpu(vcpu);
for_each_set_bit(i, (unsigned long *)&xfeatures_mask, XFEATURE_MAX)
fpstate_clear_xstate_component(fpstate, i);
kvm_load_guest_fpu(vcpu);
}
--
From: Sean Christopherson <seanjc@google.com>
Date: Wed, 1 May 2024 12:12:31 -0700
Subject: [PATCH] KVM: x86: Manually clear MPX state only on INIT
Don't manually clear/zero MPX state on RESET, as the guest FPU state is
zero allocated and KVM only does RESET during vCPU creation, i.e. the
relevant state is guaranteed to be all zeroes.
Opportunistically move the relevant code into a helper in anticipation of
adding support for CET shadow stacks, which also has state that is zeroed
on INIT.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/x86.c | 46 ++++++++++++++++++++++++++++++----------------
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 10847e1cc413..b441bf61b541 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12217,6 +12217,35 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
static_branch_dec(&kvm_has_noapic_vcpu);
}
+static void kvm_xstate_reset(struct kvm_vcpu *vcpu, bool init_event)
+{
+ struct fpstate *fpstate = vcpu->arch.guest_fpu.fpstate;
+
+ /*
+ * Guest FPU state is zero allocated and so doesn't need to be manually
+ * cleared on RESET, i.e. during vCPU creation.
+ */
+ if (!init_event || !fpstate)
+ return;
+
+ /*
+ * On INIT, only select XSTATE components are zeroed, most compoments
+ * are unchanged. Currently, the only components that are zeroed and
+ * supported by KVM are MPX related.
+ */
+ if (!kvm_mpx_supported())
+ return;
+
+ /*
+ * All paths that lead to INIT are required to load the guest's FPU
+ * state (because most paths are buried in KVM_RUN).
+ */
+ kvm_put_guest_fpu(vcpu);
+ fpstate_clear_xstate_component(fpstate, XFEATURE_BNDREGS);
+ fpstate_clear_xstate_component(fpstate, XFEATURE_BNDCSR);
+ kvm_load_guest_fpu(vcpu);
+}
+
void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
{
struct kvm_cpuid_entry2 *cpuid_0x1;
@@ -12274,22 +12303,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
kvm_async_pf_hash_reset(vcpu);
vcpu->arch.apf.halted = false;
- if (vcpu->arch.guest_fpu.fpstate && kvm_mpx_supported()) {
- struct fpstate *fpstate = vcpu->arch.guest_fpu.fpstate;
-
- /*
- * All paths that lead to INIT are required to load the guest's
- * FPU state (because most paths are buried in KVM_RUN).
- */
- if (init_event)
- kvm_put_guest_fpu(vcpu);
-
- fpstate_clear_xstate_component(fpstate, XFEATURE_BNDREGS);
- fpstate_clear_xstate_component(fpstate, XFEATURE_BNDCSR);
-
- if (init_event)
- kvm_load_guest_fpu(vcpu);
- }
+ kvm_xstate_reset(vcpu, init_event);
if (!init_event) {
vcpu->arch.smbase = 0x30000;
base-commit: 1a89965fa9dae1ae04f44679860ef6bc008c2003
--
next prev parent reply other threads:[~2024-05-01 20:40 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 7:47 [PATCH v10 00/27] Enable CET Virtualization Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 01/27] x86/fpu/xstate: Always preserve non-user xfeatures/flags in __state_perm Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 02/27] x86/fpu/xstate: Refine CET user xstate bit enabling Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 03/27] x86/fpu/xstate: Add CET supervisor mode state support Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 04/27] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL_DYNAMIC xfeature set Yang Weijiang
2024-05-01 18:45 ` Sean Christopherson
2024-05-02 17:46 ` Dave Hansen
2024-05-07 22:57 ` Sean Christopherson
2024-05-07 23:17 ` Dave Hansen
2024-05-08 1:19 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 05/27] x86/fpu/xstate: Introduce fpu_guest_cfg for guest FPU configuration Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 06/27] x86/fpu/xstate: Create guest fpstate with guest specific config Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 07/27] x86/fpu/xstate: Warn if kernel dynamic xfeatures detected in normal fpstate Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 08/27] KVM: x86: Rework cpuid_get_supported_xcr0() to operate on vCPU data Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 09/27] KVM: x86: Rename kvm_{g,s}et_msr()* to menifest emulation operations Yang Weijiang
2024-05-01 18:54 ` Sean Christopherson
2024-05-06 5:58 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 10/27] KVM: x86: Refine xsave-managed guest register/MSR reset handling Yang Weijiang
2024-02-20 3:04 ` Chao Gao
2024-02-20 13:23 ` Yang, Weijiang
2024-05-01 20:40 ` Sean Christopherson [this message]
2024-05-06 7:26 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 11/27] KVM: x86: Add kvm_msr_{read,write}() helpers Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 12/27] KVM: x86: Report XSS as to-be-saved if there are supported features Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 13/27] KVM: x86: Refresh CPUID on write to guest MSR_IA32_XSS Yang Weijiang
2024-02-20 8:51 ` Chao Gao
2024-05-01 20:43 ` Sean Christopherson
2024-05-06 7:30 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 14/27] KVM: x86: Initialize kvm_caps.supported_xss Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 15/27] KVM: x86: Load guest FPU state when access XSAVE-managed MSRs Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 16/27] KVM: x86: Add fault checks for guest CR4.CET setting Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 17/27] KVM: x86: Report KVM supported CET MSRs as to-be-saved Yang Weijiang
2024-05-01 22:40 ` Sean Christopherson
2024-05-06 8:31 ` Yang, Weijiang
2024-05-07 17:27 ` Sean Christopherson
2024-05-08 7:00 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 18/27] KVM: VMX: Introduce CET VMCS fields and control bits Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 19/27] KVM: x86: Use KVM-governed feature framework to track "SHSTK/IBT enabled" Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 20/27] KVM: VMX: Emulate read and write to CET MSRs Yang Weijiang
2024-03-12 22:55 ` Sean Christopherson
2024-03-13 9:43 ` Yang, Weijiang
2024-03-13 16:00 ` Sean Christopherson
2024-02-19 7:47 ` [PATCH v10 21/27] KVM: x86: Save and reload SSP to/from SMRAM Yang Weijiang
2024-05-01 22:50 ` Sean Christopherson
2024-05-06 8:41 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 22/27] KVM: VMX: Set up interception for CET MSRs Yang Weijiang
2024-05-01 23:07 ` Sean Christopherson
2024-05-06 8:48 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 23/27] KVM: VMX: Set host constant supervisor states to VMCS fields Yang Weijiang
2024-02-19 7:47 ` [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and advertise to userspace Yang Weijiang
2024-05-01 23:15 ` Sean Christopherson
2024-05-01 23:24 ` Edgecombe, Rick P
2024-05-06 9:19 ` Yang, Weijiang
2024-05-06 16:54 ` Sean Christopherson
2024-05-07 2:37 ` Yang, Weijiang
2024-05-06 17:05 ` Edgecombe, Rick P
2024-05-06 23:33 ` Sean Christopherson
2024-05-06 23:53 ` Edgecombe, Rick P
2024-05-07 14:21 ` Sean Christopherson
2024-05-07 14:45 ` Edgecombe, Rick P
2024-05-07 15:08 ` Sean Christopherson
2024-05-07 15:33 ` Edgecombe, Rick P
2024-05-16 7:13 ` Yang, Weijiang
2024-05-16 14:39 ` Sean Christopherson
2024-05-16 15:36 ` Dave Hansen
2024-05-16 16:58 ` Sean Christopherson
2024-05-17 8:27 ` Yang, Weijiang
2024-05-17 8:57 ` Thomas Gleixner
2024-05-17 14:26 ` Sean Christopherson
2024-05-20 9:43 ` Yang, Weijiang
2024-05-20 17:09 ` Sean Christopherson
2024-05-20 17:15 ` Dave Hansen
2024-05-22 9:03 ` Yang, Weijiang
2024-05-22 15:06 ` Edgecombe, Rick P
2024-05-23 10:07 ` Yang, Weijiang
2024-05-22 8:41 ` Yang, Weijiang
2024-05-27 9:05 ` Yang, Weijiang
2024-05-01 23:34 ` Sean Christopherson
2024-05-06 9:41 ` Yang, Weijiang
2024-05-16 7:20 ` Yang, Weijiang
2024-05-16 14:43 ` Sean Christopherson
2024-05-17 8:04 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 25/27] KVM: nVMX: Introduce new VMX_BASIC bit for event error_code delivery to L1 Yang Weijiang
2024-05-01 23:19 ` Sean Christopherson
2024-05-06 9:19 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 26/27] KVM: nVMX: Enable CET support for nested guest Yang Weijiang
2024-05-01 23:23 ` Sean Christopherson
2024-05-06 9:25 ` Yang, Weijiang
2024-02-19 7:47 ` [PATCH v10 27/27] KVM: x86: Don't emulate instructions guarded by CET Yang Weijiang
2024-05-01 23:24 ` Sean Christopherson
2024-05-06 9:26 ` Yang, Weijiang
2024-03-06 14:44 ` [PATCH v10 00/27] Enable CET Virtualization Yang, Weijiang
2024-05-01 23:27 ` Sean Christopherson
2024-05-06 9:31 ` Yang, Weijiang
2024-11-05 18:25 ` Edgecombe, Rick P
2024-11-06 1:45 ` Yang, Weijiang
2024-11-06 3:20 ` Edgecombe, Rick P
2024-11-06 16:32 ` Sean Christopherson
2024-11-07 2:05 ` Edgecombe, Rick P
2024-11-12 0:33 ` Chao Gao
2024-11-12 20:03 ` Edgecombe, Rick P
2024-11-13 10:53 ` Chao Gao
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=ZjKouS2ZyH7cXOqM@google.com \
--to=seanjc@google.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.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).