Re: [PATCH v14 06/22] KVM: x86: Load guest FPU state when access XSAVE-managed MSRs

[Sean Christopherson <seanjc@google.com>]

On Wed, Sep 10, 2025, Chao Gao wrote:
> On Wed, Sep 10, 2025 at 05:37:50PM +0800, Xiaoyao Li wrote:
> >On 9/9/2025 5:39 PM, Chao Gao wrote:
> >> From: Sean Christopherson <seanjc@google.com>
> >> 
> >> Load the guest's FPU state if userspace is accessing MSRs whose values
> >> are managed by XSAVES. Introduce two helpers, kvm_{get,set}_xstate_msr(),
> >> to facilitate access to such kind of MSRs.
> >> 
> >> If MSRs supported in kvm_caps.supported_xss are passed through to guest,
> >> the guest MSRs are swapped with host's before vCPU exits to userspace and
> >> after it reenters kernel before next VM-entry.
> >> 
> >> Because the modified code is also used for the KVM_GET_MSRS device ioctl(),
> >> explicitly check @vcpu is non-null before attempting to load guest state.
> >> The XSAVE-managed MSRs cannot be retrieved via the device ioctl() without
> >> loading guest FPU state (which doesn't exist).
> >> 
> >> Note that guest_cpuid_has() is not queried as host userspace is allowed to
> >> access MSRs that have not been exposed to the guest, e.g. it might do
> >> KVM_SET_MSRS prior to KVM_SET_CPUID2.
> 
> ...
> 
> >> +	bool fpu_loaded = false;
> >>   	int i;
> >> -	for (i = 0; i < msrs->nmsrs; ++i)
> >> +	for (i = 0; i < msrs->nmsrs; ++i) {
> >> +		/*
> >> +		 * If userspace is accessing one or more XSTATE-managed MSRs,
> >> +		 * temporarily load the guest's FPU state so that the guest's
> >> +		 * MSR value(s) is resident in hardware, i.e. so that KVM can
> >> +		 * get/set the MSR via RDMSR/WRMSR.
> >> +		 */
> >> +		if (vcpu && !fpu_loaded && kvm_caps.supported_xss &&
> >
> >why not check vcpu->arch.guest_supported_xss?
> 
> Looks like Sean anticipated someone would ask this question.

I don't think so, I'm pretty sure querying kvm_caps.supported_xss is a holdover
from the early days of this patch, e.g. before guest_cpu_cap_has() existed, and
potentially even before vcpu->arch.guest_supported_xss existed.

I'm pretty sure we can make this less weird and more accurate:

/*
 * Returns true if the MSR in question is managed via XSTATE, i.e. is context
 * switched with the rest of guest FPU state.  Note!  S_CET is _not_ context
 * switched via XSTATE even though it _is_ saved/restored via XSAVES/XRSTORS.
 * Because S_CET is loaded on VM-Enter and VM-Exit via dedicated VMCS fields,
 * the value saved/restored via XSTATE is always the host's value.  That detail
 * is _extremely_ important, as the guest's S_CET must _never_ be resident in
 * hardware while executing in the host.  Loading guest values for U_CET and
 * PL[0-3]_SSP while executing in the kernel is safe, as U_CET is specific to
 * userspace, and PL[0-3]_SSP are only consumed when transitioning to lower
 * privilegel levels, i.e. are effectively only consumed by userspace as well.
 */
static bool is_xstate_managed_msr(struct kvm_vcpu *vcpu, u32 msr)
{
	if (!vcpu)
		return false;

	switch (msr) {
	case MSR_IA32_U_CET:
		return guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) ||
		       guest_cpu_cap_has(vcpu, X86_FEATURE_IBT);
	case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
		return guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK);
	default:
		return false;
	}
}

Which is very desirable because the KVM_{G,S}ET_ONE_REG path also needs to
load/put the FPU, as found via a WIP selftest that tripped:

  KVM_BUG_ON(!vcpu->arch.guest_fpu.fpstate->in_use, vcpu->kvm);

And if we simplify is_xstate_managed_msr(), then the accessors can also do:

  KVM_BUG_ON(!is_xstate_managed_msr(vcpu, msr_info->index), vcpu->kvm);