[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings
From: |
Joerg Roedel |
Subject: |
Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings |
Date: |
Wed, 24 Aug 2011 11:10:35 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Aug 23, 2011 at 01:33:14PM -0400, Aaron Fabbri wrote:
> On 8/23/11 10:01 AM, "Alex Williamson" <address@hidden> wrote:
> > The iommu domain would probably be allocated when the first device is
> > bound to vfio. As each device is bound, it gets attached to the group.
> > DMAs are done via an ioctl on the group.
> >
> > I think group + uiommu leads to effectively reliving most of the
> > problems with the current code. The only benefit is the group
> > assignment to enforce hardware restrictions. We still have the problem
> > that uiommu open() = iommu_domain_alloc(), whose properties are
> > meaningless without attached devices (groups). Which I think leads to
> > the same awkward model of attaching groups to define the domain, then we
> > end up doing mappings via the group to enforce ordering.
>
> Is there a better way to allow groups to share an IOMMU domain?
>
> Maybe, instead of having an ioctl to allow a group A to inherit the same
> iommu domain as group B, we could have an ioctl to fully merge two groups
> (could be what Ben was thinking):
>
> A.ioctl(MERGE_TO_GROUP, B)
>
> The group A now goes away and its devices join group B. If A ever had an
> iommu domain assigned (and buffers mapped?) we fail.
>
> Groups cannot get smaller (they are defined as minimum granularity of an
> IOMMU, initially). They can get bigger if you want to share IOMMU
> resources, though.
>
> Any downsides to this approach?
As long as this is a 2-way road its fine. There must be a way to split
the groups again after the guest exits. But then we are again at the
super-groups (aka meta-groups, aka uiommu) point.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, (continued)
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, aafabbri, 2011/08/22
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Benjamin Herrenschmidt, 2011/08/22
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, aafabbri, 2011/08/22
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Benjamin Herrenschmidt, 2011/08/22
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, aafabbri, 2011/08/22
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Benjamin Herrenschmidt, 2011/08/23
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Joerg Roedel, 2011/08/23
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Alex Williamson, 2011/08/23
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Aaron Fabbri, 2011/08/23
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Alex Williamson, 2011/08/23
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings,
Joerg Roedel <=
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Alex Williamson, 2011/08/24
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Roedel, Joerg, 2011/08/25
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Don Dutile, 2011/08/25
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Roedel, Joerg, 2011/08/25
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Alex Williamson, 2011/08/25
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Joerg Roedel, 2011/08/25
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Alex Williamson, 2011/08/26
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Joerg Roedel, 2011/08/30
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, Joerg Roedel, 2011/08/23
- Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings, aafabbri, 2011/08/23