> 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
