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
