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
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
