Re: [PATCH v2 06/13] KVM: arm64: Refactor hvc filtering to support different actions

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

On Fri, Mar 31, 2023 at 06:03:26PM +0100, Marc Zyngier wrote:
> On Thu, 30 Mar 2023 16:49:11 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > KVM presently allows userspace to filter guest hypercalls with bitmaps
> > expressed via pseudo-firmware registers. These bitmaps have a narrow
> > scope and, of course, can only allow/deny a particular call. A
> > subsequent change to KVM will introduce a generalized UAPI for filtering
> > hypercalls, allowing functions to be forwarded to userspace.
> > 
> > Refactor the existing hypercall filtering logic to make room for more
> > than two actions. While at it, generalize the function names around
> > SMCCC as it is the basis for the upcoming UAPI.
> > 
> > No functional change intended.
> > 
> > Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> > ---
> >  arch/arm64/include/uapi/asm/kvm.h |  9 +++++++++
> >  arch/arm64/kvm/hypercalls.c       | 19 +++++++++++++++----
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index f8129c624b07..bbab92402510 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -469,6 +469,15 @@ enum {
> >  /* run->fail_entry.hardware_entry_failure_reason codes. */
> >  #define KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED	(1ULL << 0)
> >  
> > +enum kvm_smccc_filter_action {
> > +	KVM_SMCCC_FILTER_ALLOW = 0,
> > +	KVM_SMCCC_FILTER_DENY,
> > +
> > +#ifdef __KERNEL__
> > +	NR_SMCCC_FILTER_ACTIONS
> > +#endif
> > +};
> > +
> 
> One thing I find myself wondering is what "ALLOW" mean here: Allow the
> handling of the hypercall? Or allow its forwarding? My guess is that
> this is the former, but I'd love a comment to clarify it, or even a
> clearer name ("HANDLE" instead of "ALLOW", for example, but YMMV...).

Yeah, I prefer calling it HANDLE as you suggest.

-- 
Thanks,
Oliver