[Qemu-devel] Is mips-user broken on 64bit host?

[Qemu-devel] Is mips-user broken on 64bit host?

[Michael Tokarev]

Since at least 1.1 version of qemu, I can't run any
mips binary using statically linked qemu-mips on x86_64
host.  It immediately fails with SIGSEGV:

# chroot mipsroot /bin/bash
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

mipsroot/bin/bash: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV),
 dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
 BuildID[sha1]=0xeb1a3595d733e28f4f081beabb1f135bc5bf7527,
 with unknown capability 0x41000000 = 0xf676e75,
 with unknown capability 0x10000 = 0x70401,
 stripped

(this is current Debian install of mips architecture).

At the same time, 32bit qemu-mips works just fine:


# cp -p /usr/bin/qemu-mips-static-32 mipsroot/usr/bin/
# chroot mipsroot /bin/bash
I have no name!@gandalf:/# ls
bin   dev  home  lib64	proc  run   selinux  tmp  var
boot  etc  lib	 mnt	root  sbin  sys      usr
I have no name!@gandalf:/# uname -a
Linux gandalf 3.2.0-amd64 #3.2.30 SMP Thu Sep 20 18:50:45 MSK 2012 mips GNU/Linux

Current qemu git behaves the same - it also segfaults
when trying to run a 32bit mips binary from x86_64
host qemu-mips binary.

There are numerous bugreports about this issue on Debian
as well.

Is it just Debian, or is something really broken there?
I'd think that running 32bit mips code on x86_64 host
is quite common, no?

(Cc'ing Aurelien for this one)

Thanks,

/mjt

[Qemu-devel] (bisected): Is mips-user broken on 64bit host since v1.1?

[Michael Tokarev]

On 18.12.2012 20:10, Michael Tokarev wrote:
> Since at least 1.1 version of qemu, I can't run any
> mips binary using statically linked qemu-mips on x86_64
> host.  It immediately fails with SIGSEGV:
> 
> # chroot mipsroot /bin/bash
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> 
> mipsroot/bin/bash: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV),
>  dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
>  BuildID[sha1]=0xeb1a3595d733e28f4f081beabb1f135bc5bf7527,
>  with unknown capability 0x41000000 = 0xf676e75,
>  with unknown capability 0x10000 = 0x70401,
>  stripped
> 
> (this is current Debian install of mips architecture).
> 
> At the same time, 32bit qemu-mips works just fine:
> 
> 
> # cp -p /usr/bin/qemu-mips-static-32 mipsroot/usr/bin/
> # chroot mipsroot /bin/bash
> I have no name!@gandalf:/# ls
> bin   dev  home  lib64	proc  run   selinux  tmp  var
> boot  etc  lib	 mnt	root  sbin  sys      usr
> I have no name!@gandalf:/# uname -a
> Linux gandalf 3.2.0-amd64 #3.2.30 SMP Thu Sep 20 18:50:45 MSK 2012 mips GNU/Linux
> 
> Current qemu git behaves the same - it also segfaults
> when trying to run a 32bit mips binary from x86_64
> host qemu-mips binary.
> 
> There are numerous bugreports about this issue on Debian
> as well.
> 
> Is it just Debian, or is something really broken there?
> I'd think that running 32bit mips code on x86_64 host
> is quite common, no?

This is broken (bisected to) since

commit 288e65b9eea0c9b3cbe21be46f3e24e4e8b2a090
Author: Alexander Graf <agraf@suse.de>
Date:   Wed Dec 14 00:33:28 2011 +0100

    linux-user: reserve 4GB of vmem for 32-on-64

    When running 32-on-64 bit guests, we should always reserve as much
    virtual memory as we possibly can for the guest process, so it can
    never overlap with QEMU address space.

    Fortunately we already have the infrastructure for that. All that's
    missing is some sane default value to also make use of it!

    Signed-off-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Riku Voipio <riku.voipio@linaro.org>

(Cc'ing).

Reverting this commit on top of qemu-1.1, 1.2 or 1.3 makes
it work again.

This commit has been applied in the middle between 1.0 and 1.1
versions of qemu.  It is interesting that no one noticed this
before now, when 1.3 is out already.  Oh well.

Thanks,

/mjt

Re: [Qemu-devel] (bisected): Is mips-user broken on 64bit host since v1.1?

[Stefan Weil]

Am 18.12.2012 20:05, schrieb Michael Tokarev:
> On 18.12.2012 20:10, Michael Tokarev wrote:
>> Since at least 1.1 version of qemu, I can't run any
>> mips binary using statically linked qemu-mips on x86_64
>> host.  It immediately fails with SIGSEGV:
>>
>> # chroot mipsroot /bin/bash
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>>
>> mipsroot/bin/bash: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV),
>>   dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
>>   BuildID[sha1]=0xeb1a3595d733e28f4f081beabb1f135bc5bf7527,
>>   with unknown capability 0x41000000 = 0xf676e75,
>>   with unknown capability 0x10000 = 0x70401,
>>   stripped
>>
>> (this is current Debian install of mips architecture).
>>
>> At the same time, 32bit qemu-mips works just fine:
>>
>>
>> # cp -p /usr/bin/qemu-mips-static-32 mipsroot/usr/bin/
>> # chroot mipsroot /bin/bash
>> I have no name!@gandalf:/# ls
>> bin   dev  home  lib64	proc  run   selinux  tmp  var
>> boot  etc  lib	 mnt	root  sbin  sys      usr
>> I have no name!@gandalf:/# uname -a
>> Linux gandalf 3.2.0-amd64 #3.2.30 SMP Thu Sep 20 18:50:45 MSK 2012 mips GNU/Linux
>>
>> Current qemu git behaves the same - it also segfaults
>> when trying to run a 32bit mips binary from x86_64
>> host qemu-mips binary.
>>
>> There are numerous bugreports about this issue on Debian
>> as well.
>>
>> Is it just Debian, or is something really broken there?
>> I'd think that running 32bit mips code on x86_64 host
>> is quite common, no?
>
> This is broken (bisected to) since
>
> commit 288e65b9eea0c9b3cbe21be46f3e24e4e8b2a090
> Author: Alexander Graf<agraf@suse.de>
> Date:   Wed Dec 14 00:33:28 2011 +0100
>
>      linux-user: reserve 4GB of vmem for 32-on-64
>
>      When running 32-on-64 bit guests, we should always reserve as much
>      virtual memory as we possibly can for the guest process, so it can
>      never overlap with QEMU address space.
>
>      Fortunately we already have the infrastructure for that. All that's
>      missing is some sane default value to also make use of it!
>
>      Signed-off-by: Alexander Graf<agraf@suse.de>
>      Signed-off-by: Riku Voipio<riku.voipio@linaro.org>
>
> (Cc'ing).
>
> Reverting this commit on top of qemu-1.1, 1.2 or 1.3 makes
> it work again.
>
> This commit has been applied in the middle between 1.0 and 1.1
> versions of qemu.  It is interesting that no one noticed this
> before now, when 1.3 is out already.  Oh well.
>
> Thanks,
>
> /mjt

I'm afraid that the main focus of most testers is system emulation
and must admit that I run user emulation very rarely.

Nevertheless it should be possible to add some statically linked
binaries for each architecture to the buildbot machines and add
tests which run these binaries.

Regards,

Stefan Weil

Re: [Qemu-devel] (bisected): Is mips-user broken on 64bit host since v1.1?

[Alexander Graf]

On 18.12.2012, at 20:05, Michael Tokarev wrote:

> On 18.12.2012 20:10, Michael Tokarev wrote:
>> Since at least 1.1 version of qemu, I can't run any
>> mips binary using statically linked qemu-mips on x86_64
>> host.  It immediately fails with SIGSEGV:
>> 
>> # chroot mipsroot /bin/bash
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> 
>> mipsroot/bin/bash: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
>> BuildID[sha1]=0xeb1a3595d733e28f4f081beabb1f135bc5bf7527,
>> with unknown capability 0x41000000 = 0xf676e75,
>> with unknown capability 0x10000 = 0x70401,
>> stripped
>> 
>> (this is current Debian install of mips architecture).
>> 
>> At the same time, 32bit qemu-mips works just fine:
>> 
>> 
>> # cp -p /usr/bin/qemu-mips-static-32 mipsroot/usr/bin/
>> # chroot mipsroot /bin/bash
>> I have no name!@gandalf:/# ls
>> bin   dev  home  lib64	proc  run   selinux  tmp  var
>> boot  etc  lib	 mnt	root  sbin  sys      usr
>> I have no name!@gandalf:/# uname -a
>> Linux gandalf 3.2.0-amd64 #3.2.30 SMP Thu Sep 20 18:50:45 MSK 2012 mips GNU/Linux
>> 
>> Current qemu git behaves the same - it also segfaults
>> when trying to run a 32bit mips binary from x86_64
>> host qemu-mips binary.
>> 
>> There are numerous bugreports about this issue on Debian
>> as well.
>> 
>> Is it just Debian, or is something really broken there?
>> I'd think that running 32bit mips code on x86_64 host
>> is quite common, no?
> 
> This is broken (bisected to) since
> 
> commit 288e65b9eea0c9b3cbe21be46f3e24e4e8b2a090
> Author: Alexander Graf <agraf@suse.de>
> Date:   Wed Dec 14 00:33:28 2011 +0100
> 
>    linux-user: reserve 4GB of vmem for 32-on-64
> 
>    When running 32-on-64 bit guests, we should always reserve as much
>    virtual memory as we possibly can for the guest process, so it can
>    never overlap with QEMU address space.
> 
>    Fortunately we already have the infrastructure for that. All that's
>    missing is some sane default value to also make use of it!
> 
>    Signed-off-by: Alexander Graf <agraf@suse.de>
>    Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
> 
> (Cc'ing).
> 
> Reverting this commit on top of qemu-1.1, 1.2 or 1.3 makes
> it work again.

Do you know exactly why it breaks mips?


Alex

> 
> This commit has been applied in the middle between 1.0 and 1.1
> versions of qemu.  It is interesting that no one noticed this
> before now, when 1.3 is out already.  Oh well.
> 
> Thanks,
> 
> /mjt

Re: [Qemu-devel] (bisected): Is mips-user broken on 64bit host since v1.1?

[Michael Tokarev]

On 19.12.2012 01:33, Alexander Graf wrote:
> On 18.12.2012, at 20:05, Michael Tokarev wrote:

>>> # chroot mipsroot /bin/bash
>>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped

>> commit 288e65b9eea0c9b3cbe21be46f3e24e4e8b2a090
>> Author: Alexander Graf <agraf@suse.de>
>> Date:   Wed Dec 14 00:33:28 2011 +0100
>>
>>    linux-user: reserve 4GB of vmem for 32-on-64

> Do you know exactly why it breaks mips?

Guess what?  Yesterday was the first day I "met" mips in
general and qemu-user in particular... ;)

That's why I Cc'ed Aurelien in the first place ;)

Thanks,

/mjt

Re: [Qemu-devel] Is mips-user broken on 64bit host?

[Richard Henderson]

On 12/18/2012 08:10 AM, Michael Tokarev wrote:
> Is it just Debian, or is something really broken there?

Something's broken.  But it's tricky.

For instance, running with -R 2G works, but -R 3G does not.

Now, I'll also note for the record that 2G is the most that
a mips32 userland application ought to be able to reference
anyway -- anything with the high-bit set is by definition
kernel space.

So while I have yet to track down exactly what went wrong,
I have a suspicion that it might actually be related to the
incorrect placement of the objects in the address space.


r~