[Qemu-devel] [patch] linux-user: problem with mmap_find_vma

[Qemu-devel] [patch] linux-user: problem with mmap_find_vma

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

With host x86_64 target alpha, a trivial recompile started producing 
"MMU faults".  Eventually, I determined that adding "-B 0x100000000" was 
enough to produce the fault with the original working executable.  I 
expect, but have not verified, that a similar failure can be elicited 
with any 64-bit host and any target using such a large explicit base.

The cause is that the default address used by mmap_find_vma may not be 
inside the area defined for use by the guest by GUEST_BASE.  Certainly 
this patch fixes the failure I was seeing.

I cannot see though all the macro ugliness to understand what happens 
when GUEST_BASE is not in use to know what needs happening there. 
Please feel free to edit the ??? comment to match reality.


r~

[-- Attachment #2: commit-find-vma --]
[-- Type: text/plain, Size: 1727 bytes --]

commit a85b499eabe5a71bb02305c2856c136590276edf
Author: Richard Henderson <rth@twiddle.net>
Date:   Sun Dec 13 20:00:39 2009 -0800

    linux-user: Adjust mmap_find_vma for guest_base.
    
    The definition of mmap_find_vma requires guest addresses as input
    to the START parameter.  However, when START==0 i.e. no preferred
    address, we use a value pre-defined value which may not be within
    the area defined by GUEST_BASE.  Make sure and adjust that value
    via g2h before using it.

diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 144fb7c..7e04c23 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -266,11 +266,13 @@ static int mmap_frag(abi_ulong real_start,
 
 #if defined(__CYGWIN__)
 /* Cygwin doesn't have a whole lot of address space.  */
-static abi_ulong mmap_next_start = 0x18000000;
+#define MMAP_FIRST_START 0x18000000
 #else
-static abi_ulong mmap_next_start = 0x40000000;
+#define MMAP_FIRST_START 0x40000000
 #endif
 
+static abi_ulong mmap_next_start;
+
 unsigned long last_brk;
 
 /*
@@ -288,8 +290,19 @@ abi_ulong mmap_find_vma(abi_ulong start, abi_ulong size)
     start &= qemu_host_page_mask;
 
     /* If 'start' == 0, then a default start address is used. */
-    if (start == 0)
+    if (start == 0) {
         start = mmap_next_start;
+        if (start == 0) {
+#ifdef CONFIG_USE_GUEST_BASE
+            mmap_next_start = start = (abi_ulong) g2h(MMAP_FIRST_START);
+#else
+            /* ??? What sort of host-guest remapping do we use for
+               when GUEST_BASE is not in use?  Presumably we can
+               simply map at any address we choose.  */
+            mmap_next_start = start = MMAP_FIRST_START;
+#endif
+        }
+    }
 
     addr = start;
 

Re: [Qemu-devel] [patch] linux-user: problem with mmap_find_vma

[Richard Henderson]

On 12/13/2009 08:14 PM, Richard Henderson wrote:
> With host x86_64 target alpha, a trivial recompile started producing
> "MMU faults". Eventually, I determined that adding "-B 0x100000000" was
> enough to produce the fault with the original working executable. I
> expect, but have not verified, that a similar failure can be elicited
> with any 64-bit host and any target using such a large explicit base.
>
> The cause is that the default address used by mmap_find_vma may not be
> inside the area defined for use by the guest by GUEST_BASE. Certainly
> this patch fixes the failure I was seeing.
>
> I cannot see though all the macro ugliness to understand what happens
> when GUEST_BASE is not in use to know what needs happening there. Please
> feel free to edit the ??? comment to match reality.

... Well, while I do think this patch is still a good idea,
since one hardly likes to see things like

   start_stack 0xffffffff04012000

it seems to simply have moved the MMU data fault around; it's back with 
the rest of the patch set applied.  :-(


r~