Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Fri, Apr 26, 2013 at 10:23:40AM +0200, Paolo Bonzini wrote:
> Il 26/04/2013 08:02, David Gibson ha scritto:
> > At the moment, vfio maintains a global list of containers that are assumed
> > to be more or less interchangeable, since they are all set up with a
> > MemoryListener to have all of system memory mapped.  However, that only
> > makes sense if all the containers are used on devices which really do
> > expect a dma address space identical to system memory.
> > 
> > This patch moves towards that by making the list of containers per
> > MemoryRegion (which corresponds to a dma address space) instead of global.
> 
> This is the same violation of encapsulation that Alex pointed out in
> v1.

As I said in response to that, I can't see any way to avoid this that
isn't much uglier.  Fundamentally we need to associate the in-kernel
notion of an address space (the vfio container) with the qemu object.
Adding a opaque pointer to the MemoryRegion seems a lot cleaner than
having some data structure in the vfio code that's indexed by
MemoryRegion.

>  You need to add this capability to VFIO's MemoryListener (either the
> one that's already there, or a new one), looking for IOMMU regions in
> the region_add callback.

Putting it in the MemoryListener doesn't work.  First, there could be
multiple listeners if there are multiple containers attached to the
MemoryRegion - the information we have here needs to be per
MemoryRegion.  More importantly, what I'm working towards here is
vfio support for guest visible IOMMUs that don't have all of guest RAM
mapped into them initially.  In that case there won't (and can't) be
any MemoryListener at all.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]