Re: [PATCH v9 08/22] KVM: VMX: Set FRED MSR intercepts

[Sean Christopherson <seanjc@google.com>]

On Fri, Mar 06, 2026, Chao Gao wrote:
> On Wed, Mar 04, 2026 at 04:48:52PM -0800, Sean Christopherson wrote:
> >On Wed, Nov 12, 2025, Chao Gao wrote:
> >> On Sun, Oct 26, 2025 at 01:18:56PM -0700, Xin Li (Intel) wrote:
> >> >From: Xin Li <xin3.li@intel.com>
> >> >
> >> >On a userspace MSR filter change, set FRED MSR intercepts.
> >> >
> >> >The eight FRED MSRs, MSR_IA32_FRED_RSP[123], MSR_IA32_FRED_STKLVLS,
> >> >MSR_IA32_FRED_SSP[123] and MSR_IA32_FRED_CONFIG, are all safe to
> >> >passthrough, because each has a corresponding host and guest field
> >> >in VMCS.
> >> 
> >> Sean prefers to pass through MSRs only when there is a reason to do that rather
> >> than just because it is free. My thinking is that RSPs and SSPs are per-task
> >> and are context-switched frequently, so we need to pass through them. But I am
> >> not sure if there is a reason for STKLVLS and CONFIG.
> >
> >There are VMCS fields, at which point intercepting and emulating is probably
> >more work than just letting the guest access directly. :-/
> 
> Just drop the MSR intercepting code and everything should work, right? KVM
> needs to handle userspace writes anyway. so, there is no "more work" to me.

True.  I was thinking KVM would need to marshall the value to/from the hardware
MSR, but that's obviously not necessary :-)  (and also would be comically wrong).

After working through the various implications, I think it makes to adjust the
"rule" to be "if necessary for performance OR it's _completely_ free (minus the
interception toggling)" (and in both cases, obviously disabling interception needs
to be functionally safe/correct too).  Because I think we'll end up with confusing
code if we limit disable interception only for performance reasons.

E.g. I can't imagine MSR_IA32_S_CET will get modified post-boot, so by the
performance-only rule, KVM should always intercept S_CET.  But MSR_IA32_U_CET
can be read/written much more frequency, and so should be passed through.  And
then we'd end up intercept S_CET but not U_CET, which _looks_ wrong.

The FRED MSRs fall into the same boat.  Intercepting only STKLVLS and CONFIG is
likely a-ok from a performance perspective, but once this is all merged and folks
that weren't part of this discussion come along, readers will likely be wondering
why STKLVLS and CONFIG are "missing".

All in all, unless someone has an functional or performance argument against
disabling interception, I think it makes sense to disabling interception for all
FRED MSRs that are context switched by hardware.