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

[Congkai Tan <congkai@amazon.com>]

On Mon, Jun 08, 2026 at 09:54:45PM -0700, Oliver Upton wrote:
> >   - set_pmmir() writes pmmir_slots to 0 if the user input is 0;
> >     otherwise it no-ops or rejects.
>
> Reject is always better heh :)

For sure. Just to see what happens when migrating a guest onto a PMU
with different SLOTS - after pmmir_slots is set to the new value, the VMM
tries to restore the original non-zero SLOTS via SET_ONE_REG and gets the
error. I think it's a good design to force VMMs to be aware of SLOTS
changes?

> 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.

It makes sense to guard everything behind a flag. Just to confirm my
understanding, by "a new vCPU feature flag" are you referring to
extending the features set through KVM_ARM_VCPU_INIT? If so,
since the flag may guard more PMU features later, do you have a preferred
name in mind that best reflects its planned usage?

For v2 I'll work on 3 patches:

  - Patch 1 adds the flag, skips the default PMU selection behind it, and
    checks for/rejects absent PMU

  - Patch 2 implements the new PMMIR_EL1 behavior

  - Patch 3 implements the new PMCEID1 behavior

Thanks,
Congkai