qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for 6.2 38/49] bsd-user: Update mapping to handle reserved an


From: Richard Henderson
Subject: Re: [PATCH for 6.2 38/49] bsd-user: Update mapping to handle reserved and starting conditions
Date: Tue, 10 Aug 2021 06:27:31 -1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 8/7/21 11:42 AM, Warner Losh wrote:
From: Warner Losh <imp@FreeBSD.org>

Update the reserved base based on what platform we're on, as well as the
start of the mmap range. Update routines that find va ranges to interact
with the reserved ranges as well as properly align the mapping (this is
especially important for targets whose page size does not match the
host's). Loop where appropriate when the initial address space offered
by mmap does not meet the contraints.

Signed-off-by: Mikaƫl Urankar <mikael.urankar@gmail.com>
Signed-off-by: Stacey Son <sson@FreeBSD.org>
Signed-off-by: Warner Losh <imp@bsdimp.com>
---
  bsd-user/main.c |  23 ++-
  bsd-user/mmap.c | 372 ++++++++++++++++++++++++++++++++++++++++--------
  bsd-user/qemu.h |   5 +-
  3 files changed, 335 insertions(+), 65 deletions(-)

diff --git a/bsd-user/main.c b/bsd-user/main.c
index 93ef9298b8..36852604f8 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -49,12 +49,29 @@
  #include "target_arch_cpu.h"
int singlestep;
-unsigned long mmap_min_addr;
  uintptr_t guest_base;
  static const char *cpu_model;
  static const char *cpu_type;
  bool have_guest_base;
+#if (TARGET_LONG_BITS == 32) && (HOST_LONG_BITS == 64)
+/*
+ * When running 32-on-64 we should make sure we can fit all of the possible
+ * guest address space into a contiguous chunk of virtual host memory.
+ *
+ * This way we will never overlap with our own libraries or binaries or stack
+ * or anything else that QEMU maps.
+ */
+# ifdef TARGET_MIPS
+/* MIPS only supports 31 bits of virtual address space for user space */
+unsigned long reserved_va = 0x77000000;
+# elif defined(TARGET_PPC64)
+unsigned long reserved_va = 0xfffff000;
+# else
+unsigned long reserved_va = 0xf7000000;
+# endif
+#else
  unsigned long reserved_va;
+#endif

All of these 7's look to be copying an old linux-user bug.
I cleaned this up in 18e80c55bb6.

Otherwise,
Acked-by: Richard Henderson <richard.henderson@linaro.org>

I would hope one day this memory management could be shared between the user-only implementations. It's complicated enough...


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]