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