From: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH 0/3] IOMMU groups
Date: Tue, 10 Apr 2012 15:03:21 -0600 [thread overview]
Message-ID: <1334091801.3799.387.camel@bling.home> (raw)
In-Reply-To: <20120402203721.28977.95285.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
Ping. Does this approach look like it could satisfy your desire for a
more integrated group layer? I'd really like to move VFIO forward,
we've been stalled on this long enough. David Woodhouse, I think this
provides the quirking you're looking for for device like the Ricoh, do
you have any other requirements for a group layer? Thanks,
Alex
On Mon, 2012-04-02 at 15:14 -0600, Alex Williamson wrote:
> This series attempts to make IOMMU device grouping a slightly more
> integral part of the device model. iommu_device_groups were originally
> introduced to support the VFIO user space driver interface which needs
> to understand the granularity of device isolation in order to ensure
> security of devices when assigned for user access. This information
> was provided via a simple group identifier from the IOMMU driver allowing
> VFIO to walk devices and assemble groups itself.
>
> The feedback received from this was that groups should be the effective
> unit of work for the IOMMU API. The existing model of allowing domains
> to be created and individual devices attached ignores many of the
> restrictions of the IOMMU, whether by design, by topology or by defective
> devices. Additionally we should be able to use the grouping information
> at the dma ops layer for managing domains and quirking devices.
>
> This series is a sketch at implementing only those aspects and leaving
> everything else about the multifaceted hairball of Isolation groups for
> another API. Please comment and let me know if this seems like the
> direction we should be headed. Thanks,
>
> Alex
>
>
> ---
>
> Alex Williamson (3):
> iommu: Create attach/detach group interface
> iommu: Create basic group infrastructure and update AMD-Vi & Intel VT-d
> iommu: Introduce iommu_group
>
>
> drivers/iommu/amd_iommu.c | 50 ++++++----
> drivers/iommu/intel-iommu.c | 76 ++++++++--------
> drivers/iommu/iommu.c | 210 ++++++++++++++++++++++++++++++++++++++-----
> include/linux/device.h | 2
> include/linux/iommu.h | 43 +++++++++
> 5 files changed, 301 insertions(+), 80 deletions(-)
prev parent reply other threads:[~2012-04-10 21:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 21:14 [RFC PATCH 0/3] IOMMU groups Alex Williamson
[not found] ` <20120402203721.28977.95285.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-04-02 21:14 ` [RFC PATCH 1/3] iommu: Introduce iommu_group Alex Williamson
[not found] ` <20120402211440.28977.74440.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2012-04-18 9:58 ` David Gibson
[not found] ` <20120418095824.GB5387-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2012-04-18 20:07 ` Alex Williamson
2012-04-02 21:14 ` [RFC PATCH 2/3] iommu: Create basic group infrastructure and update AMD-Vi & Intel VT-d Alex Williamson
2012-04-18 11:55 ` David Gibson
[not found] ` <20120418115553.GC5387-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2012-04-18 20:28 ` Alex Williamson
2012-04-02 21:14 ` [RFC PATCH 3/3] iommu: Create attach/detach group interface Alex Williamson
2012-04-10 21:03 ` Alex Williamson [this message]
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=1334091801.3799.387.camel@bling.home \
--to=alex.williamson-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
/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 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).