Oliver Upton <[email protected]> writes:
On Mon, Jun 02, 2025 at 07:27:01PM +0000, Colton Lewis wrote:+ case KVM_ARM_PARTITION_PMU: {
This should be a vCPU attribute similar to the other PMUv3 controls we already have. Ideally a single attribute where userspace tells us it wants paritioning and specifies the PMU ID to use. None of this can be changed after INIT'ing the PMU.
Okay
+ struct arm_pmu *pmu; + u8 host_counters; + + if (unlikely(!kvm_vcpu_initialized(vcpu))) + return -ENOEXEC; + + if (!kvm_pmu_partition_supported()) + return -EPERM; + + if (copy_from_user(&host_counters, argp, sizeof(host_counters))) + return -EFAULT; + + pmu = vcpu->kvm->arch.arm_pmu; + return kvm_pmu_partition(pmu, host_counters);
Yeah, we really can't be changing the counters available to the ARM PMU driver at this point. What happens to host events already scheduled on the CPU?
Okay. I remember talking about this before.
Either the partition of host / KVM-owned counters needs to be computed up front (prior to scheduling events) or KVM needs a way to direct perf to reschedule events on the PMU based on the new operating constraints.
Yes. I will think about it.
