Re: [PATCH v10 08/28] KVM: VMX: Set FRED MSR intercepts

[Sohil Mehta <sohil.mehta@intel.com>]

On 10/23/2026 1:07 AM, Binbin Wu wrote:

>> Consequently, passing these MSRs through to the guest would only add
>                   ^
> "passing" or "intercepting"?

Yup, it's a typo. I had it on my list of fixes already :)


>> +static void vmx_set_intercept_for_fred_msr(struct kvm_vcpu *vcpu)
> 
> Nit:
> Maybe follow the name of the function above, i.e. vmx_recalc_xxx_intercepts().
> vmx_recalc_fred_msr_intercepts()?
> 

Sure, I'll change it to make it consistent.

>> +{
>> +	bool intercept = !guest_cpu_cap_has(vcpu, X86_FEATURE_FRED);
> 
> This assignment could be moved after the check below.
> 

The compiler should take care of it automatically, right? I think it's a
style preference that saves a line. Other functions such as
vmx_recalc_pmu_msr_intercepts() follow a similar pattern. I would prefer
to leave this as-is unless you have a strong preference.

>> +
>> +	if (!kvm_cpu_cap_has(X86_FEATURE_FRED))
>> +		return;
>> +
>> +	/*
>> +	 * Because the following eight FRED MSRs,
>> +	 * 	MSR_IA32_FRED_RSP[123], MSR_IA32_FRED_STKLVLS,
>> +	 * 	MSR_IA32_FRED_SSP[123], MSR_IA32_FRED_CONFIG,
>> +	 * are used by the kernel itself to take an exception at any time, they
>> +	 * should be context-switched by Intel VT-x automatically in order to
>> +	 * preserve the FRED architectural invariant that there should NEVER be
>> +	 * a "gap" during which it is unsafe to take an exception.
>> +	 *
>> +	 * KVM leverages Intel VT-x hardware to automatically context switch the
>> +	 * eight FRED MSRs using:
>> +	 *
>> +	 *   1) Dedicated host and guest VMCS fields for each MSR.
>> +	 *
>> +	 *   2) VM-entry/exit controls to manage the automated loading and saving
>> +	 *      of the eight FRED MSRs.
>> +	 *
>> +	 * Consequently, passing these MSRs through to the guest would only add
>                            ^
> Ditto.> +	 * unnecessary handling code without benefit.
>> +	 */
> 
> 
> I am not sure whether it needs to repeats the changelog almost the same description.
> But I see the version history mentions it was suggested by Dave and Chao?
> 
> Can this be just a summary instead?
> 

I will try to shorten this one and the next paragraph a bit.  But RSP0
treatment can be confusing to a first time reader so it makes sense to
explain it in code as well. The next paragraph also has wording that
makes more sense in the changelog ".. so no change is needed to the
interception logic.. "


>> +	/*
>> +	 * MSR_IA32_FRED_RSP0 and MSR_IA32_PL0_SSP (aka MSR_IA32_FRED_SSP0) are
>> +	 * designed for event delivery while executing in userspace.  Since KVM
>> +	 * operates entirely in kernel mode (CPL is always 0 after any VM exit),
>> +	 * it can safely retain and operate with guest-defined values for these
>> +	 * MSRs.
>> +	 *
>> +	 * Disabling interception of the two MSRs offers two advantages:
>> +	 *   1) Simplicity: Eliminates dedicated MSR handling code.
>> +	 *   2) Performance: Avoids frequent VM-exits since the two MSRs are
>> +	 *      per user thread variables and frequently accessed.
>> +	 *
>> +	 * MSR_IA32_PL0_SSP (aka MSR_IA32_FRED_SSP0) is part of CET supervisor
>> +	 * state, but all four FRED SSP MSRs are architecturally visible on any
>> +	 * processor that enumerates FRED.  Even if CET is absent, these MSRs
>> +	 * remain accessible via RDMSR/WRMSR, though FRED transitions will not
>> +	 * use them.
>> +	 *
>> +	 * Intercept MSR_IA32_PL0_SSP if CET shadow stacks are unsupported (even
>> +	 * with FRED present).  Since this MSR is rarely accessed and ignored by
>> +	 * XSAVES in this configuration, interception avoids the overhead of
>> +	 * manually context switching the hardware MSR during vcpu_load/put.
>> +	 *
>> +	 * This behavior is consistent with the current setup in
>> +	 * vmx_recalc_msr_intercepts(), so no change is needed to the interception
>> +	 * logic for MSR_IA32_PL0_SSP.
>> +	 */