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 <redacted>
Signed-off-by: Prakruthi Deepak Heragu <redacted>
Signed-off-by: Elliot Berman <redacted>

Mostly minor suggestions here.	-Alex

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)"

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.)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel