All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Joel Stanley" <joel@jms.id.au>,
	qemu-block@nongnu.org, "Thomas Huth" <thuth@redhat.com>,
	qemu-arm@nongnu.org, jusual@mail.ru,
	"Laurent Vivier" <lvivier@redhat.com>,
	jim@groklearning.com,
	"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Kevin Wolf" <kwolf@redhat.com>, "Max Reitz" <mreitz@redhat.com>,
	"Steffen Görtz" <contrib@steffen-goertz.de>,
	"Richard Henderson" <rth@twiddle.net>,
	"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: [Qemu-devel] [PATCH v2 1/5] memory: add memory_region_flush_rom_device()
Date: Wed, 23 Jan 2019 21:22:30 +0000	[thread overview]
Message-ID: <20190123212234.32068-2-stefanha@redhat.com> (raw)
In-Reply-To: <20190123212234.32068-1-stefanha@redhat.com>

ROM devices go via MemoryRegionOps->write() callbacks for write
operations and do not dirty/invalidate that memory.  Device emulation
must be able to mark memory ranges that have been modified internally
(e.g. using memory_region_get_ram_ptr()).

Introduce the memory_region_flush_rom_device() API for this purpose.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 include/exec/memory.h | 18 ++++++++++++++++++
 exec.c                | 12 ++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index cd2f209b64..abe9cc79c0 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1344,6 +1344,24 @@ bool memory_region_snapshot_get_dirty(MemoryRegion *mr,
 void memory_region_reset_dirty(MemoryRegion *mr, hwaddr addr,
                                hwaddr size, unsigned client);
 
+/**
+ * memory_region_flush_rom_device: Mark a range of pages dirty and invalidate
+ *                                 TBs (for self-modifying code).
+ *
+ * The MemoryRegionOps->write() callback of a ROM device must use this function
+ * to mark byte ranges that have been modified internally, such as by directly
+ * accessing the memory returned by memory_region_get_ram_ptr().
+ *
+ * This function marks the range dirty and invalidates TBs so that TCG can
+ * detect self-modifying code.
+ *
+ * @mr: the region being flushed.
+ * @addr: the start, relative to the start of the region, of the range being
+ *        flushed.
+ * @size: the size, in bytes, of the range being flushed.
+ */
+void memory_region_flush_rom_device(MemoryRegion *mr, hwaddr addr, hwaddr size);
+
 /**
  * memory_region_set_readonly: Turn a memory region read-only (or read-write)
  *
diff --git a/exec.c b/exec.c
index 895449f926..105ff21e74 100644
--- a/exec.c
+++ b/exec.c
@@ -3162,6 +3162,18 @@ static void invalidate_and_set_dirty(MemoryRegion *mr, hwaddr addr,
     cpu_physical_memory_set_dirty_range(addr, length, dirty_log_mask);
 }
 
+void memory_region_flush_rom_device(MemoryRegion *mr, hwaddr addr, hwaddr size)
+{
+    /* In principle this function would work on other memory region types too,
+     * but the ROM device use case is the only one where this operation is
+     * necessary.  Other memory regions should use the
+     * address_space_read/write() APIs.
+     */
+    assert(memory_region_is_romd(mr));
+
+    invalidate_and_set_dirty(mr, addr, size);
+}
+
 static int memory_access_size(MemoryRegion *mr, unsigned l, hwaddr addr)
 {
     unsigned access_size_max = mr->ops->valid.max_access_size;
-- 
2.20.1

  reply	other threads:[~2019-01-23 21:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 21:22 [Qemu-devel] [PATCH v2 0/5] arm: microbit Non-Volatile Memory Controller Stefan Hajnoczi
2019-01-23 21:22 ` Stefan Hajnoczi [this message]
2019-01-23 21:22 ` [Qemu-devel] [PATCH v2 2/5] pflash: flush rom device memory region Stefan Hajnoczi
2019-01-24 11:11   ` Philippe Mathieu-Daudé
2019-01-25 10:28     ` Stefan Hajnoczi
2019-01-25 10:36       ` Peter Maydell
2019-01-25 15:37         ` Stefan Hajnoczi
2019-01-25 16:00           ` Philippe Mathieu-Daudé
2019-01-23 21:22 ` [Qemu-devel] [PATCH v2 3/5] hw/nvram/nrf51_nvm: Add nRF51 non-volatile memories Stefan Hajnoczi
2019-01-23 21:22 ` [Qemu-devel] [PATCH v2 4/5] arm: Instantiate NRF51 special NVM's and NVMC Stefan Hajnoczi
2019-01-23 21:22 ` [Qemu-devel] [PATCH v2 5/5] tests/microbit-test: Add tests for nRF51 NVMC Stefan Hajnoczi
2019-01-24  9:53   ` Thomas Huth
2019-01-24 13:38 ` [Qemu-devel] [PATCH v2 0/5] arm: microbit Non-Volatile Memory Controller Peter Maydell
2019-01-24 13:58   ` Peter Maydell

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=20190123212234.32068-2-stefanha@redhat.com \
    --to=stefanha@redhat.com \
    --cc=contrib@steffen-goertz.de \
    --cc=crosthwaite.peter@gmail.com \
    --cc=jim@groklearning.com \
    --cc=joel@jms.id.au \
    --cc=jusual@mail.ru \
    --cc=kwolf@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.