Re: [PATCH v3 06/22] perf: arm_pmuv3: Introduce method to partition the PMU

[Oliver Upton <oliver.upton@linux.dev>]

On Mon, Jul 07, 2025 at 05:57:14PM +0100, Mark Rutland wrote:
> On Thu, Jun 26, 2025 at 08:04:42PM +0000, Colton Lewis wrote:
> > For PMUv3, the register field MDCR_EL2.HPMN partitiones the PMU
> > counters into two ranges where counters 0..HPMN-1 are accessible by
> > EL1 and, if allowed, EL0 while counters HPMN..N are only accessible by
> > EL2.
> > 
> > Create module parameter reserved_host_counters to reserve a number of
> > counters for the host. This number is set at boot because the perf
> > subsystem assumes the number of counters will not change after the PMU
> > is probed.
> > 
> > Introduce the function armv8pmu_partition() to modify the PMU driver's
> > cntr_mask of available counters to exclude the counters being reserved
> > for the guest and record reserved_guest_counters as the maximum
> > allowable value for HPMN.
> > 
> > Due to the difficulty this feature would create for the driver running
> > at EL1 on the host, partitioning is only allowed in VHE mode. Working
> > on nVHE mode would require a hypercall for every counter access in the
> > driver because the counters reserved for the host by HPMN are only
> > accessible to EL2.
> 
> It would be good if we could elaborate on this last point. When exactly
> do we intend to configure HPMN (e.g. is that static, dynamic at
> load/put, or dynamic at finer granularity)?
> 
> I ask becuase it's not immediately clear to me how this would break nVHE
> without also breaking direct userspace access on VHE, unless we flip
> HPMN dynamically at load/put, and this is only broken in some transient
> windows on nVHE.

Agree that KVM's HPMN can only take effect between vcpu_load() /
vcpu_put().

The changelog isn't correct regarding the complications of nVHE, though.
In order to support a 'partitioned' PMU on nVHE we'd need to explicitly
disable guest counters on every exit and reset HPMN to place all
counters in the 'first range'. Unless someone has a use case for this
stuff on nVHE I'm not too bothered by the VHE-only limitation.

> > 
> > Signed-off-by: Colton Lewis <coltonlewis@google.com>
> > ---
> >  arch/arm/include/asm/arm_pmuv3.h   | 14 ++++++
> >  arch/arm64/include/asm/arm_pmuv3.h |  5 ++
> >  arch/arm64/include/asm/kvm_pmu.h   |  6 +++
> >  arch/arm64/kvm/Makefile            |  2 +-
> >  arch/arm64/kvm/pmu-part.c          | 23 ++++++++++
> 
> Maybe I'll contradict Oliver and Marc here (and whatever they say
> rules), but IMO it'd be nice to spell out "partition" rather than "part"
> here for clarity.

I'm not too big of a fan of the naming here either. I'd prefer something
like "pmu-direct". Partitioning is just a side effect of how we're
allocating counters currently and most of this implementation could be
reused if we pass the entire PMU to the guest in the future.

With that being said -- Colton I'd focus on getting these patches in
shape while we figure out what color we want it ;-)

Thanks,
Oliver