From: "Roedel, Joerg" <Joerg.Roedel@amd.com>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Hiroshi DOYU <Hiroshi.DOYU@nokia.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Tony Lindgren <tony@atomide.com>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH] iommu: omap_iovmm: support non page-aligned buffers in iommu_vmap
Date: Wed, 31 Aug 2011 15:06:42 +0200 [thread overview]
Message-ID: <20110831130642.GQ12940@amd.com> (raw)
In-Reply-To: <CAK=Wgbb06Z0_8OKFf6MKjYe+SJN16Mh9PA6z_T+cpSpB9EKHFw@mail.gmail.com>
On Wed, Aug 31, 2011 at 06:52:08AM -0400, Ohad Ben-Cohen wrote:
> On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > omap_iovmm requires page-aligned buffers, and that sometimes causes
> > omap3isp failures (i.e. whenever the buffer passed from userspace is not
> > page-aligned).
> >
> > Remove this limitation by rounding the address of the first page entry
> > down, and adding the offset back to the device address.
>
> I'm having second thoughts about this.
>
> Obviously it works for omap3isp and its users because the buffer gets
> mapped and everyone is happy.
>
> But I'm not sure this is a valid IOMMU interface that the kernel
> should have, because effectively we're now mapping physical memory
> which nobody asked us to, and which might contain sensitive stuff we
> don't want to give the device (e.g. a remote processor which might be
> running rogue code) access to.
>
> Thoughts ?
Do you mean the parts of the pages you map to the device that are not in
the requested range (basically everything before offset and all after
size)?
This issue exists in other iommu drivers as well. It is inherent to how
the dma-api is defined and how the iommu hardware works.
The dma-api can work on byte granularity while the hardware usually only
works on page granularity.
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-08-31 13:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 19:36 [PATCH] iommu: omap_iovmm: support non page-aligned buffers in iommu_vmap Ohad Ben-Cohen
2011-08-31 10:52 ` Ohad Ben-Cohen
2011-08-31 11:27 ` Laurent Pinchart
2011-08-31 13:06 ` Roedel, Joerg [this message]
2011-08-31 16:56 ` Laurent Pinchart
2011-08-31 17:16 ` Ohad Ben-Cohen
2011-09-01 9:35 ` Roedel, Joerg
2011-09-01 11:47 ` Ohad Ben-Cohen
2011-09-01 13:31 ` Laurent Pinchart
2011-09-01 13:42 ` Roedel, Joerg
2011-09-01 13:59 ` Laurent Pinchart
2011-09-01 14:02 ` Ohad Ben-Cohen
2011-09-01 14:15 ` Laurent Pinchart
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=20110831130642.GQ12940@amd.com \
--to=joerg.roedel@amd.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=arnd@arndb.de \
--cc=iommu@lists.linux-foundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=tony@atomide.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