[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 04/15] memory: MemoryRegion topology must be sta
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [PATCH 04/15] memory: MemoryRegion topology must be stable when updating |
Date: |
Wed, 08 Aug 2012 12:13:26 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 |
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.
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.
--
error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, (continued)
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, Avi Kivity, 2012/08/08
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, Paolo Bonzini, 2012/08/08
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, Avi Kivity, 2012/08/08
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, liu ping fan, 2012/08/09
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, Paolo Bonzini, 2012/08/09
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, Avi Kivity, 2012/08/09
- Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, liu ping fan, 2012/08/10
Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj, Paolo Bonzini, 2012/08/08
[Qemu-devel] [PATCH 04/15] memory: MemoryRegion topology must be stable when updating, Liu Ping Fan, 2012/08/08
Re: [Qemu-devel] [PATCH 04/15] memory: MemoryRegion topology must be stable when updating, Blue Swirl, 2012/08/08
[Qemu-devel] [PATCH 05/15] memory: introduce life_ops to MemoryRegion, Liu Ping Fan, 2012/08/08
[Qemu-devel] [PATCH 06/15] memory: use refcnt to manage MemoryRegion, Liu Ping Fan, 2012/08/08