From: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Woodhouse <dwmw2@infradead.org>,
Andy Lutomirski <luto@amacapital.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
linux-arch <linux-arch@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Sebastian Ott <sebott@linux.vnet.ibm.com>,
linux-s390 <linux-s390@vger.kernel.org>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Joerg Roedel <jroedel@suse.de>, Jonathan Corbet <corbet@lwn.net>,
KVM <kvm@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS
Date: Mon, 2 Nov 2015 09:23:58 +0200 [thread overview]
Message-ID: <20151102072358.GA4642@shamir-ThinkPad-T430> (raw)
In-Reply-To: <1446412249.4060.7.camel@kernel.crashing.org>
On Mon, Nov 02, 2015 at 08:10:49AM +1100, Benjamin Herrenschmidt wrote:
> But but but ...
>
> What I don't understand is how that brings you any safety.
Limited safety maybe? If some device DMA mappings are via IOMMU
and this fall to some address range that is far from the bypass /
pass through range then small drifts in address might be still figured
if we do not bypass / pass through the IOMMU - right?
Device can sure use the bypass address and just reach the memory w/o
IOMMU protection. See some comments about that below.
>
> Basically, either your bridge has a bypass window, or it doesn't. (Or
> it has one and it's enabled or not, same thing).
Agree.
>
> If you request the bypass on a per-mapping basis, you basically have to
> keep the window always enabled, unless you do some nasty refcounting of
> how many people have a bypass mapping in flight, but that doesn't seem
> useful.
>
> Thus you have already lost all protection from the device, since your
> entire memory is accessible via the bypass mapping.
Correct, see my above comment.
>
> Which means what is the point of then having non-bypass mappings for
> other things ? Just to make things slower ?
>
> I really don't see what this whole "bypass on a per-mapping basis" buys
> you.
>
> Note that we implicitly already do that on powerpc, but not for those
> reasons, we do it based on the DMA mask, so that if your coherent mask
> is 32-bit but your dma mask is 64-bit (which is not an uncommon
> combination), we service the "coherent" requests (basically the long
> lifed dma allocs) from the remapped region and the "stream" requests
> (ie, map_page/map_sg) from the bypass.
To summary -
1. The whole point of the IOMMU pass through was to get bigger address space
and faster map/unmap operations for performance critical hardware
2. SPARC IOMMU in particular has the ability to DVMA which adress all the
protection concerns raised above. Not sure what will be the performance
impact though. This still need a lot of work before we could test this.
3. On x86 we use IOMMU in pass through mode so all the above concerns are valid
The question are -
1. Does partial use of IOMMU while the pass through window is enabled add some
protection?
2. Do we rather the x86 way of doing this which is enable / disable IOMMU
translations at kernel level?
I think that I can live with option (2) till I have DVMA if there is strong
disagree on the need for per allocation IOMMU bypass.
>
> Cheers,
> Ben.
>
next prev parent reply other threads:[~2015-11-02 7:30 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-25 16:07 [PATCH v1 1/2] dma-mapping-common: add dma_map_page_attrs API Shamir Rabinovitch
2015-10-25 16:07 ` [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS Shamir Rabinovitch
2015-10-28 6:30 ` David Woodhouse
2015-10-28 11:10 ` Shamir Rabinovitch
2015-10-28 11:10 ` Shamir Rabinovitch
2015-10-28 13:31 ` David Woodhouse
2015-10-28 13:31 ` David Woodhouse
2015-10-28 14:07 ` David Miller
2015-10-28 13:57 ` David Woodhouse
2015-10-28 13:57 ` David Woodhouse
2015-10-29 0:23 ` David Miller
2015-10-29 0:23 ` David Miller
2015-10-28 14:07 ` David Miller
2015-10-29 0:32 ` Benjamin Herrenschmidt
2015-10-29 0:32 ` Benjamin Herrenschmidt
2015-10-29 0:42 ` David Woodhouse
2015-10-29 0:42 ` David Woodhouse
2015-10-29 1:10 ` Benjamin Herrenschmidt
2015-10-29 1:10 ` Benjamin Herrenschmidt
2015-10-29 18:31 ` Andy Lutomirski
2015-10-29 18:31 ` Andy Lutomirski
2015-10-29 22:35 ` David Woodhouse
2015-11-01 7:45 ` Shamir Rabinovitch
2015-11-01 7:45 ` Shamir Rabinovitch
2015-11-01 21:10 ` Benjamin Herrenschmidt
2015-11-01 21:10 ` Benjamin Herrenschmidt
2015-11-02 7:23 ` Shamir Rabinovitch [this message]
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 21:45 ` Arnd Bergmann
2015-11-02 23:08 ` Benjamin Herrenschmidt
2015-11-02 23:08 ` Benjamin Herrenschmidt
2015-11-03 13:11 ` Christoph Hellwig
2015-11-03 13:11 ` Christoph Hellwig
2015-11-03 19:35 ` Benjamin Herrenschmidt
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-02 23:10 ` Benjamin Herrenschmidt
2015-11-05 21:08 ` David Miller
2015-11-05 21:08 ` David Miller
2015-10-30 1:51 ` Benjamin Herrenschmidt
2015-10-30 1:51 ` Benjamin Herrenschmidt
2015-10-30 10:32 ` Arnd Bergmann
2015-10-30 10:32 ` Arnd Bergmann
2015-10-30 23:17 ` Benjamin Herrenschmidt
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-02 17:32 ` Shamir Rabinovitch
2015-11-05 13:42 ` Joerg Roedel
2015-11-05 21:11 ` David Miller
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
2015-11-16 18:42 ` Benjamin Serebrin
-- strict thread matches above, loose matches on Subject: below --
2015-10-25 16:37 [PATCH v1 1/2] dma-mapping-common: add dma_map_page_attrs API Shamir Rabinovitch
2015-10-25 16:37 ` [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS Shamir Rabinovitch
2015-11-16 6:56 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=20151102072358.GA4642@shamir-ThinkPad-T430 \
--to=shamir.rabinovitch@oracle.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--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@amacapital.net \
--cc=pbonzini@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=sebott@linux.vnet.ibm.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