From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Woodhouse <dwmw2@infradead.org>,
Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
Cc: arnd@arndb.de, corbet@lwn.net, linux-doc@vger.kernel.org,
linux-arch@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
Joerg Roedel <jroedel@suse.de>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Sebastian Ott <sebott@linux.vnet.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Christoph Hellwig <hch@lst.de>, KVM <kvm@vger.kernel.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS
Date: Thu, 29 Oct 2015 10:10:46 +0900 [thread overview]
Message-ID: <1446081046.1856.55.camel@kernel.crashing.org> (raw)
In-Reply-To: <1446079332.3405.273.camel@infradead.org>
On Thu, 2015-10-29 at 09:42 +0900, David Woodhouse wrote:
> On Thu, 2015-10-29 at 09:32 +0900, Benjamin Herrenschmidt wrote:
>
> > On Power, I generally have 2 IOMMU windows for a device, one at the
> > bottom is remapped, and is generally used for 32-bit devices and the
> > one at the top us setup as a bypass
>
> So in the normal case of decent 64-bit devices (and not in a VM),
> they'll *already* be using the bypass region and have full access to
> all of memory, all of the time? And you have no protection against
> driver and firmware bugs causing stray DMA?
Correct, we chose to do that for performance reasons.
> > I don't see how thata ttribute would work for us.
>
> Because you're already doing it anyway without being asked :)
>
> If SPARC and POWER are both doing that, perhaps we should change the
> default for Intel too?
>
> Aside from the lack of security, the other disadvantage of that is that
> you have to pin *all* pages of a guest in case DMA happens; you don't
> get to pin *only* those pages which are referenced by that guest's
> IOMMU page tables...
Correct, the problem is that the cost of doing map/unmap from a guest
is really a huge hit on things like network devices.
Another problem is that the failure mode isn't great if you don't pin.
IE. You have to pin pages as they get mapped into the iommu by the
guest, but you don't know in advance how much and you may hit the
process ulimit on pinned pages half way through.
We tried to address that in various ways but it always ended up horrid.
> Maybe we should at least coordinate IOMMU 'paranoid/fast' modes across
> architectures, and then the DMA_ATTR_IOMMU_BYPASS flag would have a
> sane meaning in the paranoid mode (and perhaps we'd want an ultra
> -paranoid mode where it's not honoured).
Possibly, though ideally that would be a user policy but of course by
the time you get to userspace it's generally too late.
Cheers,
Ben.
next prev parent reply other threads:[~2015-10-29 1:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1445789224-28032-1-git-send-email-shamir.rabinovitch@oracle.com>
[not found] ` <1445789224-28032-2-git-send-email-shamir.rabinovitch@oracle.com>
2015-10-28 6:30 ` [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS David Woodhouse
2015-10-28 11:10 ` Shamir Rabinovitch
2015-10-28 13:31 ` David Woodhouse
2015-10-28 14:07 ` David Miller
2015-10-28 13:57 ` David Woodhouse
2015-10-29 0:23 ` David Miller
2015-10-29 0:32 ` Benjamin Herrenschmidt
2015-10-29 0:42 ` David Woodhouse
2015-10-29 1:10 ` Benjamin Herrenschmidt [this message]
2015-10-29 18:31 ` Andy Lutomirski
2015-10-29 22:35 ` David Woodhouse
2015-11-01 7:45 ` Shamir Rabinovitch
2015-11-01 21:10 ` Benjamin Herrenschmidt
2015-11-02 7:23 ` Shamir Rabinovitch
2015-11-02 10:00 ` Benjamin Herrenschmidt
2015-11-02 12:07 ` Shamir Rabinovitch
2015-11-02 20:13 ` Benjamin Herrenschmidt
2015-11-02 21:45 ` Arnd Bergmann
2015-11-02 23:08 ` Benjamin Herrenschmidt
2015-11-03 13:11 ` Christoph Hellwig
2015-11-03 19:35 ` Benjamin Herrenschmidt
2015-11-02 21:49 ` Shamir Rabinovitch
2015-11-02 22:48 ` David Woodhouse
2015-11-02 23:10 ` Benjamin Herrenschmidt
2015-11-05 21:08 ` David Miller
2015-10-30 1:51 ` Benjamin Herrenschmidt
2015-10-30 10:32 ` Arnd Bergmann
2015-10-30 23:17 ` Benjamin Herrenschmidt
2015-10-30 23:24 ` Arnd Bergmann
2015-11-02 14:51 ` Joerg Roedel
2015-10-29 7:32 ` Shamir Rabinovitch
2015-11-02 14:44 ` Joerg Roedel
2015-11-02 17:32 ` Shamir Rabinovitch
2015-11-05 13:42 ` Joerg Roedel
2015-11-05 21:11 ` David Miller
2015-11-07 15:06 ` Shamir Rabinovitch
[not found] ` <CAN+hb0UvztgwNuAh93XdJEe7vgiZgNMc9mHNziHpEopg8Oi4Mg@mail.gmail.com>
2015-11-16 8:42 ` David Woodhouse
[not found] ` <CAN+hb0UWpfcS5DvgMxNjY-5JOztw2mO1r2FJAW17fn974mhxPA@mail.gmail.com>
2015-11-16 18:42 ` Benjamin Serebrin
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=1446081046.1856.55.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=borntraeger@de.ibm.com \
--cc=corbet@lwn.net \
--cc=cornelia.huck@de.ibm.com \
--cc=dwmw2@infradead.org \
--cc=hch@lst.de \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pbonzini@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=sebott@linux.vnet.ibm.com \
--cc=shamir.rabinovitch@oracle.com \
/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