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

From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Reiji Watanabe <reijiw@google.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Catalin Marinas <catalin.marinas@arm.com>,
	kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ricardo Koller <ricarkol@google.com>,
	Jing Zhang <jingzhangos@google.com>,
	Raghavendra Rao Anata <rananta@google.com>,
	Shaoqin Huang <shahuang@redhat.com>,
	Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v2 0/2] KVM: arm64: PMU: Correct the handling of PMUSERENR_EL0
Date: Wed, 12 Apr 2023 11:29:50 +0100	[thread overview]
Message-ID: <86ttxll7fl.wl-maz@kernel.org> (raw)
In-Reply-To: <20230411112458.GA22090@willie-the-truck>

On Tue, 11 Apr 2023 12:24:59 +0100,
Will Deacon <will@kernel.org> 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@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.

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel