Re: [Qemu-devel] [PATCH v1 2/2] reduce qemu's heap Rss size from 12252kB to 2752KB

[Xu, Anthony]

> So please send it to the list with Signed-off-by line.
Thanks, 

> 
>             DPRINTF("handle_mmio\n");
>             /* Called outside BQL */
>             address_space_rw(&address_space_memory,
>                              run->mmio.phys_addr, attrs,
>                              run->mmio.data,
>                              run->mmio.len,
>                              run->mmio.is_write);
> 
> and adding a simple assert() would have quickly disproved your theory.
You are right here.
If it is a PCI bar write, a memory region operation(del/add) may 
be called inside address_space_rw, and 
memory_region_transaction_commit will be called.
If address_space_rw is called  without the global lock, 
memory_region_transaction_commit is called with the global lock.
 It conflicts with what you said before.

>No, you don't need to check it.  Most functions (in this case,
>memory_region_transaction_commit) can only be called under the global lock.

And if two vcpus program the different PCI bars at the same time 
(it is unlikely, but QEMU should not assume it), without the global lock, 
region operations may be called at the same time. 
Are memory_region_del_subregion and 
memory_region_add_subregion_overlap thread-safe?

> It's not a fix if the code is not thread-safe anymore!  But I think you
> have the answer now as to why you cannot use synchronize_rcu.

Can you elaborate why the code is not thread-safe?

Thanks
Anthony