Re: [PATCH v5 22/24] KVM: arm64: Add KVM_CAP to partition the PMU

Colton Lewis
2025-12-12T22:59:03Z

Oliver Upton <oupton@kernel.org> writes:

> On Tue, Dec 09, 2025 at 08:51:19PM +0000, Colton Lewis wrote:
>> +
>> +7.245 KVM_CAP_ARM_PARTITION_PMU
>> +-------------------------------------
>> +

> Why can't this be a vCPU attribute similar to the other vPMU controls?
> Making the UAPI consistent will make it easier for userspace to reason
> about it.

I'm confused by the inconsistency of using a vCPU attribute for
something we want to affect the whole VM.

But I'll do a vCPU attribute if you want.

> Better yet, we could make the UAPI such that userspace selects a PMU
> implementation and the partitioned-ness of the PMU at the same time.

Sounds good.

>> @@ -132,6 +134,16 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>> }
>> mutex_unlock(&kvm->lock);
>> break;
>> + case KVM_CAP_ARM_PARTITION_PMU:
>> + if (kvm->created_vcpus) {
>> + r = -EBUSY;
>> + } else if (!kvm_pmu_partition_ready()) {
>> + r = -EPERM;
>> + } else {
>> + r = 0;
>> + kvm_pmu_partition_enable(kvm, cap->args[0]);
>> + }
>> + break;
>> default:
>> break;
>> }
>> @@ -388,6 +400,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm,
>> long ext)
>> case KVM_CAP_ARM_PMU_V3:
>> r = kvm_supports_guest_pmuv3();
>> break;
>> + case KVM_CAP_ARM_PARTITION_PMU:
>> + r = kvm_pmu_partition_ready();

> "ready" is very confusing in this context, as KVM will never be ready to
> support the feature on a system w/o the prerequisites.

That was a last minute addition. I'll change the name to something
better.

> Thanks,
> Oliver