Re: [PATCH v4 1/1] KVM: x86: Introduce has_protected_pmu state for TDX VMs

[Sean Christopherson]

On Thu, May 07, 2026, Vishal Annapurve wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0a1b63c63d1a..c248abb0e2ab 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6909,6 +6909,13 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>  		if (!enable_pmu || (cap->args[0] & ~KVM_CAP_PMU_VALID_MASK))
>  			break;
>  
> +		if (kvm->arch.has_protected_pmu) {
> +			WARN_ON_ONCE(kvm->arch.enable_pmu);
> +			if (cap->args[0] == KVM_PMU_CAP_DISABLE)
> +				r = 0;
> +			break;

Sashiko: 3, Sean: 0

 : Does this code bypass standard lifecycle validation?
 : 
 : For standard VMs, KVM strictly enforces that PMU capabilities can only be
 : configured before any vCPUs are created, returning -EINVAL otherwise. The newly
 : added block for TDX VMs short-circuits this logic, returning 0 unconditionally
 : when disabling the PMU, regardless of whether vCPUs have been created.
 : Could this introduce a UAPI inconsistency where the same userspace sequence
 : could fail on standard VMs but silently succeed on TDX VMs, potentially
 : hiding VMM initialization order bugs?

That potential issue crossed my mind when first trying to figure out how to allow
KVM_PMU_CAP_DISABLE for protected PMUs, but then SQUIRREL!!!

I think my original reaction is the way to go: add extra validation for protected
PMUs (reject everything except CAP_DISABLE), but otherwise let the normal flow do
it's thing.

Completely untested, but I think this would do what we want?

	case KVM_CAP_PMU_CAPABILITY:
		r = -EINVAL;
		if (!enable_pmu || (cap->args[0] & ~KVM_CAP_PMU_VALID_MASK))
			break;

		if (kvm->arch.has_protected_pmu &&
		    cap->args[0] != KVM_PMU_CAP_DISABLE)
			break;

		mutex_lock(&kvm->lock);
		if (!kvm->created_vcpus && !kvm->arch.created_mediated_pmu) {
			kvm->arch.enable_pmu = !(cap->args[0] & KVM_PMU_CAP_DISABLE);
			r = 0;
		}
		mutex_unlock(&kvm->lock);
		break;