From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UW44t-0005YU-Vp for qemu-devel@nongnu.org; Sat, 27 Apr 2013 08:18:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UW44s-0000PN-QT for qemu-devel@nongnu.org; Sat, 27 Apr 2013 08:18:07 -0400 Received: from mail-bk0-x235.google.com ([2a00:1450:4008:c01::235]:62263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UW44s-0000PJ-FU for qemu-devel@nongnu.org; Sat, 27 Apr 2013 08:18:06 -0400 Received: by mail-bk0-f53.google.com with SMTP id jg9so2074735bkc.26 for ; Sat, 27 Apr 2013 05:18:05 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <517BC1F2.70405@redhat.com> Date: Sat, 27 Apr 2013 14:17:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1366956141-2066-1-git-send-email-david@gibson.dropbear.id.au> <1366956141-2066-4-git-send-email-david@gibson.dropbear.id.au> <517A398C.6030104@redhat.com> <20130426113121.GB4360@truffula.fritz.box> <517A83CE.2070505@redhat.com> <20130427094927.GC20202@truffula.fritz.box> In-Reply-To: <20130427094927.GC20202@truffula.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: aik@ozlabs.ru, alex.williamson@redhat.com, qemu-devel@nongnu.org -----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-----