Quoting Paolo Bonzini (2015-02-11 01:30:00)
On 11/02/2015 06:13, Michael Roth wrote:
(gdb) print node
$1 = (struct rcu_head *) 0x11189a68
(gdb) print node-func
$2 = (RCUCBFunc *) 0x0
(gdb) print node-next
$3 = (struct rcu_head *) 0x3fff9800d4f0
I've seen it on both x86 and
On 11/02/2015 14:16, Michael Roth wrote:
Since the AddressSpace is a fields of PCIDevice, do we maybe need to make
sure it's refcount doesn't drop to 0 prior to the RCU callback taking
place?
Yes, but then the problem is that objects are finalized outside the big
QEMU lock.
This is a pretty
On Tue, 2015-02-10 at 13:52 +0100, Paolo Bonzini wrote:
address_space_destroy_dispatch is called from an RCU callback and hence
outside the iothread mutex (BQL). However, after address_space_destroy
no new accesses can hit the destroyed AddressSpace so it is not necessary
to observe changes
On Tue, 2015-02-10 at 18:13 +0100, Paolo Bonzini wrote:
On 10/02/2015 18:11, Alex Williamson wrote:
Reported-by: Alex Williamson alex.william...@redhat.com
Fixes: 374f2981d1f10bc4307f250f24b2a7ddb9b14be0
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
exec.c
On 10/02/2015 18:11, Alex Williamson wrote:
Reported-by: Alex Williamson alex.william...@redhat.com
Fixes: 374f2981d1f10bc4307f250f24b2a7ddb9b14be0
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
exec.c | 6 +-
include/exec/memory-internal.h | 1 +
On 11/02/2015 06:13, Michael Roth wrote:
(gdb) print node
$1 = (struct rcu_head *) 0x11189a68
(gdb) print node-func
$2 = (RCUCBFunc *) 0x0
(gdb) print node-next
$3 = (struct rcu_head *) 0x3fff9800d4f0
I've seen it on both x86 and pseries (with spapr hotplug patches applied), and
have
Quoting Paolo Bonzini (2015-02-10 06:52:49)
address_space_destroy_dispatch is called from an RCU callback and hence
outside the iothread mutex (BQL). However, after address_space_destroy
no new accesses can hit the destroyed AddressSpace so it is not necessary
to observe changes to the memory
address_space_destroy_dispatch is called from an RCU callback and hence
outside the iothread mutex (BQL). However, after address_space_destroy
no new accesses can hit the destroyed AddressSpace so it is not necessary
to observe changes to the memory map. Move the memory_listener_unregister
call
