On Wed, Dec 07, 2011 at 09:54:39AM -0600, Stuart Yoder wrote:
> Alex, Alexey I'm wondering if you've had any new thoughts on this over
> the last week.
>
> For Freescale, our iommu domain attributes would look something like:
> -domain iova base address
> -domain iova window size
I agree with that.
> -domain enable/disable
> -number of subwindows
> -operation mapping table index
> -stash destination CPU
> -stash target (cache– L1, L2, L3)
Why does the user of the IOMMU-API need to have control over these
things?
> These are all things that need to be set by the creator of the domain.
>
> Since the domain attributes are going to be so different for each platform does
> it make sense to define a new iommu_ops call back that just takes a void pointer
> that can be implemented in a platform specific way? For example:
>
> struct iommu_ops {
> [cut]
> int (*domain_set_attrs)(struct iommu_domain *domain,
> void *attrs);
> int (*domain_get_attrs)(struct iommu_domain *domain,
> void *attrs);
> }
A void pointer is certainly the worst choice for an interface. I think
it is better to have at least a set of common attributes. Somthing like
this:
iommu_domain_set_attr(struct iommu_domain *domain, enum attr_type, void *data)
iommu_domain_get_attr(struct iommu_domain *domain, enum attr_type, void *data)
The iova base/size options make sense for more IOMMUs than just
Freescale. For example it would allow to manage GART-like IOMMUs with
the IOMMU-API too.
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
