From: Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Linux DeviceTree
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-samsung-soc
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 21 May 2014 08:44:42 -0700 [thread overview]
Message-ID: <CANEJEGvhEsC9wKqX_pYmOg7LwsQkoN9=jjXJuW0UeEa9XywSPw@mail.gmail.com> (raw)
In-Reply-To: <11242680.PQytQQqlPJ@wuerfel>
On Wed, May 21, 2014 at 2:32 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
>> On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
>>
>> > Right. As long as we always unmap the buffers from the IOMMU after they
>> > have stopped being in use, it's very unlikely that even a broken device
>> > driver causes a DMA into some bus address that happens to be mapped for
>> > another device.
>>
>> I think that if buffers remain mapped in the IOMMU when they have been
>> deallocated that should be considered a bug.
There is currently no general requirement to tear down mappings immediately.
An option to enforce immediate tear down might be useful since I agree
Virtual Guests sharing host memory through shared physical devices
will want that. ie there should be no opportunity for a shared device
to be able to access another guests memory through "stale" (but live)
DMA mappings. I don't think that's the case but I'd ask someone like
Alex Williamson for a more certain answer.
> You could see it as a performance optimization in some cases, e.g. when you
> cannot flush individual IOTLBs or doing so is expensive, and you just keep
> assigning new addresses until every one has been used, then you do a global
> IOTLB flush once.
This is in fact exactly what several IOMMUs do - including the Intel
IOMMU driver.
IIRC, the Intel IOMMU driver collects 256 or so entries to flush and
then flushes them all at once and updates the metadata. I don't if it
does this for ranges assigned to different virtual guests though or
just within a given range.
> Obviously you have to maintain the IO page tables correctly.
To be clear, "Correctly" in this case just means until the IOTLB is
flushed, the given IOMMU Pdir entries are marked "in use" even though
the driver has handed "ownership" back to the IOMMU driver.
cheers,
grant
WARNING: multiple messages have this Message-ID (diff)
From: Grant Grundler <grundler@chromium.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Thierry Reding <thierry.reding@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Linux DeviceTree <devicetree@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Grant Grundler <grundler@chromium.org>,
Joerg Roedel <joro@8bytes.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Will Deacon <will.deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
Rob Herring <robh+dt@kernel.org>,
Kumar Gala <galak@codeaurora.org>,
linux-tegra@vger.kernel.org, Cho KyongHo <pullip.cho@samsung.com>,
Dave Martin <Dave.Martin@arm.com>
Subject: Re: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 21 May 2014 08:44:42 -0700 [thread overview]
Message-ID: <CANEJEGvhEsC9wKqX_pYmOg7LwsQkoN9=jjXJuW0UeEa9XywSPw@mail.gmail.com> (raw)
In-Reply-To: <11242680.PQytQQqlPJ@wuerfel>
On Wed, May 21, 2014 at 2:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
>> On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
>>
>> > Right. As long as we always unmap the buffers from the IOMMU after they
>> > have stopped being in use, it's very unlikely that even a broken device
>> > driver causes a DMA into some bus address that happens to be mapped for
>> > another device.
>>
>> I think that if buffers remain mapped in the IOMMU when they have been
>> deallocated that should be considered a bug.
There is currently no general requirement to tear down mappings immediately.
An option to enforce immediate tear down might be useful since I agree
Virtual Guests sharing host memory through shared physical devices
will want that. ie there should be no opportunity for a shared device
to be able to access another guests memory through "stale" (but live)
DMA mappings. I don't think that's the case but I'd ask someone like
Alex Williamson for a more certain answer.
> You could see it as a performance optimization in some cases, e.g. when you
> cannot flush individual IOTLBs or doing so is expensive, and you just keep
> assigning new addresses until every one has been used, then you do a global
> IOTLB flush once.
This is in fact exactly what several IOMMUs do - including the Intel
IOMMU driver.
IIRC, the Intel IOMMU driver collects 256 or so entries to flush and
then flushes them all at once and updates the metadata. I don't if it
does this for ranges assigned to different virtual guests though or
just within a given range.
> Obviously you have to maintain the IO page tables correctly.
To be clear, "Correctly" in this case just means until the IOTLB is
flushed, the given IOMMU Pdir entries are marked "in use" even though
the driver has handed "ownership" back to the IOMMU driver.
cheers,
grant
WARNING: multiple messages have this Message-ID (diff)
From: grundler@chromium.org (Grant Grundler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 21 May 2014 08:44:42 -0700 [thread overview]
Message-ID: <CANEJEGvhEsC9wKqX_pYmOg7LwsQkoN9=jjXJuW0UeEa9XywSPw@mail.gmail.com> (raw)
In-Reply-To: <11242680.PQytQQqlPJ@wuerfel>
On Wed, May 21, 2014 at 2:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
>> On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
>>
>> > Right. As long as we always unmap the buffers from the IOMMU after they
>> > have stopped being in use, it's very unlikely that even a broken device
>> > driver causes a DMA into some bus address that happens to be mapped for
>> > another device.
>>
>> I think that if buffers remain mapped in the IOMMU when they have been
>> deallocated that should be considered a bug.
There is currently no general requirement to tear down mappings immediately.
An option to enforce immediate tear down might be useful since I agree
Virtual Guests sharing host memory through shared physical devices
will want that. ie there should be no opportunity for a shared device
to be able to access another guests memory through "stale" (but live)
DMA mappings. I don't think that's the case but I'd ask someone like
Alex Williamson for a more certain answer.
> You could see it as a performance optimization in some cases, e.g. when you
> cannot flush individual IOTLBs or doing so is expensive, and you just keep
> assigning new addresses until every one has been used, then you do a global
> IOTLB flush once.
This is in fact exactly what several IOMMUs do - including the Intel
IOMMU driver.
IIRC, the Intel IOMMU driver collects 256 or so entries to flush and
then flushes them all at once and updates the metadata. I don't if it
does this for ranges assigned to different virtual guests though or
just within a given range.
> Obviously you have to maintain the IO page tables correctly.
To be clear, "Correctly" in this case just means until the IOTLB is
flushed, the given IOMMU Pdir entries are marked "in use" even though
the driver has handed "ownership" back to the IOMMU driver.
cheers,
grant
next prev parent reply other threads:[~2014-05-21 15:44 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 12:23 [PATCH] devicetree: Add generic IOMMU device tree bindings Thierry Reding
2014-05-16 12:23 ` Thierry Reding
2014-05-16 12:23 ` Thierry Reding
[not found] ` <1400242998-437-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 8:04 ` Cho KyongHo
2014-05-17 20:48 ` Thierry Reding
2014-05-17 20:48 ` Thierry Reding
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 10:26 ` Arnd Bergmann
2014-05-19 12:53 ` Thierry Reding
2014-05-19 12:53 ` Thierry Reding
2014-05-19 17:22 ` Dave Martin
2014-05-19 17:22 ` Dave Martin
2014-05-19 17:22 ` Dave Martin
[not found] ` <20140519172113.GA13858-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-19 20:32 ` Thierry Reding
2014-05-19 20:32 ` Thierry Reding
2014-05-19 20:32 ` Thierry Reding
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 10:08 ` Arnd Bergmann
2014-05-20 13:07 ` Dave Martin
2014-05-20 13:07 ` Dave Martin
2014-05-20 13:07 ` Dave Martin
[not found] ` <20140520130659.GA5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 13:23 ` Arnd Bergmann
2014-05-20 15:26 ` Will Deacon
2014-05-20 15:26 ` Will Deacon
2014-05-20 15:26 ` Will Deacon
[not found] ` <20140520152659.GA30404-5wv7dgnIgG8@public.gmane.org>
2014-05-20 16:39 ` Dave Martin
2014-05-20 16:39 ` Dave Martin
2014-05-20 16:39 ` Dave Martin
[not found] ` <20140520163912.GC5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 20:40 ` Arnd Bergmann
2014-05-20 20:40 ` Arnd Bergmann
2014-05-20 20:40 ` Arnd Bergmann
2014-05-19 18:34 ` Arnd Bergmann
2014-05-19 18:34 ` Arnd Bergmann
2014-05-19 20:59 ` Thierry Reding
2014-05-19 20:59 ` Thierry Reding
2014-05-19 20:59 ` Thierry Reding
2014-05-20 10:04 ` Arnd Bergmann
2014-05-20 10:04 ` Arnd Bergmann
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:05 ` Thierry Reding
2014-05-20 11:15 ` Arnd Bergmann
2014-05-20 11:15 ` Arnd Bergmann
2014-05-20 12:02 ` Thierry Reding
2014-05-20 12:02 ` Thierry Reding
2014-05-20 12:02 ` Thierry Reding
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 12:41 ` Arnd Bergmann
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:17 ` Thierry Reding
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 13:34 ` Arnd Bergmann
2014-05-20 14:00 ` Thierry Reding
2014-05-20 14:00 ` Thierry Reding
2014-05-20 14:00 ` Thierry Reding
2014-05-20 20:31 ` Arnd Bergmann
2014-05-20 20:31 ` Arnd Bergmann
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:16 ` Thierry Reding
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 8:54 ` Arnd Bergmann
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:02 ` Thierry Reding
2014-05-21 9:32 ` Arnd Bergmann
2014-05-21 9:32 ` Arnd Bergmann
2014-05-21 15:44 ` Grant Grundler [this message]
2014-05-21 15:44 ` Grant Grundler
2014-05-21 15:44 ` Grant Grundler
2014-05-21 16:01 ` Arnd Bergmann
2014-05-21 16:01 ` Arnd Bergmann
2014-05-21 16:01 ` Arnd Bergmann
2014-05-20 15:24 ` Dave Martin
2014-05-20 15:24 ` Dave Martin
2014-05-20 15:24 ` Dave Martin
[not found] ` <20140520152458.GB5041-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-20 20:26 ` Arnd Bergmann
2014-05-20 20:26 ` Arnd Bergmann
2014-05-20 20:26 ` Arnd Bergmann
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:26 ` Thierry Reding
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 8:50 ` Arnd Bergmann
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:00 ` Thierry Reding
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 9:36 ` Arnd Bergmann
2014-05-21 10:50 ` Thierry Reding
2014-05-21 10:50 ` Thierry Reding
2014-05-21 10:50 ` Thierry Reding
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 14:01 ` Arnd Bergmann
2014-05-21 17:09 ` Dave Martin
2014-05-21 17:09 ` Dave Martin
2014-05-21 17:09 ` Dave Martin
[not found] ` <20140521170954.GC3830-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-21 18:11 ` Arnd Bergmann
2014-05-21 18:11 ` Arnd Bergmann
2014-05-21 18:11 ` Arnd Bergmann
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='CANEJEGvhEsC9wKqX_pYmOg7LwsQkoN9=jjXJuW0UeEa9XywSPw@mail.gmail.com' \
--to=grundler-f7+t8e8rja9g9huczpvpmw@public.gmane.org \
--cc=Dave.Martin-5wv7dgnIgG8@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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.