| Message ID | 4B25BBB8.5070807@twiddle.net |
|---|---|
| State | New |
| Headers | show |
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~
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;
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~ 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.