Re: [Qemu-devel] [PATCH] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets

[Paul Brook <paul@codesourcery.com>]

On Monday 08 December 2008, Kirill A. Shutemov wrote:
> On Wed, Dec 03, 2008 at 02:50:57PM +0200, Kirill A. Shutemov wrote:
> > On Wed, Dec 03, 2008 at 12:34:18PM +0000, Paul Brook wrote:
> > > On Wednesday 03 December 2008, Kirill A. Shutemov wrote:
> > > > qemu's page table can be incomple if /proc/self/maps is unavailable
> > > > or host allocating a memory with mmap(), so we can't use it to find
> > > > free memory area.
> > >
> > > Do we really care? Do such systems exist?
> >
> > I use qemu-arm to build packages in restricted environment -- in
> > hasher[1]. hasher mounts /proc only for packages that really need it for
> > building (java, for example).
> >
> > [1] http://en.altlinux.org/Hasher
>
> Paul, do you have any objection or not? I really want to see it into
> upstream.

My objection is that we're replacing a fairly deterministic code that 
maintains an address map with something that uses host mmap fairly 
aggressively to do probing. I'm not sure this is a good thing.

I'm a bit worried that we've now got a strange mix of code that "knows" which 
areas are available and code that does probing. I'm also a bit worried about 
the overhead of doing that probing.

> > One question I have though... What happens, if a start up script (ini
> > script) run in qemu linux-user changes /proc/sys/vm/mmap_min_addr from 0
> > to say 65536? Can this ever work, without later memory allocs with
> > mmap() failing?
>
> If I understood you correctly, it's one more reason for new
> mmap_find_vma(). I guess, it should work fine, but I haven't tested this
> case.

That's generally a different problem. Linux applications tend to be mapped at 
a fixed address (typically 0x8000 for ARM) If your host system has randomly 
decided to disallow this then you've much bigger problems..

Paul