From: Chao Gao <chao.gao@intel.com>
To: "Yang, Weijiang" <weijiang.yang@intel.com>
Cc: <seanjc@google.com>, <pbonzini@redhat.com>,
<peterz@infradead.org>, <john.allen@amd.com>,
<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<rick.p.edgecombe@intel.com>, <binbin.wu@linux.intel.com>
Subject: Re: [PATCH v4 09/20] KVM:x86: Add common code of CET MSR access
Date: Wed, 26 Jul 2023 21:46:33 +0800 [thread overview]
Message-ID: <ZMEjudsdr8WEiw3b@chao-email> (raw)
In-Reply-To: <67250373-c5f4-d1d7-9334-4c9e6a43ab63@intel.com>
On Wed, Jul 26, 2023 at 04:26:06PM +0800, Yang, Weijiang wrote:
>> > + /*
>> > + * This function cannot work without later CET MSR read/write
>> > + * emulation patch.
>> Probably you should consider merging the "later" patch into this one.
>> Then you can get rid of this comment and make this patch easier for
>> review ...
>
>Which later patch you mean? If you mean [13/20] KVM:VMX: Emulate read and
>write to CET MSRs,
>
>then I intentionally separate these two, this one is for CET MSR common
>checks and operations,
>
>the latter is specific to VMX, and add the above comments in case someone is
The problem of this organization is the handling of S_CET, SSP, INT_SSP_TABLE
MSR is incomplete in this patch. I think a better organization is to either
merge this patch and patch 13, or move all changes related to S_CET, SSP,
INT_SSP_TABLE into patch 13? e.g.,
case MSR_IA32_U_CET:
- case MSR_IA32_S_CET:
if (!kvm_cet_is_msr_accessible(vcpu, msr_info))
return 1;
if ((!guest_can_use(vcpu, X86_FEATURE_SHSTK) &&
(data & CET_SHSTK_MASK_BITS)) ||
(!guest_can_use(vcpu, X86_FEATURE_IBT) &&
(data & CET_IBT_MASK_BITS)))
return 1;
- if (msr == MSR_IA32_U_CET)
- kvm_set_xsave_msr(msr_info);
kvm_set_xsave_msr(msr_info);
break;
- case MSR_KVM_GUEST_SSP:
- case MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB:
case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
if (!kvm_cet_is_msr_accessible(vcpu, msr_info))
return 1;
if (is_noncanonical_address(data, vcpu))
return 1;
if (!IS_ALIGNED(data, 4))
return 1;
if (msr == MSR_IA32_PL0_SSP || msr == MSR_IA32_PL1_SSP ||
msr == MSR_IA32_PL2_SSP) {
vcpu->arch.cet_s_ssp[msr - MSR_IA32_PL0_SSP] = data;
} else if (msr == MSR_IA32_PL3_SSP) {
kvm_set_xsave_msr(msr_info);
}
break;
BTW, shouldn't bit2:0 of MSR_KVM_GUEST_SSP be 0? i.e., for MSR_KVM_GUEST_SSP,
the alignment check should be IS_ALIGNED(data, 8).
>bisecting
>
>the patches and happens to split at this patch, then it would faulted and
>take some actions.
I am not sure what kind of issue you are worrying about. In my understanding,
KVM hasn't advertised the support of IBT and SHSTK, so,
kvm_cpu_cap_has(X86_FEATURE_SHSTK/IBT) will always return false. and then
kvm_cet_is_msr_accessible() is guaranteed to return false.
If there is any issue in your mind, you can fix it or reorganize your patches to
avoid the issue. To me, adding a comment and a warning is not a good solution.
>
>> > int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>> > {
>> > u32 msr = msr_info->index;
>> > @@ -3982,6 +4023,35 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>> > vcpu->arch.guest_fpu.xfd_err = data;
>> > break;
>> > #endif
>> > +#define CET_IBT_MASK_BITS GENMASK_ULL(63, 2)
>> bit9:6 are reserved even if IBT is supported.
>
>Yes, as IBT is only available on Intel platforms, I move the handling of bit
>9:6 to VMX related patch.
IIUC, bits 9:6 are not reserved for IBT. I don't get how IBT availability
affects the handling of bits 9:6.
>
>Here's the common check in case IBT is not available.
>
>>
>> > @@ -12131,6 +12217,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
>> >
>> > vcpu->arch.cr3 = 0;
>> > kvm_register_mark_dirty(vcpu, VCPU_EXREG_CR3);
>> > + memset(vcpu->arch.cet_s_ssp, 0, sizeof(vcpu->arch.cet_s_ssp));
>> ... this begs the question: where other MSRs are reset. I suppose
>> U_CET/PL3_SSP are handled when resetting guest FPU. But how about S_CET
>> and INT_SSP_TAB? there is no answer in this patch.
>
>I think the related guest VMCS fields(S_CET/INT_SSP_TAB/SSP) should be reset
>to 0 in vmx_vcpu_reset(),
>
>do you think so?
Yes, looks good.
next prev parent reply other threads:[~2023-07-26 13:46 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-21 3:03 [PATCH v4 00/20] Enable CET Virtualization Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 01/20] x86/cpufeatures: Add CPU feature flags for shadow stacks Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 02/20] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 03/20] KVM:x86: Report XSS as to-be-saved if there are supported features Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 04/20] KVM:x86: Refresh CPUID on write to guest MSR_IA32_XSS Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 05/20] KVM:x86: Initialize kvm_caps.supported_xss Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 06/20] KVM:x86: Load guest FPU state when access XSAVE-managed MSRs Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 07/20] KVM:x86: Add fault checks for guest CR4.CET setting Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 08/20] KVM:x86: Report KVM supported CET MSRs as to-be-saved Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 09/20] KVM:x86: Add common code of CET MSR access Yang Weijiang
2023-07-26 7:33 ` Chao Gao
2023-07-26 8:26 ` Yang, Weijiang
2023-07-26 13:46 ` Chao Gao [this message]
2023-07-27 6:06 ` Yang, Weijiang
2023-07-27 7:41 ` Chao Gao
2023-07-27 16:58 ` Sean Christopherson
2023-07-21 3:03 ` [PATCH v4 10/20] KVM:x86: Make guest supervisor states as non-XSAVE managed Yang Weijiang
2023-07-24 8:26 ` Chao Gao
2023-07-24 13:50 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 11/20] KVM:x86: Save and reload GUEST_SSP to/from SMRAM Yang Weijiang
2023-07-24 9:13 ` Chao Gao
2023-07-24 14:16 ` Yang, Weijiang
2023-07-24 14:26 ` Sean Christopherson
2023-07-21 3:03 ` [PATCH v4 12/20] KVM:VMX: Introduce CET VMCS fields and control bits Yang Weijiang
2023-07-27 5:26 ` Chao Gao
2023-07-27 7:13 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 13/20] KVM:VMX: Emulate read and write to CET MSRs Yang Weijiang
2023-07-26 8:06 ` Chao Gao
2023-07-27 3:19 ` Yang, Weijiang
2023-07-27 5:16 ` Chao Gao
2023-07-27 7:10 ` Yang, Weijiang
2023-07-27 15:20 ` Sean Christopherson
2023-07-28 0:43 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 14/20] KVM:VMX: Set up interception for " Yang Weijiang
2023-07-26 8:30 ` Chao Gao
2023-07-27 3:48 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 15/20] KVM:VMX: Save host MSR_IA32_S_CET to VMCS field Yang Weijiang
2023-07-26 8:47 ` Chao Gao
2023-07-26 14:05 ` Sean Christopherson
2023-07-27 7:29 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 16/20] KVM:x86: Optimize CET supervisor SSP save/reload Yang Weijiang
2023-07-27 3:27 ` Chao Gao
2023-07-27 6:23 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 17/20] KVM:x86: Enable CET virtualization for VMX and advertise to userspace Yang Weijiang
2023-07-27 6:32 ` Chao Gao
2023-07-27 7:26 ` Yang, Weijiang
2023-07-21 3:03 ` [PATCH v4 18/20] KVM:x86: Enable guest CET supervisor xstate bit support Yang Weijiang
2023-07-27 8:03 ` Chao Gao
2023-07-21 3:03 ` [PATCH v4 19/20] KVM:nVMX: Refine error code injection to nested VM Yang Weijiang
2023-07-21 3:03 ` [PATCH v4 20/20] KVM:nVMX: Enable CET support for " Yang Weijiang
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=ZMEjudsdr8WEiw3b@chao-email \
--to=chao.gao@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=weijiang.yang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.