[Qemu-devel] Qemu and mmap_min_addr

[Qemu-devel] Qemu and mmap_min_addr

[Jussi Hakala]

Depending on the setting of mmap_min_addr, the userspace qemu may just 
die with permission denied when trying to run a program with recent 
linux kernels.

The newest Ubuntu, Hardy Heron, ships with a default value of 65536 in 
/proc/sys/vm/mmap_min_addr which will cause the following problem (the 
test program is a simple hello world compiled for arm architecture).

$ sudo sh -c 'echo 65536 > /proc/sys/vm/mmap_min_addr'
$ qemu-arm ./a.out
mmap: Permission denied
$ sudo sh -c 'echo 32768 > /proc/sys/vm/mmap_min_addr'
$ qemu-arm ./a.out
hello world
$ qemu-arm -h
qemu-arm version 0.9.1, Copyright (c) 2003-2008 Fabrice Bellard
usage: qemu-arm [options] program [arguments...]
Linux CPU emulator (compiled for arm emulation)

The problem is present in every version of qemu I've tried, from 0.8.2 
to a quite recent cvs snapshot.

Seems that the problem is related to the mmap2 call and the first 
argument interpreted as a fixed address with MAP_FIXED flag set... 
here's an excerpt from strace for details:

mmap2(0x40000000, 528384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40000000
mprotect(0x40080000, 4096, PROT_NONE)   = 0
mmap2(0x8000, 434176, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = -1 EACCES (Permission denied)
dup(2)                                  = 4
fcntl64(4, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7f5f000
_llseek(4, 0, 0xbfe5bf48, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(4, "mmap: Permission denied\n", 24mmap: Permission denied
) = 24
close(4)                                = 0
munmap(0xb7f5f000, 4096)                = 0
exit_group(-1)                          = ?

So, basically I'm asking if this is an easy thing to fix, ie. if it's 
easy to increment the address value to begin with or if the MAP_FIXED 
can be somehow done away with...

Regards,

   Jussi

Re: [Qemu-devel] Qemu and mmap_min_addr

[Paul Brook]

> The newest Ubuntu, Hardy Heron, ships with a default value of 65536 in
> /proc/sys/vm/mmap_min_addr which will cause the following problem (the
> test program is a simple hello world compiled for arm architecture).

You have to use a nonzero GUEST_BASE to offset the guest VM.  However this 
hasn't been tested in a while, and has probably bitrotted.

Paul

Re: [Qemu-devel] Qemu and mmap_min_addr

[Jussi Hakala]

Paul Brook wrote:
> You have to use a nonzero GUEST_BASE to offset the guest VM.  However this 
> hasn't been tested in a while, and has probably bitrotted.

For preliminary testing, setting GUEST_BASE to 65536 seemed to work. 
I'll investigate further and report back to you :)

Thank you!

Regards,

   Jussi

Re: [Qemu-devel] Qemu and mmap_min_addr

[Jussi Hakala]

Celebrated too early.

My initial tests without the patch gave permission denied, and with the 
patch an error as expected (lenny's qemu not being able to run binaries 
generated by the cs2008q1 compiler).

Added some patches from [1], and tried running the hello world 
application again but with the GUEST_BASE being different from 0, the 
qemu seems just to hang when trying to mmap. CPU load is ~ 1.0 but 
nothing happens after mmap2() call [2].

Without the GUEST_BASE modification (and with a reasonably low 
mmap_min_addr), the binaries run just fine.

Regards,

   Jussi

[1]
http://qemu-arm-eabi.wiki.sourceforge.net/

[2]
mmap2(0x91000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x91000

Jussi Hakala wrote:
> Paul Brook wrote:
>> You have to use a nonzero GUEST_BASE to offset the guest VM.  However 
>> this hasn't been tested in a while, and has probably bitrotted.
> 
> For preliminary testing, setting GUEST_BASE to 65536 seemed to work. 
> I'll investigate further and report back to you :)

Re: [Qemu-devel] Qemu and mmap_min_addr

[Richard Purdie]

On Wed, 2008-04-30 at 16:31 +0300, Jussi Hakala wrote:
> Paul Brook wrote:
> > You have to use a nonzero GUEST_BASE to offset the guest VM.  However this 
> > hasn't been tested in a while, and has probably bitrotted.
> 
> For preliminary testing, setting GUEST_BASE to 65536 seemed to work. 
> I'll investigate further and report back to you :)

I was also looking at this problem and setting GUEST_BASE seemed to fix
my test cases although I've not tried it in a wider environment.

I was wondering if mismatching the host and guest memory layouts like
that incurred a performance penalty though?

Regards,

Richard