Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp9236848rwi; Tue, 25 Oct 2022 17:18:16 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4+7VpFTmvK70LBSy7cIC8vHZT7xDuiq83cXwE9V7sVHp/Yb1J0AWdUyPzqxSt6u9W2Ywpu X-Received: by 2002:a17:902:d506:b0:184:987e:3cf2 with SMTP id b6-20020a170902d50600b00184987e3cf2mr40633905plg.67.1666743496643; Tue, 25 Oct 2022 17:18:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666743496; cv=none; d=google.com; s=arc-20160816; b=FipDK17HYB1BldaszkQuSkemoxuswziB01Fvk2kum88fRT9c0pkf7W7Lyz/2FP3Deq Exrr3JOHrhcxmHb7RoPhvBlpdUrenYP1EYP0oqJOXWxj5PRqL99rPvxzg7erRPW4Td5z C/LcJ7rxwzKRs+1BfbwTFqCQg1gKedb5a9rcP/KXDTM9ZCBCYup+hcR+og2vxJ9YFumV 89wUvLn+CvIqyGNeBB2NPIJuVaW3jWk/ywqGRfzrGOXBS0IyGN3YeulPtCar6sujyr1i vggroQ4o/agYVBr3AFCl4+EMHmslfqJLBqvbbzsbduhuRnUHgMWR8cg2KqkueZ6WfYbT A9vQ== 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=QwiZNzf6Ql157t/aXNYIms8HcVXjLKaxwcl2q/6K1/Y=; b=ZlPgRdho7bq29QhgBFkuLw4S80vmf4PluhqvWwazfNE7Fme29CpjAX1mSnzj4kw1SM F3P0u4JaOiXBE4K2vK0/Fq0LyAncNt1Ybpq4aPAwvk+v8oPHb1Qq2qTOvV0TJ2SS9Xqr ueLTVkb2EAaxL2LV6nirNWBDemwJWTJpvw2bHdQxmHm5VNhbvveBU2RrkN2GTaCo2lQV bnObmGvmPaOMmku8LQs3efv9PPAUsgZsSdwb8QIDwalLcHBOxB3X5eGWCVwGMs0WTU6i nHgw+RPBlH7k52MMa0newgZpHb5F3EVudfwKUO9Xhi+54NP2Jh+dR0rNMWPpMoiK0386 XiTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tKirTCrk; 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 oj17-20020a17090b4d9100b00212fd5f1ad5si582541pjb.160.2022.10.25.17.18.04; Tue, 25 Oct 2022 17:18:16 -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=tKirTCrk; 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 S231861AbiJYXOZ (ORCPT + 99 others); Tue, 25 Oct 2022 19:14:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229952AbiJYXOY (ORCPT ); Tue, 25 Oct 2022 19:14:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 605D7D0CDA for ; Tue, 25 Oct 2022 16:14:23 -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 ams.source.kernel.org (Postfix) with ESMTPS id 20898B81D7A for ; Tue, 25 Oct 2022 23:14:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEA0FC433C1; Tue, 25 Oct 2022 23:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666739660; bh=MzpMrjWsH19E0r9kWq1TaDGhbd1xbuNvnFOB0rRZuG0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tKirTCrkpCCd3YLx/m4i2cluGCr9cIfpNNUIUtlNsJ/DZNQjfoX454lPX3VSqBQ2p zhdBBTCDI3Q/KNfgVzdKOcXyveQC0zAfn/yHE9NAStjzn9I32Wnc7r0HrWZTZU/gw9 s5NM24A32ZlFXUF1n5wbPgtTkHWYNV6saz+VHXhHEFIslvwIYGzQf3YRQlZSRkexc0 cnRFvzSqm/RaywfgWrwzuIJRuW1gPPW814LYsY4hj3Q/c3gTrLm2S5zQLuvH/NbnAM acQ4G7Bu7ri3Vmx+Ka4TA9M/7IWQC7ZfyjOy4yqCejJjrl1zGDyVIY+UmbSTOvjB3c obBl5/YTcTp6A== Date: Tue, 25 Oct 2022 16:14:18 -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 V4 2/2] xen/virtio: Handle PCI devices which Host controller is described in DT In-Reply-To: <20221025162004.8501-3-olekstysh@gmail.com> Message-ID: References: <20221025162004.8501-1-olekstysh@gmail.com> <20221025162004.8501-3-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.6 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 Tue, 25 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 > xen_dt_grant_init_backend_domid(). > > 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 Reviewed-by: Stefano Stabellini > --- > 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() > > Changes V3 -> V4: > - just rebase on new prereq patch > "xen/virtio: Optimize the setup of "xen-grant-dma" devices" > > 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/ > https://lore.kernel.org/xen-devel/20221021172408.77397-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 | 46 +++++++++++++++++++++++++++++++------ > 1 file changed, 39 insertions(+), 7 deletions(-) > > diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > index 1e797a043980..9784a77fa3c9 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,15 +293,43 @@ static const struct dma_map_ops xen_grant_dma_ops = { > .dma_supported = xen_grant_dma_supported, > }; > > +static struct device_node *xen_dt_get_node(struct device *dev) > +{ > + 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 int xen_dt_grant_init_backend_domid(struct device *dev, > + 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_dbg(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_dbg(dev, "Cannot translate ID\n"); > + return -ESRCH; > + } > + } else { > + if (of_parse_phandle_with_args(np, "iommus", "#iommu-cells", > + 0, &iommu_spec)) { > + dev_dbg(dev, "Cannot parse iommus property\n"); > + return -ESRCH; > + } > } > > if (!of_device_is_compatible(iommu_spec.np, "xen,grant-dma") || > @@ -324,10 +353,13 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > static int xen_grant_init_backend_domid(struct device *dev, > domid_t *backend_domid) > { > + struct device_node *np; > int ret = -ENODEV; > > - if (dev->of_node) { > - ret = xen_dt_grant_init_backend_domid(dev, backend_domid); > + np = xen_dt_get_node(dev); > + if (np) { > + ret = xen_dt_grant_init_backend_domid(dev, np, backend_domid); > + of_node_put(np); > } else if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT) || xen_pv_domain()) { > dev_info(dev, "Using dom0 as backend\n"); > *backend_domid = 0; > -- > 2.25.1 >