From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:40338)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <b08248@gmail.com>) id 1RYJpV-0003z6-QB
	for qemu-devel@nongnu.org; Wed, 07 Dec 2011 10:54:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <b08248@gmail.com>) id 1RYJpR-0000GO-0T
	for qemu-devel@nongnu.org; Wed, 07 Dec 2011 10:54:45 -0500
Received: from mail-qw0-f52.google.com ([209.85.216.52]:61464)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <b08248@gmail.com>) id 1RYJpQ-0000Fo-US
	for qemu-devel@nongnu.org; Wed, 07 Dec 2011 10:54:40 -0500
Received: by qadc11 with SMTP id c11so523397qad.4
	for <qemu-devel@nongnu.org>; Wed, 07 Dec 2011 07:54:39 -0800 (PST)
MIME-Version: 1.0
Date: Wed, 7 Dec 2011 09:54:39 -0600
Message-ID: <CALRxmdDS4qas9fyHXeDVw2e_yMCTqzMi6VXUF-q+eYwgMwg7tw@mail.gmail.com>
From: Stuart Yoder <b08248@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] vfio / iommu domain attributes
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alex Williamson <alex.williamson@redhat.com>, Alexey Kardashevskiy <aik@au1.ibm.com>
Cc: chrisw@sous-sol.org, kvm@vger.kernel.org, konrad.wilk@oracle.com, joerg.roedel@amd.com, pmac@au1.ibm.com, qemu-devel@nongnu.org, agraf@suse.de, aafabbri@cisco.com, B08248@freescale.com, iommu@lists.linux-foundation.org, avi@redhat.com, David Gibson <david@gibson.dropbear.id.au>, linux-pci@vger.kernel.org, dwg@au1.ibm.com, B07421@freescale.com, benve@cisco.com

In the vfio RFC thread there seemed to be convergence that some new
iommu_ops API is needed to set some platform specific aspects of an
iommu domain.

On Wed, Nov 30, 2011 at 10:58 AM, Alex Williamson
<alex.williamson@redhat.com> wrote:
[cut]
> In that case, you should definitely be following what Alexey is thinking
> about with an iommu_setup IOMMU API callback.  I think it's shaping up
> to do:
>
> x86:
>  - Report any IOVA range restrictions imposed by hw implementation
> POWER:
>  - Request IOVA window size, report size and base
> powerpc:
>  - Set domain attributes, probably report range as well.

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
    -domain enable/disable
    -number of subwindows
    -operation mapping table index
    -stash destination CPU
    -stash target (cache=96 L1, L2, L3)

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 po=
inter
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);
    }

Whatever this API winds up looking like it needs to be reflected in
the vfio interface to user space as well.

Thanks,
Stuart