| Message ID | 20190122205909.24165-2-weijiang.yang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | This patch-set is to enable Guest CET support | expand |
On 22/01/19 21:59, Yang Weijiang wrote: > On processors that support CET, VMX saves/restores > the states of IA32_S_CET, SSP and IA32_INTERRUPT_SSP_TABLE_ADDR MSR > to the VMCS area for Guest/Host unconditionally. > > If VM_EXIT_LOAD_HOST_CET_STATE = 1, the host CET MSRs are > restored from VMCS host-state area at VM exit as follows: > > - HOST_IA32_S_CET: Host supervisor mode IA32_S_CET MSR is loaded > from this field. > > - HOST_SSP : Host SSP is loaded from this field. > > - HOST_INTR_SSP_TABLE_ADDR : Host IA32_INTERRUPT_SSP_TABLE_ADDR > MSR is loaded from this field. > > If VM_ENTRY_LOAD_GUEST_CET_STATE = 1, the guest CET MSRs are loaded > from VMCS guest-state area at VM entry as follows: > > - GUEST_IA32_S_CET : Guest supervisor mode IA32_S_CET MSR is loaded > from this field. > > - GUEST_SSP : Guest SSP is loaded from this field. > > - GUEST_INTR_SSP_TABL_ADDR : Guest IA32_INTERRUPT_SSP_TABLE_ADDR > MSR is loaded from this field. There is no code in this series to pass these fields to and from userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and PL3_SSP across context switches. In addition, PL1_SSP and PL2_SSP should be supported even if the guest doesn't use them. It makes sense to avoid intercepting them, but they should still be supported and switched (possibly only if nonzero). Am I missing something, for example a dependency on host CET support? If not, how was this series tested? Paolo
On Wed, Jan 23, 2019 at 04:59:03AM +0800, Yang Weijiang wrote: > On processors that support CET, VMX saves/restores > the states of IA32_S_CET, SSP and IA32_INTERRUPT_SSP_TABLE_ADDR MSR It'd be helpful to spell out CET and SSP on their initial usage here, especially since this is the first patch in the series. If you're going to abbreviate INTERRUPT below, might as well do so here. > to the VMCS area for Guest/Host unconditionally. > > If VM_EXIT_LOAD_HOST_CET_STATE = 1, the host CET MSRs are > restored from VMCS host-state area at VM exit as follows: > > - HOST_IA32_S_CET: Host supervisor mode IA32_S_CET MSR is loaded > from this field. > > - HOST_SSP : Host SSP is loaded from this field. > > - HOST_INTR_SSP_TABLE_ADDR : Host IA32_INTERRUPT_SSP_TABLE_ADDR > MSR is loaded from this field. > > If VM_ENTRY_LOAD_GUEST_CET_STATE = 1, the guest CET MSRs are loaded > from VMCS guest-state area at VM entry as follows: > > - GUEST_IA32_S_CET : Guest supervisor mode IA32_S_CET MSR is loaded > from this field. > > - GUEST_SSP : Guest SSP is loaded from this field. > > - GUEST_INTR_SSP_TABL_ADDR : Guest IA32_INTERRUPT_SSP_TABLE_ADDR /s/TABL_/TABLE_ > MSR is loaded from this field. > > Additionally, to context switch guest and host CET states, the VMM > uses xsaves/xrstors instructions to save/restore the guest CET states > at VM exit/entry. The CET xsave area is within thread_struct.fpu area. > If OS execution flow changes during task switch/interrupt/exception etc., > the OS also relies on xsaves/xrstors to switch CET states accordingly. > > Note: Although these VMCS fields are 64-bit, they don't have high fields. ...that are documented. I'm still betting it's a doc bug and not a divergence from every other VMCS field in existence. > Signed-off-by: Zhang Yi Z <yi.z.zhang@linux.intel.com> > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > --- > arch/x86/include/asm/vmx.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h > index ade0f153947d..395c1f7e5938 100644 > --- a/arch/x86/include/asm/vmx.h > +++ b/arch/x86/include/asm/vmx.h > @@ -98,6 +98,7 @@ > #define VM_EXIT_LOAD_IA32_EFER 0x00200000 > #define VM_EXIT_SAVE_VMX_PREEMPTION_TIMER 0x00400000 > #define VM_EXIT_CLEAR_BNDCFGS 0x00800000 > +#define VM_EXIT_LOAD_HOST_CET_STATE 0x10000000 > > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff > > @@ -109,6 +110,7 @@ > #define VM_ENTRY_LOAD_IA32_PAT 0x00004000 > #define VM_ENTRY_LOAD_IA32_EFER 0x00008000 > #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 > +#define VM_ENTRY_LOAD_GUEST_CET_STATE 0x00100000 > > #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff > > @@ -325,6 +327,9 @@ enum vmcs_field { > GUEST_PENDING_DBG_EXCEPTIONS = 0x00006822, > GUEST_SYSENTER_ESP = 0x00006824, > GUEST_SYSENTER_EIP = 0x00006826, > + GUEST_IA32_S_CET = 0x00006828, > + GUEST_SSP = 0x0000682a, > + GUEST_INTR_SSP_TABL_ADDR = 0x0000682c, /s/TABL/TABLE > HOST_CR0 = 0x00006c00, > HOST_CR3 = 0x00006c02, > HOST_CR4 = 0x00006c04, > @@ -337,6 +342,9 @@ enum vmcs_field { > HOST_IA32_SYSENTER_EIP = 0x00006c12, > HOST_RSP = 0x00006c14, > HOST_RIP = 0x00006c16, > + HOST_IA32_S_CET = 0x00006c18, > + HOST_SSP = 0x00006c1a, > + HOST_INTR_SSP_TABL_ADDR = 0x00006c1c /s/TABL/TABLE > }; > > /* > -- > 2.17.1 >
On Mon, Jan 28, 2019 at 12:00:17PM +0100, Paolo Bonzini wrote: > Please do not drop the mailing list. > > On 27/01/19 16:40, Yang Weijiang wrote: > > On Fri, Jan 25, 2019 at 07:02:37PM +0100, Paolo Bonzini wrote: > >> There is no code in this series to pass these fields to and from > >> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and > >> PL3_SSP across context switches. > >> > > In current CET implementation, these VMCS fields are not consumed by > > VMM, so now it's rather some placeholders, but in future, we may use > > them. > > If this is not a complete implementation, this should be mentioned in > the patches. KVM must support accesses to the MSRs from userspace, for > example in order to perform live migration. > OK, will do that, thanks. > >> In addition, PL1_SSP and PL2_SSP should be supported even if the guest > >> doesn't use them. It makes sense to avoid intercepting them, but they > >> should still be supported and switched (possibly only if nonzero). > >> > > In the CET spec., there's no such kind of VMCS definitions for PL1_SSP > > and PL2_SSP, so they don't appear in the patches. > > That doesn't matter. I'm not talking of the VMCS definitions, but > rather the MSRs. Currently, any guest using PL1_SSP will cause a #GP. > > >> Am I missing something, for example a dependency on host CET support? > >> If not, how was this series tested? > >> > > In current implementation, guest CET has dependency on host CET > > realization, e.g., kernel code. Right now, I tested guest CET feature > > with host CET enabled on internel virtual platform. > > Ok, please mention this in the cover letter too. > > Paolo
On Fri, Jan 25, 2019 at 07:02:37PM +0100, Paolo Bonzini wrote: > On 22/01/19 21:59, Yang Weijiang wrote: > > On processors that support CET, VMX saves/restores > > the states of IA32_S_CET, SSP and IA32_INTERRUPT_SSP_TABLE_ADDR MSR > > to the VMCS area for Guest/Host unconditionally. > > > > If VM_EXIT_LOAD_HOST_CET_STATE = 1, the host CET MSRs are > > restored from VMCS host-state area at VM exit as follows: > > > > - HOST_IA32_S_CET: Host supervisor mode IA32_S_CET MSR is loaded > > from this field. > > > > - HOST_SSP : Host SSP is loaded from this field. > > > > - HOST_INTR_SSP_TABLE_ADDR : Host IA32_INTERRUPT_SSP_TABLE_ADDR > > MSR is loaded from this field. > > > > If VM_ENTRY_LOAD_GUEST_CET_STATE = 1, the guest CET MSRs are loaded > > from VMCS guest-state area at VM entry as follows: > > > > - GUEST_IA32_S_CET : Guest supervisor mode IA32_S_CET MSR is loaded > > from this field. > > > > - GUEST_SSP : Guest SSP is loaded from this field. > > > > - GUEST_INTR_SSP_TABL_ADDR : Guest IA32_INTERRUPT_SSP_TABLE_ADDR > > MSR is loaded from this field. > Thanks for review. > There is no code in this series to pass these fields to and from > userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and > PL3_SSP across context switches. > The kernel consumes these MSRs, please see kernel CET patch: https://lkml.org/lkml/fancy/2018/11/20/225 > In addition, PL1_SSP and PL2_SSP should be supported even if the guest > doesn't use them. It makes sense to avoid intercepting them, but they > should still be supported and switched (possibly only if nonzero). > > Am I missing something, for example a dependency on host CET support? > If not, how was this series tested? > The guest CET feature is tested with kernel CET patches on internal virtual platform. > Paolo
Please do not drop the mailing list. On 27/01/19 16:40, Yang Weijiang wrote: > On Fri, Jan 25, 2019 at 07:02:37PM +0100, Paolo Bonzini wrote: >> There is no code in this series to pass these fields to and from >> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and >> PL3_SSP across context switches. >> > In current CET implementation, these VMCS fields are not consumed by > VMM, so now it's rather some placeholders, but in future, we may use > them. If this is not a complete implementation, this should be mentioned in the patches. KVM must support accesses to the MSRs from userspace, for example in order to perform live migration. >> In addition, PL1_SSP and PL2_SSP should be supported even if the guest >> doesn't use them. It makes sense to avoid intercepting them, but they >> should still be supported and switched (possibly only if nonzero). >> > In the CET spec., there's no such kind of VMCS definitions for PL1_SSP > and PL2_SSP, so they don't appear in the patches. That doesn't matter. I'm not talking of the VMCS definitions, but rather the MSRs. Currently, any guest using PL1_SSP will cause a #GP. >> Am I missing something, for example a dependency on host CET support? >> If not, how was this series tested? >> > In current implementation, guest CET has dependency on host CET > realization, e.g., kernel code. Right now, I tested guest CET feature > with host CET enabled on internel virtual platform. Ok, please mention this in the cover letter too. Paolo
On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote: > On 28/01/19 11:33, Yang Weijiang wrote: > >> There is no code in this series to pass these fields to and from > >> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and > >> PL3_SSP across context switches. > >> > > The kernel consumes these MSRs, please see kernel CET patch: > > https://lkml.org/lkml/fancy/2018/11/20/225 > > Still, even if the kernel saves these fields across context switch in > XSAVE areas, KVM must support accesses to the MSRs from userspace, for > example in order to perform live migration. > > For example, when reading/writing these in kvm_set_msr or > kvm_get_msr_common, you would have to do a read/write from the host > MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls > in __msr_io. Thanks, you're right, if we want to support live migration we need do that. However, this feature relies on quite a few external dependencies, e.g., cpu capabilities, kernel version and configuration, we don't support live migration right now. what's your opinion? > > Thanks, > > Paolo > > >> In addition, PL1_SSP and PL2_SSP should be supported even if the guest > >> doesn't use them. It makes sense to avoid intercepting them, but they > >> should still be supported and switched (possibly only if nonzero). > >> > >> Am I missing something, for example a dependency on host CET support? > >> If not, how was this series tested? > >> > > The guest CET feature is tested with kernel CET patches on internal > > virtual platform. > >
On Tue, Jan 29, 2019 at 10:27:50AM -0800, Sean Christopherson wrote: > On Tue, Jan 29, 2019 at 10:01:15AM -0800, Jim Mattson wrote: > > On Tue, Jan 29, 2019 at 9:47 AM Jim Mattson <jmattson@google.com> wrote: > > > > > > On Wed, Jan 23, 2019 at 6:06 AM Yang Weijiang <weijiang.yang@intel.com> wrote: > > > > Note: Although these VMCS fields are 64-bit, they don't have high fields. > > > > > > This statement directly contradicts the SDM, volume 3, appendix B.2: > > > > > > "A value of 1 in bits 14:13 of an encoding indicates a 64-bit field. > > > There are 64-bit fields only for controls and for guest state. As > > > noted in Section 24.11.2, every 64-bit field has two encodings, which > > > differ on bit 0, the access type. Thus, each such field has an even > > > encoding for full access and an odd encoding for high access." > > > > Ah! They're not actually 64-bit fields. If you look at the encodings > > (0x68XX and 0x6cxx), they're natural-width fields! Natural-width > > fields don't have a high component. > > They're indeed natural width (I actually looked at the spec this time). > > The "_FULL" postfix on VMX_HOST_IA32_INTERRUPT_SSP_TABLE_ADDR_FULL and > VMX_HOST_SSP_FULL is confusing as it generally only shows up on 64-bit > fields. I'll see if we can get the fields renamed to drop "_FULL". I > suggest we preemptively do the same for KVM. Thank you for making it clear! I should have modified the annotation correctly. I'll add a note for this in next version.
On 28/01/19 11:33, Yang Weijiang wrote: >> There is no code in this series to pass these fields to and from >> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and >> PL3_SSP across context switches. >> > The kernel consumes these MSRs, please see kernel CET patch: > https://lkml.org/lkml/fancy/2018/11/20/225 Still, even if the kernel saves these fields across context switch in XSAVE areas, KVM must support accesses to the MSRs from userspace, for example in order to perform live migration. For example, when reading/writing these in kvm_set_msr or kvm_get_msr_common, you would have to do a read/write from the host MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls in __msr_io. Thanks, Paolo >> In addition, PL1_SSP and PL2_SSP should be supported even if the guest >> doesn't use them. It makes sense to avoid intercepting them, but they >> should still be supported and switched (possibly only if nonzero). >> >> Am I missing something, for example a dependency on host CET support? >> If not, how was this series tested? >> > The guest CET feature is tested with kernel CET patches on internal > virtual platform. >
On Wed, Jan 23, 2019 at 6:06 AM Yang Weijiang <weijiang.yang@intel.com> wrote:
> Note: Although these VMCS fields are 64-bit, they don't have high fields.
This statement directly contradicts the SDM, volume 3, appendix B.2:
"A value of 1 in bits 14:13 of an encoding indicates a 64-bit field.
There are 64-bit fields only for controls and for guest state. As
noted in Section 24.11.2, every 64-bit field has two encodings, which
differ on bit 0, the access type. Thus, each such field has an even
encoding for full access and an odd encoding for high access."
On Tue, Jan 29, 2019 at 9:47 AM Jim Mattson <jmattson@google.com> wrote: > > On Wed, Jan 23, 2019 at 6:06 AM Yang Weijiang <weijiang.yang@intel.com> wrote: > > Note: Although these VMCS fields are 64-bit, they don't have high fields. > > This statement directly contradicts the SDM, volume 3, appendix B.2: > > "A value of 1 in bits 14:13 of an encoding indicates a 64-bit field. > There are 64-bit fields only for controls and for guest state. As > noted in Section 24.11.2, every 64-bit field has two encodings, which > differ on bit 0, the access type. Thus, each such field has an even > encoding for full access and an odd encoding for high access." Ah! They're not actually 64-bit fields. If you look at the encodings (0x68XX and 0x6cxx), they're natural-width fields! Natural-width fields don't have a high component.
On 29/01/19 09:29, Yang Weijiang wrote: > On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote: >> On 28/01/19 11:33, Yang Weijiang wrote: >>>> There is no code in this series to pass these fields to and from >>>> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and >>>> PL3_SSP across context switches. >>>> >>> The kernel consumes these MSRs, please see kernel CET patch: >>> https://lkml.org/lkml/fancy/2018/11/20/225 >> >> Still, even if the kernel saves these fields across context switch in >> XSAVE areas, KVM must support accesses to the MSRs from userspace, for >> example in order to perform live migration. >> >> For example, when reading/writing these in kvm_set_msr or >> kvm_get_msr_common, you would have to do a read/write from the host >> MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls >> in __msr_io. > Thanks, you're right, if we want to support live migration we need do that. > However, this feature relies on quite a few external > dependencies, e.g., cpu capabilities, kernel version and configuration, we > don't support live migration right now. what's your opinion? Live migration is generally a requirement for a feature to be accepted in KVM. Paolo >> Thanks, >> >> Paolo >> >>>> In addition, PL1_SSP and PL2_SSP should be supported even if the guest >>>> doesn't use them. It makes sense to avoid intercepting them, but they >>>> should still be supported and switched (possibly only if nonzero). >>>> >>>> Am I missing something, for example a dependency on host CET support? >>>> If not, how was this series tested? >>>> >>> The guest CET feature is tested with kernel CET patches on internal >>> virtual platform. >>>
On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote: > On 28/01/19 11:33, Yang Weijiang wrote: > >> There is no code in this series to pass these fields to and from > >> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and > >> PL3_SSP across context switches. > >> > > The kernel consumes these MSRs, please see kernel CET patch: > > https://lkml.org/lkml/fancy/2018/11/20/225 > > Still, even if the kernel saves these fields across context switch in > XSAVE areas, KVM must support accesses to the MSRs from userspace, for > example in order to perform live migration. > > For example, when reading/writing these in kvm_set_msr or > kvm_get_msr_common, you would have to do a read/write from the host > MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls > in __msr_io. Paolo, can you elaborate on why KVM would read the host MSRs? Wouldn't kvm_{get,set}_msr() pull the values from the VMCS when necessary?
On 04/03/19 19:56, Sean Christopherson wrote: > On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote: >> On 28/01/19 11:33, Yang Weijiang wrote: >>>> There is no code in this series to pass these fields to and from >>>> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and >>>> PL3_SSP across context switches. >>>> >>> The kernel consumes these MSRs, please see kernel CET patch: >>> https://lkml.org/lkml/fancy/2018/11/20/225 >> >> Still, even if the kernel saves these fields across context switch in >> XSAVE areas, KVM must support accesses to the MSRs from userspace, for >> example in order to perform live migration. >> >> For example, when reading/writing these in kvm_set_msr or >> kvm_get_msr_common, you would have to do a read/write from the host >> MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls >> in __msr_io. > > Paolo, can you elaborate on why KVM would read the host MSRs? Wouldn't > kvm_{get,set}_msr() pull the values from the VMCS when necessary? Not all MSRs are in the VMCS; IA32_U_CET and IA32_PL*_SSP are not. Paolo
On Fri, Mar 08, 2019 at 10:15:15AM +0100, Paolo Bonzini wrote: > On 04/03/19 19:56, Sean Christopherson wrote: > > On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote: > >> On 28/01/19 11:33, Yang Weijiang wrote: > >>>> There is no code in this series to pass these fields to and from > >>>> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and > >>>> PL3_SSP across context switches. > >>>> > >>> The kernel consumes these MSRs, please see kernel CET patch: > >>> https://lkml.org/lkml/fancy/2018/11/20/225 > >> > >> Still, even if the kernel saves these fields across context switch in > >> XSAVE areas, KVM must support accesses to the MSRs from userspace, for > >> example in order to perform live migration. > >> > >> For example, when reading/writing these in kvm_set_msr or > >> kvm_get_msr_common, you would have to do a read/write from the host > >> MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls > >> in __msr_io. > > > > Paolo, can you elaborate on why KVM would read the host MSRs? Wouldn't > > kvm_{get,set}_msr() pull the values from the VMCS when necessary? > > Not all MSRs are in the VMCS; IA32_U_CET and IA32_PL*_SSP are not. Ah, "host MSRs" confused me. I though you meant the host's version of the MSRs, but you're saying do an XRSTORS to load the guest's FPU state and then {RD,WR}MSR to pull the guest's value from hardware.
On 08/03/19 16:50, Sean Christopherson wrote: > On Fri, Mar 08, 2019 at 10:15:15AM +0100, Paolo Bonzini wrote: >> On 04/03/19 19:56, Sean Christopherson wrote: >>> On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote: >>>> On 28/01/19 11:33, Yang Weijiang wrote: >>>>>> There is no code in this series to pass these fields to and from >>>>>> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and >>>>>> PL3_SSP across context switches. >>>>>> >>>>> The kernel consumes these MSRs, please see kernel CET patch: >>>>> https://lkml.org/lkml/fancy/2018/11/20/225 >>>> >>>> Still, even if the kernel saves these fields across context switch in >>>> XSAVE areas, KVM must support accesses to the MSRs from userspace, for >>>> example in order to perform live migration. >>>> >>>> For example, when reading/writing these in kvm_set_msr or >>>> kvm_get_msr_common, you would have to do a read/write from the host >>>> MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls >>>> in __msr_io. >>> >>> Paolo, can you elaborate on why KVM would read the host MSRs? Wouldn't >>> kvm_{get,set}_msr() pull the values from the VMCS when necessary? >> >> Not all MSRs are in the VMCS; IA32_U_CET and IA32_PL*_SSP are not. > > Ah, "host MSRs" confused me. I though you meant the host's version of > the MSRs, but you're saying do an XRSTORS to load the guest's FPU state > and then {RD,WR}MSR to pull the guest's value from hardware. Yes, that's what Weijang's patches are already doing in the next version. Paolo
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h index ade0f153947d..395c1f7e5938 100644 --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -98,6 +98,7 @@ #define VM_EXIT_LOAD_IA32_EFER 0x00200000 #define VM_EXIT_SAVE_VMX_PREEMPTION_TIMER 0x00400000 #define VM_EXIT_CLEAR_BNDCFGS 0x00800000 +#define VM_EXIT_LOAD_HOST_CET_STATE 0x10000000 #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff @@ -109,6 +110,7 @@ #define VM_ENTRY_LOAD_IA32_PAT 0x00004000 #define VM_ENTRY_LOAD_IA32_EFER 0x00008000 #define VM_ENTRY_LOAD_BNDCFGS 0x00010000 +#define VM_ENTRY_LOAD_GUEST_CET_STATE 0x00100000 #define VM_ENTRY_ALWAYSON_WITHOUT_TRUE_MSR 0x000011ff @@ -325,6 +327,9 @@ enum vmcs_field { GUEST_PENDING_DBG_EXCEPTIONS = 0x00006822, GUEST_SYSENTER_ESP = 0x00006824, GUEST_SYSENTER_EIP = 0x00006826, + GUEST_IA32_S_CET = 0x00006828, + GUEST_SSP = 0x0000682a, + GUEST_INTR_SSP_TABL_ADDR = 0x0000682c, HOST_CR0 = 0x00006c00, HOST_CR3 = 0x00006c02, HOST_CR4 = 0x00006c04, @@ -337,6 +342,9 @@ enum vmcs_field { HOST_IA32_SYSENTER_EIP = 0x00006c12, HOST_RSP = 0x00006c14, HOST_RIP = 0x00006c16, + HOST_IA32_S_CET = 0x00006c18, + HOST_SSP = 0x00006c1a, + HOST_INTR_SSP_TABL_ADDR = 0x00006c1c }; /*
On processors that support CET, VMX saves/restores the states of IA32_S_CET, SSP and IA32_INTERRUPT_SSP_TABLE_ADDR MSR to the VMCS area for Guest/Host unconditionally. If VM_EXIT_LOAD_HOST_CET_STATE = 1, the host CET MSRs are restored from VMCS host-state area at VM exit as follows: - HOST_IA32_S_CET: Host supervisor mode IA32_S_CET MSR is loaded from this field. - HOST_SSP : Host SSP is loaded from this field. - HOST_INTR_SSP_TABLE_ADDR : Host IA32_INTERRUPT_SSP_TABLE_ADDR MSR is loaded from this field. If VM_ENTRY_LOAD_GUEST_CET_STATE = 1, the guest CET MSRs are loaded from VMCS guest-state area at VM entry as follows: - GUEST_IA32_S_CET : Guest supervisor mode IA32_S_CET MSR is loaded from this field. - GUEST_SSP : Guest SSP is loaded from this field. - GUEST_INTR_SSP_TABL_ADDR : Guest IA32_INTERRUPT_SSP_TABLE_ADDR MSR is loaded from this field. Additionally, to context switch guest and host CET states, the VMM uses xsaves/xrstors instructions to save/restore the guest CET states at VM exit/entry. The CET xsave area is within thread_struct.fpu area. If OS execution flow changes during task switch/interrupt/exception etc., the OS also relies on xsaves/xrstors to switch CET states accordingly. Note: Although these VMCS fields are 64-bit, they don't have high fields. Signed-off-by: Zhang Yi Z <yi.z.zhang@linux.intel.com> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> --- arch/x86/include/asm/vmx.h | 8 ++++++++ 1 file changed, 8 insertions(+)