qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 01/11] memory: Sanity check that no listeners


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v5 01/11] memory: Sanity check that no listeners remain on a destroyed AddressSpace
Date: Thu, 27 Mar 2014 13:15:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

Il 27/03/2014 06:40, Alexey Kardashevskiy ha scritto:
On 03/20/2014 09:20 PM, Paolo Bonzini wrote:
Il 12/03/2014 06:52, Alexey Kardashevskiy ha scritto:
From: David Gibson <address@hidden>

At the moment, most AddressSpace objects last as long as the guest system
in practice, but that could well change in future.  In addition, for VFIO
we will be introducing some private per-AdressSpace information, which must
be disposed of before the AddressSpace itself is destroyed.

To reduce the chances of subtle bugs in this area, this patch adds
asssertions to ensure that when an AddressSpace is destroyed, there are no
remaining MemoryListeners using that AS as a filter.

Signed-off-by: David Gibson <address@hidden>
Signed-off-by: Alexey Kardashevskiy <address@hidden>
---
 memory.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/memory.c b/memory.c
index 3f1df23..678661e 100644
--- a/memory.c
+++ b/memory.c
@@ -1722,12 +1722,19 @@ void address_space_init(AddressSpace *as,
MemoryRegion *root, const char *name)

 void address_space_destroy(AddressSpace *as)
 {
+    MemoryListener *listener;
+
     /* Flush out anything from MemoryListeners listening in on this */
     memory_region_transaction_begin();
     as->root = NULL;
     memory_region_transaction_commit();
     QTAILQ_REMOVE(&address_spaces, as, address_spaces_link);
     address_space_destroy_dispatch(as);
+
+    QTAILQ_FOREACH(listener, &memory_listeners, link) {
+        assert(listener->address_space_filter != as);
+    }
+
     flatview_unref(as->current_map);
     g_free(as->name);
     g_free(as->ioeventfds);


Reviewed-by: Paolo Bonzini <address@hidden>


What happens next to this patch and the next one ("int128: add
int128_exts64()")? I mean who you expect to pull them? Alex Graf? :) Thanks.

Either him, or Alex Williamson.

Paolo




reply via email to

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