[PATCH] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests

[Oliver Upton]

On Mon, Jun 08, 2026 at 09:03:59PM +0000, Congkai Tan wrote:
> On Mon, Jun 01, 2026 at 01:06:17PM -0700, Oliver Upton wrote:
> > We can't change the value of PMMIR_EL1 unconditionally since older KVM
> > treated this register as RAZ/WI. This also mixes poorly with the default
> > PMU garbage that we have since as the value of the register can change
> > based on where KVM_ARM_VCPU_INIT gets called...
> >
> > Considering everything, I'd like to see this wired up where:
> >
> >  - PMMIR_EL1.SLOTS takes the value of the underlying hardware PMU only
> >    if the VMM explicitly selects a particular PMU implementation
> >
> >  - KVM allows userspace to set PMMIR_EL1.SLOTS=0 for backwards
> >    compatibility
> 
> Thanks a lot for the review! Makes sense. We'll work on v2, and here is
> the high-level design we plan to follow:
> 
>   - Introduce a new VM-wide field, e.g. kvm->arch.pmmir_slots.
> 
>   - Seed it from the underlying hardware value only when handling
>     KVM_ARM_VCPU_PMU_V3_SET_PMU; otherwise it stays 0.
> 
>   - access_pmmir() returns whatever is in pmmir_slots.
>   
>   - set_pmmir() writes pmmir_slots to 0 if the user input is 0;
>     otherwise it no-ops or rejects.

Reject is always better heh :)

So I was previously under the impression that we already expose PMMIR_EL1
to userspace but we actually don't. Grr.

The UAPI around PMUv3 is crappy enough that we should just add a new
vCPU feature flag. When that flag is set:

 - KVM will not create a 'default' PMU, userspace must select a PMU
   implementation to init the vCPU

 - PMMIR_EL1 becomes a user-visible register with the behavior that you
   outline above

 - No PMCEID masking for STALL_SLOT* events

There's a couple larger PMU features underway (e.g. Colton's partitioned
PMU, Akihiko's fixed counters PMU) that we can also condition on the new
feature flag.

Does this sound OK to you?

Thanks,
Oliver