[PATCH v2 0/2] KVM: arm64: PMU: Correct the handling of PMUSERENR_EL0

[Will Deacon]

On Sat, Apr 08, 2023 at 10:04:19AM +0100, Marc Zyngier wrote:
> On Sat, 08 Apr 2023 04:47:57 +0100,
> Reiji Watanabe <reijiw at google.com> wrote:
> > 
> > This series will fix bugs in KVM's handling of PMUSERENR_EL0.
> > 
> > With PMU access support from EL0 [1], the perf subsystem would
> > set CR and ER bits of PMUSERENR_EL0 as needed to allow EL0 to have
> > a direct access to PMU counters.  However, KVM appears to assume
> > that the register value is always zero for the host EL0, and has
> > the following two problems in handling the register.
> > 
> > [A] The host EL0 might lose the direct access to PMU counters, as
> >     KVM always clears PMUSERENR_EL0 before returning to userspace.
> > 
> > [B] With VHE, the guest EL0 access to PMU counters might be trapped
> >     to EL1 instead of to EL2 (even when PMUSERENR_EL0 for the guest
> >     indicates that the guest EL0 has an access to the counters).
> >     This is because, with VHE, KVM sets ER, CR, SW and EN bits of
> >     PMUSERENR_EL0 to 1 on vcpu_load() to ensure to trap PMU access
> >     from the guset EL0 to EL2, but those bits might be cleared by
> >     the perf subsystem after vcpu_load() (when PMU counters are
> >     programmed for the vPMU emulation).
> > 
> > Patch-1 will fix [A], and Patch-2 will fix [B] respectively.
> > The series is based on v6.3-rc5.
> > 
> > v2:
> >  - Save the PMUSERENR_EL0 for the host in the sysreg array of
> >    kvm_host_data. [Marc]
> >  - Don't let armv8pmu_start() overwrite PMUSERENR if the vCPU
> >    is loaded, instead have KVM update the saved shadow register
> >    value for the host. [Marc, Mark]
> 
> This looks much better to me. If Mark is OK with it, I'm happy to take
> it in 6.4.
> 
> Speaking of which, this will clash with the queued move of the PMUv3
> code into drivers/perf, and probably break on 32bit. I can either take
> a branch shared with arm64 (009d6dc87a56 ("ARM: perf: Allow the use of
> the PMUv3 driver on 32bit ARM")), or wait until -rc1.
> 
> Will, what do you prefer?

I'd be inclined to wait until -rc1, but for-next/perf is stable if you
decide to take it anyway.

Will