On Tue, 11 Apr 2023 12:24:59 +0100,
Will Deacon <will@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxx> 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.
Given that Mark and Reiji are still working out some of the corner
cases, -rc1 feels like the right target.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
