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@xxxxxxxxx> 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@xxxxxxx>
> > Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx>
> > ---
> > 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
