Oliver Upton oliver.upton@linux.dev 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.
It would be cool to have perf reschedule events. I'm not positive how to do that, but it looks not too hard. Can someone comment on the correctness and feasibility here?
1. Scan perf events and call event_sched_out on all events using the counters KVM wants. 2. Do the PMU surgery to change the available counters. 3. Call ctx_resched to reschedule events with the available counters.
There is a second option to avoid a permanent partition up front. We know which counters are in use through used_mask. We could check if the partition would claim any counters in use and fail with an error if it would.