Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

2 messages, 2 authors, 2012-12-11 · open the first message on its own page

Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

From: Scott Wood <hidden>
Date: 2012-12-11 01:00:56

On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote:

=20
=20

quoted

-----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-kernel@vger.kernel.org;
iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; =20

Tabi

quoted

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:

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Monday, December 03, 2012 10:34 PM
To: Sethi Varun-B16395
Cc: Joerg Roedel; linux-kernel@vger.kernel.org; =20

iommu@lists.linux-

quoted

foundation.org; Wood Scott-B07421; =20

linuxppc-dev@lists.ozlabs.org;

quoted

Tabi

quoted

Timur-B04825
Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain =20

attributes

quoted

required by fsl PAMU driver.

On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote:

quoted

-----Original Message-----
From: iommu-bounces@lists.linux-foundation.org =20

[mailto:iommu-

quoted

bounces@lists.linux-foundation.org] On Behalf Of Joerg =20

Roedel

quoted

Sent: Sunday, December 02, 2012 7:33 PM
To: Sethi Varun-B16395
Cc: linux-kernel@vger.kernel.org;

iommu@lists.linux-foundation.org;

quoted

Wood

quoted

Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi =20

Timur-B04825

quoted

Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain

attributes

quoted

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:

quoted

Added the following domain attributes required by FSL PAMU

driver:

quoted

1. Subwindows field added to the iommu domain geometry

attribute.

quoted

Are the Subwindows mapped with full size or do you map only

parts

quoted

of the

quoted

subwindows?

[Sethi Varun-B16395] It's possible to map a part of the =20

subwindow

quoted

i.e.

quoted

size of the mapping can be less than the sub window size.

quoted

+	 * This attribute indicates number of DMA subwindows

supported

quoted

by

quoted

+	 * the geometry. If there is a single window that maps

the

quoted

entire

quoted

+	 * geometry, attribute must be set to "1". A value of

"0"

quoted

implies

quoted

+	 * that this mechanism is not used at all(normal paging

is

quoted

used).

quoted

+	 * Value other than* "0" or "1" indicates the actual

number

quoted

of

quoted

+	 * subwindows.
+	 */

This semantic is ugly, how about a feature detection =20

mechanism?

quoted

[Sethi Varun-B16395] A feature mechanism to query the type of

IOMMU?

quoted

A feature mechanism to determine whether this subwindow =20

mechanism is

quoted

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 =20

windows

quoted

would be specified as a part of the geometry and the valid value =20

for

quoted

sub windows would  0,1 or actual number of sub windows.

How does a user of the interface find out what values are possible =20

for

quoted

the "actual number of subwindows"?  How does a user of the =20

interface find

quoted

out whether there are any limitations on specifying a value of zero =20

(in

quoted

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 =20
this what you get when you read the geometry (iommu_get_attr) after =20
initializing the domain? In that case the user would know that =20
implication of setting subwindows to zero with respect to the =20
aperture size.

So it would default to the maximum aperture size possible with no =20
subwindows?  That might be OK, though is there a way to reset the =20
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", =20
which the user can use to validate the attribute value. For example =20
in case of geometry, the user can fill up the structure and pass it =20
to the iommu driver in order to verify the aperture and subwindows =20
field.

Doesn't the current API raise an error if you do something =20
unsupported?  In any case I don't think making a series of guesses and =20
seeing which ones are accepted is a good substitute for being able to =20
simply read out the relevant parameters.

-Scott=

RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.

From: Sethi Varun-B16395 <hidden>
Date: 2012-12-11 04:50:34

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, December 11, 2012 6:31 AM
To: Sethi Varun-B16395
Cc: Wood Scott-B07421; Joerg Roedel; linux-kernel@vger.kernel.org;
iommu@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.
=20
On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote:

quoted

-----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-kernel@vger.kernel.org;
iommu@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;

Tabi

quoted

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:

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Monday, December 03, 2012 10:34 PM
To: Sethi Varun-B16395
Cc: Joerg Roedel; linux-kernel@vger.kernel.org;

iommu@lists.linux-

quoted

foundation.org; Wood Scott-B07421;

linuxppc-dev@lists.ozlabs.org;

quoted

Tabi

quoted

Timur-B04825
Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain

attributes

quoted

required by fsl PAMU driver.

On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote:

quoted

-----Original Message-----
From: iommu-bounces@lists.linux-foundation.org

[mailto:iommu-

quoted

quoted
quoted
quoted
quoted
bounces@lists.linux-foundation.org] On Behalf Of Joerg

Roedel

quoted

Sent: Sunday, December 02, 2012 7:33 PM
To: Sethi Varun-B16395
Cc: linux-kernel@vger.kernel.org;

iommu@lists.linux-foundation.org;

quoted

Wood

quoted

Scott-B07421; linuxppc-dev@lists.ozlabs.org; Tabi

Timur-B04825

quoted

Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain

attributes

quoted

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:

quoted

Added the following domain attributes required by FSL PAMU

driver:

quoted

1. Subwindows field added to the iommu domain geometry

attribute.

quoted

Are the Subwindows mapped with full size or do you map only

parts

quoted

of the

quoted

subwindows?

[Sethi Varun-B16395] It's possible to map a part of the

subwindow

quoted

i.e.

quoted

size of the mapping can be less than the sub window size.

quoted

+	 * This attribute indicates number of DMA subwindows

supported

quoted

by

quoted

+	 * the geometry. If there is a single window that maps

the

quoted

entire

quoted

+	 * geometry, attribute must be set to "1". A value of

"0"

quoted

implies

quoted

+	 * that this mechanism is not used at all(normal paging

is

quoted

used).

quoted

+	 * Value other than* "0" or "1" indicates the actual

number

quoted

of

quoted

+	 * subwindows.
+	 */

This semantic is ugly, how about a feature detection

mechanism?

quoted

[Sethi Varun-B16395] A feature mechanism to query the type of

IOMMU?

quoted

A feature mechanism to determine whether this subwindow

mechanism is

quoted

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

quoted

would be specified as a part of the geometry and the valid value

for

quoted

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

quoted

the "actual number of subwindows"?  How does a user of the

interface find

quoted

out whether there are any limitations on specifying a value of zero

(in

quoted

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.

=20
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?
=20

[Sethi Varun-B16395] Yes, that can be done via iommu_set_attr API.

How about finding out the maximum number of subwindows?

[Sethi Varun-B16395] We can introduce an API to determine the permissible r=
ange of values for an attribute, but it may be redundant for other IOMMU im=
plementations. For the IOMMU implementations where geometry is just a read =
only attribute, iommu_get_attr returns the set of permissible values. I thi=
nk it would be better if we can add a read only field (for the users) "max_=
subwindows" to the geometry.

-Varun

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help