From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 09453C76196 for ; Fri, 31 Mar 2023 14:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:Subject:From: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TolbwR0lhXCrmah4wrI3+xmfgyb433FsTEmxTksux5E=; b=gomCMjZJdTHwoG 8oOXVuD3gLAtaixj56Hn/wfOeIO4FQ3CA6etDJCEx8X0LiqrxgPAJfAkSFgQFOxfug8nojcot/hvb Ny6ykc6QiOJ/K6/Y5O6wgxUWK0XEivL+c0+S6KDn0C/jQRQa38jlECRKonQS1PjGuSpUbICE28yUS txHtWuz6TqYnteAz0NY8cun4DpjUR3Dmk7r+mluBl0jTWCr5vYv3eSFt/EhlO350Pdd0t5suS17+i sZnABWmM5jj068Lcfykatbi3mL+5J0IRNB8YulPBKlfANH8vumol38VA1MOmK4MGa/zE0ENYu44in 19/y5yLXyD6lwvCFeyzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1piFsS-007kih-2H; Fri, 31 Mar 2023 14:37:16 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1piFjJ-007h7T-2f for linux-arm-kernel@lists.infradead.org; Fri, 31 Mar 2023 14:27:52 +0000 Received: by mail-il1-x132.google.com with SMTP id x6so11583155ile.3 for ; Fri, 31 Mar 2023 07:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680272869; x=1682864869; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=yd8a2rRt4CgsuNoaw1uAdWSFVR3asYYuQ3SN1GygOPM=; b=JsNYMn960aSPeOjPjz/EG2ICt2oP8vT4WEz+2/wEatQXwBBjniH11Ht3oxXIhpNirV ZRKxw0w/TxfkEvvhjRaoPWC63JyahCs6YFMLXpovKsgzrTP7jN2kORtiSzOQppqxKddV xtAsWGT3QdOm8DVq5gX/7zqeqqhVk6pCAqmOmhCXDIGyxI0e07q2ra+a+KlJdMkRD3Cm fgop6HfzMGGedbI8y/mBaY4pe1xX9PdampNdKZm08ymzE/d7w7YogSskKtV20Uhfaqrq 666vC9iTPeh3i5HP+dgdupI3ZnReqfhlyec9nPFQTN2tgbHizJHoEfKGuPS0K3O1G4Gi UH8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680272869; x=1682864869; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yd8a2rRt4CgsuNoaw1uAdWSFVR3asYYuQ3SN1GygOPM=; b=wgXp/0drU3BPdyr08hU/m1xg0AVGJdcruz9o301eVyuV0pDcCEiy6HoqS8/HymYDBq p/NiCR2nW1w6MfaOrU6TJ0U5UU7lwPRsIyaOrZ9glGv13hRBNBbC9VjX0P2AkKaLb6xJ drR3AjkKQUJ/p5wZCxPUTkdYcQ1kLZvmcwmAKHHyHl9Ug6ICpdgcBdd7dPviIRmDW8T7 /2A0HQXWdRgIyllQ8wx8WsGHQ39gTSwzLc0/yq4yDqhb785PdVK2eA259Q50D2uQclUC HBD+W4db0w9ntWqIpN8Ljm9R3mX32BjaE84r7FZfmSKyXkpU4rfDXAJh+fcELvuqJ22A 21Cg== X-Gm-Message-State: AAQBX9f0k2UOodM0d0emJXPDC7Eh45u1agOzcr8NanG755dLVX1XiqUK 6P5iODflKtjarx1ePAT4ApSRFA== X-Google-Smtp-Source: AKy350aZNorfWB4V2Ge2QcV6oV839CWjp+/XVjrj5bDLpfaK3tmG1dySfUq5FH5Bx1ItFP14N6t75A== X-Received: by 2002:a92:c812:0:b0:325:c8ed:6775 with SMTP id v18-20020a92c812000000b00325c8ed6775mr17319062iln.18.1680272868928; Fri, 31 Mar 2023 07:27:48 -0700 (PDT) Received: from [172.22.22.4] ([98.61.227.136]) by smtp.googlemail.com with ESMTPSA id x20-20020a927c14000000b003261bc23979sm649417ilc.57.2023.03.31.07.27.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 07:27:48 -0700 (PDT) Message-ID: <88a35ed3-78f9-c8ad-93b0-c7335e39a754@linaro.org> Date: Fri, 31 Mar 2023 09:27:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 From: Alex Elder Subject: Re: [PATCH v11 25/26] virt: gunyah: Add ioeventfd To: Elliot Berman , Srinivas Kandagatla , Prakruthi Deepak Heragu , Jonathan Corbet Cc: Murali Nalajala , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Dmitry Baryshkov , Bjorn Andersson , Konrad Dybcio , Arnd Bergmann , Greg Kroah-Hartman , Rob Herring , Krzysztof Kozlowski , Bagas Sanjaya , Will Deacon , Andy Gross , Catalin Marinas , Jassi Brar , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20230304010632.2127470-1-quic_eberman@quicinc.com> <20230304010632.2127470-26-quic_eberman@quicinc.com> Content-Language: en-US In-Reply-To: <20230304010632.2127470-26-quic_eberman@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230331_072750_017897_9622E131 X-CRM114-Status: GOOD ( 43.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > Signed-off-by: Prakruthi Deepak Heragu > Signed-off-by: Elliot Berman 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 > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel