[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] linux-user mmap bug
From: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] linux-user mmap bug |
Date: |
Tue, 25 May 2010 11:19:11 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Mon, May 24, 2010 at 08:45:31AM -0700, Richard Henderson wrote:
> On 05/24/2010 07:57 AM, Edgar E. Iglesias wrote:
> > I took a look at the code again and I dont really understand how the
> > particular case when we get a high address from the kernel while
> > mmap_min_addr is busy case is supposed to work :/
> > In fact, for CRIS it never works on my host.
>
> Indeed, there are many cases for which it doesn't work for the Alpha
> target either.
Ye, what puzzled me was that if I am not completely senile, CRIS apps
used to emulate on my x86_64 host not so long ago :)
> > I changed it locally to keep scanning after a wrap until we succeed to
> > allocate a chunk or rewrap (SLOW) but at least I can run dynamically
> > linked CRIS programs again.
>
> Yep. My hack had been similar, except that I used the PageDesc tree
> to help speed things up. But PageDesc is hardly an ideal data structure
> in which to search, since it quickly devolves into a linear search of
> the address space.
>
> Probably the easiest real fix is to re-read /proc/self/maps each time
> the mmap_next_start guess fails and the kernel's returned address is
> out of range.
>
> Another is using the MMAP_32BIT flag on x86-64 host whenever a 31-bit
> address is appropriate for the guest. E.g. mips32, where architecturally
> the high half of the address space is reserved for kernel mode.
MAP_32BIT sounds good as long as guest_base is not used. When used I
guess we'd need to fallback to something else anyway..
Maybe these issues are something too look more at during the bug day? :)
In the meantime, I've patched the cris git to use the MAP_32BIT and
to fallback to a super ugly and slow linear scan..
Thanks again for the help,
Cheers
> See
> http://www.mail-archive.com/address@hidden/msg28924.html
> for more ideas on the subject.
>
>
>
> r~