From: Sean Christopherson <seanjc@google.com>
To: Weijiang Yang <weijiang.yang@intel.com>
Cc: Chao Gao <chao.gao@intel.com>,
pbonzini@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, peterz@infradead.org,
rppt@kernel.org, binbin.wu@linux.intel.com,
rick.p.edgecombe@intel.com, john.allen@amd.com,
gil.neiger@intel.com
Subject: Re: [PATCH v3 10/21] KVM:x86: Add #CP support in guest exception classification
Date: Fri, 30 Jun 2023 08:07:52 -0700 [thread overview]
Message-ID: <ZJ7vyBw1nbTBOfuf@google.com> (raw)
In-Reply-To: <0a98683f-3e60-1f1b-55df-f2a781929fdf@intel.com>
On Fri, Jun 30, 2023, Weijiang Yang wrote:
>
> On 6/17/2023 2:57 AM, Sean Christopherson wrote:
> > > Do you mean documentation for #CP as an generic exception or the behavior in
> > > KVM as this patch shows?
> > As I pointed out two *years* ago, this entry in the SDM
> >
> > — The field's deliver-error-code bit (bit 11) is 1 if each of the following
> > holds: (1) the interruption type is hardware exception; (2) bit 0
> > (corresponding to CR0.PE) is set in the CR0 field in the guest-state area;
> > (3) IA32_VMX_BASIC[56] is read as 0 (see Appendix A.1); and (4) the vector
> > indicates one of the following exceptions: #DF (vector 8), #TS (10),
> > #NP (11), #SS (12), #GP (13), #PF (14), or #AC (17).
> >
> > needs to read something like
> >
> > — The field's deliver-error-code bit (bit 11) is 1 if each of the following
> > holds: (1) the interruption type is hardware exception; (2) bit 0
> > (corresponding to CR0.PE) is set in the CR0 field in the guest-state area;
> > (3) IA32_VMX_BASIC[56] is read as 0 (see Appendix A.1); and (4) the vector
> > indicates one of the following exceptions: #DF (vector 8), #TS (10),
> > #NP (11), #SS (12), #GP (13), #PF (14), #AC (17), or #CP (21)[1]
> >
> > [1] #CP has an error code if and only if IA32_VMX_CR4_FIXED1 enumerates
> > support for the 1-setting of CR4.CET.
>
> Hi, Sean,
>
> I sent above change request to Gil(added in cc), but he shared different
> opinion on this issue:
Heh, "opinion".
> It may make things clearer if we document the statement above (all
> CET-capable parts enumerate IA32_VMX_BASIC[56] as 1).
>
> I will see if we can update future revisions of the SDM to clarify this."
That would be helpful. Though to be perfectly honest, I simply overlooked the
existence of IA32_VMX_BASIC[56].
Thanks!
> Then if this is the case, kvm needs to check IA32_VMX_BASIC[56] before
> inject exception to nested VM.
>
> And this patch could be removed, instead need another patch like below:
>
> diff --git a/arch/x86/include/asm/msr-index.h
> b/arch/x86/include/asm/msr-index.h
> index ad35355ee43e..6b33aacc8587 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -1076,6 +1076,7 @@
> #define VMX_BASIC_MEM_TYPE_MASK 0x003c000000000000LLU
> #define VMX_BASIC_MEM_TYPE_WB 6LLU
> #define VMX_BASIC_INOUT 0x0040000000000000LLU
> +#define VMX_BASIC_CHECK_ERRCODE 0x0140000000000000LLU
"Check Error Code" isn't a great description. The flag enumerates that there the
CPU does *not* perform consistency checks on the error code when injecting hardware
exceptions.
So something like this?
VMX_BASIC_NO_HW_ERROR_CODE_CC
or maybe
VMX_BASIC_PM_NO_HW_ERROR_CODE_CC
if we want to capture that only protected mode is exempt (I personally prefer
just VMX_BASIC_NO_HW_ERROR_CODE_CC as "PM" is a bit ambiguous).
> @@ -2873,7 +2873,8 @@ static int nested_check_vm_entry_controls(struct
> kvm_vcpu *vcpu,
> should_have_error_code =
> intr_type == INTR_TYPE_HARD_EXCEPTION && prot_mode &&
> x86_exception_has_error_code(vector);
> - if (CC(has_error_code != should_have_error_code))
> + if (!cpu_has_vmx_basic_check_errcode() &&
> + CC(has_error_code != should_have_error_code))
This is wrong on mutiple fronts:
1. The new feature flag only excempts hardware exceptions delivered to guests
with CR0.PE=1. The above will skip the consistency check for all event injection.
2. KVM needs to check the CPU model that is exposed to L1, not the capabilities
of the host CPU.
Highlighting the key phrases in the SDM:
The field's deliver-error-code bit (bit 11) is 1 if each of the following holds: (1) the interruption type is
^^^^^^^
hardware exception; (2) bit 0 (corresponding to CR0.PE) is set in the CR0 field in the guest-state area;
(3) IA32_VMX_BASIC[56] is read as 0 (see Appendix A.1); and (4) the vector indicates one of the following
exceptions: #DF (vector 8), #TS (10), #NP (11), #SS (12), #GP (13), #PF (14), or #AC (17).
The field's deliver-error-code bit is 0 if any of the following holds: (1) the interruption type is not hardware
^^^^^^
exception; (2) bit 0 is clear in the CR0 field in the guest-state area; or (3) IA32_VMX_BASIC[56] is read as
0 and the vector is in one of the following ranges: 0–7, 9, 15, 16, or 18–31.
I think what we want is:
/* VM-entry interruption-info field: deliver error code */
if (!prot_mode || intr_type != INTR_TYPE_HARD_EXCEPTION ||
!nested_cpu_has_no_hw_error_code_cc(vcpu)) {
should_have_error_code =
intr_type == INTR_TYPE_HARD_EXCEPTION && prot_mode &&
x86_exception_has_error_code(vector);
if (CC(has_error_code != should_have_error_code))
return -EINVAL;
}
next prev parent reply other threads:[~2023-06-30 15:08 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 4:08 [PATCH v3 00/21] Enable CET Virtualization Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 01/21] x86/shstk: Add Kconfig option for shadow stack Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 02/21] x86/cpufeatures: Add CPU feature flags for shadow stacks Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 03/21] x86/cpufeatures: Enable CET CR4 bit for shadow stack Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 04/21] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 05/21] x86/fpu: Add helper for modifying xstate Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 06/21] KVM:x86: Report XSS as to-be-saved if there are supported features Yang Weijiang
2023-05-24 7:06 ` Chao Gao
2023-05-24 8:19 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 07/21] KVM:x86: Refresh CPUID on write to guest MSR_IA32_XSS Yang Weijiang
2023-05-25 6:10 ` Chao Gao
2023-05-30 3:51 ` Yang, Weijiang
2023-05-30 12:08 ` Chao Gao
2023-05-31 1:11 ` Yang, Weijiang
2023-06-15 23:45 ` Sean Christopherson
2023-06-16 1:58 ` Yang, Weijiang
2023-06-23 23:21 ` Sean Christopherson
2023-06-26 9:24 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 08/21] KVM:x86: Init kvm_caps.supported_xss with supported feature bits Yang Weijiang
2023-06-06 8:38 ` Chao Gao
2023-06-08 5:42 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 09/21] KVM:x86: Load guest FPU state when accessing xsaves-managed MSRs Yang Weijiang
2023-06-15 23:50 ` Sean Christopherson
2023-06-16 2:02 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 10/21] KVM:x86: Add #CP support in guest exception classification Yang Weijiang
2023-06-06 9:08 ` Chao Gao
2023-06-08 6:01 ` Yang, Weijiang
2023-06-15 23:58 ` Sean Christopherson
2023-06-16 6:56 ` Yang, Weijiang
2023-06-16 18:57 ` Sean Christopherson
2023-06-19 9:28 ` Yang, Weijiang
2023-06-30 9:34 ` Yang, Weijiang
2023-06-30 10:27 ` Chao Gao
2023-06-30 12:05 ` Yang, Weijiang
2023-06-30 15:05 ` Neiger, Gil
2023-06-30 15:15 ` Sean Christopherson
2023-07-01 1:58 ` Yang, Weijiang
2023-07-01 1:54 ` Yang, Weijiang
2023-06-30 15:07 ` Sean Christopherson [this message]
2023-06-30 15:21 ` Neiger, Gil
2023-07-01 1:57 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 11/21] KVM:VMX: Introduce CET VMCS fields and control bits Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 12/21] KVM:x86: Add fault checks for guest CR4.CET setting Yang Weijiang
2023-06-06 11:03 ` Chao Gao
2023-06-08 6:06 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 13/21] KVM:VMX: Emulate reads and writes to CET MSRs Yang Weijiang
2023-05-23 8:21 ` Binbin Wu
2023-05-24 2:49 ` Yang, Weijiang
2023-06-23 23:53 ` Sean Christopherson
2023-06-26 14:05 ` Yang, Weijiang
2023-06-26 21:15 ` Sean Christopherson
2023-06-27 3:32 ` Yang, Weijiang
2023-06-27 14:55 ` Sean Christopherson
2023-06-28 1:42 ` Yang, Weijiang
2023-07-07 9:10 ` Yang, Weijiang
2023-07-07 15:28 ` Neiger, Gil
2023-07-12 16:42 ` Sean Christopherson
2023-05-11 4:08 ` [PATCH v3 14/21] KVM:VMX: Add a synthetic MSR to allow userspace to access GUEST_SSP Yang Weijiang
2023-05-23 8:57 ` Binbin Wu
2023-05-24 2:55 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 15/21] KVM:x86: Report CET MSRs as to-be-saved if CET is supported Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 16/21] KVM:x86: Save/Restore GUEST_SSP to/from SMM state save area Yang Weijiang
2023-06-23 22:30 ` Sean Christopherson
2023-06-26 8:59 ` Yang, Weijiang
2023-06-26 21:20 ` Sean Christopherson
2023-06-27 3:50 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 17/21] KVM:VMX: Pass through user CET MSRs to the guest Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 18/21] KVM:x86: Enable CET virtualization for VMX and advertise to userspace Yang Weijiang
2023-05-24 6:35 ` Chenyi Qiang
2023-05-24 8:07 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 19/21] KVM:nVMX: Enable user CET support for nested VMX Yang Weijiang
2023-05-11 4:08 ` [PATCH v3 20/21] KVM:x86: Enable kernel IBT support for guest Yang Weijiang
2023-06-24 0:03 ` Sean Christopherson
2023-06-26 12:10 ` Yang, Weijiang
2023-06-26 20:50 ` Sean Christopherson
2023-06-27 1:53 ` Yang, Weijiang
2023-05-11 4:08 ` [PATCH v3 21/21] KVM:x86: Support CET supervisor shadow stack MSR access Yang Weijiang
2023-06-15 23:30 ` [PATCH v3 00/21] Enable CET Virtualization Sean Christopherson
2023-06-16 0:00 ` Sean Christopherson
2023-06-16 1:00 ` Yang, Weijiang
2023-06-16 8:25 ` Yang, Weijiang
2023-06-16 17:56 ` Sean Christopherson
2023-06-19 6:41 ` Yang, Weijiang
2023-06-23 20:51 ` Sean Christopherson
2023-06-26 6:46 ` Yang, Weijiang
2023-07-17 7:44 ` Yang, Weijiang
2023-07-19 19:41 ` Sean Christopherson
2023-07-19 20:26 ` Sean Christopherson
2023-07-20 1:58 ` Yang, Weijiang
2023-07-19 20:36 ` Peter Zijlstra
2023-07-20 5:26 ` Pankaj Gupta
2023-07-20 8:03 ` Peter Zijlstra
2023-07-20 8:09 ` Peter Zijlstra
2023-07-20 9:14 ` Pankaj Gupta
2023-07-20 10:46 ` Andrew Cooper
2023-07-20 1:55 ` Yang, Weijiang
2023-07-10 0:28 ` Yang, Weijiang
2023-07-10 22:18 ` Sean Christopherson
2023-07-11 1:24 ` 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=ZJ7vyBw1nbTBOfuf@google.com \
--to=seanjc@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=gil.neiger@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=rppt@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox