[PATCH 0/7] KVM: SVM: Enable FRED support

[PATCH 0/7] KVM: SVM: Enable FRED support

[Shivansh Dhiman]

This series adds SVM support for FRED (Flexible Return and Event Delivery)
virtualization in KVM.

FRED introduces simplified privilege level transitions to replace IDT-based
event delivery and IRET returns, providing lower latency event handling while
ensuring complete supervisor context on delivery and full user context on
return. FRED defines event delivery for both ring 3->0 and ring 0->0
transitions, and introduces ERETU for returning to ring 3 and ERETS for
remaining in ring 0.

AMD hardware extends the VMCB to support FRED virtualization with dedicated
save area fields for FRED MSRs (RSP0-3, SSP1-3, STKLVLS, CONFIG) and control
fields for event injection data (EXITINTDATA, EVENTINJDATA).

The implementation spans seven patches. The important changes are:

1) Extend VMCB structures with FRED fields mentioned above and disable MSR
   interception for FRED-enabled guests to avoid unnecessary VM exits.

2) Support for nested exceptions where we populate event injection data
   when delivering exceptions like page faults and debug traps. 

This series is based on top of FRED support for VMX patchset [1],
patches 1-17. The VMX patchset was rebased on top of v6.18.0 kernel.

[1] https://lore.kernel.org/kvm/20251026201911.505204-1-xin@zytor.com

Regards,
Shivansh
---
Neeraj Upadhyay (5):
  KVM: SVM: Initialize FRED VMCB fields
  KVM: SVM: Disable interception of FRED MSRs for FRED supported guests
  KVM: SVM: Save restore FRED_RSP0 for FRED supported guests
  KVM: SVM: Populate FRED event data on event injection
  KVM: SVM: Support FRED nested exception injection

Shivansh Dhiman (2):
  KVM: SVM: Dump FRED context in dump_vmcb()
  KVM: SVM: Enable save/restore of FRED MSRs

 arch/x86/include/asm/svm.h |  35 ++++++++++-
 arch/x86/kvm/svm/svm.c     | 116 +++++++++++++++++++++++++++++++++++--
 2 files changed, 144 insertions(+), 7 deletions(-)


base-commit: f76e83ecf6bce6d3793f828d92170b69e636f3c9
-- 
2.43.0

[PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Shivansh Dhiman]

From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>

The upcoming AMD FRED (Flexible Return and Event Delivery) feature
introduces several new fields to the VMCB save area. These fields include
FRED-specific stack pointers (fred_rsp[0-3], fred_ssp[1-3]), stack level
tracking (fred_stklvls), and configuration (fred_config).

Ensure that a vCPU starts with a clean and valid FRED state on
capable hardware. Also update the size of save areas of VMCB.

Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
---
 arch/x86/include/asm/svm.h | 33 ++++++++++++++++++++++++++++++---
 arch/x86/kvm/svm/svm.c     | 10 ++++++++++
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 17f6c3fedeee..a42ed39aa8fb 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -165,7 +165,10 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
 	u8 reserved_9[22];
 	u64 allowed_sev_features;	/* Offset 0x138 */
 	u64 guest_sev_features;		/* Offset 0x140 */
-	u8 reserved_10[664];
+	u8 reserved_10[40];
+	u64 exit_int_data;		/* Offset 0x170 */
+	u64 event_inj_data;
+	u8 reserved_11[608];
 	/*
 	 * Offset 0x3e0, 32 bytes reserved
 	 * for use by hypervisor/software.
@@ -360,6 +363,18 @@ struct vmcb_save_area {
 	u64 last_excp_to;
 	u8 reserved_0x298[72];
 	u64 spec_ctrl;		/* Guest version of SPEC_CTRL at 0x2E0 */
+	u8 reserved_0x2e8[448];
+	u64 guest_exit_int_data;        /* GUEST_EXITINTDATA 0x4A8 */
+	u64 guest_event_inj_data;
+	u64 fred_rsp0;
+	u64 fred_rsp1;
+	u64 fred_rsp2;
+	u64 fred_rsp3;
+	u64 fred_stklvls;
+	u64 fred_ssp1;
+	u64 fred_ssp2;
+	u64 fred_ssp3;
+	u64 fred_config;
 } __packed;
 
 /* Save area definition for SEV-ES and SEV-SNP guests */
@@ -472,6 +487,18 @@ struct sev_es_save_area {
 	u8 fpreg_x87[80];
 	u8 fpreg_xmm[256];
 	u8 fpreg_ymm[256];
+	u8 reserved_0x670[568];
+	u64 guest_exit_int_data;        /* GUEST_EXITINTDATA 0x8A8 */
+	u64 guest_event_inj_data;
+	u64 fred_rsp0;
+	u64 fred_rsp1;
+	u64 fred_rsp2;
+	u64 fred_rsp3;
+	u64 fred_stklvls;
+	u64 fred_ssp1;
+	u64 fred_ssp2;
+	u64 fred_ssp3;
+	u64 fred_config;
 } __packed;
 
 struct ghcb_save_area {
@@ -542,9 +569,9 @@ struct vmcb {
 	};
 } __packed;
 
-#define EXPECTED_VMCB_SAVE_AREA_SIZE		744
+#define EXPECTED_VMCB_SAVE_AREA_SIZE		1280
 #define EXPECTED_GHCB_SAVE_AREA_SIZE		1032
-#define EXPECTED_SEV_ES_SAVE_AREA_SIZE		1648
+#define EXPECTED_SEV_ES_SAVE_AREA_SIZE		2304
 #define EXPECTED_VMCB_CONTROL_AREA_SIZE		1024
 #define EXPECTED_GHCB_SIZE			PAGE_SIZE
 
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index f4ccb3e66635..5cec971a1f5a 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1110,6 +1110,16 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
 	save->idtr.base = 0;
 	save->idtr.limit = 0xffff;
 
+	save->fred_rsp0 = 0;
+	save->fred_rsp1 = 0;
+	save->fred_rsp2 = 0;
+	save->fred_rsp3 = 0;
+	save->fred_stklvls = 0;
+	save->fred_ssp1 = 0;
+	save->fred_ssp2 = 0;
+	save->fred_ssp3 = 0;
+	save->fred_config = 0;
+
 	init_sys_seg(&save->ldtr, SEG_TYPE_LDT);
 	init_sys_seg(&save->tr, SEG_TYPE_BUSY_TSS16);
 
-- 
2.43.0

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Sean Christopherson]

On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> 
> The upcoming AMD FRED (Flexible Return and Event Delivery) feature
> introduces several new fields to the VMCB save area. These fields include
> FRED-specific stack pointers (fred_rsp[0-3], fred_ssp[1-3]), stack level
> tracking (fred_stklvls), and configuration (fred_config).
> 
> Ensure that a vCPU starts with a clean and valid FRED state on
> capable hardware. Also update the size of save areas of VMCB.

> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index f4ccb3e66635..5cec971a1f5a 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1110,6 +1110,16 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
>  	save->idtr.base = 0;
>  	save->idtr.limit = 0xffff;
>  
> +	save->fred_rsp0 = 0;
> +	save->fred_rsp1 = 0;
> +	save->fred_rsp2 = 0;
> +	save->fred_rsp3 = 0;
> +	save->fred_stklvls = 0;
> +	save->fred_ssp1 = 0;
> +	save->fred_ssp2 = 0;
> +	save->fred_ssp3 = 0;
> +	save->fred_config = 0;

Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Shivansh Dhiman]

Hey Sean,

On 07-03-2026 07:28, Sean Christopherson wrote:
> On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
>> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
>>
>> The upcoming AMD FRED (Flexible Return and Event Delivery) feature
>> introduces several new fields to the VMCB save area. These fields include
>> FRED-specific stack pointers (fred_rsp[0-3], fred_ssp[1-3]), stack level
>> tracking (fred_stklvls), and configuration (fred_config).
>>
>> Ensure that a vCPU starts with a clean and valid FRED state on
>> capable hardware. Also update the size of save areas of VMCB.
> 
>> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
>> index f4ccb3e66635..5cec971a1f5a 100644
>> --- a/arch/x86/kvm/svm/svm.c
>> +++ b/arch/x86/kvm/svm/svm.c
>> @@ -1110,6 +1110,16 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
>>  	save->idtr.base = 0;
>>  	save->idtr.limit = 0xffff;
>>  
>> +	save->fred_rsp0 = 0;
>> +	save->fred_rsp1 = 0;
>> +	save->fred_rsp2 = 0;
>> +	save->fred_rsp3 = 0;
>> +	save->fred_stklvls = 0;
>> +	save->fred_ssp1 = 0;
>> +	save->fred_ssp2 = 0;
>> +	save->fred_ssp3 = 0;
>> +	save->fred_config = 0;
> 
> Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?

Yes that's right, the FRED MSRs are zeroed on init.

- Shivansh

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Sean Christopherson]

On Mon, Mar 09, 2026, Shivansh Dhiman wrote:
> Hey Sean,
> 
> On 07-03-2026 07:28, Sean Christopherson wrote:
> > On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> >> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> >>
> >> The upcoming AMD FRED (Flexible Return and Event Delivery) feature
> >> introduces several new fields to the VMCB save area. These fields include
> >> FRED-specific stack pointers (fred_rsp[0-3], fred_ssp[1-3]), stack level
> >> tracking (fred_stklvls), and configuration (fred_config).
> >>
> >> Ensure that a vCPU starts with a clean and valid FRED state on
> >> capable hardware. Also update the size of save areas of VMCB.
> > 
> >> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> >> index f4ccb3e66635..5cec971a1f5a 100644
> >> --- a/arch/x86/kvm/svm/svm.c
> >> +++ b/arch/x86/kvm/svm/svm.c
> >> @@ -1110,6 +1110,16 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
> >>  	save->idtr.base = 0;
> >>  	save->idtr.limit = 0xffff;
> >>  
> >> +	save->fred_rsp0 = 0;
> >> +	save->fred_rsp1 = 0;
> >> +	save->fred_rsp2 = 0;
> >> +	save->fred_rsp3 = 0;
> >> +	save->fred_stklvls = 0;
> >> +	save->fred_ssp1 = 0;
> >> +	save->fred_ssp2 = 0;
> >> +	save->fred_ssp3 = 0;
> >> +	save->fred_config = 0;
> > 
> > Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?
> 
> Yes that's right, the FRED MSRs are zeroed on init.

Please use that as the basis for the changelog.  "Ensure that a vCPU starts with
a clean and valid FRED state on capable hardware" is largely meaningless because
vCPU structures are zero-allocated.

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Shivansh Dhiman]

On 10-03-2026 00:27, Sean Christopherson wrote:
>>>> +	save->fred_rsp0 = 0;
>>>> +	save->fred_rsp1 = 0;
>>>> +	save->fred_rsp2 = 0;
>>>> +	save->fred_rsp3 = 0;
>>>> +	save->fred_stklvls = 0;
>>>> +	save->fred_ssp1 = 0;
>>>> +	save->fred_ssp2 = 0;
>>>> +	save->fred_ssp3 = 0;
>>>> +	save->fred_config = 0;
>>>
>>> Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?
>>
>> Yes that's right, the FRED MSRs are zeroed on init.
> 
> Please use that as the basis for the changelog.  "Ensure that a vCPU starts with
> a clean and valid FRED state on capable hardware" is largely meaningless because
> vCPU structures are zero-allocated.

Will do. Thanks for pointing out.

- Shivansh

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Shivansh Dhiman]

Hi,

On 09-03-2026 23:16, Shivansh Dhiman wrote:
> Hey Sean,
> 
> On 07-03-2026 07:28, Sean Christopherson wrote:
>> On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
>>> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
>>>
>>> The upcoming AMD FRED (Flexible Return and Event Delivery) feature
>>> introduces several new fields to the VMCB save area. These fields include
>>> FRED-specific stack pointers (fred_rsp[0-3], fred_ssp[1-3]), stack level
>>> tracking (fred_stklvls), and configuration (fred_config).
>>>
>>> Ensure that a vCPU starts with a clean and valid FRED state on
>>> capable hardware. Also update the size of save areas of VMCB.
>>
>>> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
>>> index f4ccb3e66635..5cec971a1f5a 100644
>>> --- a/arch/x86/kvm/svm/svm.c
>>> +++ b/arch/x86/kvm/svm/svm.c
>>> @@ -1110,6 +1110,16 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
>>>  	save->idtr.base = 0;
>>>  	save->idtr.limit = 0xffff;
>>>  
>>> +	save->fred_rsp0 = 0;
>>> +	save->fred_rsp1 = 0;
>>> +	save->fred_rsp2 = 0;
>>> +	save->fred_rsp3 = 0;
>>> +	save->fred_stklvls = 0;
>>> +	save->fred_ssp1 = 0;
>>> +	save->fred_ssp2 = 0;
>>> +	save->fred_ssp3 = 0;
>>> +	save->fred_config = 0;
>>
>> Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?
> 
> Yes that's right, the FRED MSRs are zeroed on init.

I would like to correct my earlier statement. After consulting with the hardware
folks, it turns out the FRED MSRs are not zeroed on INIT, instead they are left
unchanged. I had incorrectly mixed up the INIT behavior with RESET values in my
previous reply. Apologies for the confusion.

I'll rework this patch so that the FRED MSR initialization is only applied on
RESET and not on INIT events. v2 will address this soon.

- Shivansh

> 
> - Shivansh
> 

[PATCH 2/7] KVM: SVM: Disable interception of FRED MSRs for FRED supported guests

[Shivansh Dhiman]

From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>

The FRED (Flexible Return and Event Delivery) feature introduces a new set
of MSRs for managing its state, such as MSR_IA32_FRED_CONFIG and the
various stack pointer MSRs.

For a guest that has FRED enabled via its CPUID bits, the guest OS
expects to be able to directly read and write these MSRs. Intercepting
these accesses would cause unnecessary VM-Exits and performance overhead.
In addition, the state of the MSRs at any point should always correspond
to the context (host or guest) which is running. Otherwise, the event
delivery could refer to wrong MSR values.

Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 arch/x86/include/asm/svm.h |  1 +
 arch/x86/kvm/svm/svm.c     | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index a42ed39aa8fb..c2f3e03e1f4b 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -224,6 +224,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
 
 #define LBR_CTL_ENABLE_MASK BIT_ULL(0)
 #define VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK BIT_ULL(1)
+#define FRED_VIRT_ENABLE_MASK BIT_ULL(4)
 
 #define SVM_INTERRUPT_SHADOW_MASK	BIT_ULL(0)
 #define SVM_GUEST_INTERRUPT_MASK	BIT_ULL(1)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 5cec971a1f5a..05e44e804aba 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -727,6 +727,22 @@ void svm_vcpu_free_msrpm(void *msrpm)
 	__free_pages(virt_to_page(msrpm), get_order(MSRPM_SIZE));
 }
 
+static void svm_recalc_fred_msr_intercepts(struct kvm_vcpu *vcpu)
+{
+	struct vcpu_svm *svm = to_svm(vcpu);
+	bool fred_enabled = svm->vmcb->control.virt_ext & FRED_VIRT_ENABLE_MASK;
+
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP0, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP1, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP2, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP3, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_STKLVLS, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP1, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP2, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP3, MSR_TYPE_RW, !fred_enabled);
+	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_CONFIG, MSR_TYPE_RW, !fred_enabled);
+}
+
 static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
@@ -795,6 +811,8 @@ static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
 	if (sev_es_guest(vcpu->kvm))
 		sev_es_recalc_msr_intercepts(vcpu);
 
+	svm_recalc_fred_msr_intercepts(vcpu);
+
 	/*
 	 * x2APIC intercepts are modified on-demand and cannot be filtered by
 	 * userspace.
-- 
2.43.0

Re: [PATCH 2/7] KVM: SVM: Disable interception of FRED MSRs for FRED supported guests

[Sean Christopherson]

On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> +static void svm_recalc_fred_msr_intercepts(struct kvm_vcpu *vcpu)
> +{
> +	struct vcpu_svm *svm = to_svm(vcpu);
> +	bool fred_enabled = svm->vmcb->control.virt_ext & FRED_VIRT_ENABLE_MASK;

Please use guest_cpu_cap_has().  The VMCB enable bit is a reflection of the
guest's capabilities, not the other way around.

And s/fred_enabled/intercept.

> +
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP0, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP1, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP2, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP3, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_STKLVLS, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP1, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP2, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP3, MSR_TYPE_RW, !fred_enabled);
> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_CONFIG, MSR_TYPE_RW, !fred_enabled);
> +}
> +
>  static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
>  {
>  	struct vcpu_svm *svm = to_svm(vcpu);
> @@ -795,6 +811,8 @@ static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
>  	if (sev_es_guest(vcpu->kvm))
>  		sev_es_recalc_msr_intercepts(vcpu);
>  
> +	svm_recalc_fred_msr_intercepts(vcpu);
> +
>  	/*
>  	 * x2APIC intercepts are modified on-demand and cannot be filtered by
>  	 * userspace.
> -- 
> 2.43.0
> 

Re: [PATCH 2/7] KVM: SVM: Disable interception of FRED MSRs for FRED supported guests

[Shivansh Dhiman]

On 07-03-2026 07:40, Sean Christopherson wrote:
> On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
>> +static void svm_recalc_fred_msr_intercepts(struct kvm_vcpu *vcpu)
>> +{
>> +	struct vcpu_svm *svm = to_svm(vcpu);
>> +	bool fred_enabled = svm->vmcb->control.virt_ext & FRED_VIRT_ENABLE_MASK;
> 
> Please use guest_cpu_cap_has().  The VMCB enable bit is a reflection of the
> guest's capabilities, not the other way around.

That makes sense. Will do.

> 
> And s/fred_enabled/intercept.

Ack.

- Shivansh

> 
>> +
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP0, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP1, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP2, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_RSP3, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_STKLVLS, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP1, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP2, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_SSP3, MSR_TYPE_RW, !fred_enabled);
>> +	svm_set_intercept_for_msr(vcpu, MSR_IA32_FRED_CONFIG, MSR_TYPE_RW, !fred_enabled);
>> +}
>> +
>>  static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
>>  {
>>  	struct vcpu_svm *svm = to_svm(vcpu);
>> @@ -795,6 +811,8 @@ static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
>>  	if (sev_es_guest(vcpu->kvm))
>>  		sev_es_recalc_msr_intercepts(vcpu);
>>  
>> +	svm_recalc_fred_msr_intercepts(vcpu);
>> +
>>  	/*
>>  	 * x2APIC intercepts are modified on-demand and cannot be filtered by
>>  	 * userspace.
>> -- 
>> 2.43.0
>>

[PATCH 3/7] KVM: SVM: Save restore FRED_RSP0 for FRED supported guests

[Shivansh Dhiman]

From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>

Hardware does not save/restore FRED_RSP0 for Non-SEV-ES guests.
Save/restore it early in svm_vcpu_enter_exit() so that the
correct physical CPU state is updated.

Synchronize the current value of MSR_IA32_FRED_RSP0 in hardware to the kernel's
local cache. Note that the desired host's RSP0 will be set when the CPU exits to
userspace for servicing vCPU tasks.

Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 arch/x86/kvm/svm/svm.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 05e44e804aba..ddd8941af6f0 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4192,6 +4192,15 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu, bool spec_ctrl_in
 {
 	struct svm_cpu_data *sd = per_cpu_ptr(&svm_data, vcpu->cpu);
 	struct vcpu_svm *svm = to_svm(vcpu);
+	bool update_fred_rsp0;
+
+	/*
+	 * Hardware does not save/restore FRED_RSP0 for Non-SEV-ES guests.
+	 */
+	update_fred_rsp0 = !sev_es_guest(vcpu->kvm) && guest_cpu_cap_has(vcpu, X86_FEATURE_FRED);
+
+	if (update_fred_rsp0)
+		wrmsrq(MSR_IA32_FRED_RSP0, svm->vmcb->save.fred_rsp0);
 
 	guest_state_enter_irqoff();
 
@@ -4218,6 +4227,15 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu, bool spec_ctrl_in
 	raw_local_irq_disable();
 
 	guest_state_exit_irqoff();
+
+	if (update_fred_rsp0) {
+		rdmsrq(MSR_IA32_FRED_RSP0, svm->vmcb->save.fred_rsp0);
+		/*
+		 * Sync hardware MSR value to per-CPU cache. This helps in restoring
+		 * Host RSP0 when exiting to userspace in fred_update_rsp0().
+		 */
+		fred_sync_rsp0(svm->vmcb->save.fred_rsp0);
+	}
 }
 
 static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
-- 
2.43.0

Re: [PATCH 3/7] KVM: SVM: Save restore FRED_RSP0 for FRED supported guests

[Shivansh Dhiman]

Hi,

On 29-01-2026 12:06, Shivansh Dhiman wrote:
> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> 
> Hardware does not save/restore FRED_RSP0 for Non-SEV-ES guests.
> Save/restore it early in svm_vcpu_enter_exit() so that the
> correct physical CPU state is updated.


I'm planning to improve this path in v2 of this series, by moving the
restoring/saving of FRED RSP0 to svm_prepare_[switch_to_guest/host_switch]
respectively, thus saving some MSR accesses. Any comments are welcome.

> 
> Synchronize the current value of MSR_IA32_FRED_RSP0 in hardware to the kernel's
> local cache. Note that the desired host's RSP0 will be set when the CPU exits to
> userspace for servicing vCPU tasks.
> 
> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  arch/x86/kvm/svm/svm.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 05e44e804aba..ddd8941af6f0 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -4192,6 +4192,15 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu, bool spec_ctrl_in
>  {
>  	struct svm_cpu_data *sd = per_cpu_ptr(&svm_data, vcpu->cpu);
>  	struct vcpu_svm *svm = to_svm(vcpu);
> +	bool update_fred_rsp0;
> +
> +	/*
> +	 * Hardware does not save/restore FRED_RSP0 for Non-SEV-ES guests.
> +	 */
> +	update_fred_rsp0 = !sev_es_guest(vcpu->kvm) && guest_cpu_cap_has(vcpu, X86_FEATURE_FRED);
> +
> +	if (update_fred_rsp0)
> +		wrmsrq(MSR_IA32_FRED_RSP0, svm->vmcb->save.fred_rsp0);
>  
>  	guest_state_enter_irqoff();
>  

@@ -1391,12 +1433,34 @@ static void svm_prepare_switch_to_guest(struct kvm_vcpu
*vcpu)
                sd->bp_spec_reduce_set = true;
                msr_set_bit(MSR_ZEN4_BP_CFG, MSR_ZEN4_BP_CFG_BP_SPEC_REDUCE_BIT);
        }
+
+       /*
+        * Hardware does not save/restore FRED_RSP0 for Non-SEV-ES guests.
+        */
+       if (!sev_es_guest(vcpu->kvm) && guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
+               wrmsrq(MSR_IA32_FRED_RSP0, svm->vmcb->save.fred_rsp0);
+
        svm->guest_state_loaded = true;
 }

> @@ -4218,6 +4227,15 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu, bool spec_ctrl_in
>  	raw_local_irq_disable();
>  
>  	guest_state_exit_irqoff();
> +
> +	if (update_fred_rsp0) {
> +		rdmsrq(MSR_IA32_FRED_RSP0, svm->vmcb->save.fred_rsp0);
> +		/*
> +		 * Sync hardware MSR value to per-CPU cache. This helps in restoring
> +		 * Host RSP0 when exiting to userspace in fred_update_rsp0().
> +		 */
> +		fred_sync_rsp0(svm->vmcb->save.fred_rsp0);
> +	}
>  }
>  
>  static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)

 static void svm_prepare_host_switch(struct kvm_vcpu *vcpu)
 {
-       to_svm(vcpu)->guest_state_loaded = false;
+       struct vcpu_svm *svm = to_svm(vcpu);
+
+       if (!svm->guest_state_loaded)
+               return;
+
+       /*
+        * Hardware does not save/restore FRED_RSP0 for Non-SEV-ES guests.
+        * Also, sync hardware MSR value to per-CPU cache. This helps in
+        * restoring Host RSP0 when exiting to userspace in fred_update_rsp0().
+        */
+       if (!sev_es_guest(vcpu->kvm) && guest_cpu_cap_has(vcpu, X86_FEATURE_FRED)) {
+               rdmsrq(MSR_IA32_FRED_RSP0, svm->vmcb->save.fred_rsp0);
+               fred_sync_rsp0(svm->vmcb->save.fred_rsp0);
+       }
+
+       svm->guest_state_loaded = false;
 }

Thanks,
Shivansh

[PATCH 4/7] KVM: SVM: Populate FRED event data on event injection

[Shivansh Dhiman]

From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>

Set injected-event data (in EVENTINJDATA) when injecting an event,
use EXITINTDATA for populating the injected-event data during
reinjection.

Unlike IDT using some extra CPU register as part of an event
context, e.g., %cr2 for #PF, FRED saves a complete event context
in its stack frame, e.g., FRED saves the faulting linear address
of a #PF into the event data field defined in its stack frame.

Populate the EVENTINJDATA during event injection. The event data
will be pushed into a FRED stack frame for VM entries that inject
an event using FRED event delivery.

Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 arch/x86/kvm/svm/svm.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index ddd8941af6f0..693b46d715b4 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -374,6 +374,10 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
 		| SVM_EVTINJ_VALID
 		| (ex->has_error_code ? SVM_EVTINJ_VALID_ERR : 0)
 		| SVM_EVTINJ_TYPE_EXEPT;
+
+	if (is_fred_enabled(vcpu))
+		svm->vmcb->control.event_inj_data = ex->event_data;
+
 	svm->vmcb->control.event_inj_err = ex->error_code;
 }
 
@@ -4066,7 +4070,7 @@ static void svm_complete_soft_interrupt(struct kvm_vcpu *vcpu, u8 vector,
 		kvm_rip_write(vcpu, svm->soft_int_old_rip);
 }
 
-static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
+static void svm_complete_interrupts(struct kvm_vcpu *vcpu, bool reinject_on_vmexit)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 	u8 vector;
@@ -4111,6 +4115,7 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
 		break;
 	case SVM_EXITINTINFO_TYPE_EXEPT: {
 		u32 error_code = 0;
+		u64 event_data = 0;
 
 		/*
 		 * Never re-inject a #VC exception.
@@ -4121,9 +4126,18 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
 		if (exitintinfo & SVM_EXITINTINFO_VALID_ERR)
 			error_code = svm->vmcb->control.exit_int_info_err;
 
+		/*
+		 * FRED requires an additional field to pass injected-event
+		 * data to the guest.
+		 */
+		if (is_fred_enabled(vcpu) && (vector == PF_VECTOR || vector == DB_VECTOR))
+			event_data = reinject_on_vmexit ?
+					svm->vmcb->control.exit_int_data :
+					svm->vmcb->control.event_inj_data;
+
 		kvm_requeue_exception(vcpu, vector,
 				      exitintinfo & SVM_EXITINTINFO_VALID_ERR,
-				      error_code, false, 0);
+				      error_code, false, event_data);
 		break;
 	}
 	case SVM_EXITINTINFO_TYPE_INTR:
@@ -4146,7 +4160,7 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
 	control->exit_int_info = control->event_inj;
 	control->exit_int_info_err = control->event_inj_err;
 	control->event_inj = 0;
-	svm_complete_interrupts(vcpu);
+	svm_complete_interrupts(vcpu, false);
 }
 
 static int svm_vcpu_pre_run(struct kvm_vcpu *vcpu)
@@ -4382,7 +4396,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
 
 	trace_kvm_exit(vcpu, KVM_ISA_SVM);
 
-	svm_complete_interrupts(vcpu);
+	svm_complete_interrupts(vcpu, true);
 
 	return svm_exit_handlers_fastpath(vcpu);
 }
-- 
2.43.0

Re: [PATCH 4/7] KVM: SVM: Populate FRED event data on event injection

[Paolo Bonzini]

On 1/29/26 07:36, Shivansh Dhiman wrote:
> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> 
> Set injected-event data (in EVENTINJDATA) when injecting an event,
> use EXITINTDATA for populating the injected-event data during
> reinjection.
> 
> Unlike IDT using some extra CPU register as part of an event
> context, e.g., %cr2 for #PF, FRED saves a complete event context
> in its stack frame, e.g., FRED saves the faulting linear address
> of a #PF into the event data field defined in its stack frame.
> 
> Populate the EVENTINJDATA during event injection. The event data
> will be pushed into a FRED stack frame for VM entries that inject
> an event using FRED event delivery.
> 
> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>   arch/x86/kvm/svm/svm.c | 22 ++++++++++++++++++----
>   1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index ddd8941af6f0..693b46d715b4 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -374,6 +374,10 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
>   		| SVM_EVTINJ_VALID
>   		| (ex->has_error_code ? SVM_EVTINJ_VALID_ERR : 0)
>   		| SVM_EVTINJ_TYPE_EXEPT;
> +
> +	if (is_fred_enabled(vcpu))
> +		svm->vmcb->control.event_inj_data = ex->event_data;
> +
>   	svm->vmcb->control.event_inj_err = ex->error_code;
>   }
>   
> @@ -4066,7 +4070,7 @@ static void svm_complete_soft_interrupt(struct kvm_vcpu *vcpu, u8 vector,
>   		kvm_rip_write(vcpu, svm->soft_int_old_rip);
>   }
>   
> -static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
> +static void svm_complete_interrupts(struct kvm_vcpu *vcpu, bool reinject_on_vmexit)
>   {
>   	struct vcpu_svm *svm = to_svm(vcpu);
>   	u8 vector;
> @@ -4111,6 +4115,7 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
>   		break;
>   	case SVM_EXITINTINFO_TYPE_EXEPT: {
>   		u32 error_code = 0;
> +		u64 event_data = 0;
>   
>   		/*
>   		 * Never re-inject a #VC exception.
> @@ -4121,9 +4126,18 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
>   		if (exitintinfo & SVM_EXITINTINFO_VALID_ERR)
>   			error_code = svm->vmcb->control.exit_int_info_err;
>   
> +		/*
> +		 * FRED requires an additional field to pass injected-event
> +		 * data to the guest.
> +		 */
> +		if (is_fred_enabled(vcpu) && (vector == PF_VECTOR || vector == DB_VECTOR))
> +			event_data = reinject_on_vmexit ?
> +					svm->vmcb->control.exit_int_data :
> +					svm->vmcb->control.event_inj_data;

The new argument is not needed, just...

> @@ -4146,7 +4160,7 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
>   	control->exit_int_info = control->event_inj;
>   	control->exit_int_info_err = control->event_inj_err;

... move event_inj into exit_int here, similar to the other fields:

	control->exit_int_data = control->event_inj_data;

Paolo

>   	control->event_inj = 0;
> -	svm_complete_interrupts(vcpu);
> +	svm_complete_interrupts(vcpu, false);
>   }
>   
>   static int svm_vcpu_pre_run(struct kvm_vcpu *vcpu)
> @@ -4382,7 +4396,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
>   
>   	trace_kvm_exit(vcpu, KVM_ISA_SVM);
>   
> -	svm_complete_interrupts(vcpu);
> +	svm_complete_interrupts(vcpu, true);
>   
>   	return svm_exit_handlers_fastpath(vcpu);
>   }

Re: [PATCH 4/7] KVM: SVM: Populate FRED event data on event injection

[Shivansh Dhiman]

Hey Paolo,

On 06-03-2026 17:01, Paolo Bonzini wrote:
> On 1/29/26 07:36, Shivansh Dhiman wrote:
>> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
>>
>> Set injected-event data (in EVENTINJDATA) when injecting an event,
>> use EXITINTDATA for populating the injected-event data during
>> reinjection.
>>
>> Unlike IDT using some extra CPU register as part of an event
>> context, e.g., %cr2 for #PF, FRED saves a complete event context
>> in its stack frame, e.g., FRED saves the faulting linear address
>> of a #PF into the event data field defined in its stack frame.
>>
>> Populate the EVENTINJDATA during event injection. The event data
>> will be pushed into a FRED stack frame for VM entries that inject
>> an event using FRED event delivery.
>>
>> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
>> Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
>> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
>> ---
>>   arch/x86/kvm/svm/svm.c | 22 ++++++++++++++++++----
>>   1 file changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
>> index ddd8941af6f0..693b46d715b4 100644
>> --- a/arch/x86/kvm/svm/svm.c
>> +++ b/arch/x86/kvm/svm/svm.c
>> @@ -374,6 +374,10 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
>>               | SVM_EVTINJ_VALID
>>               | (ex->has_error_code ? SVM_EVTINJ_VALID_ERR : 0)
>>               | SVM_EVTINJ_TYPE_EXEPT;
>> +
>> +     if (is_fred_enabled(vcpu))
>> +             svm->vmcb->control.event_inj_data = ex->event_data;
>> +
>>       svm->vmcb->control.event_inj_err = ex->error_code;
>>   }
>>
>> @@ -4066,7 +4070,7 @@ static void svm_complete_soft_interrupt(struct kvm_vcpu *vcpu, u8 vector,
>>               kvm_rip_write(vcpu, svm->soft_int_old_rip);
>>   }
>>
>> -static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
>> +static void svm_complete_interrupts(struct kvm_vcpu *vcpu, bool reinject_on_vmexit)
>>   {
>>       struct vcpu_svm *svm = to_svm(vcpu);
>>       u8 vector;
>> @@ -4111,6 +4115,7 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
>>               break;
>>       case SVM_EXITINTINFO_TYPE_EXEPT: {
>>               u32 error_code = 0;
>> +             u64 event_data = 0;
>>
>>               /*
>>                * Never re-inject a #VC exception.
>> @@ -4121,9 +4126,18 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu)
>>               if (exitintinfo & SVM_EXITINTINFO_VALID_ERR)
>>                       error_code = svm->vmcb->control.exit_int_info_err;
>>
>> +             /*
>> +              * FRED requires an additional field to pass injected-event
>> +              * data to the guest.
>> +              */
>> +             if (is_fred_enabled(vcpu) && (vector == PF_VECTOR || vector == DB_VECTOR))
>> +                     event_data = reinject_on_vmexit ?
>> +                                     svm->vmcb->control.exit_int_data :
>> +                                     svm->vmcb->control.event_inj_data;
> 
> The new argument is not needed, just...

Agreed. That'll simplify this to:

        if (is_fred_enabled(vcpu) && (vector == PF_VECTOR || vector == DB_VECTOR))
                event_data = svm->vmcb->control.exit_int_data;

> 
>> @@ -4146,7 +4160,7 @@ static void svm_cancel_injection(struct kvm_vcpu *vcpu)
>>       control->exit_int_info = control->event_inj;
>>       control->exit_int_info_err = control->event_inj_err;
> 
> ... move event_inj into exit_int here, similar to the other fields:
> 
>        control->exit_int_data = control->event_inj_data;

Ack.

- Shivansh

> 
> Paolo
> 
>>       control->event_inj = 0;
>> -     svm_complete_interrupts(vcpu);
>> +     svm_complete_interrupts(vcpu, false);
>>   }
>>
>>   static int svm_vcpu_pre_run(struct kvm_vcpu *vcpu)
>> @@ -4382,7 +4396,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
>>
>>       trace_kvm_exit(vcpu, KVM_ISA_SVM);
>>
>> -     svm_complete_interrupts(vcpu);
>> +     svm_complete_interrupts(vcpu, true);
>>
>>       return svm_exit_handlers_fastpath(vcpu);
>>   }
> 

[PATCH 5/7] KVM: SVM: Support FRED nested exception injection

[Shivansh Dhiman]

From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>

Set the SVM nested exception bit in EVENT_INJECTION_CTL when
injecting a nested exception using FRED event delivery to
ensure:
  1) A nested exception is injected on a correct stack level.
  2) The nested bit defined in FRED stack frame is set.

The event stack level used by FRED event delivery depends on whether
the event was a nested exception encountered during delivery of an
earlier event, because a nested exception is "regarded" as happening
on ring 0.  E.g., when #PF is configured to use stack level 1 in
IA32_FRED_STKLVLS MSR:
  - nested #PF will be delivered on the stack pointed by FRED_RSP1
    MSR when encountered in ring 3 and ring 0.
  - normal #PF will be delivered on the stack pointed by FRED_RSP0
    MSR when encountered in ring 3.

The SVM nested-exception support ensures a correct event stack level is
chosen when a VM entry injects a nested exception.

Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
---
 arch/x86/include/asm/svm.h | 1 +
 arch/x86/kvm/svm/svm.c     | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index c2f3e03e1f4b..f4a9781c1d6c 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -657,6 +657,7 @@ static inline void __unused_size_checks(void)
 
 #define SVM_EVTINJ_VALID (1 << 31)
 #define SVM_EVTINJ_VALID_ERR (1 << 11)
+#define SVM_EVTINJ_NESTED_EXCEPTION    (1 << 13)
 
 #define SVM_EXITINTINFO_VEC_MASK SVM_EVTINJ_VEC_MASK
 #define SVM_EXITINTINFO_TYPE_MASK SVM_EVTINJ_TYPE_MASK
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 693b46d715b4..374589784206 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -363,6 +363,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
 {
 	struct kvm_queued_exception *ex = &vcpu->arch.exception;
 	struct vcpu_svm *svm = to_svm(vcpu);
+	bool nested = is_fred_enabled(vcpu) && ex->nested;
 
 	kvm_deliver_exception_payload(vcpu, ex);
 
@@ -373,6 +374,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
 	svm->vmcb->control.event_inj = ex->vector
 		| SVM_EVTINJ_VALID
 		| (ex->has_error_code ? SVM_EVTINJ_VALID_ERR : 0)
+		| (nested ? SVM_EVTINJ_NESTED_EXCEPTION : 0)
 		| SVM_EVTINJ_TYPE_EXEPT;
 
 	if (is_fred_enabled(vcpu))
@@ -4137,7 +4139,8 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu, bool reinject_on_vmex
 
 		kvm_requeue_exception(vcpu, vector,
 				      exitintinfo & SVM_EXITINTINFO_VALID_ERR,
-				      error_code, false, event_data);
+				      error_code, exitintinfo & SVM_EVTINJ_NESTED_EXCEPTION,
+				      event_data);
 		break;
 	}
 	case SVM_EXITINTINFO_TYPE_INTR:
-- 
2.43.0

Re: [PATCH 5/7] KVM: SVM: Support FRED nested exception injection

[Sean Christopherson]

On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> 
> Set the SVM nested exception bit in EVENT_INJECTION_CTL when
> injecting a nested exception using FRED event delivery to
> ensure:
>   1) A nested exception is injected on a correct stack level.
>   2) The nested bit defined in FRED stack frame is set.
> 
> The event stack level used by FRED event delivery depends on whether
> the event was a nested exception encountered during delivery of an
> earlier event, because a nested exception is "regarded" as happening
> on ring 0.  E.g., when #PF is configured to use stack level 1 in
> IA32_FRED_STKLVLS MSR:
>   - nested #PF will be delivered on the stack pointed by FRED_RSP1
>     MSR when encountered in ring 3 and ring 0.
>   - normal #PF will be delivered on the stack pointed by FRED_RSP0
>     MSR when encountered in ring 3.
> 
> The SVM nested-exception support ensures a correct event stack level is
> chosen when a VM entry injects a nested exception.
> 
> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> Co-developed-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
> ---
>  arch/x86/include/asm/svm.h | 1 +
>  arch/x86/kvm/svm/svm.c     | 5 ++++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index c2f3e03e1f4b..f4a9781c1d6c 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -657,6 +657,7 @@ static inline void __unused_size_checks(void)
>  
>  #define SVM_EVTINJ_VALID (1 << 31)
>  #define SVM_EVTINJ_VALID_ERR (1 << 11)
> +#define SVM_EVTINJ_NESTED_EXCEPTION    (1 << 13)
>  
>  #define SVM_EXITINTINFO_VEC_MASK SVM_EVTINJ_VEC_MASK
>  #define SVM_EXITINTINFO_TYPE_MASK SVM_EVTINJ_TYPE_MASK
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 693b46d715b4..374589784206 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -363,6 +363,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_queued_exception *ex = &vcpu->arch.exception;
>  	struct vcpu_svm *svm = to_svm(vcpu);
> +	bool nested = is_fred_enabled(vcpu) && ex->nested;

Reverse fir-tree please (swap this with the line above it).  Similar to my comment
on the VMX series, us is_nested to avoid shadowing the global nested.

Re: [PATCH 5/7] KVM: SVM: Support FRED nested exception injection

[Shivansh Dhiman]

On 07-03-2026 07:37, Sean Christopherson wrote:
> On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
>> @@ -363,6 +363,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
>>  {
>>  	struct kvm_queued_exception *ex = &vcpu->arch.exception;
>>  	struct vcpu_svm *svm = to_svm(vcpu);
>> +	bool nested = is_fred_enabled(vcpu) && ex->nested;
> 
> Reverse fir-tree please (swap this with the line above it).  Similar to my comment
> on the VMX series, us is_nested to avoid shadowing the global nested.

Sure. Adding is_nested() helper should be a better choice. Will do that in v2.

- Shivansh

Re: [PATCH 5/7] KVM: SVM: Support FRED nested exception injection

[Sean Christopherson]

On Tue, Mar 10, 2026, Shivansh Dhiman wrote:
> 
> On 07-03-2026 07:37, Sean Christopherson wrote:
> > On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> >> @@ -363,6 +363,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
> >>  {
> >>  	struct kvm_queued_exception *ex = &vcpu->arch.exception;
> >>  	struct vcpu_svm *svm = to_svm(vcpu);
> >> +	bool nested = is_fred_enabled(vcpu) && ex->nested;
> > 
> > Reverse fir-tree please (swap this with the line above it).  Similar to my comment
> > on the VMX series, us is_nested to avoid shadowing the global nested.
> 
> Sure. Adding is_nested() helper should be a better choice. Will do that in v2.

Please don't add is_nested().  In KVM, "nested" means nested virtualization.
I don't see any reason to add a wrapper, it's a single boolean.

Re: [PATCH 5/7] KVM: SVM: Support FRED nested exception injection

[Shivansh Dhiman]

On 10-03-2026 21:50, Sean Christopherson wrote:
> On Tue, Mar 10, 2026, Shivansh Dhiman wrote:
>>
>> On 07-03-2026 07:37, Sean Christopherson wrote:
>>> On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
>>>> @@ -363,6 +363,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu)
>>>>  {
>>>>  	struct kvm_queued_exception *ex = &vcpu->arch.exception;
>>>>  	struct vcpu_svm *svm = to_svm(vcpu);
>>>> +	bool nested = is_fred_enabled(vcpu) && ex->nested;
>>>
>>> Reverse fir-tree please (swap this with the line above it).  Similar to my comment
>>> on the VMX series, us is_nested to avoid shadowing the global nested.
>>
>> Sure. Adding is_nested() helper should be a better choice. Will do that in v2.
> 
> Please don't add is_nested().  In KVM, "nested" means nested virtualization.
> I don't see any reason to add a wrapper, it's a single boolean.

Ah, I understand it now. Thanks for correcting.

- Shivansh

[PATCH 6/7] KVM: SVM: Dump FRED context in dump_vmcb()

[Shivansh Dhiman]

Add fields related to FRED to dump_vmcb() to dump FRED context.

Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 arch/x86/kvm/svm/svm.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 374589784206..954df4eae90e 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3319,6 +3319,8 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
 	pr_err("%-20s%016llx\n", "vmsa_pa:", control->vmsa_pa);
 	pr_err("%-20s%016llx\n", "allowed_sev_features:", control->allowed_sev_features);
 	pr_err("%-20s%016llx\n", "guest_sev_features:", control->guest_sev_features);
+	pr_err("%-20s%016llx\n", "exit_int_data:", control->exit_int_data);
+	pr_err("%-20s%016llx\n", "event_inj_data:", control->event_inj_data);
 
 	if (sev_es_guest(vcpu->kvm)) {
 		save = sev_decrypt_vmsa(vcpu);
@@ -3434,6 +3436,25 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
 		       "r14:", vmsa->r14, "r15:", vmsa->r15);
 		pr_err("%-15s %016llx %-13s %016llx\n",
 		       "xcr0:", vmsa->xcr0, "xss:", vmsa->xss);
+
+		pr_err("%-27s %d %-18s%016llx\n",
+		       "is_fred_enabled:", is_fred_enabled(vcpu),
+		       "guest_evntinjdata:", vmsa->guest_event_inj_data);
+		pr_err("%-12s %016llx %-18s%016llx\n",
+		       "fred_config:", vmsa->fred_config,
+		       "guest_exitintdata:", vmsa->guest_exit_int_data);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_rsp0:", vmsa->fred_rsp0,
+		       "fred_rsp1:", vmsa->fred_rsp1);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_rsp2:", vmsa->fred_rsp2,
+		       "fred_rsp3:", vmsa->fred_rsp3);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_stklvls:", vmsa->fred_stklvls,
+		       "fred_ssp1:", vmsa->fred_ssp1);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_ssp2:", vmsa->fred_ssp2,
+		       "fred_ssp3:", vmsa->fred_ssp3);
 	} else {
 		pr_err("%-15s %016llx %-13s %016lx\n",
 		       "rax:", save->rax, "rbx:",
@@ -3461,6 +3482,24 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
 		       "r14:", vcpu->arch.regs[VCPU_REGS_R14],
 		       "r15:", vcpu->arch.regs[VCPU_REGS_R15]);
 #endif
+		pr_err("%-26s %d %-18s %016llx\n",
+		       "is_fred_enabled:", is_fred_enabled(vcpu),
+		       "guest_evntinjdata:", save->guest_event_inj_data);
+		pr_err("%-12s%016llx %-18s%016llx\n",
+		       "fred_config:", save->fred_config,
+		       "guest_exitintdata:", save->guest_exit_int_data);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_rsp0:", save->fred_rsp0,
+		       "fred_rsp1:", save->fred_rsp1);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_rsp2:", save->fred_rsp2,
+		       "fred_rsp3:", save->fred_rsp3);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_stklvls:", save->fred_stklvls,
+		       "fred_ssp1:", save->fred_ssp1);
+		pr_err("%-15s %016llx %-13s %016llx\n",
+		       "fred_ssp2:", save->fred_ssp2,
+		       "fred_ssp3:", save->fred_ssp3);
 	}
 
 no_vmsa:
-- 
2.43.0

Re: [PATCH 6/7] KVM: SVM: Dump FRED context in dump_vmcb()

[Sean Christopherson]

On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> Add fields related to FRED to dump_vmcb() to dump FRED context.
> 
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  arch/x86/kvm/svm/svm.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 374589784206..954df4eae90e 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3319,6 +3319,8 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
>  	pr_err("%-20s%016llx\n", "vmsa_pa:", control->vmsa_pa);
>  	pr_err("%-20s%016llx\n", "allowed_sev_features:", control->allowed_sev_features);
>  	pr_err("%-20s%016llx\n", "guest_sev_features:", control->guest_sev_features);
> +	pr_err("%-20s%016llx\n", "exit_int_data:", control->exit_int_data);
> +	pr_err("%-20s%016llx\n", "event_inj_data:", control->event_inj_data);
>  
>  	if (sev_es_guest(vcpu->kvm)) {
>  		save = sev_decrypt_vmsa(vcpu);
> @@ -3434,6 +3436,25 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
>  		       "r14:", vmsa->r14, "r15:", vmsa->r15);
>  		pr_err("%-15s %016llx %-13s %016llx\n",
>  		       "xcr0:", vmsa->xcr0, "xss:", vmsa->xss);
> +
> +		pr_err("%-27s %d %-18s%016llx\n",
> +		       "is_fred_enabled:", is_fred_enabled(vcpu),
> +		       "guest_evntinjdata:", vmsa->guest_event_inj_data);
> +		pr_err("%-12s %016llx %-18s%016llx\n",
> +		       "fred_config:", vmsa->fred_config,
> +		       "guest_exitintdata:", vmsa->guest_exit_int_data);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_rsp0:", vmsa->fred_rsp0,
> +		       "fred_rsp1:", vmsa->fred_rsp1);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_rsp2:", vmsa->fred_rsp2,
> +		       "fred_rsp3:", vmsa->fred_rsp3);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_stklvls:", vmsa->fred_stklvls,
> +		       "fred_ssp1:", vmsa->fred_ssp1);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_ssp2:", vmsa->fred_ssp2,
> +		       "fred_ssp3:", vmsa->fred_ssp3);
>  	} else {
>  		pr_err("%-15s %016llx %-13s %016lx\n",
>  		       "rax:", save->rax, "rbx:",
> @@ -3461,6 +3482,24 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
>  		       "r14:", vcpu->arch.regs[VCPU_REGS_R14],
>  		       "r15:", vcpu->arch.regs[VCPU_REGS_R15]);
>  #endif
> +		pr_err("%-26s %d %-18s %016llx\n",
> +		       "is_fred_enabled:", is_fred_enabled(vcpu),
> +		       "guest_evntinjdata:", save->guest_event_inj_data);
> +		pr_err("%-12s%016llx %-18s%016llx\n",
> +		       "fred_config:", save->fred_config,
> +		       "guest_exitintdata:", save->guest_exit_int_data);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_rsp0:", save->fred_rsp0,
> +		       "fred_rsp1:", save->fred_rsp1);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_rsp2:", save->fred_rsp2,
> +		       "fred_rsp3:", save->fred_rsp3);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_stklvls:", save->fred_stklvls,
> +		       "fred_ssp1:", save->fred_ssp1);
> +		pr_err("%-15s %016llx %-13s %016llx\n",
> +		       "fred_ssp2:", save->fred_ssp2,
> +		       "fred_ssp3:", save->fred_ssp3);

These should all be gated on guest_cpu_cap_has(X86_FEATURE_FRED).  Just because
KVM can read and print garbage doesn't mean it should.

Re: [PATCH 6/7] KVM: SVM: Dump FRED context in dump_vmcb()

[Shivansh Dhiman]

On 07-03-2026 07:33, Sean Christopherson wrote:
>> @@ -3461,6 +3482,24 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
>>  		       "r14:", vcpu->arch.regs[VCPU_REGS_R14],
>>  		       "r15:", vcpu->arch.regs[VCPU_REGS_R15]);
>>  #endif
>> +		pr_err("%-26s %d %-18s %016llx\n",
>> +		       "is_fred_enabled:", is_fred_enabled(vcpu),
>> +		       "guest_evntinjdata:", save->guest_event_inj_data);
>> +		pr_err("%-12s%016llx %-18s%016llx\n",
>> +		       "fred_config:", save->fred_config,
>> +		       "guest_exitintdata:", save->guest_exit_int_data);
>> +		pr_err("%-15s %016llx %-13s %016llx\n",
>> +		       "fred_rsp0:", save->fred_rsp0,
>> +		       "fred_rsp1:", save->fred_rsp1);
>> +		pr_err("%-15s %016llx %-13s %016llx\n",
>> +		       "fred_rsp2:", save->fred_rsp2,
>> +		       "fred_rsp3:", save->fred_rsp3);
>> +		pr_err("%-15s %016llx %-13s %016llx\n",
>> +		       "fred_stklvls:", save->fred_stklvls,
>> +		       "fred_ssp1:", save->fred_ssp1);
>> +		pr_err("%-15s %016llx %-13s %016llx\n",
>> +		       "fred_ssp2:", save->fred_ssp2,
>> +		       "fred_ssp3:", save->fred_ssp3);
> 
> These should all be gated on guest_cpu_cap_has(X86_FEATURE_FRED).  Just because
> KVM can read and print garbage doesn't mean it should.

Will include that in v2. Thanks.

- Shivansh

[PATCH 7/7] KVM: SVM: Enable save/restore of FRED MSRs

[Shivansh Dhiman]

Set the FRED_VIRT_ENABLE bit (bit 4) in the VIRT_EXT field of VMCB to enable
FRED Virtualization for the guest. This enables automatic save/restore of
FRED MSRs. Also toggle this bit when setting CPUIDs, to support booting of
secure guests.

Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
---
 arch/x86/kvm/svm/svm.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 954df4eae90e..24579c149937 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1144,6 +1144,9 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
 	save->fred_ssp3 = 0;
 	save->fred_config = 0;
 
+	if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
+		svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;
+
 	init_sys_seg(&save->ldtr, SEG_TYPE_LDT);
 	init_sys_seg(&save->tr, SEG_TYPE_BUSY_TSS16);
 
@@ -4529,6 +4532,9 @@ static void svm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 	if (guest_cpuid_is_intel_compatible(vcpu))
 		guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD);
 
+	if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
+		svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;
+
 	if (sev_guest(vcpu->kvm))
 		sev_vcpu_after_set_cpuid(svm);
 }
-- 
2.43.0

Re: [PATCH 7/7] KVM: SVM: Enable save/restore of FRED MSRs

[Sean Christopherson]

On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> Set the FRED_VIRT_ENABLE bit (bit 4) in the VIRT_EXT field of VMCB to enable
> FRED Virtualization for the guest. This enables automatic save/restore of
> FRED MSRs. Also toggle this bit when setting CPUIDs, to support booting of
> secure guests.
> 
> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
> ---
>  arch/x86/kvm/svm/svm.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 954df4eae90e..24579c149937 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1144,6 +1144,9 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
>  	save->fred_ssp3 = 0;
>  	save->fred_config = 0;
>  
> +	if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
> +		svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;

This is completely unnecessary, no?  CPUID is empty at vCPU creation and so FRED
_can't_ be enabled before going through svm_vcpu_after_set_cpuid().

>  	init_sys_seg(&save->ldtr, SEG_TYPE_LDT);
>  	init_sys_seg(&save->tr, SEG_TYPE_BUSY_TSS16);
>  
> @@ -4529,6 +4532,9 @@ static void svm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
>  	if (guest_cpuid_is_intel_compatible(vcpu))
>  		guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD);
>  
> +	if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
> +		svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;

The flag needs to be cleared if FRED isn't supported, because KVM's wonderful
ABI allows userspace to modify CPUID however many times it wants before running
the vCPU.

> +
>  	if (sev_guest(vcpu->kvm))
>  		sev_vcpu_after_set_cpuid(svm);
>  }
> -- 
> 2.43.0
> 

Re: [PATCH 7/7] KVM: SVM: Enable save/restore of FRED MSRs

[Shivansh Dhiman]

On 07-03-2026 07:44, Sean Christopherson wrote:
> On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
>> Set the FRED_VIRT_ENABLE bit (bit 4) in the VIRT_EXT field of VMCB to enable
>> FRED Virtualization for the guest. This enables automatic save/restore of
>> FRED MSRs. Also toggle this bit when setting CPUIDs, to support booting of
>> secure guests.
>>
>> Signed-off-by: Shivansh Dhiman <shivansh.dhiman@amd.com>
>> ---
>>  arch/x86/kvm/svm/svm.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
>> index 954df4eae90e..24579c149937 100644
>> --- a/arch/x86/kvm/svm/svm.c
>> +++ b/arch/x86/kvm/svm/svm.c
>> @@ -1144,6 +1144,9 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
>>  	save->fred_ssp3 = 0;
>>  	save->fred_config = 0;
>>  
>> +	if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
>> +		svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;
> 
> This is completely unnecessary, no?  CPUID is empty at vCPU creation and so FRED
> _can't_ be enabled before going through svm_vcpu_after_set_cpuid().

On a second thought, this is actually redundant. I'll drop this from init_vmcb().

> 
>>  	init_sys_seg(&save->ldtr, SEG_TYPE_LDT);
>>  	init_sys_seg(&save->tr, SEG_TYPE_BUSY_TSS16);
>>  
>> @@ -4529,6 +4532,9 @@ static void svm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
>>  	if (guest_cpuid_is_intel_compatible(vcpu))
>>  		guest_cpu_cap_clear(vcpu, X86_FEATURE_V_VMSAVE_VMLOAD);
>>  
>> +	if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
>> +		svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;
> 
> The flag needs to be cleared if FRED isn't supported, because KVM's wonderful
> ABI allows userspace to modify CPUID however many times it wants before running
> the vCPU.

Agreed. I'll add:

if (guest_cpu_cap_has(vcpu, X86_FEATURE_FRED))
	svm->vmcb->control.virt_ext |= FRED_VIRT_ENABLE_MASK;
else
	svm->vmcb->control.virt_ext &= ~FRED_VIRT_ENABLE_MASK;

- Shivansh

> 
>> +
>>  	if (sev_guest(vcpu->kvm))
>>  		sev_vcpu_after_set_cpuid(svm);
>>  }
>> -- 
>> 2.43.0
>>

Re: [PATCH 0/7] KVM: SVM: Enable FRED support

[Shivansh Dhiman]

Hi,

Here is the newly published FRED virtualization spec by AMD for reference:

	https://docs.amd.com/v/u/en-US/69191-PUB

Please feel free to share any feedback or questions.

Regards,
Shivansh

On 29-01-2026 12:06, Shivansh Dhiman wrote:
> This series adds SVM support for FRED (Flexible Return and Event Delivery)
> virtualization in KVM.
> 
> FRED introduces simplified privilege level transitions to replace IDT-based
> event delivery and IRET returns, providing lower latency event handling while
> ensuring complete supervisor context on delivery and full user context on
> return. FRED defines event delivery for both ring 3->0 and ring 0->0
> transitions, and introduces ERETU for returning to ring 3 and ERETS for
> remaining in ring 0.
> 
> AMD hardware extends the VMCB to support FRED virtualization with dedicated
> save area fields for FRED MSRs (RSP0-3, SSP1-3, STKLVLS, CONFIG) and control
> fields for event injection data (EXITINTDATA, EVENTINJDATA).
> 
> The implementation spans seven patches. The important changes are:
> 
> 1) Extend VMCB structures with FRED fields mentioned above and disable MSR
>    interception for FRED-enabled guests to avoid unnecessary VM exits.
> 
> 2) Support for nested exceptions where we populate event injection data
>    when delivering exceptions like page faults and debug traps. 
> 
> This series is based on top of FRED support for VMX patchset [1],
> patches 1-17. The VMX patchset was rebased on top of v6.18.0 kernel.
> 
> [1] https://lore.kernel.org/kvm/20251026201911.505204-1-xin@zytor.com
> 
> Regards,
> Shivansh
> ---
> Neeraj Upadhyay (5):
>   KVM: SVM: Initialize FRED VMCB fields
>   KVM: SVM: Disable interception of FRED MSRs for FRED supported guests
>   KVM: SVM: Save restore FRED_RSP0 for FRED supported guests
>   KVM: SVM: Populate FRED event data on event injection
>   KVM: SVM: Support FRED nested exception injection
> 
> Shivansh Dhiman (2):
>   KVM: SVM: Dump FRED context in dump_vmcb()
>   KVM: SVM: Enable save/restore of FRED MSRs
> 
>  arch/x86/include/asm/svm.h |  35 ++++++++++-
>  arch/x86/kvm/svm/svm.c     | 116 +++++++++++++++++++++++++++++++++++--
>  2 files changed, 144 insertions(+), 7 deletions(-)
> 
> 
> base-commit: f76e83ecf6bce6d3793f828d92170b69e636f3c9

Re: [PATCH 0/7] KVM: SVM: Enable FRED support

[Andrew Cooper]

> Here is the newly published FRED virtualization spec by AMD for reference:
>
> 	https://docs.amd.com/v/u/en-US/69191-PUB
>
> Please feel free to share any feedback or questions.


FYI, there is a fun behaviour captured in the sentence:

"If FRED virtualization is enabled, NMI virtualization must be enabled
in order to properly handle guest NMIs"

i.e. hypervisors need to make sure not run the guest with FRED &&
!vNMI.  AIUI, there's no ERETUx intercept similar to the IRET intercept
with with to emulate NMI window tracking in !vNMI mode.

I requested that this become a VMRUN consistency check, but was
declined.  I've asked that at least the wording change to "undefined
behaviour" so something sane can be done for the nested case where L1
tries to do something daft.


There are two other issues which are going to be adjusted.  One is the
consistency check concerning SS.DPL==3 && INTR_SHADOW==0 (not a valid
restriction in later drafts of the spec), and one is "On an intercepted
#DB, EXITINFO2 has DR6 register value."  Both do/will (not sure which)
behave like Intel, rather than as currently documented.

~Andrew

Re: [PATCH 0/7] KVM: SVM: Enable FRED support

[Shivansh Dhiman]

Hi Andrew,

On 11-02-2026 06:23, Andrew Cooper wrote:
>> Here is the newly published FRED virtualization spec by AMD for reference:
>>
>> 	https://docs.amd.com/v/u/en-US/69191-PUB
>>
>> Please feel free to share any feedback or questions.
> 
> 
> FYI, there is a fun behaviour captured in the sentence:
> 
> "If FRED virtualization is enabled, NMI virtualization must be enabled
> in order to properly handle guest NMIs"
> 
> i.e. hypervisors need to make sure not run the guest with FRED &&
> !vNMI.  AIUI, there's no ERETUx intercept similar to the IRET intercept
> with with to emulate NMI window tracking in !vNMI mode.

Thanks for letting me know about this. Seems like a legitimate consistency
check. I'll try to integrate it.

> 
> I requested that this become a VMRUN consistency check, but was
> declined.  I've asked that at least the wording change to "undefined
> behaviour" so something sane can be done for the nested case where L1
> tries to do something daft.
> 
> 
> There are two other issues which are going to be adjusted.  One is the
> consistency check concerning SS.DPL==3 && INTR_SHADOW==0 (not a valid
> restriction in later drafts of the spec), and one is "On an intercepted
> #DB, EXITINFO2 has DR6 register value."  Both do/will (not sure which)
> behave like Intel, rather than as currently documented.

Can you tell under which conditions does the #DB issue may arise?

> 
> ~Andrew

- Shivansh

Re: [PATCH 0/7] KVM: SVM: Enable FRED support

[Shivansh Dhiman]

Hi everyone,

Gentle ping for reviewing patches on SVM support for FRED in this series.
Would appreciate any feedback or guidance on next steps.

Thanks,
Shivansh

On 29-01-2026 12:06, Shivansh Dhiman wrote:
> This series adds SVM support for FRED (Flexible Return and Event Delivery)
> virtualization in KVM.
> 
> FRED introduces simplified privilege level transitions to replace IDT-based
> event delivery and IRET returns, providing lower latency event handling while
> ensuring complete supervisor context on delivery and full user context on
> return. FRED defines event delivery for both ring 3->0 and ring 0->0
> transitions, and introduces ERETU for returning to ring 3 and ERETS for
> remaining in ring 0.
> 
> AMD hardware extends the VMCB to support FRED virtualization with dedicated
> save area fields for FRED MSRs (RSP0-3, SSP1-3, STKLVLS, CONFIG) and control
> fields for event injection data (EXITINTDATA, EVENTINJDATA).
> 
> The implementation spans seven patches. The important changes are:
> 
> 1) Extend VMCB structures with FRED fields mentioned above and disable MSR
>    interception for FRED-enabled guests to avoid unnecessary VM exits.
> 
> 2) Support for nested exceptions where we populate event injection data
>    when delivering exceptions like page faults and debug traps. 
> 
> This series is based on top of FRED support for VMX patchset [1],
> patches 1-17. The VMX patchset was rebased on top of v6.18.0 kernel.
> 
> [1] https://lore.kernel.org/kvm/20251026201911.505204-1-xin@zytor.com
> 
> Regards,
> Shivansh
> ---
> Neeraj Upadhyay (5):
>   KVM: SVM: Initialize FRED VMCB fields
>   KVM: SVM: Disable interception of FRED MSRs for FRED supported guests
>   KVM: SVM: Save restore FRED_RSP0 for FRED supported guests
>   KVM: SVM: Populate FRED event data on event injection
>   KVM: SVM: Support FRED nested exception injection
> 
> Shivansh Dhiman (2):
>   KVM: SVM: Dump FRED context in dump_vmcb()
>   KVM: SVM: Enable save/restore of FRED MSRs
> 
>  arch/x86/include/asm/svm.h |  35 ++++++++++-
>  arch/x86/kvm/svm/svm.c     | 116 +++++++++++++++++++++++++++++++++++--
>  2 files changed, 144 insertions(+), 7 deletions(-)
> 
> 
> base-commit: f76e83ecf6bce6d3793f828d92170b69e636f3c9

Re: Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Christian Ludloff]

>> Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?
> Yes that's right, the FRED MSRs are zeroed on init.

Ahem... citation required, please.  :)

Because the FRED spec certainly claims otherwise:

  "The RESET state of each of the new MSRs is zero.
  INIT does not change the value of the FRED MSRs."

See SDM vol3 #325384-090 @ end of section 8.2.3.

Getting initialized by INIT tends to be outlier behavior
when it comes to MSRs – MPX, CET, EFER, FS/GS/
kGS... but afaik the rest all remain unchanged.

And yes... this will need clarification from Intel... given
that CET_PL0_SSP = FRED_SSP0_SL0... and it can
not be both, unchanged and set-to-zero...  8-)

--
C.

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Shivansh Dhiman]

Hi Christian,

On 14-03-2026 18:25, Christian Ludloff wrote:
>>> Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?
>> Yes that's right, the FRED MSRs are zeroed on init.
> 
> Ahem... citation required, please.  :)
> 
> Because the FRED spec certainly claims otherwise:
> 
>   "The RESET state of each of the new MSRs is zero.
>   INIT does not change the value of the FRED MSRs."
> 
> See SDM vol3 #325384-090 @ end of section 8.2.3.
> 
> Getting initialized by INIT tends to be outlier behavior
> when it comes to MSRs – MPX, CET, EFER, FS/GS/
> kGS... but afaik the rest all remain unchanged.

Thanks for pointing this out. After consulting with the hardware folks, it
turns out the FRED MSRs are left unchanged on INIT. I had mistakenly mixed
up the INIT and RESET behavior. Apologies for the confusion.

I'll update the patch to only zero the FRED MSRs on RESET. Will address this
in v2.

Thanks,
Shivansh

> 
> And yes... this will need clarification from Intel... given
> that CET_PL0_SSP = FRED_SSP0_SL0... and it can
> not be both, unchanged and set-to-zero...  8-)
> 
> --
> C.

Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields

[Christian Ludloff]

On Fri, Mar 27, 2026 at 7:47 AM Shivansh Dhiman <shivansh.dhiman@amd.com> wrote:
> On 14-03-2026 18:25, Christian Ludloff wrote:
> >>> Is this architecturally correct?  I.e. are all the FRED MSRs zeroed on INIT?
> >> Yes that's right, the FRED MSRs are zeroed on init.
> >
> > Ahem... citation required, please.  :)
> >
> > Because the FRED spec certainly claims otherwise:
> >
> >   "The RESET state of each of the new MSRs is zero.
> >   INIT does not change the value of the FRED MSRs."
> >
> > See SDM vol3 #325384-090 @ end of section 8.2.3.
> >
> > Getting initialized by INIT tends to be outlier behavior
> > when it comes to MSRs – MPX, CET, EFER, FS/GS/
> > kGS... but afaik the rest all remain unchanged.
>
> Thanks for pointing this out. After consulting with the hardware folks, it
> turns out the FRED MSRs are left unchanged on INIT. I had mistakenly mixed
> up the INIT and RESET behavior. Apologies for the confusion.

Thanks.

> I'll update the patch to only zero the FRED MSRs on RESET. Will address this
> in v2.

Thanks.

> > And yes... this will need clarification from Intel... given
> > that CET_PL0_SSP = FRED_SSP0_SL0... and it can
> > not be both, unchanged and set-to-zero...  8-)

Intel folks – can you please state the CET INIT behavior,
for SSP as well as the 4+1+2=7 MSRs, at long last? The
answer I was given years ago was "like RESET", but for
at least PL0_SSP that doesn't match SSP0_SL0.

--
C.