All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	tnowicki-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org,
	peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	Jean-Philippe Brucker
	<jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	robin.murphy-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,
	jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org
Subject: Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu
Date: Mon, 15 Oct 2018 06:52:10 -0400	[thread overview]
Message-ID: <20181015065024-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181012194158.GX5906-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>

On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
> 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?


Thinking about this comment, I would like to ask: can't the
virtio device indicate the ranges in a portable way?
This would minimize the dependency on dt bindings and ACPI,
enabling support for systems that have neither but do
have virtio e.g. through pci.

>  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: "Michael S. Tsirkin" <mst@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	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, 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: Mon, 15 Oct 2018 06:52:10 -0400	[thread overview]
Message-ID: <20181015065024-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181012194158.GX5906@bhelgaas-glaptop.roam.corp.google.com>

On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
> 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?


Thinking about this comment, I would like to ask: can't the
virtio device indicate the ranges in a portable way?
This would minimize the dependency on dt bindings and ACPI,
enabling support for systems that have neither but do
have virtio e.g. through pci.

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

  parent reply	other threads:[~2018-10-15 10:52 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
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 [this message]
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=20181015065024-mutt-send-email-mst@kernel.org \
    --to=mst-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=helgaas-DgEjT+Ai2ygdnm+yROfE0A@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=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: link
Be 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.