[libvirt] FYI: aarch64 test suite failures
Libvirt compiles fine on aarch64. You will need to configure with --without-dtrace as systemtap tracepoints are pretty broken, giving lots of strange compile-time errors/link failures in both libvirt and qemu. The test suite fails, see attachment. Note this is all running under qemu-arm64 userspace emulation[1], so certain things are expected to be a bit different. In particular, any aarch64 binary which the test suite runs is actually run under the qemu-arm64 interpreter (using binfmt). I'm guessing this explains the extra file descriptor in some tests. Also qemu intercepts system calls and thunks them into host system calls (an x86-64 host in this case), and its support for IPv6 seems shaky at best. Rich. [1] http://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-binaries-on-an-x86-64-host-using-qemu-userspace-emulation/#content -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW = libvirt 1.2.1: tests/test-suite.log = # TOTAL: 96 # PASS: 89 # SKIP: 4 # XFAIL: 0 # FAIL: 3 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: nodeinfotest == FAIL: commandtest = TEST: commandtest 1) Command Exec test0 test ... OK 2) Command Exec test1 test ... OK 3) Command Exec test2 test ... Offset 0 Expect [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 DAEMON:no CWD:/tmp ] Actual [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 FD:3 DAEMON:no CWD:/tmp ] ... FAILED 4) Command Exec test3 test ... Offset 0 Expect [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 FD:5 FD:7 DAEMON:no CWD:/tmp ] Actual [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 FD:3 FD:5 FD:7 DAEMON:no CWD:/tmp ] ... FAILED 5) Command Exec test4 test ... Offset 0 Expect [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 DAEMON:yes CWD:/ ] Actual [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 FD:3 DAEMON:yes CWD:/ ] ... FAILED 6) Command Exec test5 test ... Offset 0 Expect [ENV:HOME=/home/test ENV:LC_ALL=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 DAEMON:no CWD:/tmp ] Actual [ENV:HOME=/home/test ENV:LC_ALL=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 FD:3 DAEMON:no CWD:/tmp ] ... FAILED 7) Command Exec test6 test ... Offset 0 Expect [ENV:DISPLAY=:0.0 FD:0 FD:1 FD:2 DAEMON:no CWD:/tmp ] Actual [ENV:DISPLAY=:0.0 FD:0 FD:1 FD:2 FD:3 DAEMON:no CWD:/tmp ] ... FAILED 8) Command Exec test7 test ... Offset 0 Expect [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:LC_ALL=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 DAEMON:no CWD:/tmp ] Actual [ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:LC_ALL=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0 FD:1 FD:2 FD:3 DAEMON:no CWD:/tmp ] ... FAILED 9) Command Exec test8 test ... Offset 0 Expect [ENV:LANG=C ENV:USER=test FD:0 FD:1 FD:2 DAEMON:no CWD:/tmp ] Actual [ENV:LANG=C ENV:USER=test FD:0 FD:1 FD:2 FD:3 DAEMON:no CWD:/tmp ] ... FAILED 10) Command Exec test9 test ... Offset 0 Expect [ARG:-version ARG:-log=bar.log ARG:arg1 ARG:arg2 ARG: ARG:arg4 ARG:arg5 ARG:arg6 ENV:DISPLAY=:0.0 ENV:HOME=/home/test ENV:HOSTNAME=test ENV:LANG=C ENV:LOGNAME=testTMPDIR=/tmp ENV:PATH=/usr/bin:/bin ENV:USER=test FD:0
Re: [libvirt] FYI: aarch64 test suite failures
On Wed, Jan 01, 2014 at 02:51:30PM +, Richard W.M. Jones wrote: In particular, any aarch64 binary which the test suite runs is actually run under the qemu-arm64 interpreter (using binfmt). I'm guessing this explains the extra file descriptor in some tests. More precisely, qemu opens a file descriptor for the binary, and then seems to leak that fd across fork/exec. Compare: On the host: $ ls -l /proc/self/fd total 0 lrwx--. 1 rjones rjones 64 Jan 1 15:04 0 - /dev/pts/7 lrwx--. 1 rjones rjones 64 Jan 1 15:04 1 - /dev/pts/7 lrwx--. 1 rjones rjones 64 Jan 1 15:04 2 - /dev/pts/7 lr-x--. 1 rjones rjones 64 Jan 1 15:04 3 - /proc/18301/fd In the qemu chroot: $ ./arm64-chroot.sh # ls -l /proc/self/fd total 0 lrwx--. 1 root root 64 Jan 1 15:04 0 - /dev/pts/7 lrwx--. 1 root root 64 Jan 1 15:04 1 - /dev/pts/7 lrwx--. 1 root root 64 Jan 1 15:04 2 - /dev/pts/7 lr-x--. 1 root root 64 Jan 1 15:04 3 - /usr/bin/bash lr-x--. 1 root root 64 Jan 1 15:04 4 - /usr/bin/ls lr-x--. 1 root root 64 Jan 1 15:04 5 - /proc/18331/fd So anything which is testing file descriptors should probably be skipped until we can afford to run this on real hardware or qemu gets system emulation of aarch64. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FYI: aarch64 test suite failures
On Wed, Jan 01, 2014 at 02:51:30PM +, Richard W.M. Jones wrote: FAIL: sysinfotest = TEST: sysinfotest 1) aarch64 sysinfo ... Offset 0 Expect [sysinfo type='smbios' /sysinfo ] Actual [sysinfo type='smbios' processor entry name='socket_destination'0/entry entry name='type'AArch64 Processor rev 0 (aarch64) /entry /processor processor entry name='socket_destination'1/entry entry name='type'AArch64 Processor rev 0 (aarch64)/entry /processor /sysinfo ] ... FAILED /proc/cpuinfo is emulated by qemu by intercepting any system call which tries to open that file. Under qemu: $ cat /proc/sysinfo /bin/cat: /proc/sysinfo: No such file or directory $ cat /proc/cpuinfo Processor: AArch64 Processor rev 0 (aarch64) processor: 0 BogoMIPS : 200.00 Features : fp asimd CPU implementer : 0x41 CPU architecture: AArch64 CPU variant : 0x0 CPU part: 0xd00 CPU revision: 0 Hardware: V2P-AARCH64 However my understanding of this test is that it doesn't use /proc/cpuinfo from the system, but uses the test data from tests/sysinfodata/aarch64cpuinfo.data, and since it is using fixed test data, the test output should be identical. Therefore this appears to be a genuine libvirt bug. I will post a patch in a few minutes. FAIL: virnetsockettest == TEST: virnetsockettest Cannot identify IPv4/6 availability This one fails because: getifaddrs: Address family not supported by protocol getifaddrs first calls socket(PF_NETLINK, SOCK_RAW, 0) [see netlink(7)]. This seems firmly in the category of qemu emulation failure, so I think we should ignore it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FYI: aarch64 test suite failures
On Wed, Jan 01, 2014 at 03:34:33PM +, Richard W.M. Jones wrote: On Wed, Jan 01, 2014 at 02:51:30PM +, Richard W.M. Jones wrote: FAIL: sysinfotest = In fact, since this test is entirely test-data-driven, why does the test contain arch-specific sections at all? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
