Re: [RFC PATCH 23/27] KVM: x86: Account for runtime CPUID features in paranoid mode

[Binbin Wu <binbin.wu@linux.intel.com>]

Below are responses to issues reported by sashiko. [1]
[1] https://sashiko.dev/#/patchset/20260417073610.3246316-1-binbin.wu%40linux.intel.com?part=23

> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 2027230a1f426..af87b803572c0 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -498,6 +498,24 @@ static int do_cpuid_reg_paranoid_check(struct kvm *kvm,
>  	return -EINVAL;
>  }
>  
> +static u32 get_cpuid_reg_dynamic(struct kvm_vcpu *vcpu, u32 func, u32 index, int reg)
> +{
> +	switch (func) {
> +	case 1:
> +		if (reg == CPUID_ECX && kvm_is_cr4_bit_set(vcpu, X86_CR4_OSXSAVE))
> +			return feature_bit(OSXSAVE);
Issue #1:
"Does this create a circular dependency that breaks VM migration?
KVM requires X86_FEATURE_XSAVE to be present in the guest CPUID before allowing
CR4.OSXSAVE to be set (via cr4_guest_rsvd_bits). Because of this, VMMs must call
KVM_SET_CPUID2 before KVM_SET_SREGS during VM restore.
However, get_cpuid_reg_dynamic() requires the vCPU's CR4 register to already have
the OSXSAVE bit set in order to include the OSXSAVE feature bit in the supported
mask.
If a VMM live-migrates a running VM and passes the current CPUID array (where
KVM has dynamically set OSXSAVE=1), will KVM_SET_CPUID2 falsely reject the array
with -EINVAL because the destination's CR4 is still at its reset value (0)?
This would mean CPUID needs CR4 to validate OSXSAVE, but CR4 needs CPUID to allow
OSXSAVE, breaking live migration when paranoid CPUID checks are enabled."

This should be a false positive.

If userspace needs to set CR4, it should use KVM_SET_{SREGS,SREGS2}, which doesn't
rely on the CPUID bit.

Actually userspace doesn't need to set OSXSAVE CPUID bit explicitly, KVM will take
care of it.

This helper exists to handle the scenario as following, which exists in KVM selftests:

E.g. in hyperv_features.c
guest_test_msrs_access
|   vm_create_with_one_vcpu
|   |   ...
|   |       vm_arch_vcpu_add
|   |       |   vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid())
|   |       |   vcpu_init_sregs
|   |       |   |   [kvm_cpu_has(X86_FEATURE_XSAVE)]
|   |       |   |       sregs.cr4 |= X86_CR4_OSXSAVE
|   |       |   |   ...
|   |       |   |   vcpu_sregs_set(vcpu, &sregs)
|   |       |   ...
|   |       |   vcpu_get_cpuid(vcpu)
|   ...
|   vcpu_set_cpuid(vcpu)  //OSXSAVE is set in CPUID.


> +		break;
> +	case 7:
> +		if (index == 0 && reg == CPUID_ECX && kvm_is_cr4_bit_set(vcpu, X86_CR4_PKE))
> +			return feature_bit(OSPKE);
Issue #2:
"Could the same circular dependency issue also apply to OSPKE and CR4.PKE?"

Same as above.