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

On 8/13/2026 4:57 AM, Sean Christopherson wrote:
> +Nikunj
> 
> On Mon, Aug 10, 2026, Shivansh Dhiman wrote:
>> On 07-03-26 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 <[email protected]>
>>>> ---
>>>>  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().
>>
>> Hi Sean,
>>
>> You're right for vCPU creation, CPUID is empty there and the hunk does
>> nothing, so I dropped it in v2. While preparing v3 I hit a case that does
>> need it though, a triple fault:
>>
>>  1. The guest enumerates FRED, so the FRED MSRs are passed through and
>>     FRED_VIRT_ENABLE is set in virt_ext.
>>
>>  2. The guest triple faults and KVM intercepts SHUTDOWN.
>>
>>  3. shutdown_interception() does clear_page(svm->vmcb), which wipes
>>     virt_ext along with the rest of the VMCB, and then INITs the vCPU.
>>
>>  4. init_vmcb() runs, but svm_vcpu_after_set_cpuid() does not.
>>
>>  5. CPUID still enumerates FRED, so the intercept recalc puts the FRED
>>     MSRs back into passthrough.
>>
>>  6. Nothing restores FRED_VIRT_ENABLE, as only svm_vcpu_after_set_cpuid()
>>     ever sets it.
>>
>>
>> So the guest ends up with direct access to the FRED MSRs while hardware is
>> no longer context switching them, i.e. it can clobber the host's FRED state.
>>
>> Setting the bit in init_vmcb() is the smallest fix I came up with, so I'd
>> like to add the hunk back in v3.
>>
>> Would you prefer it handled in svm_recalc_fred_msr_intercepts() instead
>> while setting intercepts? Or is there a better way to deal with this?
> 
> Take a hard dependency on an upcoming APM update that states the control area
> is valid after shutdown, and rework KVM to not clobber control fields on shutdown
> interception.

AMD APM 3.45 [1] is now publicly available and has the updated wording:

    "After an intercepted shutdown, the VMCB control area is valid (with
     the exception of offsets 60h, 61h, and 68h) and the VMCB state save
     area is undefined."

> Nikunj, I was actually expecting that to come with the PML series.  But looking
> back, I see that you proposed a targeted fix for PML[*].  That's probably fine?
> Rewriting shutdown interception just to avoid a one-liner is a bit ridiculous,
> but on the other hand, we really should do that sooner than later, because PML
> obviously isn't the only thing affected by KVM's conservative read of the old APM
> wording.

Will send a separate series to fix shutdown_interception() to not clear the
VMCB control area.

Regards,
Nikunj

[1] https://docs.amd.com/v/u/en-US/24593_3.45_APM_Vol2