[PATCH 1/2] KVM: arm64: Fix MDCR_EL2.HPMN reset value

[Marc Zyngier]

On Mon, 17 Feb 2025 18:53:50 +0000,
Oliver Upton <oliver.upton at linux.dev> wrote:
> 
> Hey,
> 
> On Mon, Feb 17, 2025 at 11:24:11AM +0000, Marc Zyngier wrote:
> > The MDCR_EL2 documentation indicates that the HPMN field has
> > the following behaviour:
> > 
> > "On a Warm reset, this field resets to the expression NUM_PMU_COUNTERS."
> > 
> > However, it appears we reset it to zero, which is not very useful.
> > 
> > Add a reset helper for MDCR_EL2, and handle the case where userspace
> > changes the target PMU, which may force us to change HPMN again.
> > 
> > Reported-by: Joey Gouly <joey.gouly at arm.com>
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> 
> The existing ABI expectations are that writes to PMCR_EL0.N constrain
> the number of counters, so that should have a similar effect on
> MDCR_EL2.HPMN.
> 
> At the same time, I get the feeling that we should throw out this whole
> behavior of writing N to change the shape of the PMU, because it
> complete breaks down for NV. PMCR_EL0.N is another one of those fields
> that change behavior based on EL and isn't a global source of truth on
> the shape of the PMU.
> 
> What do you think about adding a new vCPU attribute for selecting the
> number of counters for a VM? We can allow non-nested VMs to use the
> 'old' method of writing PMCR_EL0.N and force nested VMs to use the
> attribute.

VCPU attribute? or PMU attribute? I'm really not keen on the former,
but the latter is probably workable, as it is VM-wide, similar to the
way we keep track of pmcr_n.

> We can then enforce ordering on the attribute and prevent it from being
> used after vCPU reset.

How would that work? Do you really want to mandate the PMU selection
(with its counter capping) to strictly occur between vcpu creation and
init?

This would, for example, break kvmtool which has these two operations
back-to-back, and sneaking new device-specific actions in the middle
is a bit unpalatable (there is a split between VM-wide and per-vcpu
actions).

Any idea?

	M.

-- 
Without deviation from the norm, progress is not possible.