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

[Oliver Upton <oliver.upton@linux.dev>]

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.

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

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.

-- 
Thanks,
Oliver