Oliver Upton <[email protected]> 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