All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Stuart Yoder <b08248@gmail.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Alexey Kardashevskiy <aik@au1.ibm.com>,
	Joerg Roedel <joerg.roedel@amd.com>,
	Scott Wood <scottwood@freescale.com>,
	Alexander Graf <agraf@suse.de>,
	kvm@vger.kernel.org, iommu@lists.linux-foundation.org,
	varun.sethi@freescale.com
Subject: Re: RFC: extend iommu_ops with domain attributes API
Date: Thu, 12 Jan 2012 15:47:47 +0100	[thread overview]
Message-ID: <20120112144747.GA25119@8bytes.org> (raw)
In-Reply-To: <CALRxmdDFR0zFaBKHu-Wz750_KtV4TnRdhNhBDcGcSdigiSO4Tw@mail.gmail.com>

On Tue, Jan 10, 2012 at 10:22:36AM -0600, Stuart Yoder wrote:
> As we work on mapping the Freescale IOMMU (called PAMU) into the existing
> Linux iommu infrastructure, one issue is that we have additional domain
> attributes that need to be set.   This was discussed briefly a month ago
> or so and I believe there was a need for a similar mechanism by IBM.
> 
> We are proposing a couple of APIs to be added to iommu_ops to
> get/set domain attributes:
> 
>    int domain_set_attr(struct iommu_domain *domain, int attr_type, void *data);
>    int domain_get_attr(struct iommu_domain *domain, int attr_type, void *data);

Yes, something similar to that interface is required to support
GART-like IOMMUs too.
I prefer to split the attr-type into generic ones supported by many
IOMMU drivers and implementation specific ones required by your PAMU for
example.

> A couple of the attributes I'm considering PAMU specific with a generic
> enable attribute:
> 
>    enum iommu_attr_type {
>        IOMMU_ATTR_PAMU_GEOMETRY,       // the PAMU geometry for the domain

This should be a generic attribute. It makes sense for nearly all IOMMUs
to export geometry information.

>        IOMMU_ATTR_PAMU_STASH,          // stash characteristics for a domain

That one is fine.

>        IOMMU_ATTR_ENABLE

I do not get the need of this one. Can you explain why you need to
enable/disable a domain? What happens on the hardware side when you do
that?


	Joerg


  reply	other threads:[~2012-01-12 14:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 16:22 RFC: extend iommu_ops with domain attributes API Stuart Yoder
2012-01-12 14:47 ` Joerg Roedel [this message]
2012-01-12 16:41   ` Scott Wood
2012-01-12 21:28     ` Stuart Yoder
2012-01-12 17:14 ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120112144747.GA25119@8bytes.org \
    --to=joro@8bytes.org \
    --cc=agraf@suse.de \
    --cc=aik@au1.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=b08248@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=scottwood@freescale.com \
    --cc=varun.sethi@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.