Documentation/virt/kvm/x86/nested-vmx.rst | 19 ++ arch/x86/include/asm/kvm_host.h | 9 +- arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/vmx.h | 32 ++- arch/x86/kvm/cpuid.c | 4 +- arch/x86/kvm/governed_features.h | 1 + arch/x86/kvm/kvm_cache_regs.h | 15 ++ arch/x86/kvm/svm/svm.c | 15 +- arch/x86/kvm/vmx/capabilities.h | 17 +- arch/x86/kvm/vmx/nested.c | 291 ++++++++++++++++---- arch/x86/kvm/vmx/nested.h | 8 + arch/x86/kvm/vmx/nested_vmcs_fields.h | 25 ++ arch/x86/kvm/vmx/vmcs.h | 1 + arch/x86/kvm/vmx/vmcs12.c | 19 ++ arch/x86/kvm/vmx/vmcs12.h | 38 +++ arch/x86/kvm/vmx/vmcs_shadow_fields.h | 37 ++- arch/x86/kvm/vmx/vmx.c | 308 +++++++++++++++++++--- arch/x86/kvm/vmx/vmx.h | 15 +- arch/x86/kvm/x86.c | 140 ++++++---- arch/x86/kvm/x86.h | 8 +- arch/x86/mm/cpu_entry_area.c | 1 + 21 files changed, 846 insertions(+), 158 deletions(-) create mode 100644 arch/x86/kvm/vmx/nested_vmcs_fields.h
This patch set enables the Intel flexible return and event delivery (FRED) architecture with KVM VMX to allow guests to utilize FRED. The FRED architecture defines simple new transitions that change privilege level (ring transitions). The FRED architecture was designed with the following goals: 1) Improve overall performance and response time by replacing event delivery through the interrupt descriptor table (IDT event delivery) and event return by the IRET instruction with lower latency transitions. 2) Improve software robustness by ensuring that event delivery establishes the full supervisor context and that event return establishes the full user context. The new transitions defined by the FRED architecture are FRED event delivery and, for returning from events, two FRED return instructions. FRED event delivery can effect a transition from ring 3 to ring 0, but it is used also to deliver events incident to ring 0. One FRED instruction (ERETU) effects a return from ring 0 to ring 3, while the other (ERETS) returns while remaining in ring 0. Collectively, FRED event delivery and the FRED return instructions are FRED transitions. Intel VMX architecture is extended to run FRED guests, and the major changes are: 1) New VMCS fields for FRED context management, which includes two new event data VMCS fields, eight new guest FRED context VMCS fields and eight new host FRED context VMCS fields. 2) VMX nested-exception support for proper virtualization of stack levels introduced with FRED architecture. Search for the latest FRED spec in most search engines with this search pattern: site:intel.com FRED (flexible return and event delivery) specification The first 20 patches add FRED support to VMX, and the rest 7 patches add FRED support to nested VMX. Following is the link to the v2 of this patch set: https://lore.kernel.org/kvm/20240207172646.3981-1-xin3.li@intel.com/ Sean Christopherson (3): KVM: x86: Use a dedicated flow for queueing re-injected exceptions KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1 KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM Xin Li (21): KVM: VMX: Add support for the secondary VM exit controls KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config KVM: VMX: Disable FRED if FRED consistency checks fail KVM: VMX: Initialize VMCS FRED fields KVM: x86: Use KVM-governed feature framework to track "FRED enabled" KVM: VMX: Set FRED MSR interception KVM: VMX: Save/restore guest FRED RSP0 KVM: VMX: Add support for FRED context save/restore KVM: x86: Add a helper to detect if FRED is enabled for a vCPU KVM: VMX: Virtualize FRED event_data KVM: VMX: Virtualize FRED nested exception tracking KVM: x86: Mark CR4.FRED as not reserved when guest can use FRED KVM: VMX: Dump FRED context in dump_vmcs() KVM: x86: Allow FRED/LKGS to be advertised to guests KVM: x86: Allow WRMSRNS to be advertised to guests KVM: VMX: Invoke vmx_set_cpu_caps() before nested setup KVM: nVMX: Add support for the secondary VM exit controls KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros KVM: nVMX: Add FRED VMCS fields KVM: nVMX: Add VMCS FRED states checking KVM: nVMX: Allow VMX FRED controls Xin Li (Intel) (3): x86/cea: Export per CPU variable cea_exception_stacks KVM: VMX: Do not use MAX_POSSIBLE_PASSTHROUGH_MSRS in array definition KVM: nVMX: Add a prerequisite to existence of VMCS fields Documentation/virt/kvm/x86/nested-vmx.rst | 19 ++ arch/x86/include/asm/kvm_host.h | 9 +- arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/vmx.h | 32 ++- arch/x86/kvm/cpuid.c | 4 +- arch/x86/kvm/governed_features.h | 1 + arch/x86/kvm/kvm_cache_regs.h | 15 ++ arch/x86/kvm/svm/svm.c | 15 +- arch/x86/kvm/vmx/capabilities.h | 17 +- arch/x86/kvm/vmx/nested.c | 291 ++++++++++++++++---- arch/x86/kvm/vmx/nested.h | 8 + arch/x86/kvm/vmx/nested_vmcs_fields.h | 25 ++ arch/x86/kvm/vmx/vmcs.h | 1 + arch/x86/kvm/vmx/vmcs12.c | 19 ++ arch/x86/kvm/vmx/vmcs12.h | 38 +++ arch/x86/kvm/vmx/vmcs_shadow_fields.h | 37 ++- arch/x86/kvm/vmx/vmx.c | 308 +++++++++++++++++++--- arch/x86/kvm/vmx/vmx.h | 15 +- arch/x86/kvm/x86.c | 140 ++++++---- arch/x86/kvm/x86.h | 8 +- arch/x86/mm/cpu_entry_area.c | 1 + 21 files changed, 846 insertions(+), 158 deletions(-) create mode 100644 arch/x86/kvm/vmx/nested_vmcs_fields.h base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc -- 2.46.2
On 9/30/2024 10:00 PM, Xin Li (Intel) wrote:
> This patch set enables the Intel flexible return and event delivery
> (FRED) architecture with KVM VMX to allow guests to utilize FRED.
>
> The FRED architecture defines simple new transitions that change
> privilege level (ring transitions). The FRED architecture was
> designed with the following goals:
>
> 1) Improve overall performance and response time by replacing event
> delivery through the interrupt descriptor table (IDT event
> delivery) and event return by the IRET instruction with lower
> latency transitions.
>
> 2) Improve software robustness by ensuring that event delivery
> establishes the full supervisor context and that event return
> establishes the full user context.
>
> The new transitions defined by the FRED architecture are FRED event
> delivery and, for returning from events, two FRED return instructions.
> FRED event delivery can effect a transition from ring 3 to ring 0, but
> it is used also to deliver events incident to ring 0. One FRED
> instruction (ERETU) effects a return from ring 0 to ring 3, while the
> other (ERETS) returns while remaining in ring 0. Collectively, FRED
> event delivery and the FRED return instructions are FRED transitions.
>
> Intel VMX architecture is extended to run FRED guests, and the major
> changes are:
>
> 1) New VMCS fields for FRED context management, which includes two new
> event data VMCS fields, eight new guest FRED context VMCS fields and
> eight new host FRED context VMCS fields.
>
> 2) VMX nested-exception support for proper virtualization of stack
> levels introduced with FRED architecture.
>
> Search for the latest FRED spec in most search engines with this search
> pattern:
>
> site:intel.com FRED (flexible return and event delivery) specification
>
> The first 20 patches add FRED support to VMX, and the rest 7 patches
> add FRED support to nested VMX.
>
>
> Following is the link to the v2 of this patch set:
> https://lore.kernel.org/kvm/20240207172646.3981-1-xin3.li@intel.com/
>
> Sean Christopherson (3):
> KVM: x86: Use a dedicated flow for queueing re-injected exceptions
> KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
> KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
>
> Xin Li (21):
> KVM: VMX: Add support for the secondary VM exit controls
> KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config
> KVM: VMX: Disable FRED if FRED consistency checks fail
> KVM: VMX: Initialize VMCS FRED fields
> KVM: x86: Use KVM-governed feature framework to track "FRED enabled"
> KVM: VMX: Set FRED MSR interception
> KVM: VMX: Save/restore guest FRED RSP0
> KVM: VMX: Add support for FRED context save/restore
> KVM: x86: Add a helper to detect if FRED is enabled for a vCPU
> KVM: VMX: Virtualize FRED event_data
> KVM: VMX: Virtualize FRED nested exception tracking
> KVM: x86: Mark CR4.FRED as not reserved when guest can use FRED
> KVM: VMX: Dump FRED context in dump_vmcs()
> KVM: x86: Allow FRED/LKGS to be advertised to guests
> KVM: x86: Allow WRMSRNS to be advertised to guests
> KVM: VMX: Invoke vmx_set_cpu_caps() before nested setup
> KVM: nVMX: Add support for the secondary VM exit controls
> KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros
> KVM: nVMX: Add FRED VMCS fields
> KVM: nVMX: Add VMCS FRED states checking
> KVM: nVMX: Allow VMX FRED controls
>
> Xin Li (Intel) (3):
> x86/cea: Export per CPU variable cea_exception_stacks
> KVM: VMX: Do not use MAX_POSSIBLE_PASSTHROUGH_MSRS in array definition
> KVM: nVMX: Add a prerequisite to existence of VMCS fields
Hi Sean,
While I'm waiting for the CET patches for native Linux and KVM to be
upstreamed, do you think if it's worth it for you to take the cleanup
and some of the preparation patches first?
Top of my mind are:
KVM: x86: Use a dedicated flow for queueing re-injected exceptions
KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
KVM: nVMX: Add a prerequisite to existence of VMCS fields
KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros
Then specially, the nested exception tracking patch seems a good one as
Chao Gao suggested to decouple the nested tracking from FRED:
KVM: VMX: Virtualize nested exception tracking
Lastly the patches to add support for the secondary VM exit controls
might go in early as well:
KVM: VMX: Add support for the secondary VM exit controls
KVM: nVMX: Add support for the secondary VM exit controls
But if you don't like the idea please just let me know.
Thanks!
Xin
On Tue, Feb 18, 2025, Xin Li wrote: > On 9/30/2024 10:00 PM, Xin Li (Intel) wrote: > While I'm waiting for the CET patches for native Linux and KVM to be > upstreamed, do you think if it's worth it for you to take the cleanup > and some of the preparation patches first? Yes, definitely. I'll go through the series and see what I can grab now. Thanks! > Top of my mind are: > KVM: x86: Use a dedicated flow for queueing re-injected exceptions > KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1 > KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM > KVM: nVMX: Add a prerequisite to existence of VMCS fields > KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros > > Then specially, the nested exception tracking patch seems a good one as > Chao Gao suggested to decouple the nested tracking from FRED: > KVM: VMX: Virtualize nested exception tracking > > Lastly the patches to add support for the secondary VM exit controls might > go in early as well: > KVM: VMX: Add support for the secondary VM exit controls > KVM: nVMX: Add support for the secondary VM exit controls > > But if you don't like the idea please just let me know. > > Thanks! > Xin
On 2/25/2025 7:24 AM, Sean Christopherson wrote:
> On Tue, Feb 18, 2025, Xin Li wrote:
>> On 9/30/2024 10:00 PM, Xin Li (Intel) wrote:
>> While I'm waiting for the CET patches for native Linux and KVM to be
>> upstreamed, do you think if it's worth it for you to take the cleanup
>> and some of the preparation patches first?
>
> Yes, definitely. I'll go through the series and see what I can grab now.
I planned to do a rebase and fix the conflicts due to the reordering.
But I'm more than happy you do a first round.
BTW, if you plan to take
KVM: VMX: Virtualize nested exception tracking
Then as Gao Chao suggested we also need a patch to Save/restore the
nested flag of an exception (obviously a corresponding host patch is
needed). Following is a version that I have.
Thanks!
Xin
---
KVM: x86: Save/restore the nested flag of an exception
Save/restore the nested flag of an exception during VM save/restore
and live migration to ensure a correct event stack level is chosen
when a nested exception is injected through FRED event delivery.
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
---
Change since v3:
* Add live migration support for exception nested flag (Chao Gao).
---
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 2b52eb77e29c..ed171fa6926f 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -1180,6 +1180,10 @@ The following bits are defined in the flags field:
fields contain a valid state. This bit will be set whenever
KVM_CAP_EXCEPTION_PAYLOAD is enabled.
+- KVM_VCPUEVENT_VALID_NESTED_FLAG may be set to inform that the
+ exception is a nested exception. This bit will be set whenever
+ KVM_CAP_EXCEPTION_NESTED_FLAG is enabled.
+
- KVM_VCPUEVENT_VALID_TRIPLE_FAULT may be set to signal that the
triple_fault_pending field contains a valid state. This bit will
be set whenever KVM_CAP_X86_TRIPLE_FAULT_EVENT is enabled.
@@ -1279,6 +1283,10 @@ can be set in the flags field to signal that the
exception_has_payload, exception_payload, and exception.pending fields
contain a valid state and shall be written into the VCPU.
+If KVM_CAP_EXCEPTION_NESTED_FLAG is enabled,
KVM_VCPUEVENT_VALID_NESTED_FLAG
+can be set in the flags field to inform that the exception is a nested
+exception and exception_is_nested shall be written into the VCPU.
+
If KVM_CAP_X86_TRIPLE_FAULT_EVENT is enabled,
KVM_VCPUEVENT_VALID_TRIPLE_FAULT
can be set in flags field to signal that the triple_fault field contains
a valid state and shall be written into the VCPU.
@@ -8258,6 +8266,17 @@ KVM exits with the register state of either the
L1 or L2 guest
depending on which executed at the time of an exit. Userspace must
take care to differentiate between these cases.
+7.37 KVM_CAP_EXCEPTION_NESTED_FLAG
+----------------------------------
+
+:Architectures: x86
+:Parameters: args[0] whether feature should be enabled or not
+
+With this capability enabled, an exception is save/restored with the
+additional information of whether it was nested or not. FRED event
+delivery uses this information to ensure a correct event stack level
+is chosen when a VM entry injects a nested exception.
+
8. Other capabilities.
======================
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h
index 4cfe1b8f4547..ede2319cee45 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1441,6 +1441,7 @@ struct kvm_arch {
bool guest_can_read_msr_platform_info;
bool exception_payload_enabled;
+ bool exception_nested_flag_enabled;
bool triple_fault_event;
diff --git a/arch/x86/include/uapi/asm/kvm.h
b/arch/x86/include/uapi/asm/kvm.h
index 9e75da97bce0..f5167e3a7d0f 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -326,6 +326,7 @@ struct kvm_reinject_control {
#define KVM_VCPUEVENT_VALID_SMM 0x00000008
#define KVM_VCPUEVENT_VALID_PAYLOAD 0x00000010
#define KVM_VCPUEVENT_VALID_TRIPLE_FAULT 0x00000020
+#define KVM_VCPUEVENT_VALID_NESTED_FLAG 0x00000040
/* Interrupt shadow states */
#define KVM_X86_SHADOW_INT_MOV_SS 0x01
@@ -363,7 +364,8 @@ struct kvm_vcpu_events {
struct {
__u8 pending;
} triple_fault;
- __u8 reserved[26];
+ __u8 reserved[25];
+ __u8 exception_is_nested;
__u8 exception_has_payload;
__u64 exception_payload;
};
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 01c945b27f01..80a9fa6ab720 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4675,6 +4675,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm,
long ext)
case KVM_CAP_GET_MSR_FEATURES:
case KVM_CAP_MSR_PLATFORM_INFO:
case KVM_CAP_EXCEPTION_PAYLOAD:
+ case KVM_CAP_EXCEPTION_NESTED_FLAG:
case KVM_CAP_X86_TRIPLE_FAULT_EVENT:
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_LAST_CPU:
@@ -5401,6 +5402,7 @@ static void
kvm_vcpu_ioctl_x86_get_vcpu_events(struct kvm_vcpu *vcpu,
events->exception.error_code = ex->error_code;
events->exception_has_payload = ex->has_payload;
events->exception_payload = ex->payload;
+ events->exception_is_nested = ex->nested;
events->interrupt.injected =
vcpu->arch.interrupt.injected && !vcpu->arch.interrupt.soft;
@@ -5426,6 +5428,8 @@ static void
kvm_vcpu_ioctl_x86_get_vcpu_events(struct kvm_vcpu *vcpu,
| KVM_VCPUEVENT_VALID_SMM);
if (vcpu->kvm->arch.exception_payload_enabled)
events->flags |= KVM_VCPUEVENT_VALID_PAYLOAD;
+ if (vcpu->kvm->arch.exception_nested_flag_enabled)
+ events->flags |= KVM_VCPUEVENT_VALID_NESTED_FLAG;
if (vcpu->kvm->arch.triple_fault_event) {
events->triple_fault.pending =
kvm_test_request(KVM_REQ_TRIPLE_FAULT, vcpu);
events->flags |= KVM_VCPUEVENT_VALID_TRIPLE_FAULT;
@@ -5440,7 +5444,8 @@ static int
kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu,
| KVM_VCPUEVENT_VALID_SHADOW
| KVM_VCPUEVENT_VALID_SMM
| KVM_VCPUEVENT_VALID_PAYLOAD
- | KVM_VCPUEVENT_VALID_TRIPLE_FAULT))
+ | KVM_VCPUEVENT_VALID_TRIPLE_FAULT
+ | KVM_VCPUEVENT_VALID_NESTED_FLAG))
return -EINVAL;
if (events->flags & KVM_VCPUEVENT_VALID_PAYLOAD) {
@@ -5455,6 +5460,13 @@ static int
kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu,
events->exception_has_payload = 0;
}
+ if (events->flags & KVM_VCPUEVENT_VALID_NESTED_FLAG) {
+ if (!vcpu->kvm->arch.exception_nested_flag_enabled)
+ return -EINVAL;
+ } else {
+ events->exception_is_nested = 0;
+ }
+
if ((events->exception.injected || events->exception.pending) &&
(events->exception.nr > 31 || events->exception.nr == NMI_VECTOR))
return -EINVAL;
@@ -5486,6 +5498,7 @@ static int
kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu,
vcpu->arch.exception.error_code = events->exception.error_code;
vcpu->arch.exception.has_payload = events->exception_has_payload;
vcpu->arch.exception.payload = events->exception_payload;
+ vcpu->arch.exception.nested = events->exception_is_nested;
vcpu->arch.interrupt.injected = events->interrupt.injected;
vcpu->arch.interrupt.nr = events->interrupt.nr;
@@ -6609,6 +6622,10 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
kvm->arch.exception_payload_enabled = cap->args[0];
r = 0;
break;
+ case KVM_CAP_EXCEPTION_NESTED_FLAG:
+ kvm->arch.exception_nested_flag_enabled = cap->args[0];
+ r = 0;
+ break;
case KVM_CAP_X86_TRIPLE_FAULT_EVENT:
kvm->arch.triple_fault_event = cap->args[0];
r = 0;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 45e6d8fca9b9..b79f3c10a887 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -929,6 +929,7 @@ struct kvm_enable_cap {
#define KVM_CAP_PRE_FAULT_MEMORY 236
#define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237
#define KVM_CAP_X86_GUEST_MODE 238
+#define KVM_CAP_EXCEPTION_NESTED_FLAG 239
struct kvm_irq_routing_irqchip {
__u32 irqchip;
>
> Thanks!
>
>> Top of my mind are:
>> KVM: x86: Use a dedicated flow for queueing re-injected exceptions
>> KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
>> KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
>> KVM: nVMX: Add a prerequisite to existence of VMCS fields
>> KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros
>>
>> Then specially, the nested exception tracking patch seems a good one as
>> Chao Gao suggested to decouple the nested tracking from FRED:
>> KVM: VMX: Virtualize nested exception tracking
>>
>> Lastly the patches to add support for the secondary VM exit controls might
>> go in early as well:
>> KVM: VMX: Add support for the secondary VM exit controls
>> KVM: nVMX: Add support for the secondary VM exit controls
>>
>> But if you don't like the idea please just let me know.
>>
>> Thanks!
>> Xin
>
On Tue, Feb 25, 2025, Xin Li wrote: > On 2/25/2025 7:24 AM, Sean Christopherson wrote: > > On Tue, Feb 18, 2025, Xin Li wrote: > > > On 9/30/2024 10:00 PM, Xin Li (Intel) wrote: > > > While I'm waiting for the CET patches for native Linux and KVM to be > > > upstreamed, do you think if it's worth it for you to take the cleanup > > > and some of the preparation patches first? > > > > Yes, definitely. I'll go through the series and see what I can grab now. > > I planned to do a rebase and fix the conflicts due to the reordering. > But I'm more than happy you do a first round. For now, I'm only going to grab these: KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1 KVM: x86: Use a dedicated flow for queueing re-injected exceptions and the WRMSRNS patch. I'll post (and apply, if it looks good) the entry/exit pairs patch separately. Easiest thing would be to rebase when all of those hit kvm-x86/next. > BTW, if you plan to take > KVM: VMX: Virtualize nested exception tracking I'm not planning on grabbing this in advance of the FRED series, especially if it's adding new uAPI. The code doesn't need to exist without FRED, and doesn't really make much sense to readers without the context of FRED. > > > Top of my mind are: > > > KVM: x86: Use a dedicated flow for queueing re-injected exceptions > > > KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1 > > > KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM As above, I'll grab these now. > > > KVM: nVMX: Add a prerequisite to existence of VMCS fields > > > KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros Unless there's a really, really good reason to add precise checking, I strongly prefer to skip these entirely. > > > > > > Then specially, the nested exception tracking patch seems a good one as > > > Chao Gao suggested to decouple the nested tracking from FRED: > > > KVM: VMX: Virtualize nested exception tracking > > > > > > Lastly the patches to add support for the secondary VM exit controls might > > > go in early as well: > > > KVM: VMX: Add support for the secondary VM exit controls > > > KVM: nVMX: Add support for the secondary VM exit controls Unless there's another feature on the horizon that depends on secondary exit controls, (and y'all will be posted patches soon), I'd prefer just grab these in the FRED series. With the pairs check prep work out of the way, adding support for the new controls should be very straightforward, and shouldn't conflict with anything.
On 2/25/2025 9:35 AM, Sean Christopherson wrote:
> On Tue, Feb 25, 2025, Xin Li wrote:
>> On 2/25/2025 7:24 AM, Sean Christopherson wrote:
>>> On Tue, Feb 18, 2025, Xin Li wrote:
>>>> On 9/30/2024 10:00 PM, Xin Li (Intel) wrote:
>>>> While I'm waiting for the CET patches for native Linux and KVM to be
>>>> upstreamed, do you think if it's worth it for you to take the cleanup
>>>> and some of the preparation patches first?
>>>
>>> Yes, definitely. I'll go through the series and see what I can grab now.
>>
>> I planned to do a rebase and fix the conflicts due to the reordering.
>> But I'm more than happy you do a first round.
>
> For now, I'm only going to grab these:
>
> KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
> KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
> KVM: x86: Use a dedicated flow for queueing re-injected exceptions
>
> and the WRMSRNS patch. I'll post (and apply, if it looks good) the entry/exit
> pairs patch separately.
>
> Easiest thing would be to rebase when all of those hit kvm-x86/next.
Excellent!
>
>> BTW, if you plan to take
>> KVM: VMX: Virtualize nested exception tracking
>
> I'm not planning on grabbing this in advance of the FRED series, especially if
> it's adding new uAPI. The code doesn't need to exist without FRED, and doesn't
> really make much sense to readers without the context of FRED.
Sounds reasonable.
>
>>>> Top of my mind are:
>>>> KVM: x86: Use a dedicated flow for queueing re-injected exceptions
>>>> KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
>>>> KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
>
> As above, I'll grab these now.
>
>>>> KVM: nVMX: Add a prerequisite to existence of VMCS fields
>>>> KVM: nVMX: Add a prerequisite to SHADOW_FIELD_R[OW] macros
>
> Unless there's a really, really good reason to add precise checking, I strongly
> prefer to skip these entirely.
>
They are to make kvm-unit-tests happy, as if we have a ground rule, it's
clear that we don't need them.
They can be used to detect whether an OS is running on a VMM or bare
metal, but do we really care the difference? -- We probably care if we
live in a virtual reality ;-)
>>>>
>>>> Then specially, the nested exception tracking patch seems a good one as
>>>> Chao Gao suggested to decouple the nested tracking from FRED:
>>>> KVM: VMX: Virtualize nested exception tracking
>>>>
>>>> Lastly the patches to add support for the secondary VM exit controls might
>>>> go in early as well:
>>>> KVM: VMX: Add support for the secondary VM exit controls
>>>> KVM: nVMX: Add support for the secondary VM exit controls
>
> Unless there's another feature on the horizon that depends on secondary exit controls,
> (and y'all will be posted patches soon), I'd prefer just grab these in the FRED
> series. With the pairs check prep work out of the way, adding support for the
> new controls should be very straightforward, and shouldn't conflict with anything.
NP.
Thanks!
Xin
On Mon, 30 Sep 2024 22:00:43 -0700, Xin Li (Intel) wrote:
> This patch set enables the Intel flexible return and event delivery
> (FRED) architecture with KVM VMX to allow guests to utilize FRED.
>
> The FRED architecture defines simple new transitions that change
> privilege level (ring transitions). The FRED architecture was
> designed with the following goals:
>
> [...]
Applied
[01/27] KVM: x86: Use a dedicated flow for queueing re-injected exceptions
https://github.com/kvm-x86/linux/commit/b50cb2b1555d
to kvm-x86 misc, and
[02/27] KVM: VMX: Don't modify guest XFD_ERR if CR0.TS=1
https://github.com/kvm-x86/linux/commit/3ef0df3f760f
[14/27] KVM: VMX: Pass XFD_ERR as pseudo-payload when injecting #NM
https://github.com/kvm-x86/linux/commit/d62c02af7a96k
to kvm-x86 vmx.
--
https://github.com/kvm-x86/linux/tree/next
© 2016 - 2026 Red Hat, Inc.