On 8/24/2025 7:55 PM, Chao Gao wrote:
static bool is_xstate_managed_msr(u32 index)
{
if (!kvm_caps.supported_xss)
return false;
switch (index) {
case MSR_IA32_U_CET:
case MSR_IA32_S_CET:
case MSR_IA32_PL1_SSP ... MSR_IA32_PL3_SSP:
return kvm_caps.supported_xss & XFEATURE_MASK_CET_USER &&
kvm_caps.supported_xss & XFEATURE_MASK_CET_KERNEL;
default:
return false;
This will duplicate checks in other functions. I slightly prefer to keep this
function super simple and do all capability checks in __kvm_{set,get}_msr()
or kvm_emulate_msr_{write,read}.
}
}
And it would be obvious how to add new MSRs related to other XFEATURE bits.
Just return true for all those MSRs, regardless of host capabilities. If
kvm_caps doesn't support them, those MSRs are not advertised to userspace
either (see kvm_probe_msr_to_save()). Loading or putting the guest FPU when
userspace attempts to read/write those unsupported MSRs shouldn't cause any
performance issues, as userspace is unlikely to access them in hot paths.
There is no problem as of now, because there are only two CET related bits
set in KVM_SUPPORTED_XSS. So if !CET, the two bits are cleared thus
kvm_caps.supported_xss is 0, and kvm_load_guest_fpu() is never executed in
__msr_io().
However after any new bit is added to KVM_SUPPORTED_XSS in future, if !CET,
kvm_caps.supported_xss could be non-zero. There should still be no problem
because we don't expect any access to CET MSRs.
The trouble comes with MSR_IA32_PL0_SSP when FRED and !CET, because it will
be accessed even !CET. And we need to have to do the following:
static bool is_xstate_managed_msr(u32 index)
{
switch (index) {
case MSR_IA32_U_CET:
case MSR_IA32_PL1_SSP ... MSR_IA32_PL3_SSP:
return true;
case MSR_IA32_PL0_SSP:
return kvm_caps.supported_xss & XFEATURE_MASK_CET_USER &&
kvm_caps.supported_xss & XFEATURE_MASK_CET_KERNEL;
default:
return false;
}
}
Then it makes more sense to handle all CET MSRs consistently.
Thanks!
Xin
