Re: [PATCH v13 05/21] KVM: x86: Load guest FPU state when access XSAVE-managed MSRs

[Chao Gao <chao.gao@intel.com>]

On Sun, Aug 24, 2025 at 06:52:55PM -0700, Xin Li wrote:
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 6b01c6e9330e..799ac76679c9 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -4566,6 +4569,21 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>>   }
>>   EXPORT_SYMBOL_GPL(kvm_get_msr_common);
>> +/*
>> + *  Returns true if the MSR in question is managed via XSTATE, i.e. is context
>> + *  switched with the rest of guest FPU state.
>> + */
>> +static bool is_xstate_managed_msr(u32 index)
>> +{
>> +	switch (index) {
>> +	case MSR_IA32_U_CET:
>
>
>Why MSR_IA32_S_CET is not included here?

Emm. I didn't think about this.

MSR_IA32_S_CET is read from or written to a dedicated VMCS/B field, so KVM
doesn't need to load the guest FPU to access MSR_IA32_S_CET. This pairs with
the kvm_{get,set}_xstate_msr() in kvm_{get,set}_msr_common().

That said, userspace writes can indeed cause an inconsistency between the guest
FPU and VMCS fields regarding MSR_IA32_S_CET. If migration occurs right after a
userspace write (without a VM-entry, which would bring them in sync) and
userspace just restores MSR_IA32_S_CET from the guest FPU, the write before
migration could be lost.

If that migration issue is a practical problem, I think MSR_IA32_S_CET should
be included here, and we need to perform a kvm_set_xstate_msr() after writing
to the VMCS/B.

>
>
>> +	case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
>> +		return true;
>> +	default:
>> +		return false;
>> +	}
>> +}
>
>
>Is it better to do?
>
>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.

>
>Thanks!
>    Xin