Re: [PATCH 0/3] KVM: arm64: nv: Add EL2 PMU event filtering support

[Marc Zyngier <maz@kernel.org>]

On Tue, 27 Aug 2024 08:01:11 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Tue, Aug 27, 2024 at 07:35:15AM +0100, Marc Zyngier wrote:
> > > Thoughts?
> > 
> > I see that you have already posted your proposed approach, but allow
> > me to say what I have in mind.
> > 
> > We have three possibilities:
> > 
> > - either we go with your approach, which has the advantage of not
> >   requiring any new trap description, but breaks the (unwritten)
> >   promise that we don't do any "local" handling at this stage
> > 
> > - or we perform the handling where we normally do it (in sys_regs.c),
> >   but we start littering the already overly complicated emulation code
> >   for something that is barely a trap reinjection
> 
> Hell no :)
> 
> > - or (and this is my preferred option), we treat it as a "fast" trap,
> >   which would match what we do for other things that we trap and that
> >   behave differently when 'InHost' (ERET, TLBIs).
> > 
> > This last option does require another bit of decoding, but has the
> > following advantages:
> > 
> > - it follows the existing model for 'InHost' trap handling
> > 
> > - it is close to optimal from a performance perspective
> > 
> > - it doesn't change the existing behaviour of the xarray handling
> > 
> > The way I think of it, this sort of EL0->EL2 trap reinjection is
> > simply the other side of the ERET coin, and I would very much like to
> > keep this symmetry, unless I have missed something obvious.
> > 
> > What do you think?
> 
> My primary concern about stuffing more things into the fast path is the
> limited debuggability since we can't use instrumentation in a
> not-quite-kernel context.

Yes and no. We can use *some* instrumentation (such as tracing, and
even - horror - printk). But it is the likes of WARN() that go south
because the VHE vectors are not handling BRK as the rest of the
kernel. This is definitely on my list of things to fix.

> I do generally agree with the intent of organizing it all similarly,
> just that the traps infrastructure is _really_ handy for doing the job.

Maybe there is a middle-ground here. We could, as you suggest, use the
xarray as the repository for trap routing information (including the
'InHost' aspect), and yet have the fast path. It shouldn't be too hard
to expose a lookup function and the relevant helpers to decode the
63bit control word.

> Let me take an accounting of how many other 'InHost' trap bits we have
> and get a feel for if we need a generalized solution or if I can do
> something PMU-specific here.

That'd be super useful indeed.

Thanks,

	M.

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