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

[Paolo Bonzini <pbonzini@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 27/04/2013 11:49, David Gibson ha scritto:
>> 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.

Ah, thanks for teaching me.  It is indeed more convenient.

>>> 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.

Ok, knowing about changes that happen in the IOMMU mapping is indeed
out of scope of MemoryListeners.  What about adding a NotifierList?
Then VFIO can register a notifier and use it to learn about "events"
in the IOMMU mapping.  The notifier data can be a MemoryRegionSection
or IOMMUTableEntry, whatever you find more convenient.

Paolo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRe8HyAAoJEBvWZb6bTYbyZCwP+gMnSTE/zmzYWXQtnXgS5XrD
ezsOO55RfV6awehSa0ITGzuMzatn3DHakp0YAfcWJaz3cdFlAT+xWg4PNbw4yilJ
a/kFoG7sG4xXQD0bEkgZmHxyPHhKhSeKQfTUJ7FRjjEDWCDXo/5fLBX01tvKefYF
DPUKK7vQANyxfsUFzqN8qJHQ4cZoA209sILCbRXdAsPIj++sBx9TPQYDoCAGNFZd
OlB60yLXdwMlb1VrUlNbZOvdut8Ky6L1RfalKgKXyZnkCFssp02CKLaubyPw0WRk
8N7xjvojEnQb82Kk5hSfsVOdwZNO03GkjhcgtuBhk90Hw43fO7JhbPYCg32EvX1E
4SX+NbbL7WYFMVqe019zjKLQ4ZX5/TdUoMJo1TqtATHUyn4k7G0cWpO52p1tr/Iw
FN8l6kzOZH1H0DbBYyc+4ifFxBJ9WiWUDUKr+CJF4EhDxzcceC2aXXTLYOA9mD2Y
oMh4gDdwlelzXO4JuGYXSU/dG8cZ0HdGnCrUO5KgQJwSio/BkUece5ga8X3qUVdG
p/Z2ZCI2xMVv/IbPVR5vJtDkPIxOmnyjQKQrMDjv7EQSf8yrW3rMcqgnxVgZZoob
o96krNwAr5tQT2a9a/U2qne6ueVe0BxcqPkd+8n5ybh/YKzjWed2r1K2Oe4ZNved
a+Qi/12Z+Pv9zTZrMH37
=AtuM
-----END PGP SIGNATURE-----