qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion
Date: Sat, 27 Apr 2013 19:49:27 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Apr 26, 2013 at 03:40:30PM +0200, Paolo Bonzini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 26/04/2013 13:31, David Gibson ha scritto:
> >> 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.
> 
> There's no fundamental reason for VFIO to use multiple
> MemoryListeners.  It could use one for all VFIO instances.

Actually, there kind of is.  Using a new listener for each new
container means the listener framework automatically invokes callbacks
for all the existing reasons, allowing us to map them into the
container.  With a single listener, we'd have to manually write logic
to map all the existing mappings into each new container.

> > 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.
> 
> Why?  All you want here is to look for appearance of an IOMMU
> MemoryRegion in the flat representation of the AddressSpace.  That's
> exactly what the MemoryListener does---of course that's a different
> MemoryListener implementation than VFIO's current one.
> 
> The MemoryListener is used for a lot of different things, I find it
> hard to believe that this is not a variation on one of them.

Uh.. so, yes we might actually want a memorylistener to watch for
appearance of iommu regions, if there are memoryregion layers between
us and the iommu region itself.

But the point remains that from the code which implements the guest
side IOMMU we have to somehow invoke a hook which will make parallel
mappings in the vfio container.  That will need to go from the iommu
code's handle on the address space - a MemoryRegion - to vfio's handle
on the address space, the vfio container.  I don't see a way to do
that without having a vfio private pointer in the memoryregion, that
isn't much uglier than that minor encapsulation breach.

-- 
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: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]