From: Alvise Rigo <a.rigo@virtualopensystems.com>
To: qemu-devel@nongnu.org
Cc: mttcg@listserver.greensocs.com, claudio.fontana@huawei.com,
cota@braap.org, jani.kokkonen@huawei.com,
tech@virtualopensystems.com, alex.bennee@linaro.org,
rth@twiddle.net
Subject: [Qemu-devel] [RFC v2 2/7] exec: Add new exclusive bitmap to ram_list
Date: Mon, 15 Jun 2015 13:51:23 +0200 [thread overview]
Message-ID: <1434369088-15076-3-git-send-email-a.rigo@virtualopensystems.com> (raw)
In-Reply-To: <1434369088-15076-1-git-send-email-a.rigo@virtualopensystems.com>
The purpose of this new bitmap is to flag the memory pages that are in
the middle of LL/SC operations (after a LL, before a SC).
For all these pages, the corresponding TLB entries will be generated
in such a way to force the slow-path.
When the system starts, the whole memory is dirty (all the bitmap is
set). A page, after being marked as exclusively-clean, will *not* be
restored as dirty after the SC; the cputlb code will take care of that,
lazily setting the page as dirty when the TLB EXCL entry is about to be
overwritten.
The accessors to this bitmap are currently not atomic, but they have to
be so in a real multi-threading TCG.
Fix also one bracket alignment.
Suggested-by: Jani Kokkonen <jani.kokkonen@huawei.com>
Suggested-by: Claudio Fontana <claudio.fontana@huawei.com>
Signed-off-by: Alvise Rigo <a.rigo@virtualopensystems.com>
---
exec.c | 7 +++++--
include/exec/memory.h | 3 ++-
include/exec/ram_addr.h | 19 +++++++++++++++++++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index 487583b..79b2571 100644
--- a/exec.c
+++ b/exec.c
@@ -1430,11 +1430,14 @@ static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp)
int i;
/* ram_list.dirty_memory[] is protected by the iothread lock. */
- for (i = 0; i < DIRTY_MEMORY_NUM; i++) {
+ for (i = 0; i < DIRTY_MEMORY_NUM - 1; i++) {
ram_list.dirty_memory[i] =
bitmap_zero_extend(ram_list.dirty_memory[i],
old_ram_size, new_ram_size);
- }
+ }
+ ram_list.dirty_memory[DIRTY_MEMORY_EXCLUSIVE] =
+ bitmap_one_extend(ram_list.dirty_memory[i],
+ old_ram_size, new_ram_size);
}
cpu_physical_memory_set_dirty_range(new_block->offset,
new_block->used_length,
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 8ae004e..5ad6f20 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -19,7 +19,8 @@
#define DIRTY_MEMORY_VGA 0
#define DIRTY_MEMORY_CODE 1
#define DIRTY_MEMORY_MIGRATION 2
-#define DIRTY_MEMORY_NUM 3 /* num of dirty bits */
+#define DIRTY_MEMORY_EXCLUSIVE 3
+#define DIRTY_MEMORY_NUM 4 /* num of dirty bits */
#include <stdint.h>
#include <stdbool.h>
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index c113f21..f097f1b 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -21,6 +21,7 @@
#ifndef CONFIG_USER_ONLY
#include "hw/xen/xen.h"
+#include "qemu/bitmap.h"
ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
bool share, const char *mem_path,
@@ -249,5 +250,23 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(unsigned long *dest,
return num_dirty;
}
+/* Exclusive bitmap accessors. */
+static inline void cpu_physical_memory_set_excl_dirty(ram_addr_t addr)
+{
+ set_bit(addr >> TARGET_PAGE_BITS,
+ ram_list.dirty_memory[DIRTY_MEMORY_EXCLUSIVE]);
+}
+
+static inline int cpu_physical_memory_excl_is_dirty(ram_addr_t addr)
+{
+ return test_bit(addr >> TARGET_PAGE_BITS,
+ ram_list.dirty_memory[DIRTY_MEMORY_EXCLUSIVE]);
+}
+
+static inline void cpu_physical_memory_clear_excl_dirty(ram_addr_t addr)
+{
+ clear_bit(addr >> TARGET_PAGE_BITS,
+ ram_list.dirty_memory[DIRTY_MEMORY_EXCLUSIVE]);
+}
#endif
#endif
--
2.4.3
next prev parent reply other threads:[~2015-06-15 11:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 11:51 [Qemu-devel] [RFC v2 0/7] Slow-path for atomic instruction translation Alvise Rigo
2015-06-15 11:51 ` [Qemu-devel] [RFC v2 1/7] bitmap: Add bitmap_one_extend operation Alvise Rigo
2015-06-15 11:51 ` Alvise Rigo [this message]
2015-06-15 11:51 ` [Qemu-devel] [RFC v2 3/7] Add new TLB_EXCL flag Alvise Rigo
2015-06-15 11:51 ` [Qemu-devel] [RFC v2 4/7] softmmu: Add helpers for a new slow-path Alvise Rigo
2015-06-15 11:51 ` [Qemu-devel] [RFC v2 5/7] tcg-op: create new TCG qemu_ldlink and qemu_stcond instructions Alvise Rigo
2015-06-15 11:51 ` [Qemu-devel] [RFC v2 6/7] target-arm: translate: implement qemu_ldlink and qemu_stcond ops Alvise Rigo
2015-06-15 11:51 ` [Qemu-devel] [RFC v2 7/7] target-i386: " Alvise Rigo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1434369088-15076-3-git-send-email-a.rigo@virtualopensystems.com \
--to=a.rigo@virtualopensystems.com \
--cc=alex.bennee@linaro.org \
--cc=claudio.fontana@huawei.com \
--cc=cota@braap.org \
--cc=jani.kokkonen@huawei.com \
--cc=mttcg@listserver.greensocs.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=tech@virtualopensystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).