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

Reply via email to