On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, December 04, 2012 11:53 PM
> To: Sethi Varun-B16395
> Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org;
> io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
Tabi
> Timur-B04825
> Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
> required by fsl PAMU driver.
>
> On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Monday, December 03, 2012 10:34 PM
> > > To: Sethi Varun-B16395
> > > Cc: Joerg Roedel; linux-ker...@vger.kernel.org;
iommu@lists.linux-
> > > foundation.org; Wood Scott-B07421;
linuxppc-dev@lists.ozlabs.org;
> > Tabi
> > > Timur-B04825
> > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain
attributes
> > > required by fsl PAMU driver.
> > >
> > > On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: iommu-boun...@lists.linux-foundation.org
[mailto:iommu-
> > > > > boun...@lists.linux-foundation.org] On Behalf Of Joerg
Roedel
> > > > > Sent: Sunday, December 02, 2012 7:33 PM
> > > > > To: Sethi Varun-B16395
> > > > > Cc: linux-ker...@vger.kernel.org;
> > io...@lists.linux-foundation.org;
> > > > Wood
> > > > > Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi
Timur-B04825
> > > > > Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain
> > attributes
> > > > > required by fsl PAMU driver.
> > > > >
> > > > > Hmm, we need to work out a good abstraction for this.
> > > > >
> > > > > On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote:
> > > > > > Added the following domain attributes required by FSL PAMU
> > driver:
> > > > > > 1. Subwindows field added to the iommu domain geometry
> > attribute.
> > > > >
> > > > > Are the Subwindows mapped with full size or do you map only
> > parts
> > > > of the
> > > > > subwindows?
> > > > >
> > > > [Sethi Varun-B16395] It's possible to map a part of the
subwindow
> > i.e.
> > > > size of the mapping can be less than the sub window size.
> > > >
> > > > > > + * This attribute indicates number of DMA subwindows
> > > supported
> > > > by
> > > > > > + * the geometry. If there is a single window that maps
> > the
> > > > entire
> > > > > > + * geometry, attribute must be set to "1". A value of
> > "0"
> > > > implies
> > > > > > + * that this mechanism is not used at all(normal paging
> > is
> > > > used).
> > > > > > + * Value other than* "0" or "1" indicates the actual
> > number
> > > of
> > > > > > + * subwindows.
> > > > > > + */
> > > > >
> > > > > This semantic is ugly, how about a feature detection
mechanism?
> > > > >
> > > > [Sethi Varun-B16395] A feature mechanism to query the type of
> > IOMMU?
> > >
> > > A feature mechanism to determine whether this subwindow
mechanism is
> > > available, and what the limits are.
> > >
> > So, we use the IOMMU capability interface to find out if IOMMU
> > supports sub windows or not, right? But still number of sub
windows
> > would be specified as a part of the geometry and the valid value
for
> > sub windows would 0,1 or actual number of sub windows.
>
> How does a user of the interface find out what values are possible
for
> the "actual number of subwindows"? How does a user of the
interface find
> out whether there are any limitations on specifying a value of zero
(in
> the case of PAMU, that would be a maximum 1 MiB naturally-aligned
> aperture to support arbitrary 4KiB mappings)?
How about if we say that the default value for subwindows is zero and
this what you get when you read the geometry (iommu_get_attr) after
initializing the domain? In that case the user would know that
implication of setting subwindows to zero with respect to the
aperture size.
So it would default to the maximum aperture size possible with no
subwindows? That might be OK, though is there a way to reset the
domain later on to get back to that informational state?
How about finding out the maximum number of subwindows?
Also, should we introduce an additional API like "iommu_check_attr",
which the user can use to validate the attribute value. For example
in case of geometry, the user can fill up the structure and pass it
to the iommu driver in order to verify the aperture and subwindows
field.
Doesn't the current API raise an error if you do something
unsupported? In any case I don't think making a series of guesses and
seeing which ones are accepted is a good substitute for being able to
simply read out the relevant parameters.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
