From: Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, tnowicki-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, marc.zyngier-5wv7dgnIgG8@public.gmane.org, robin.murphy-5wv7dgnIgG8@public.gmane.org, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org Subject: Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu Date: Fri, 12 Oct 2018 14:41:59 -0500 [thread overview] Message-ID: <20181012194158.GX5906@bhelgaas-glaptop.roam.corp.google.com> (raw) In-Reply-To: <20181012145917.6840-4-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> s/iommu/IOMMU/ in subject On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote: > Using the iommu-map binding, endpoints in a given PCI domain can be > managed by different IOMMUs. Some virtual machines may allow a subset of > endpoints to bypass the IOMMU. In some case the IOMMU itself is presented s/case/cases/ > as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). Currently, when a > PCI root complex has an iommu-map property, the driver requires all > endpoints to be described by the property. Allow the iommu-map property to > have gaps. I'm not an IOMMU or virtio expert, so it's not obvious to me why it is safe to allow devices to bypass the IOMMU. Does this mean a typo in iommu-map could inadvertently allow devices to bypass it? Should we indicate something in dmesg (and/or sysfs) about devices that bypass it? > Relaxing of_pci_map_rid also allows the msi-map property to have gaps, s/of_pci_map_rid/of_pci_map_rid()/ > which is invalid since MSIs always reach an MSI controller. Thankfully > Linux will error out later, when attempting to find an MSI domain for the > device. Not clear to me what "error out" means here. In a userspace program, I would infer that the program exits with an error message, but I doubt you mean that Linux exits. > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> > --- > drivers/pci/of.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index 1836b8ddf292..2f5015bdb256 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -451,9 +451,10 @@ int of_pci_map_rid(struct device_node *np, u32 rid, > return 0; > } > > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > - np, map_name, rid, target && *target ? *target : NULL); > - return -EFAULT; > + /* Bypasses translation */ > + if (id_out) > + *id_out = rid; > + return 0; > } > > #if IS_ENABLED(CONFIG_OF_IRQ) > -- > 2.19.1 >
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org> To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Cc: iommu@lists.linux-foundation.org, virtualization@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, kvmarm@lists.cs.columbia.edu, peter.maydell@linaro.org, joro@8bytes.org, mst@redhat.com, jasowang@redhat.com, robh+dt@kernel.org, mark.rutland@arm.com, eric.auger@redhat.com, tnowicki@caviumnetworks.com, kevin.tian@intel.com, marc.zyngier@arm.com, robin.murphy@arm.com, will.deacon@arm.com, lorenzo.pieralisi@arm.com Subject: Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu Date: Fri, 12 Oct 2018 14:41:59 -0500 [thread overview] Message-ID: <20181012194158.GX5906@bhelgaas-glaptop.roam.corp.google.com> (raw) In-Reply-To: <20181012145917.6840-4-jean-philippe.brucker@arm.com> s/iommu/IOMMU/ in subject On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote: > Using the iommu-map binding, endpoints in a given PCI domain can be > managed by different IOMMUs. Some virtual machines may allow a subset of > endpoints to bypass the IOMMU. In some case the IOMMU itself is presented s/case/cases/ > as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). Currently, when a > PCI root complex has an iommu-map property, the driver requires all > endpoints to be described by the property. Allow the iommu-map property to > have gaps. I'm not an IOMMU or virtio expert, so it's not obvious to me why it is safe to allow devices to bypass the IOMMU. Does this mean a typo in iommu-map could inadvertently allow devices to bypass it? Should we indicate something in dmesg (and/or sysfs) about devices that bypass it? > Relaxing of_pci_map_rid also allows the msi-map property to have gaps, s/of_pci_map_rid/of_pci_map_rid()/ > which is invalid since MSIs always reach an MSI controller. Thankfully > Linux will error out later, when attempting to find an MSI domain for the > device. Not clear to me what "error out" means here. In a userspace program, I would infer that the program exits with an error message, but I doubt you mean that Linux exits. > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > --- > drivers/pci/of.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index 1836b8ddf292..2f5015bdb256 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -451,9 +451,10 @@ int of_pci_map_rid(struct device_node *np, u32 rid, > return 0; > } > > - pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n", > - np, map_name, rid, target && *target ? *target : NULL); > - return -EFAULT; > + /* Bypasses translation */ > + if (id_out) > + *id_out = rid; > + return 0; > } > > #if IS_ENABLED(CONFIG_OF_IRQ) > -- > 2.19.1 >
next prev parent reply other threads:[~2018-10-12 19:41 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-12 14:59 [PATCH v3 0/7] Add virtio-iommu driver Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` [PATCH v3 1/7] dt-bindings: virtio-mmio: Add IOMMU description Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-18 0:30 ` Rob Herring [not found] ` <20181012145917.6840-2-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> 2018-10-18 0:30 ` Rob Herring 2018-10-18 0:30 ` Rob Herring 2018-11-15 8:45 ` Auger Eric 2018-11-15 8:45 ` Auger Eric 2018-10-12 14:59 ` [PATCH v3 2/7] dt-bindings: virtio: Add virtio-pci-iommu node Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-18 0:35 ` Rob Herring 2018-10-18 0:35 ` Rob Herring 2018-10-18 0:35 ` Rob Herring 2018-11-15 8:45 ` Auger Eric 2018-11-15 8:45 ` Auger Eric 2018-11-15 8:45 ` Auger Eric 2018-10-12 14:59 ` [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker [not found] ` <20181012145917.6840-4-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> 2018-10-12 19:41 ` Bjorn Helgaas [this message] 2018-10-12 19:41 ` Bjorn Helgaas 2018-10-15 10:52 ` Michael S. Tsirkin 2018-10-15 11:32 ` Robin Murphy [not found] ` <20181012194158.GX5906-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org> 2018-10-15 10:52 ` Michael S. Tsirkin 2018-10-15 10:52 ` Michael S. Tsirkin [not found] ` <20181015065024-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2018-10-15 19:46 ` Jean-philippe Brucker 2018-10-15 19:46 ` Jean-philippe Brucker 2018-10-17 15:14 ` Michael S. Tsirkin 2018-10-17 15:14 ` Michael S. Tsirkin 2018-10-18 10:47 ` Robin Murphy 2018-10-18 10:47 ` Robin Murphy 2018-10-18 10:47 ` Robin Murphy [not found] ` <20181017111100-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2018-10-22 11:27 ` Jean-Philippe Brucker 2018-10-22 11:27 ` Jean-Philippe Brucker 2018-10-22 11:27 ` Jean-Philippe Brucker 2018-10-15 11:32 ` Robin Murphy 2018-10-15 11:32 ` Robin Murphy 2018-10-15 19:45 ` Jean-philippe Brucker 2018-10-15 19:45 ` Jean-philippe Brucker 2018-10-12 14:59 ` [PATCH v3 4/7] PCI: OF: Initialize dev->fwnode appropriately Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker [not found] ` <20181012145917.6840-5-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> 2018-10-12 19:44 ` Bjorn Helgaas 2018-10-12 19:44 ` Bjorn Helgaas 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` [PATCH v3 5/7] iommu: Add virtio-iommu driver Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 16:35 ` Michael S. Tsirkin 2018-10-12 16:35 ` Michael S. Tsirkin 2018-10-12 16:35 ` Michael S. Tsirkin [not found] ` <20181012120953-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2018-10-12 18:54 ` Jean-Philippe Brucker 2018-10-12 18:54 ` Jean-Philippe Brucker 2018-10-12 18:54 ` Jean-Philippe Brucker 2018-11-08 14:51 ` Auger Eric 2018-11-08 14:51 ` Auger Eric 2018-11-08 16:46 ` Jean-Philippe Brucker 2018-11-08 16:46 ` Jean-Philippe Brucker 2018-11-08 16:46 ` Jean-Philippe Brucker 2018-11-08 14:51 ` Auger Eric 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` [PATCH v3 6/7] iommu/virtio: Add probe request Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 16:42 ` Michael S. Tsirkin 2018-10-12 16:42 ` Michael S. Tsirkin 2018-11-08 14:48 ` Auger Eric [not found] ` <20181012145917.6840-7-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> 2018-11-08 14:48 ` Auger Eric 2018-11-08 14:48 ` Auger Eric [not found] ` <295d30bb-5aef-2727-01c0-ec10c7a8fa8c-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2018-11-08 16:46 ` Jean-Philippe Brucker 2018-11-08 16:46 ` Jean-Philippe Brucker 2018-11-08 16:46 ` Jean-Philippe Brucker 2018-11-15 13:20 ` Auger Eric 2018-11-15 13:20 ` Auger Eric 2018-11-15 16:22 ` Jean-Philippe Brucker 2018-11-15 16:22 ` Jean-Philippe Brucker 2018-11-15 16:22 ` Jean-Philippe Brucker 2018-11-15 13:20 ` Auger Eric 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` [PATCH v3 7/7] iommu/virtio: Add event queue Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 14:59 ` Jean-Philippe Brucker 2018-10-12 17:00 ` [PATCH v3 0/7] Add virtio-iommu driver Michael S. Tsirkin [not found] ` <20181012145917.6840-1-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> 2018-10-12 17:00 ` Michael S. Tsirkin 2018-10-12 17:00 ` Michael S. Tsirkin 2018-10-12 18:55 ` Jean-Philippe Brucker [not found] ` <20181012125443-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2018-10-12 18:55 ` Jean-Philippe Brucker 2018-10-12 18:55 ` Jean-Philippe Brucker 2018-10-16 9:25 ` Auger Eric 2018-10-16 9:25 ` Auger Eric 2018-10-16 18:44 ` Jean-Philippe Brucker 2018-10-16 18:44 ` Jean-Philippe Brucker 2018-10-16 20:31 ` Auger Eric 2018-10-16 20:31 ` Auger Eric 2018-10-17 11:54 ` Jean-Philippe Brucker 2018-10-17 11:54 ` Jean-Philippe Brucker 2018-10-17 15:23 ` Michael S. Tsirkin 2018-10-17 15:23 ` Michael S. Tsirkin 2018-10-17 15:23 ` Michael S. Tsirkin 2018-10-16 18:44 ` Jean-Philippe Brucker 2018-10-16 9:25 ` Auger Eric
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181012194158.GX5906@bhelgaas-glaptop.roam.corp.google.com \ --to=helgaas-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org \ --cc=kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \ --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \ --cc=tnowicki-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \ --cc=virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.