Hi James, On Wed, Sep 30, 2026 at 04:26:23PM +0100, James Clark wrote: > On 24/09/2026 18:29, Colton Lewis wrote: > > This series creates a new PMU scheme on ARM, a partitioned PMU that > > allows reserving a subset of counters for more direct guest access, > > significantly reducing overhead. More details, including performance > > benchmarks, can be read in the v1 cover letter linked below. > > > > There is no longer a kernel command line parameter > > (`arm_pmuv3.reserved_host_counters`); PMU partitioning is now completely > > controlled via the KVM API using `KVM_ARM_VCPU_PMU_V3_ENABLE_PARTITION` > > and `KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS` vCPU device attributes. When > > As far as I know there isn't a straightforward way to get the number of hw > counters from userspace. You have to either parse dmesg or attempt to open > incrementally more counters in a group until it fails. > > This makes doing things like "use all counters for guest" or "reserve two > for the host" difficult. Maybe it's time to add a file to the PMU that > userspace can use query this.
Inside a VMM, userspace can query the default PMCR_EL0.N via KVM_GET_ONE_REG(SYS_PMCR_EL0) after KVM_ARM_VCPU_INIT (or KVM_ARM_VCPU_PMU_V3_SET_PMU) and before calling KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS, since KVM initializes nr_pmu_counters to the PMU's max_counters (which is how vpmu_counter_access discovers the limit). For users and management tools outside the VMM (e.g. choosing N to pass on the QEMU command line), I agree it's awkward that /sys/bus/event_source/devices/<pmu>/caps/ exposes slots and bus_width but not the number of counters. I will add a patch to expose a caps attribute for the number of counters in drivers/perf/arm_pmuv3.c. Thanks, Colton
