From: Gerald Schaefer <gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
Frank Blaschka
<blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH linux-next] iommu: add iommu for s390 platform
Date: Mon, 27 Oct 2014 18:02:19 +0100 [thread overview]
Message-ID: <20141027180219.62b1ac4a@thinkpad> (raw)
In-Reply-To: <20141027162502.GB6202-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On Mon, 27 Oct 2014 17:25:02 +0100
Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Oct 27, 2014 at 03:32:01PM +0100, Gerald Schaefer wrote:
> > Not sure if I understood the concept of IOMMU domains right. But if
> > this is about having multiple devices in the same domain, so that
> > iommu_ops->map will establish the _same_ DMA mapping on _all_
> > registered devices, then this should be possible.
>
> Yes, this is what domains are about. A domain describes a set of DMA
> mappings which can be assigned to multiple devices in parallel.
>
> > We cannot have shared DMA tables because each device gets its own
> > DMA table allocated during device initialization.
>
> Is there some hardware reason for this or is that just an
> implementation detail that can be changed. In other words, does the
> hardware allow to use the same DMA table for multiple devices?
Yes, the HW would allow shared DMA tables, but the implementation would
need some non-trivial changes. For example, we have a per-device spin_lock
for DMA table manipulations and the code in arch/s390/pci/pci_dma.c knows
nothing about IOMMU domains or shared DMA tables, it just implements a set
of dma_map_ops.
Of course this would also go horribly wrong if a device was already
in use (via the current dma_map_ops), but I guess using devices through
the IOMMU_API prevents using them otherwise?
>
> > But we could just keep all devices from one domain in a list and
> > then call dma_update_trans() for all devices during
> > iommu_ops->map/unmap.
>
> This sounds complicated. Note that a device can be assigned to a
> domain that already has existing mappings. In this case you need to
> make sure that the new device inherits these mappings (and destroy
> all old mappings for the device that possibly exist).
>
> I think it is much easier to use the same DMA table for all devices
> in a domain, if the hardware allows that.
Yes, in this case, having one DMA table per domain and sharing it
between all devices in that domain sounds like a good idea. However,
I can't think of any use case for this, and Frank probably had a very
special use case in mind where this scenario doesn't appear, hence the
"one device per domain" restriction.
So, if having multiple devices per domain is a must, then we probably
need a thorough rewrite of the arch/s390/pci/pci_dma.c code.
Gerald
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com>,
schwidefsky@de.ibm.com, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, iommu@lists.linux-foundation.org,
sebott@linux.vnet.ibm.com
Subject: Re: [PATCH linux-next] iommu: add iommu for s390 platform
Date: Mon, 27 Oct 2014 18:02:19 +0100 [thread overview]
Message-ID: <20141027180219.62b1ac4a@thinkpad> (raw)
In-Reply-To: <20141027162502.GB6202@8bytes.org>
On Mon, 27 Oct 2014 17:25:02 +0100
Joerg Roedel <joro@8bytes.org> wrote:
> On Mon, Oct 27, 2014 at 03:32:01PM +0100, Gerald Schaefer wrote:
> > Not sure if I understood the concept of IOMMU domains right. But if
> > this is about having multiple devices in the same domain, so that
> > iommu_ops->map will establish the _same_ DMA mapping on _all_
> > registered devices, then this should be possible.
>
> Yes, this is what domains are about. A domain describes a set of DMA
> mappings which can be assigned to multiple devices in parallel.
>
> > We cannot have shared DMA tables because each device gets its own
> > DMA table allocated during device initialization.
>
> Is there some hardware reason for this or is that just an
> implementation detail that can be changed. In other words, does the
> hardware allow to use the same DMA table for multiple devices?
Yes, the HW would allow shared DMA tables, but the implementation would
need some non-trivial changes. For example, we have a per-device spin_lock
for DMA table manipulations and the code in arch/s390/pci/pci_dma.c knows
nothing about IOMMU domains or shared DMA tables, it just implements a set
of dma_map_ops.
Of course this would also go horribly wrong if a device was already
in use (via the current dma_map_ops), but I guess using devices through
the IOMMU_API prevents using them otherwise?
>
> > But we could just keep all devices from one domain in a list and
> > then call dma_update_trans() for all devices during
> > iommu_ops->map/unmap.
>
> This sounds complicated. Note that a device can be assigned to a
> domain that already has existing mappings. In this case you need to
> make sure that the new device inherits these mappings (and destroy
> all old mappings for the device that possibly exist).
>
> I think it is much easier to use the same DMA table for all devices
> in a domain, if the hardware allows that.
Yes, in this case, having one DMA table per domain and sharing it
between all devices in that domain sounds like a good idea. However,
I can't think of any use case for this, and Frank probably had a very
special use case in mind where this scenario doesn't appear, hence the
"one device per domain" restriction.
So, if having multiple devices per domain is a must, then we probably
need a thorough rewrite of the arch/s390/pci/pci_dma.c code.
Gerald
next prev parent reply other threads:[~2014-10-27 17:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 11:57 [PATCH linux-next] iommu: add iommu for s390 platform Frank Blaschka
[not found] ` <1413892645-37657-1-git-send-email-blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-10-22 14:17 ` Joerg Roedel
2014-10-22 14:17 ` Joerg Roedel
2014-10-22 15:43 ` Frank Blaschka
[not found] ` <20141022154320.GA42442-++28Fms/gMmXI4yAdoq52KN5r0PSdgG1zG2AekJRRhI@public.gmane.org>
2014-10-23 12:41 ` Joerg Roedel
2014-10-23 12:41 ` Joerg Roedel
[not found] ` <20141023124115.GB10053-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-10-23 14:04 ` Frank Blaschka
2014-10-23 14:04 ` Frank Blaschka
[not found] ` <20141023140437.GA31009-++28Fms/gMmXI4yAdoq52KN5r0PSdgG1zG2AekJRRhI@public.gmane.org>
2014-10-24 23:33 ` Joerg Roedel
2014-10-24 23:33 ` Joerg Roedel
2014-10-27 14:32 ` Gerald Schaefer
2014-10-27 16:25 ` Joerg Roedel
2014-10-27 16:25 ` Joerg Roedel
[not found] ` <20141027162502.GB6202-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-10-27 17:02 ` Gerald Schaefer [this message]
2014-10-27 17:02 ` Gerald Schaefer
2014-10-27 17:58 ` Joerg Roedel
2014-10-27 17:58 ` Joerg Roedel
[not found] ` <20141027175835.GC6202-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-10-27 18:18 ` Gerald Schaefer
2014-10-27 18:18 ` Gerald Schaefer
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=20141027180219.62b1ac4a@thinkpad \
--to=gerald.schaefer-ta70fqpds9bqt0dzr+alfa@public.gmane.org \
--cc=blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=sebott-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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.