[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <88a35ed3-78f9-c8ad-93b0-c7335e39a754@linaro.org>
Date: Fri, 31 Mar 2023 09:27:46 -0500
From: Alex Elder <elder@...aro.org>
To: Elliot Berman <quic_eberman@...cinc.com>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
Jonathan Corbet <corbet@....net>
Cc: Murali Nalajala <quic_mnalajal@...cinc.com>,
Trilok Soni <quic_tsoni@...cinc.com>,
Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
Carl van Schaik <quic_cvanscha@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Bagas Sanjaya <bagasdotme@...il.com>,
Will Deacon <will@...nel.org>, Andy Gross <agross@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Jassi Brar <jassisinghbrar@...il.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v11 25/26] virt: gunyah: Add ioeventfd
On 3/3/23 7:06 PM, Elliot Berman wrote:
> Allow userspace to attach an ioeventfd to an mmio address within the guest.
>
> Co-developed-by: Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>
> Signed-off-by: Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>
> Signed-off-by: Elliot Berman <quic_eberman@...cinc.com>
Mostly minor suggestions here. -Alex
> ---
> Documentation/virt/gunyah/vm-manager.rst | 2 +-
> drivers/virt/gunyah/Kconfig | 9 ++
> drivers/virt/gunyah/Makefile | 1 +
> drivers/virt/gunyah/gunyah_ioeventfd.c | 117 +++++++++++++++++++++++
> include/uapi/linux/gunyah.h | 37 +++++++
> 5 files changed, 165 insertions(+), 1 deletion(-)
> create mode 100644 drivers/virt/gunyah/gunyah_ioeventfd.c
>
> diff --git a/Documentation/virt/gunyah/vm-manager.rst b/Documentation/virt/gunyah/vm-manager.rst
> index a1dd70f0cbf6..cd41a705849f 100644
> --- a/Documentation/virt/gunyah/vm-manager.rst
> +++ b/Documentation/virt/gunyah/vm-manager.rst
> @@ -124,7 +124,7 @@ the VM starts.
> The possible types are documented below:
>
> .. kernel-doc:: include/uapi/linux/gunyah.h
> - :identifiers: GH_FN_VCPU gh_fn_vcpu_arg GH_FN_IRQFD gh_fn_irqfd_arg
> + :identifiers: GH_FN_VCPU gh_fn_vcpu_arg GH_FN_IRQFD gh_fn_irqfd_arg GH_FN_IOEVENTFD gh_fn_ioeventfd_arg
>
> Gunyah VCPU API Descriptions
> ----------------------------
> diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig
> index 2cde24d429d1..bd8e31184962 100644
> --- a/drivers/virt/gunyah/Kconfig
> +++ b/drivers/virt/gunyah/Kconfig
> @@ -35,3 +35,12 @@ config GUNYAH_IRQFD
> on Gunyah virtual machine.
>
> Say Y/M here if unsure and you want to support Gunyah VMMs.
> +
> +config GUNYAH_IOEVENTFD
> + tristate "Gunyah ioeventfd interface"
> + depends on GUNYAH
> + help
> + Enable kernel support for creating ioeventfds which can alert userspace
> + when a Gunyah virtual machine accesses a memory address.
> +
> + Say Y/M here if unsure and you want to support Gunyah VMMs.
> diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile
> index 6cf756bfa3c2..7347b1470491 100644
> --- a/drivers/virt/gunyah/Makefile
> +++ b/drivers/virt/gunyah/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_GUNYAH) += gunyah_rsc_mgr.o
>
> obj-$(CONFIG_GUNYAH_VCPU) += gunyah_vcpu.o
> obj-$(CONFIG_GUNYAH_IRQFD) += gunyah_irqfd.o
> +obj-$(CONFIG_GUNYAH_IOEVENTFD) += gunyah_ioeventfd.o
> diff --git a/drivers/virt/gunyah/gunyah_ioeventfd.c b/drivers/virt/gunyah/gunyah_ioeventfd.c
> new file mode 100644
> index 000000000000..517f55706ed9
> --- /dev/null
> +++ b/drivers/virt/gunyah/gunyah_ioeventfd.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/eventfd.h>
> +#include <linux/file.h>
> +#include <linux/fs.h>
> +#include <linux/gunyah.h>
> +#include <linux/gunyah_vm_mgr.h>
> +#include <linux/module.h>
> +#include <linux/printk.h>
> +
> +#include <uapi/linux/gunyah.h>
> +
> +struct gh_ioeventfd {
> + struct gh_vm_function_instance *f;
> + struct gh_vm_io_handler io_handler;
> +
> + struct eventfd_ctx *ctx;
> +};
> +
> +static int gh_write_ioeventfd(struct gh_vm_io_handler *io_dev, u64 addr, u32 len, u64 data)
> +{
> + struct gh_ioeventfd *iofd = container_of(io_dev, struct gh_ioeventfd, io_handler);
> +
I think it's interesting that this signals an event even if
len is zero. I'm not saying it's wrong, just interesting...
> + eventfd_signal(iofd->ctx, 1);
> + return 0;
> +}
> +
> +static struct gh_vm_io_handler_ops io_ops = {
> + .write = gh_write_ioeventfd,
> +};
> +
> +static long gh_ioeventfd_bind(struct gh_vm_function_instance *f)
> +{
> + const struct gh_fn_ioeventfd_arg *args = f->argp;
> + struct eventfd_ctx *ctx = NULL;
No need to initialize ctx.
> + struct gh_ioeventfd *iofd;
> + int ret;
> +
> + if (f->arg_size != sizeof(*args))
> + return -EINVAL;
> +
> + /* must be natural-word sized, or 0 to ignore length */
> + switch (args->len) {
> + case 0:
> + case 1:
> + case 2:
> + case 4:
> + case 8:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /* check for range overflow */
> + if (args->addr + args->len < args->addr)
I think you could use:
if (overflows_type(args->addr + args->len, args->addr))
This is a relatively recent addition (and I haven't been using it
myself yet) but it's meant for this purpose. Consider using it
and its relatives here and anywhere else you're making this kind
of check.
> + return -EINVAL;
> +
> + /* ioeventfd with no length can't be combined with DATAMATCH */
> + if (!args->len && (args->flags & GH_IOEVENTFD_DATAMATCH))
> + return -EINVAL;
> +
Maybe check for invalid flags before before ensuring
valid flags are used properly?
> + /* All other flag bits are reserved for future use */
> + if (args->flags & ~GH_IOEVENTFD_DATAMATCH)
> + return -EINVAL;
> +
> + ctx = eventfd_ctx_fdget(args->fd);
> + if (IS_ERR(ctx))
> + return PTR_ERR(ctx);
> +
> + iofd = kzalloc(sizeof(*iofd), GFP_KERNEL);
> + if (!iofd) {
> + ret = -ENOMEM;
> + goto err_eventfd;
> + }
> +
> + f->data = iofd;
> + iofd->f = f;
> +
> + iofd->ctx = ctx;
> +
> + if (args->flags & GH_IOEVENTFD_DATAMATCH) {
> + iofd->io_handler.datamatch = true;
> + iofd->io_handler.len = args->len;
> + iofd->io_handler.data = args->datamatch;
I think you might want to rename one or the other of these
fields (datamatch or data). I might be wrong; I'll explain
elsewhere what I mean.
> + }
> + iofd->io_handler.addr = args->addr;
> + iofd->io_handler.ops = &io_ops;
> +
> + ret = gh_vm_add_io_handler(f->ghvm, &iofd->io_handler);
> + if (ret)
> + goto err_io_dev_add;
> +
> + return 0;
> +
> +err_io_dev_add:
> + kfree(iofd);
> +err_eventfd:
> + eventfd_ctx_put(ctx);
> + return ret;
> +}
> +
> +static void gh_ioevent_unbind(struct gh_vm_function_instance *f)
> +{
> + struct gh_ioeventfd *iofd = f->data;
> +
> + eventfd_ctx_put(iofd->ctx);
It's not a big deal but I prefer to "undo" everything in the
reverse order that they are originally "done". I.e., put the
eventfd context after removing the I/O handler.
> + gh_vm_remove_io_handler(iofd->f->ghvm, &iofd->io_handler);
> + kfree(iofd);
> +}
> +
> +DECLARE_GH_VM_FUNCTION_INIT(ioeventfd, GH_FN_IOEVENTFD,
> + gh_ioeventfd_bind, gh_ioevent_unbind);
> +MODULE_DESCRIPTION("Gunyah ioeventfds");
s/ioeventfds/ioeventfd/
I understand why you might want it to be plural, but I think it's
better to just name the abstraction. (If you take this suggestion,
check elsewhere and be consistent.)
AND/OR... You might also somehow incorporate the fact that this is a
VM *function* that is represented: "Gunyah ioeventfd VM function(s)"
> +MODULE_LICENSE("GPL");
> diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
> index 5617dadc1c7b..f8482ff4cc55 100644
> --- a/include/uapi/linux/gunyah.h
> +++ b/include/uapi/linux/gunyah.h
> @@ -89,6 +89,23 @@ struct gh_vm_dtb_config {
> */
> #define GH_FN_IRQFD 2
>
> +/**
> + * GH_FN_IOEVENTFD - register ioeventfd to trigger when VM faults on parameter
What does "faults on parameter" mean?
> + *
> + * gh_fn_desc is filled with gh_fn_ioeventfd_arg
> + *
> + * Attaches an ioeventfd to a legal mmio address within the guest. A guest write
> + * in the registered address will signal the provided event instead of triggering
> + * an exit on the GH_VCPU_RUN ioctl.
> + *
> + * If GH_IOEVENTFD_DATAMATCH flag is set, the event will be signaled only if the
> + * written value to the registered address is equal to datamatch in
> + * struct gh_fn_ioeventfd_arg.
> + *
> + * Return: 0
> + */
> +#define GH_FN_IOEVENTFD 3
If you added another tab before 3, it will align more nicely with the
next definition. (If you do that, add a tab in the other function
definitions as well.)
> +
> #define GH_FN_MAX_ARG_SIZE 256
>
> /**
> @@ -118,6 +135,26 @@ struct gh_fn_irqfd_arg {
>
> #define GH_IOEVENTFD_DATAMATCH (1UL << 0)
>
> +/**
> + * struct gh_fn_ioeventfd_arg - Arguments to create an ioeventfd function
> + * @datamatch: data used when GH_IOEVENTFD_DATAMATCH is set
> + * @addr: Address in guest memory
> + * @len: Length of access
> + * @fd: When ioeventfd is matched, this eventfd is written
> + * @flags: If GH_IOEVENTFD_DATAMATCH flag is set, the event will be signaled
> + * only if the written value to the registered address is equal to
> + * @datamatch
> + * @padding: padding bytes
> + */
> +struct gh_fn_ioeventfd_arg {
> + __u64 datamatch;
> + __u64 addr; /* legal mmio address */
> + __u32 len; /* 1, 2, 4, or 8 bytes; or 0 to ignore length */
> + __s32 fd;
> + __u32 flags;
> + __u32 padding;
> +};
> +
> /**
> * struct gh_fn_desc - Arguments to create a VM function
> * @type: Type of the function. See GH_FN_* macro for supported types
Powered by blists - more mailing lists