From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIDi3-00063I-SG for qemu-devel@nongnu.org; Tue, 25 Feb 2014 03:49:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIDhy-00043h-U2 for qemu-devel@nongnu.org; Tue, 25 Feb 2014 03:49:51 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36738 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIDhy-00043V-KZ for qemu-devel@nongnu.org; Tue, 25 Feb 2014 03:49:46 -0500 Message-ID: <530C5925.8060608@suse.de> Date: Tue, 25 Feb 2014 09:49:41 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <87sirhyi1b.fsf@linaro.org> <87txbnfuw1.fsf@linaro.org> In-Reply-To: <87txbnfuw1.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: Peter Maydell , linaro-dev , Dann Frazier , Michael Matz , Alexander Graf , "linaro-toolchain@lists.linaro.org" , qemu-devel , Wook Wookey , Christoffer Dall Am 25.02.2014 09:39, schrieb Alex Benn=C3=A9e: >=20 > Dann Frazier writes: >=20 >> On Mon, Feb 17, 2014 at 6:40 AM, Alex Benn=C3=A9e wrote: >>> Hi, >> >> Thanks to all involved for your work here! >> >>> After a solid few months of work the QEMU master branch [1] has now r= eached >>> instruction feature parity with the suse-1.6 [6] tree that a lot of p= eople >>> have been using to build various aarch64 binaries. In addition to the > >>> >>> 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. >=20 > 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. >=20 > >>> >>> Feedback I'm interested in >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> >>> * Any instruction failure (please include the log line with the >>> unsupported message) >>> * Any aarch64 specific failures (i.e. not generic QEMU threading flak= einess). >> >> 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 bunc= h of >> shell scripts (postinst, etc). When it blows up, the stack consis= tently >> 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=3D8, __src=3D0x7fff62ae34e0, >> __dest=3D0x400082c330) at >> /usr/include/x86_64-linux-gnu/bits/string3.h:51 >> 51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__des= t)); >> (gdb) bt >> #0 0x0000000060058e55 in memcpy (__len=3D8, __src=3D0x7fff62ae34e0, >> __dest=3D0x400082c330) at >> /usr/include/x86_64-linux-gnu/bits/string3.h:51 >> #1 stq_p (v=3D274886476624, ptr=3D0x400082c330) at >> /mnt/qemu.upstream/include/qemu/bswap.h:280 >> #2 stq_le_p (v=3D274886476624, ptr=3D0x400082c330) at >> /mnt/qemu.upstream/include/qemu/bswap.h:315 >> #3 target_setup_sigframe (set=3D0x7fff62ae3530, env=3D0x62d9c678, >> sf=3D0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 >> #4 target_setup_frame (usig=3Dusig@entry=3D17, ka=3Dka@entry=3D0x604e= c1e0 >> , info=3Dinfo@entry=3D0x0, set=3Dset@entry=3D0x7fff6= 2ae3530, >> env=3Denv@entry=3D0x62d9c678) >> at /mnt/qemu.upstream/linux-user/signal.c:1286 >> #5 0x0000000060059f46 in setup_frame (env=3D0x62d9c678, >> set=3D0x7fff62ae3530, ka=3D0x604ec1e0 , sig=3D17) at >> /mnt/qemu.upstream/linux-user/signal.c:1322 >> #6 process_pending_signals (cpu_env=3Dcpu_env@entry=3D0x62d9c678) at >> /mnt/qemu.upstream/linux-user/signal.c:5747 >> #7 0x0000000060056e60 in cpu_loop (env=3Denv@entry=3D0x62d9c678) at >> /mnt/qemu.upstream/linux-user/main.c:1082 >> #8 0x0000000060005079 in main (argc=3D, argv=3D> out>, envp=3D) 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? >=20 > Quite likely. We explicitly concentrated on the arch64 specific > instruction emulation leaving more generic patches to flow in from SUSE > as they matured. >=20 > I guess it's time to go through the remaining patches and see what's up= -streamable. >=20 > Alex/Michael, >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg