On Wed, 18 Oct 2023 19:24:11 +0100,
Oliver Upton <oliver.upton@xxxxxxxxx> 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@xxxxxxxxx> 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.
