From: Joerg Roedel <Joerg.Roedel@amd.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Kai Huang <mail.kai.huang@gmail.com>,
Ohad Ben-Cohen <ohad@wizery.com>,
<iommu@lists.linux-foundation.org>, <linux-omap@vger.kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
<linux-arm-kernel@lists.infradead.org>,
David Brown <davidb@codeaurora.org>,
Arnd Bergmann <arnd@arndb.de>, <linux-kernel@vger.kernel.org>,
Hiroshi Doyu <hdoyu@nvidia.com>,
Stepan Moskovchenko <stepanm@codeaurora.org>,
KyongHo Cho <pullip.cho@samsung.com>, <kvm@vger.kernel.org>
Subject: Changing IOMMU-API for generic DMA-mapping supported by the hardware
Date: Fri, 11 Nov 2011 14:17:28 +0100 [thread overview]
Message-ID: <20111111131728.GG13213@amd.com> (raw)
In-Reply-To: <1320953319.535.11.camel@i7.infradead.org>
Okay, seperate thread for this one.
On Thu, Nov 10, 2011 at 07:28:39PM +0000, David Woodhouse wrote:
> > The plan is to have a single DMA-API implementation for all IOMMU
> > drivers (X86 and ARM) which just uses the IOMMU-API. But to make this
> > performing reasonalbly well a few changes to the IOMMU-API are required.
> > I already have some ideas which we can discuss if you want.
>
> Yeah, that sounds useful.
As I said some changes to the IOMMU-API are required in my opinion.
These changes should also allow it to move over old-style IOMMUs like
Calgary or GART later.
The basic idea is that IOMMU drivers should be required to put every
device they are responsible for into a default domain. The DMA mapping
code can query this default domain for each device.
Also the default domain has capabilities that can be queried. Those
capabilities include the size and offset of the address space they can
re-map. For GART and Calgary this will be the aperture, for VT-d and AMD
IOMMU the whole 64bit address space. Another capability is whether
addresses outside of that area are 1-1 mapped or no accessible to the
device.
The generic DMA-mapping code will use that information to initialize its
allocator and uses iommu_map/iommu_unmap to create and destroy mappings
as requested by the DMA-API (but the DMA-mapping code does not need to
create a domain of its own).
The good thing about these default domains is that IOMMU drivers can
implement their own optimizations on it. The AMD IOMMU driver for
example already makes a distinction between dma-mapping domains and
other protection-domains. The optimization for dma-mapping domains is
that the leaf-pages of the page-table are keept in an array so that it
is very easy to find the PTE for an address. Those optimizations are
still possible with the default-domain concept.
In short, the benefits of the default-domain concept are:
1) It allows existing optimizations for the DMA-mapping code
paths to persist
2) It also fits old-style IOMMUs like GART, Calgary and others
An open problem is how to report reserved ranges of an address-space.
These ranges might exist from a BIOS requirement for 1-1 mapping of
certain address ranges (in AMD jargon: Unity mapped ranges, something
similar exists on VT-d afaik) or hardware requirements like the reserved
address range used for MSI interrupts.
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2011-11-11 13:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 11:27 [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 1/7] iommu/core: stop converting bytes to page order back and forth Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-11-10 6:17 ` Kai Huang
2011-11-10 7:31 ` Ohad Ben-Cohen
2011-11-10 12:16 ` cody
2011-11-10 13:08 ` Joerg Roedel
2011-11-10 14:35 ` cody
2011-11-10 14:51 ` Joerg Roedel
2011-11-10 15:28 ` David Woodhouse
2011-11-10 17:09 ` Joerg Roedel
2011-11-10 19:28 ` David Woodhouse
2011-11-11 12:58 ` Joerg Roedel
2011-11-11 13:27 ` David Woodhouse
2011-11-11 14:18 ` Joerg Roedel
2011-11-11 13:17 ` Joerg Roedel [this message]
2011-11-24 12:52 ` Changing IOMMU-API for generic DMA-mapping " Marek Szyprowski
2011-11-24 15:27 ` 'Joerg Roedel'
2011-11-10 21:12 ` [PATCH v4 2/7] iommu/core: split mapping to page sizes as " Stepan Moskovchenko
2011-11-11 13:24 ` Joerg Roedel
2011-11-12 2:04 ` Stepan Moskovchenko
2011-11-13 1:43 ` KyongHo Cho
2011-10-17 11:27 ` [PATCH v4 3/7] iommu/omap: announce supported page sizes Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 4/7] iommu/msm: " Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 5/7] iommu/amd: " Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 6/7] iommu/intel: " Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 7/7] iommu/core: remove the temporary pgsize settings Ohad Ben-Cohen
2011-11-08 12:57 ` [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-11-08 14:01 ` Joerg Roedel
2011-11-08 14:03 ` Ohad Ben-Cohen
2011-11-08 16:23 ` Joerg Roedel
2011-11-08 16:43 ` Ohad Ben-Cohen
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=20111111131728.GG13213@amd.com \
--to=joerg.roedel@amd.com \
--cc=arnd@arndb.de \
--cc=davidb@codeaurora.org \
--cc=dwmw2@infradead.org \
--cc=hdoyu@nvidia.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mail.kai.huang@gmail.com \
--cc=ohad@wizery.com \
--cc=pullip.cho@samsung.com \
--cc=stepanm@codeaurora.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