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;@@ -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