Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp3229498rwi; Fri, 21 Oct 2022 13:25:56 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4xE3JSoUAeX5+D+OhxEHahA/VtUbh80jdu0CjLwrp+APVSv6UXqivhf1qpKHa7EBr9gzYA X-Received: by 2002:a17:90b:4b41:b0:20a:fe8f:5a3 with SMTP id mi1-20020a17090b4b4100b0020afe8f05a3mr59467028pjb.120.1666383946217; Fri, 21 Oct 2022 13:25:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666383946; cv=none; d=google.com; s=arc-20160816; b=tdAZA/VdUrCznXYMW3UYYZL9BlW9/KOnjwagId4h79HgP8nW9onUCVd6sA9AMJZNI4 zc4vIi5cy2douzwXGeElbYwo/sEmWVm19/rCrccm9L8jhuAKtTSyw5UVa4dn7MCBm6Ev 1tmoe0RuI7hzgMYXt27l4YMVsQxt77xab9ke5MOCBPt1R5MNMgRNaR0gdOL9RMFy/5op nSjcsIzsWtPBHimiwFOMrFFyG+/qB6jmemD1AT/f1/kafcYY8etD8wzPfnqaGVzH4hLw FxeuU+tDwqBHV5cvSwMujVifcGkx6s2Ke5JiNASFqSnEa2mSd9vgNBpd1NqKxKCABadx An7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=rDLMCIHmCMnK2ofhaIsP+Wyn94QPRqglBCuHU01guhA=; b=o4Wz54y4HZngH+kTM2U9gqEHXjWS7ysZZlcZqlhaxAIUwG1hgda+7C6MQVzRNab5Du XneaX7x+BWBq9sWIkec/lJ81nD/xesOMwzOtwmF3hqSqVJFCTwBs0J9Mf3u+2V7CYx6L U9X1D4G4dkbufI3PpzoFDqbYr0kL8jFh+u1im/XpuUwZ4EsbQslzb2F++noq8197LSf8 vS8GFgGReyBrUZ0xKJyFz7eTSz8yWxwQXz7cXoKbhM327Qd37YMiMEpdbkjDDveHIIOW ETdGT3nZwrz+KjUhkBo7bOQ8oiSEqVH9vZxHeWqiPAkIs/Bmsl3QyWuEAr53LykSlYat I3/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=oyARZFzA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 1-20020a631241000000b00434df5a8524si28037546pgs.396.2022.10.21.13.25.34; Fri, 21 Oct 2022 13:25:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=oyARZFzA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229889AbiJUUIp (ORCPT + 99 others); Fri, 21 Oct 2022 16:08:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229864AbiJUUIn (ORCPT ); Fri, 21 Oct 2022 16:08:43 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED3A72677AD for ; Fri, 21 Oct 2022 13:08:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 4913ACE2BA1 for ; Fri, 21 Oct 2022 20:08:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B79BC433C1; Fri, 21 Oct 2022 20:08:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666382918; bh=JvVuwGFgzjcQue281gO7KLG4H7q04b7BOWjJNOmrTUA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oyARZFzA3Rybv6jI7P9f+9HpWEf0RZJ0DACP+ZaQMq1CVLeiwU24NZVXLzIKoYa2r NFXpTq4n9sZGDkVpC3qrsj9MOSXfl/tPXQA/DZHI8ZTw2sWsVrwqakbg+/kAvXZuLn Hvev14eUbaecZGUxS0huWBMslcXIVMKkrWue+hBc1gkvPBjk29bmJ9TGR7Z1MhE0eM VqA6GCek1wJR3c5dsZAw9SYczD9rqAaeMhReSIJZrj5ypvUBVXXsTmVJ8oc9TPMMux GWFvazRrepCZWvKVcXDNRkvbJ8f4zAqraXGwYcJms2WdCdvrw4z4yRlL7Sa7ypOovC tWjNnkZjOkU4A== Date: Fri, 21 Oct 2022 13:08:36 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksandr Tyshchenko cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Oleksandr Tyshchenko , Stefano Stabellini , Juergen Gross , Xenia Ragiadakou Subject: Re: [PATCH V3] xen/virtio: Handle PCI devices which Host controller is described in DT In-Reply-To: <20221021172408.77397-1-olekstysh@gmail.com> Message-ID: References: <20221021172408.77397-1-olekstysh@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 21 Oct 2022, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Use the same "xen-grant-dma" device concept for the PCI devices > behind device-tree based PCI Host controller, but with one modification. > Unlike for platform devices, we cannot use generic IOMMU bindings > (iommus property), as we need to support more flexible configuration. > The problem is that PCI devices under the single PCI Host controller > may have the backends running in different Xen domains and thus have > different endpoints ID (backend domains ID). > > Add ability to deal with generic PCI-IOMMU bindings (iommu-map/ > iommu-map-mask properties) which allows us to describe relationship > between PCI devices and backend domains ID properly. > > To avoid having to look up for the PCI Host bridge twice and reduce > the amount of checks pass an extra struct device_node *np to both > xen_dt_grant_init_backend_domid() and xen_is_dt_grant_dma_device(). > While at it also pass domid_t *backend_domid instead of > struct xen_grant_dma_data *data to the former. > > So with current patch the code expects iommus property for the platform > devices and iommu-map/iommu-map-mask properties for PCI devices. > > The example of generated by the toolstack iommu-map property > for two PCI devices 0000:00:01.0 and 0000:00:02.0 whose > backends are running in different Xen domains with IDs 1 and 2 > respectively: > iommu-map = <0x08 0xfde9 0x01 0x08 0x10 0xfde9 0x02 0x08>; > > Signed-off-by: Oleksandr Tyshchenko > --- > Slightly RFC. This is needed to support Xen grant mappings for virtio-pci devices > on Arm at some point in the future. The Xen toolstack side is not completely ready yet. > Here, for PCI devices we use more flexible way to pass backend domid to the guest > than for platform devices. > > Changes V1 -> V2: > - update commit description > - rebase > - rework to use generic PCI-IOMMU bindings instead of generic IOMMU bindings > > Changes V2 -> V3: > - update commit description, add an example > - drop xen_dt_map_id() and squash xen_dt_get_pci_host_node() with > xen_dt_get_node() > - pass struct device_node *np to xen_is_dt_grant_dma_device() and > xen_dt_grant_init_backend_domid() > - pass domid_t *backend_domid instead of struct xen_grant_dma_data *data > to xen_dt_grant_init_backend_domid() > > Previous discussion is at: > https://lore.kernel.org/xen-devel/20221006174804.2003029-1-olekstysh@gmail.com/ > https://lore.kernel.org/xen-devel/20221015153409.918775-1-olekstysh@gmail.com/ > > Based on: > https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/log/?h=for-linus-6.1 > --- > drivers/xen/grant-dma-ops.c | 80 ++++++++++++++++++++++++++++++------- > 1 file changed, 66 insertions(+), 14 deletions(-) > > diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > index daa525df7bdc..76b29d20aeee 100644 > --- a/drivers/xen/grant-dma-ops.c > +++ b/drivers/xen/grant-dma-ops.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -292,12 +293,37 @@ static const struct dma_map_ops xen_grant_dma_ops = { > .dma_supported = xen_grant_dma_supported, > }; > > -static bool xen_is_dt_grant_dma_device(struct device *dev) > +static struct device_node *xen_dt_get_node(struct device *dev) > { > - struct device_node *iommu_np; > + if (dev_is_pci(dev)) { > + struct pci_dev *pdev = to_pci_dev(dev); > + struct pci_bus *bus = pdev->bus; > + > + /* Walk up to the root bus to look for PCI Host controller */ > + while (!pci_is_root_bus(bus)) > + bus = bus->parent; > + > + return of_node_get(bus->bridge->parent->of_node); > + } > + > + return of_node_get(dev->of_node); > +} > + > +static bool xen_is_dt_grant_dma_device(struct device *dev, > + struct device_node *np) > +{ > + struct device_node *iommu_np = NULL; > bool has_iommu; > > - iommu_np = of_parse_phandle(dev->of_node, "iommus", 0); > + if (dev_is_pci(dev)) { > + struct pci_dev *pdev = to_pci_dev(dev); > + u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > + > + if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_np, NULL)) > + return false; > + } else > + iommu_np = of_parse_phandle(np, "iommus", 0); > + > has_iommu = iommu_np && > of_device_is_compatible(iommu_np, "xen,grant-dma"); > of_node_put(iommu_np); I think we can remove xen_is_dt_grant_dma_device and just call xen_dt_grant_init_backend_domid passing a NULL backend_domid? It is a bit annoying that we are basically doing the same device tree parsing twice in a row given that the callers do: if (xen_is_grant_dma_device(dev)) xen_grant_setup_dma_ops(dev); Maybe we could move the backend_domid allocation and setting to xen_dt_grant_init_backend_domid, which would end up being done from the xen_is_grant_dma_device() call chain, and only leave setting dev->dma_ops from xen_grant_setup_dma_ops(). This way the parsing would be done only once? What do you think? This suggestion is optional, I am OK also with only removing xen_is_dt_grant_dma_device. > @@ -307,9 +333,17 @@ static bool xen_is_dt_grant_dma_device(struct device *dev) > > bool xen_is_grant_dma_device(struct device *dev) > { > + struct device_node *np; > + > /* XXX Handle only DT devices for now */ > - if (dev->of_node) > - return xen_is_dt_grant_dma_device(dev); > + np = xen_dt_get_node(dev); > + if (np) { > + bool ret; > + > + ret = xen_is_dt_grant_dma_device(dev, np); > + of_node_put(np); > + return ret; > + } > > return false; > } > @@ -323,14 +357,26 @@ bool xen_virtio_mem_acc(struct virtio_device *dev) > } > > static int xen_dt_grant_init_backend_domid(struct device *dev, > - struct xen_grant_dma_data *data) > + struct device_node *np, > + domid_t *backend_domid) > { > - struct of_phandle_args iommu_spec; > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > > - if (of_parse_phandle_with_args(dev->of_node, "iommus", "#iommu-cells", > - 0, &iommu_spec)) { > - dev_err(dev, "Cannot parse iommus property\n"); > - return -ESRCH; > + if (dev_is_pci(dev)) { > + struct pci_dev *pdev = to_pci_dev(dev); > + u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > + > + if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, > + iommu_spec.args)) { > + dev_err(dev, "Cannot translate ID\n"); > + return -ESRCH; > + } > + } else { > + if (of_parse_phandle_with_args(np, "iommus", "#iommu-cells", > + 0, &iommu_spec)) { > + dev_err(dev, "Cannot parse iommus property\n"); > + return -ESRCH; > + } > } > > if (!of_device_is_compatible(iommu_spec.np, "xen,grant-dma") || > @@ -346,7 +392,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > * The endpoint ID here means the ID of the domain where the > * corresponding backend is running > */ > - data->backend_domid = iommu_spec.args[0]; > + *backend_domid = iommu_spec.args[0]; > > return 0; > } > @@ -354,6 +400,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > void xen_grant_setup_dma_ops(struct device *dev) > { > struct xen_grant_dma_data *data; > + struct device_node *np; > > data = find_xen_grant_dma_data(dev); > if (data) { > @@ -365,8 +412,13 @@ void xen_grant_setup_dma_ops(struct device *dev) > if (!data) > goto err; > > - if (dev->of_node) { > - if (xen_dt_grant_init_backend_domid(dev, data)) > + np = xen_dt_get_node(dev); > + if (np) { > + int ret; > + > + ret = xen_dt_grant_init_backend_domid(dev, np, &data->backend_domid); > + of_node_put(np); > + if (ret) > goto err; > } else if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT)) { > dev_info(dev, "Using dom0 as backend\n"); > -- > 2.25.1 >