All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, Kumar Gala <kumar.gala@linaro.org>
Subject: [PATCH for-6.0 2/2] target/arm: Make M-profile VTOR loads on reset handle memory aliasing
Date: Fri, 12 Mar 2021 17:29:39 +0000	[thread overview]
Message-ID: <20210312172939.695-3-peter.maydell@linaro.org> (raw)
In-Reply-To: <20210312172939.695-1-peter.maydell@linaro.org>

For Arm M-profile CPUs, on reset the CPU must load its initial PC and
SP from a vector table in guest memory.  Because we can't guarantee
reset ordering, we have to handle the possibility that the ROM blob
loader's reset function has not yet run when the CPU resets, in which
case the data in an ELF file specified by the user won't be in guest
memory to be read yet.

We work around the reset ordering problem by checking whether the ROM
blob loader has any data for the address where the vector table is,
using rom_ptr().  Unfortunately this does not handle the possibility
of memory aliasing.  For many M-profile boards, memory can be
accessed via multiple possible physical addresses; if the board has
the vector table at address X but the user's ELF file loads data via
a different address Y which is an alias to the same underlying guest
RAM then rom_ptr() will not find it.

Handle the possibility of aliasing by iterating through the whole
FlatView of the CPU's address space checking for other mappings of
the MemoryRegion corresponding to the location of the vector table.
If we find any aliases we use rom_ptr() to see if the ROM blob loader
has any data there.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 target/arm/cpu.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index ae04884408c..aac78ae6623 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -161,6 +161,72 @@ static void cp_reg_check_reset(gpointer key, gpointer value,  gpointer opaque)
     assert(oldvalue == newvalue);
 }
 
+#ifndef CONFIG_USER_ONLY
+typedef struct FindRomCBData {
+    size_t size; /* Amount of data we want from ROM, in bytes */
+    MemoryRegion *mr; /* MR at the unaliased guest addr */
+    hwaddr xlat; /* Offset of addr within mr */
+    uint8_t *rom; /* Output: rom data pointer, if found */
+} FindRomCBData;
+
+static int find_rom_cb(Int128 start, Int128 len, const MemoryRegion *mr,
+                       hwaddr offset_in_region, void *opaque)
+{
+    FindRomCBData *cbdata = opaque;
+    hwaddr alias_addr;
+
+    if (mr != cbdata->mr) {
+        return 0;
+    }
+
+    alias_addr = int128_get64(start) + cbdata->xlat - offset_in_region;
+    cbdata->rom = rom_ptr(alias_addr, cbdata->size);
+    if (!cbdata->rom) {
+        return 0;
+    }
+    /* Found a match, stop iterating */
+    return 1;
+}
+
+static uint8_t *find_rom_for_addr(AddressSpace *as, hwaddr addr, size_t size)
+{
+    /*
+     * Find any ROM data for the given guest address range.  If there
+     * is a ROM blob then return a pointer to the host memory
+     * corresponding to 'addr'; otherwise return NULL.
+     *
+     * This is like rom_ptr(), except that it handles possible aliases
+     * within the CPU's address space, so that we still find a ROM
+     * blob even if it was loaded to an address that aliases addr
+     * rather than to addr itself.
+     */
+    FlatView *fv;
+    uint8_t *rom;
+    hwaddr len_unused;
+    FindRomCBData cbdata = {};
+
+    /* Easy case: there's data at the actual address */
+    rom = rom_ptr(addr, size);
+    if (rom) {
+        return rom;
+    }
+
+    RCU_READ_LOCK_GUARD();
+
+    fv = address_space_to_flatview(as);
+    cbdata.mr = flatview_translate(fv, addr, &cbdata.xlat, &len_unused,
+                                   false, MEMTXATTRS_UNSPECIFIED);
+    if (!cbdata.mr) {
+        /* Nothing at this address, so there can't be any aliasing */
+        return NULL;
+    }
+
+    cbdata.size = size;
+    flatview_for_each_range(fv, find_rom_cb, &cbdata);
+    return cbdata.rom;
+}
+#endif
+
 static void arm_cpu_reset(DeviceState *dev)
 {
     CPUState *s = CPU(dev);
@@ -331,7 +397,7 @@ static void arm_cpu_reset(DeviceState *dev)
 
         /* Load the initial SP and PC from offset 0 and 4 in the vector table */
         vecbase = env->v7m.vecbase[env->v7m.secure];
-        rom = rom_ptr(vecbase, 8);
+        rom = find_rom_for_addr(s->as, vecbase, 8);
         if (rom) {
             /* Address zero is covered by ROM which hasn't yet been
              * copied into physical memory.
-- 
2.20.1



  parent reply	other threads:[~2021-03-12 18:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 17:29 [PATCH for-6.0 0/2] arm: Make M-profile VTOR loads on reset handle memory aliasing Peter Maydell
2021-03-12 17:29 ` [PATCH for-6.0 1/2] memory: Add offset_in_region to flatview_cb arguments Peter Maydell
2021-03-12 20:09   ` Philippe Mathieu-Daudé
2021-03-12 17:29 ` Peter Maydell [this message]
2021-03-12 20:17   ` [PATCH for-6.0 2/2] target/arm: Make M-profile VTOR loads on reset handle memory aliasing Philippe Mathieu-Daudé
2021-03-13 19:03     ` Richard Henderson
2021-03-18 17:14     ` Peter Maydell
2021-03-12 18:59 ` [PATCH for-6.0 0/2] arm: " Peter Maydell
2021-03-13 19:05   ` Richard Henderson
2021-03-13 19:41     ` 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=20210312172939.695-3-peter.maydell@linaro.org \
    --to=peter.maydell@linaro.org \
    --cc=kumar.gala@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.