From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Gerald Schaefer
<gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@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:58:35 +0100 [thread overview]
Message-ID: <20141027175835.GC6202@8bytes.org> (raw)
In-Reply-To: <20141027180219.62b1ac4a@thinkpad>
On Mon, Oct 27, 2014 at 06:02:19PM +0100, Gerald Schaefer wrote:
> On Mon, 27 Oct 2014 17:25:02 +0100
> Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
> > 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.
I think it would make sense to move the DMA table handling code and the
dma_map_ops implementation to the IOMMU driver too. This is also how
some other IOMMU drivers implement it.
The plan is to consolidate the dma_ops implementations someday and have
a common implementation that works with all IOMMU drivers across
architectures. This would benefit s390 as well and obsoletes the driver
specific dma_ops implementation.
> 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?
This is taken care of by the device drivers. A driver for a device
either uses the DMA-API or does its own management of DMA mappings using
the IOMMU-API. VFIO is an example for the later case.
> > 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.
One usecase is device access from user-space via VFIO. A userspace
process might want to access multiple devices at the same time and VFIO
would implement this by assigning all of these devices to the same IOMMU
domain.
This requirement also comes also from the IOMMU-API itself. The
intention of the API is to make different IOMMUs look the same through
the API, and this is violated when drivers implement a 1-1
domain->device mapping.
> 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.
Yes, this is a requirement for new IOMMU drivers. We already have
drivers implementing the same 1-1 relation and we are about to fix them.
But I don't want to add new drivers doing the same.
Joerg
next prev parent reply other threads:[~2014-10-27 17:58 UTC|newest]
Thread overview: 11+ 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 15:43 ` Frank Blaschka
[not found] ` <20141022154320.GA42442-++28Fms/gMmXI4yAdoq52KN5r0PSdgG1zG2AekJRRhI@public.gmane.org>
2014-10-23 12:41 ` Joerg Roedel
[not found] ` <20141023124115.GB10053-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
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-27 14:32 ` Gerald Schaefer
2014-10-27 16:25 ` Joerg Roedel
[not found] ` <20141027162502.GB6202-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2014-10-27 17:02 ` Gerald Schaefer
2014-10-27 17:58 ` Joerg Roedel [this message]
[not found] ` <20141027175835.GC6202-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
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=20141027175835.GC6202@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=gerald.schaefer-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).