Re: [Qemu-devel] [PATCH 04/15] memory: MemoryRegion topology must be stable when updating

[liu ping fan]

On Wed, Aug 8, 2012 at 5:13 PM, Avi Kivity <address@hidden> wrote:
> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan <address@hidden>
>>
>> Using mem_map_lock to protect among updaters. So we can get the intact
>> snapshot of mem topology -- FlatView & radix-tree.
>>
>> Signed-off-by: Liu Ping Fan <address@hidden>
>> ---
>>  exec.c   |    3 +++
>>  memory.c |   22 ++++++++++++++++++++++
>>  memory.h |    2 ++
>>  3 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 8244d54..0e29ef9 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -210,6 +210,8 @@ static unsigned phys_map_nodes_nb, 
>> phys_map_nodes_nb_alloc;
>>     The bottom level has pointers to MemoryRegionSections.  */
>>  static PhysPageEntry phys_map = { .ptr = PHYS_MAP_NODE_NIL, .is_leaf = 0 };
>>
>> +QemuMutex mem_map_lock;
>> +
>>  static void io_mem_init(void);
>>  static void memory_map_init(void);
>>
>> @@ -637,6 +639,7 @@ void cpu_exec_init_all(void)
>>  #if !defined(CONFIG_USER_ONLY)
>>      memory_map_init();
>>      io_mem_init();
>> +    qemu_mutex_init(&mem_map_lock);
>>  #endif
>>  }
>>
>> diff --git a/memory.c b/memory.c
>> index aab4a31..5986532 100644
>> --- a/memory.c
>> +++ b/memory.c
>> @@ -761,7 +761,9 @@ void memory_region_transaction_commit(void)
>>      assert(memory_region_transaction_depth);
>>      --memory_region_transaction_depth;
>>      if (!memory_region_transaction_depth && memory_region_update_pending) {
>> +        qemu_mutex_lock(&mem_map_lock);
>>          memory_region_update_topology(NULL);
>> +        qemu_mutex_unlock(&mem_map_lock);
>>      }
>>  }
>
> Seems to me that nothing in memory.c can susceptible to races.  It must
> already be called under the big qemu lock, and with the exception of
> mutators (memory_region_set_*), changes aren't directly visible.
>
Yes, what I want to do is "prepare unplug out of protection of global
lock".  When io-dispatch and mmio-dispatch are all out of big lock, we
will run into the following scene:
    In vcpu context A, qdev_unplug_complete()-> delete subregion;
    In context B, write pci bar --> pci mapping update    -> add subregion

> I think it's sufficient to take the mem_map_lock at the beginning of
> core_begin() and drop it at the end of core_commit().  That means all
> updates of volatile state, phys_map, are protected.
>
The mem_map_lock is to protect both address_space_io and
address_space_memory. When without the protection of big lock,
competing will raise among the updaters
(memory_region_{add,del}_subregion and the readers
generate_memory_topology()->render_memory_region().

If just in core_begin/commit, we will duplicate it for
xx_begin/commit, right?  And at the same time, mr->subregions is
exposed under SMP without big lock.

Thanks and regards,
pingfan

>
>
> --
> error compiling committee.c: too many arguments to function