Re: [RFC PATCH 21/27] KVM: x86: Make kvm_vcpu_after_set_cpuid() return an error code

[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=21

[...]
> @@ -649,7 +651,9 @@ static int kvm_set_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 *e2,
>  #ifdef CONFIG_KVM_XEN
>  	vcpu->arch.xen.cpuid = kvm_get_hypervisor_cpuid(vcpu, XEN_SIGNATURE);
>  #endif
> -	kvm_vcpu_after_set_cpuid(vcpu);
> +	r = kvm_vcpu_after_set_cpuid(vcpu);
> +	if (r)
> +		goto err;
>  
>  success:
>  	kvfree(e2);

"Is vcpu->arch.xen.cpuid successfully restored when kvm_vcpu_after_set_cpuid()
fails?
Looking at the error path in kvm_set_cpuid():
err:
	memcpy(vcpu->arch.cpu_caps, vcpu_caps, sizeof(vcpu_caps));
	swap(vcpu->arch.cpuid_entries, e2);
	swap(vcpu->arch.cpuid_nent, nent);
	return r;
}
We restore cpuid_entries, cpuid_nent, and cpu_caps, but it does not look like
vcpu->arch.xen.cpuid is reverted back to its original state.
Could this leave xen.cpuid permanently out-of-sync with the restored CPUID
entries if an invalid configuration is rejected?"

This is a valid concern.

It is simple to snapshot the value of vcpu->arch.xen.cpuid and restore it if
the check fails. And after a further check, kvm_hv_vcpu_init() is also called
before CPUID paranoid check. If hv_vcpu is already allocated, nothing changed
in kvm_hv_vcpu_init(). If hv_vcpu has not been allocated, the memory allocated
in kvm_hv_vcpu_init() needs to be freed if the check fails.
 
Another option is to split paranoid CPUID verification out. As described as an
open in the cover letter, this patch series combines vCPU capability initialization
and paranoid CPUID verification inside kvm_vcpu_after_set_cpuid(). The issue is
gone if the paranoid CPUID verification is done before these changes are made, though
there will be some duplications during paranoid CPUID verification and vCPU
capability initialization.