From: Joerg Roedel <joro@8bytes.org>
To: Scott Wood <scottwood@freescale.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
Sethi Varun-B16395 <B16395@freescale.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Ohad Ben-Cohen <ohad@wizery.com>,
Tony Lindgren <tony@atomide.com>,
Hiroshi DOYU <Hiroshi.DOYU@nokia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Wood Scott-B07421 <B07421@freescale.com>,
David Brown <davidb@codeaurora.org>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 2/5] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute
Date: Thu, 26 Jan 2012 20:44:29 +0100 [thread overview]
Message-ID: <20120126194428.GH6269@8bytes.org> (raw)
In-Reply-To: <4F21A2D5.6000204@freescale.com>
On Thu, Jan 26, 2012 at 01:00:37PM -0600, Scott Wood wrote:
> On 01/26/2012 12:51 PM, Joerg Roedel wrote:
> > Because this is a flag that makes sense for all IOMMU. Every IOMMU
> > either allows DMA outside its aperture or it doesn't.
> >
> > Another reason why it must be in the generic struct is the intended
> > generic dma-ops layer on-top. This code can decide on this flag wheter a
> > address needs to be remapped at all.
>
> So the DMA API would just read this, not write it?
The whole geometry thing is only implemented on the read side. There is
no implementation in domain_set_attr for it. So the geometry
information is read-only by default.
> Still no reason why it couldn't be a separate attribute. Then if you
> get a failure trying to write it, it's more obvious why.
This would mean iommu specific hacks, which are not necessary in this
case.
> > Setting this flag wrong does not create unintended identity mappings.
>
> Failing to set it means that DMA can go through that is not limited to
> explicitly created mappings. In some contexts (e.g. vfio) this is a
> security hole.
No, when the hardware does not allow this, then software can't enforce
it. Again, the whole geometry attribute is only for iommu drivers to
export what the hardware can do. It is not for software to configure the
iommu driver.
> > But I don't understand what you mean by 'restrictions on possible values'. The
> > geometry attribute is filled by the IOMMU driver dependent on the
> > hardware capabilities. There are no limits from the iommu-code side.
>
> How does the user of the iommu API discover the hardware capabilities?
Which hardware capabilities besides the geometry do you mean?
Joerg
next prev parent reply other threads:[~2012-01-26 19:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 14:30 [PATCH 0/5] IOMMU: Make IOMMU-API ready for GART-like hardware Joerg Roedel
2012-01-19 14:30 ` [PATCH 1/5] iommu: Add domain-attribute handlers Joerg Roedel
2012-01-19 14:30 ` [PATCH 2/5] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute Joerg Roedel
2012-01-19 15:46 ` Laurent Pinchart
2012-01-19 16:07 ` Joerg Roedel
2012-01-19 16:27 ` Laurent Pinchart
2012-01-20 5:44 ` Hiroshi Doyu
2012-01-20 16:01 ` Joerg Roedel
2012-02-01 9:37 ` Sethi Varun-B16395
2012-01-26 18:26 ` Scott Wood
2012-01-19 17:16 ` Sethi Varun-B16395
2012-01-20 16:03 ` Joerg Roedel
2012-01-26 18:25 ` Scott Wood
2012-01-26 18:31 ` Joerg Roedel
2012-01-26 18:42 ` Scott Wood
2012-01-26 18:51 ` Joerg Roedel
2012-01-26 19:00 ` Scott Wood
2012-01-26 19:44 ` Joerg Roedel [this message]
2012-01-26 20:02 ` Scott Wood
2012-01-27 11:01 ` Joerg Roedel
2012-01-27 21:22 ` Scott Wood
2012-01-30 14:24 ` Joerg Roedel
2012-01-30 20:21 ` Scott Wood
2012-01-30 6:27 ` Sethi Varun-B16395
2012-01-30 14:30 ` Joerg Roedel
2012-01-19 14:30 ` [PATCH 3/5] iommu/vt-d: " Joerg Roedel
2012-01-19 14:30 ` [PATCH 4/5] iommu/omap: " Joerg Roedel
2012-01-19 14:30 ` [PATCH 5/5] iommu/msm: " Joerg Roedel
2012-01-20 6:14 ` [PATCH 0/5] IOMMU: Make IOMMU-API ready for GART-like hardware Hiroshi Doyu
2012-01-20 16:05 ` joerg.roedel
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=20120126194428.GH6269@8bytes.org \
--to=joro@8bytes.org \
--cc=B07421@freescale.com \
--cc=B16395@freescale.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=davidb@codeaurora.org \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=scottwood@freescale.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;
as well as URLs for NNTP newsgroup(s).