Re: [RFC PATCH v3 5/8] KVM: arm64: Introduce module param to partition the PMU

From: James Clark
Date: Wed Mar 26 2025 - 13:40:28 EST




On 25/03/2025 6:32 pm, Colton Lewis wrote:
Hi James,

Thanks for the review.

James Clark <james.clark@xxxxxxxxxx> writes:

On 13/02/2025 6:03 pm, Colton Lewis wrote:
For PMUv3, the register 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.

Introduce a module parameter in KVM to set this register. The name
reserved_host_counters reflects the intent to reserve some counters
for the host so the guest may eventually be allowed direct access to a
subset of PMU functionality for increased performance.

Track HPMN and whether the pmu is partitioned in struct arm_pmu
because both KVM and the PMUv3 driver will need to know that to handle
guests correctly.

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 register access
because the counters reserved for the host by HPMN are now only
accessible to EL2.

The parameter is only configurable at boot time. Making the parameter
configurable on a running system is dangerous due to the difficulty of
knowing for sure no counters are in use anywhere so it is safe to
reporgram HPMN.


Hi Colton,

For some high level feedback for the RFC, it probably makes sense to
include the other half of the feature at the same time. I think there is
a risk that it requires something slightly different than what's here
and there ends up being some churn.

I agree. That's what I'm working on now. I justed wanted an iteration or
two in public so I'm not building on something that needs drastic change
later.

Other than that I think it looks ok apart from some minor code review nits.

Thank you

I was also thinking about how BRBE interacts with this. Alex has done
some analysis that finds that it's difficult to use BRBE in guests with
virtualized counters due to the fact that BRBE freezes on any counter
overflow, rather than just guest ones. That leaves the guest with branch
blackout windows in the delay between a host counter overflowing and the
interrupt being taken and BRBE being restarted.

But with HPMN, BRBE does allow freeze on overflow of only one partition
or the other (or both, but I don't think we'd want that) e.g.:

   RNXCWF: If EL2 is implemented, a BRBE freeze event occurs when all of
   the following are true:

   * BRBCR_EL1.FZP is 1.
   * Generation of Branch records is not paused.
   * PMOVSCLR_EL0[(MDCR_EL2.HPMN-1):0] is nonzero.
   * The PE is in a BRBE Non-prohibited region.

Unfortunately that means we could only let guests use BRBE with a
partitioned PMU, which would massively reduce flexibility if hosts have
to lose counters just so the guest can use BRBE.

I don't know if this is a stupid idea, but instead of having a fixed
number for the partition, wouldn't it be nice if we could trap and
increment HPMN on the first guest use of a counter, then decrement it on
guest exit depending on what's still in use? The host would always
assign its counters from the top down, and guests go bottom up if they
want PMU passthrough. Maybe it's too complicated or won't work for
various reasons, but because of BRBE the counter partitioning changes go
from an optimization to almost a necessity.

This is a cool idea that would enable useful things. I can think of a
few potential problems.

1. Partitioning will give guests direct access to some PMU counter
registers. There is no reliable way for KVM to determine what is in use
from that state. A counter that is disabled guest at exit might only be
so temporarily, which could lead to a lot of thrashing allocating and
deallocating counters.

2. HPMN affects reads of PMCR_EL0.N, which is the standard way to
determine how many counters there are. If HPMN starts as a low number,
guests have no way of knowing there are more counters
available. Dynamically changing the counters available could be
confusing for guests.


Yes I was expecting that PMCR would have to be trapped and N reported to be the number of physical counters rather than how many are in the guest partition.

3. If guests were aware they could write beyond HPMN and get the
counters allocated to them, nothing stops them from writing at counter
N and taking as many counters as possible to starve the host.


Is that much different than how it is now with virtualized PMUs? As in, the guest can use all of the counters and the host's events will have to contend with them.

You can still have a module param, except it's more of a limit to the size of the partition rather than fixing it upfront. The default value would be the max number of counters, allowing the most flexibility for the common use case where it's unlikely that both host and guests are contending for all counters. But if you really want to make sure the host doesn't get starved you can set it to a lower value.

All this does sound a bit like it could be done on top of the simple partitioning though. And it's mainly for making BRBE more accessible, which I'm not 100% convinced that the blackout windows are that big of a problem. We could say BRBE may have some holes if the host happens to be using counters at the same time, and if you want to be certain of no holes, use a host with partitioned counters.

James