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...).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
