linux-kernel - Re: [RFC PATCH 0/3] IOMMU groups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1334091801.3799.387.camel@bling.home>
Date:	Tue, 10 Apr 2012 15:03:21 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	david@...son.dropbear.id.au, dwmw2@...radead.org
Cc:	iommu@...ts.linux-foundation.org, qemu-devel@...gnu.org,
	joerg.roedel@....com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] IOMMU groups


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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/