qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dann Frazier
Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Date: Wed, 26 Feb 2014 15:06:11 -0700

On Tue, Feb 25, 2014 at 1:39 AM, Alex Bennée <address@hidden> wrote:
>
> 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:

I've narrowed down the changes that seem to prevent both types of
segfaults to the following changes that introduce a wrapper around
sigprocmask:

https://github.com/susematz/qemu/commit/f1542ae9fe10d5a241fc2624ecaef5f0948e3472
https://github.com/susematz/qemu/commit/4e5e1607758841c760cda4652b0ee7a6bc6eb79d
https://github.com/susematz/qemu/commit/63eb8d3ea58f58d5857153b0c632def1bbd05781

I'm not sure if this is a real fix or just papering over my issue -
but either way, are these changes reasonable for upstream submission?

 -dann


>> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]