iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
* RFC: additional domain attributes specific to PAMU
@ 2013-02-05  3:37 Stuart Yoder
       [not found] ` <CALRxmdChbSk1gLXc2pqVd0GPdM09SofyjA5L_KuvSn4SQZJoXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Stuart Yoder @ 2013-02-05  3:37 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Varun Sethi, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Joerg,

The attributes you have defined look good and are mechanisms we need
to determine if iommu is aperture based, get max # of windows, set
actual number of windows, etc.

However, there are a couple of other attributes we need:

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 8330df1..0038c39 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -61,6 +61,8 @@ enum iommu_attr {
        DOMAIN_ATTR_GEOMETRY,
        DOMAIN_ATTR_PAGING,
        DOMAIN_ATTR_WINDOWS,
+       DOMAIN_ATTR_ENABLE,
+       DOMAIN_ATTR_FSL_PAMUV1,
        DOMAIN_ATTR_MAX,
 };

We need a mechanism to enable/disable the overall aperture, and that
is what DOMAIN_ATTR_ENABLE is for.   After everything is configured we
enable the overall aperture...and can't do it before.

There are a lot of quirky, very specific constraints that apply to
PAMU only (most likely) and may not be generic.   Here are the ones I
can think of:
   -aperture must be power of 2, and naturally aligned
   -number of windows must be power of 2, and address space size
    of each window is determined by aperture size / # of windows
   -the actual size of the mapped region of a window must be power
    of 2 starting with 4KB and physical address must be
    naturally aligned

Instead of advertising those constraints somehow, it seem easier just
to advertise that this IOMMU is a PAMU v1.  The attribute would be
read only and would be a boolean--  if the attribute is present then
it's a PAMU v1.

Wanted to get your thoughts on that.

Thanks,
Stuart

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: RFC: additional domain attributes specific to PAMU
       [not found] ` <CALRxmdChbSk1gLXc2pqVd0GPdM09SofyjA5L_KuvSn4SQZJoXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2013-02-05 10:35   ` Joerg Roedel
  0 siblings, 0 replies; 2+ messages in thread
From: Joerg Roedel @ 2013-02-05 10:35 UTC (permalink / raw)
  To: Stuart Yoder
  Cc: Varun Sethi, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Hi Stuart,

On Mon, Feb 04, 2013 at 09:37:20PM -0600, Stuart Yoder wrote:
> +       DOMAIN_ATTR_ENABLE,
> +       DOMAIN_ATTR_FSL_PAMUV1,
> Instead of advertising those constraints somehow, it seem easier just
> to advertise that this IOMMU is a PAMU v1.  The attribute would be
> read only and would be a boolean--  if the attribute is present then
> it's a PAMU v1.

> [...]

> Wanted to get your thoughts on that.

Sounds reasonable. Just put PAMU into the name of the attributes to make
clear these attributes are specific to your implementation and implement
the attributes in the PAMU specific get/set_attr call-backs. This is
particularily true for DOMAIN_ATTR_ENABLE (or better
DOMAIN_ATTR_PAMU_ENABLE). We can also go with DOMAIN_ATTR_FSL_PAMUV1 for
now, but a more generic way of determining the IOMMU type might make
sense. But this can be changed later.

Regards,

	Joerg

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-02-05 10:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-05  3:37 RFC: additional domain attributes specific to PAMU Stuart Yoder
     [not found] ` <CALRxmdChbSk1gLXc2pqVd0GPdM09SofyjA5L_KuvSn4SQZJoXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-05 10:35   ` Joerg Roedel

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).