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

[Andreas Färber]

Am 25.02.2014 09:39, schrieb 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?

I don't think so, Alex seems to hate cleaning that stuff up... :P

Compare https://github.com/openSUSE/qemu/commits/opensuse-1.7 for our
general queue. We have patches adding locking to TCG, and there's a hack
pinning the CPU somewhere.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg