From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX51C-0000Ip-Fl for qemu-devel@nongnu.org; Tue, 30 Apr 2013 03:30:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UX51A-0003Ns-Ug for qemu-devel@nongnu.org; Tue, 30 Apr 2013 03:30:30 -0400 Received: from mail-ee0-f50.google.com ([74.125.83.50]:61561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX51A-0003Nd-Ob for qemu-devel@nongnu.org; Tue, 30 Apr 2013 03:30:28 -0400 Received: by mail-ee0-f50.google.com with SMTP id b15so88704eek.23 for ; Tue, 30 Apr 2013 00:30:28 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <517F7304.1010205@redhat.com> Date: Tue, 30 Apr 2013 09:30:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <517A83CE.2070505@redhat.com> <20130427094927.GC20202@truffula.fritz.box> <517BC1F2.70405@redhat.com> <20130428015822.GE20202@truffula.fritz.box> <517E2B1A.8000209@redhat.com> <20130429110047.GL20202@truffula.fritz.box> <517E5B9E.1020006@redhat.com> <20130429115653.GQ20202@truffula.fritz.box> <517E794B.1060307@redhat.com> <20130430020539.GT20202@truffula.fritz.box> <20130430022329.GV20202@truffula.fritz.box> In-Reply-To: <20130430022329.GV20202@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 30/04/2013 04:23, David Gibson ha scritto: >>> I think this is a different problem. Basically the question is >>> "what happens if a MemoryRegion 'disappears' while an >>> AddressSpace is still referring to it", and the answer right >>> now is "badness". >> >> Well.. no. The same problem may well exist for AddressSpace >> objects, but in this case it's for the VFIO private >> per-address-space object. Well, once we clarify the lifetime of AddressSpaces, we can clarify the lifetime of the VFIO private object. >>> We should look at generic fixes before dropping hooks in the >>> code. At the very least an "assert(mr->parent == NULL);" is >>> missing in memory_region_destroy. >> >> Well, sure that's probably also a good idea. But the whole point >> here is you're insisting that the MemoryRegion code doesn't know >> about the vfio private data, even as an opaque handle, and so >> there's no possible assert we can put there to check it has been >> destroyed. > > Oh, yes, forgot to ask. I'm still unclear on what the conceptual > difference is supposed to between a MemoryRegion and an > AddressSpace. AFAICT AddressSpace seems to be roughly just a > wrapper on a MemoryRegion that gives it some more features. Yes, an AddressSpace is a wrapper for a MemoryRegion that has a NULL - ->parent, with two extra features: - - QEMU computes the "flat" view of the MemoryRegion and a compressed radix tree representation of that view - - MemoryListeners can ask to be called only for some AddressSpaces Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRf3MEAAoJEBvWZb6bTYbyRtEQAImxNNRh39bektv28FJ58hre XrEbck6PZZmJr2xARUrqdri4U8Dw/vXSJOyVWEfQWBvswDBImb6ATO3CcGGYztxS zxmget+Uobbd6ibtKU88JZP0w1WJV7Cn0oj//ylvp+I1DzCJpLRDZJLYMKMns28F KLvA9OTLXlExqEx3/qLc38rIPJ/OJmMqMgCmwNT8ba03wmvO9lSNjHsqi4Htg8Ml AnC29dfiLoNE4Zw+E/N9X7AeNaDvG2GJ52G9suJcd8fgkirEzOfwTqirxeEEGeDw oX7PX02yUuPMo5p6BeocqKFS5qgU9oMwSwSYSuy+0uMcoeBhLaVYXy1pRZDvIWVz b6hHSNc3TsgNlmi2hwYjJG/4ARngXvS1llNCvfNpuENAq3H2zH0DjpW5IHOrt9cv 97FPeWKzka2MqLUkdziGKyno2Tlgq10lfqF4TS85PhXgP66A4gtMo1XeZosCIYjX rGNoQuSnau/938H4Nkt3TAIGQZNypycPeIBXhDNQjFhKXrlLbQjdI5FCjs+3De83 AjEB4OqPEWJ2xeP9HefrEajLQB0T/MSGvoExZKBnFfFyqSv8a7MPZElSnLL6fJ4T /fj/ow3gBbDz4SnNg80FxxbZI8UOvxz3mUcCK8ogQiRBkYdp8M6lmA1rvO1FTafT f1eyeutVKUrfyanZfHy8 =yOML -----END PGP SIGNATURE-----