Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

[Alex Bennée]

Dann Frazier <address@hidden> writes:

> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée <address@hidden> wrote:
>> Hi,
>
> Thanks to all involved for your work here!
>
>> After a solid few months of work the QEMU master branch [1] has now reached
>> instruction feature parity with the suse-1.6 [6] tree that a lot of people
>> have been using to build various aarch64 binaries. In addition to the
<snip>
>>
>> I've tested against the following aarch64 rootfs:
>>     * SUSE [2]
>>     * Debian [3]
>>     * Ubuntu Saucy [4]
>
> fyi, I've been doing my testing with Ubuntu Trusty.

Good stuff, I shall see if I can set one up. Is the package coverage
between trusty and saucy much different? I noticed for example I
couldn't find zile and various build-deps for llvm.

<snip>
>>
>> Feedback I'm interested in
>> ==========================
>>
>> * Any instruction failure (please include the log line with the
>>   unsupported message)
>> * Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness).
>
> I'm not sure if this qualifies as generic QEMU threading flakiness or not. 
> I've
> found a couple conditions that causes master to core dump fairly
> reliably, while the aarch64-1.6 branch seems to consistently work
> fine.
>
>  1) dh_fixperms is a script that commonly runs at the end of a package build.
>      Its basically doing a `find | xargs chmod`.
>  2) debootstrap --second-stage
>      This is used to configure an arm64 chroot that was built using
>      debootstrap on a non-native host. It is basically invoking a bunch of
>      shell scripts (postinst, etc). When it blows up, the stack consistently
>      looks like this:
>
> Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
> /debootstrap/debootstrap --second-stage'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
> __dest=0x400082c330) at
> /usr/include/x86_64-linux-gnu/bits/string3.h:51
> 51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
> __dest=0x400082c330) at
> /usr/include/x86_64-linux-gnu/bits/string3.h:51
> #1  stq_p (v=274886476624, ptr=0x400082c330) at
> /mnt/qemu.upstream/include/qemu/bswap.h:280
> #2  stq_le_p (v=274886476624, ptr=0x400082c330) at
> /mnt/qemu.upstream/include/qemu/bswap.h:315
> #3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
> sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
> #4  target_setup_frame (address@hidden, address@hidden
> <sigact_table+512>, address@hidden, address@hidden,
> address@hidden)
>     at /mnt/qemu.upstream/linux-user/signal.c:1286
> #5  0x0000000060059f46 in setup_frame (env=0x62d9c678,
> set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at
> /mnt/qemu.upstream/linux-user/signal.c:1322
> #6  process_pending_signals (address@hidden) at
> /mnt/qemu.upstream/linux-user/signal.c:5747
> #7  0x0000000060056e60 in cpu_loop (address@hidden) at
> /mnt/qemu.upstream/linux-user/main.c:1082
> #8  0x0000000060005079 in main (argc=<optimized out>, argv=<optimized
> out>, envp=<optimized out>) at
> /mnt/qemu.upstream/linux-user/main.c:4374
>
> There are some pretty large differences between these trees with
> respect to signal syscalls - is that the likely culprit?

Quite likely. We explicitly concentrated on the arch64 specific
instruction emulation leaving more generic patches to flow in from SUSE
as they matured.

I guess it's time to go through the remaining patches and see what's 
up-streamable.

Alex/Michael,

Are any of these patches in flight now?

Cheers,

--
Alex Bennée
QEMU/KVM Hacker for Linaro