Re: [PATCH v2 2/2] KVM: arm64: Virtualise PMEVTYPER<n>_EL1.{NSU,NSK}

[Marc Zyngier <maz@kernel.org>]

On Wed, 18 Oct 2023 19:24:11 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Wed, Oct 18, 2023 at 02:31:11PM +0100, Marc Zyngier wrote:
> > On Fri, 13 Oct 2023 06:29:01 +0100,
> > Oliver Upton <oliver.upton@linux.dev> wrote:
> > > 
> > > Suzuki noticed that KVM's PMU emulation is oblivious to the NSU and NSK
> > > event filter bits. On systems that have EL3 these bits modify the
> > > filter behavior in non-secure EL0 and EL1, respectively. Even though the
> > > kernel doesn't use these bits, it is entirely possible some other guest
> > > OS does.
> > 
> > But what does it mean for KVM itself? We have no EL3 to speak of as
> > far as a guest is concerned. And the moment we allow things like
> > NSU/NSK to be set, why don't we allow M as well?
> 
> Yeah, we need to have a think about all these extra bits TBH.
> 
> KVM doesn't filter the advertised ELs in PFR0, so from the guest POV
> both EL2 and EL3 could potentially be implemented by the vCPU. Based
> on that I think the bits at least need to be stateful, even though KVM's
> emulation will never let the guest count events in a higher EL.
> 
> My patches aren't even consistent with the above statement, as NSH gets
> RES0 treatment and the NS{U,K} bits do not. So how about this:
> 
>  - If EL3 is advertised in the guest's ID registers NS{U,K}, and M can
>    be set. NS{U,K} work as proposed, M is ignored in KVM emulation.
> 
>  - If EL2 is advertised in the guest's ID registers NSH can be set but
>    is ignored in KVM emulation.
> 
> Thoughts?

This would be consistent with the pseudocode (and what KVM can
reasonably achieve at this stage).

Care to respin it?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.