diff options
Diffstat (limited to '')
34 files changed, 4017 insertions, 0 deletions
diff --git a/results/classifier/108/other/171 b/results/classifier/108/other/171 new file mode 100644 index 000000000..6549b3af1 --- /dev/null +++ b/results/classifier/108/other/171 @@ -0,0 +1,16 @@ +device: 0.869 +network: 0.651 +performance: 0.613 +semantic: 0.400 +boot: 0.388 +KVM: 0.337 +PID: 0.333 +vnc: 0.310 +files: 0.295 +graphic: 0.262 +other: 0.243 +socket: 0.199 +permissions: 0.182 +debug: 0.181 + +[RFE] option to suppress gemu_log() output diff --git a/results/classifier/108/other/1710 b/results/classifier/108/other/1710 new file mode 100644 index 000000000..c1acea232 --- /dev/null +++ b/results/classifier/108/other/1710 @@ -0,0 +1,66 @@ +device: 0.835 +PID: 0.776 +semantic: 0.645 +files: 0.619 +graphic: 0.565 +socket: 0.530 +other: 0.468 +network: 0.466 +debug: 0.430 +vnc: 0.369 +boot: 0.338 +performance: 0.336 +permissions: 0.284 +KVM: 0.109 + +contrib/plugins/Makefile is not crossplatform +Description of problem: +Currently `contrib/plugins/Makefile` makes multiple assumptions about paths used, compiler flags available, and library extension +Steps to reproduce: +1. Compile QEMU from sources on macOS or Windows +2. Enter `contrib/plugins` +3. Type `make` and become sad. +Additional information: +As the rest of QEMU switched to Meson, maybe it's a good idea to do the same for plugins as well? + +This is what I come with myself: + +`meson.build`: +```meson +project('qemu-plugins', 'c', meson_version: '>=0.50.0') + +qemu_src = get_option('qemu_path') +if qemu_src == '' + qemu_src = '../..' +endif + +qemu_include = qemu_src + '/include/qemu' +incdir = include_directories(qemu_include) + +plugins = [ + 'execlog', + 'hotblocks', + 'hotpages', + 'howvec', + 'lockstep', + 'hwprofile', + 'cache', + 'drcov', +] + +th = dependency('threads', required: true) +glib = dependency('glib-2.0', required: true) + +foreach p: plugins + library(p, p + '.c', + include_directories: incdir, + dependencies: [th, glib], + override_options: ['b_lundef=false'] + ) +endforeach +``` + +`meson_options.txt`: +``` +option('qemu_path', type : 'string', value : '', description : 'Full path to the QEMU sources to build the plugin for') +``` diff --git a/results/classifier/108/other/1711 b/results/classifier/108/other/1711 new file mode 100644 index 000000000..191258171 --- /dev/null +++ b/results/classifier/108/other/1711 @@ -0,0 +1,16 @@ +permissions: 0.879 +device: 0.745 +performance: 0.527 +network: 0.513 +other: 0.416 +semantic: 0.408 +graphic: 0.334 +KVM: 0.323 +boot: 0.236 +vnc: 0.201 +files: 0.150 +PID: 0.142 +debug: 0.136 +socket: 0.109 + +unable to set PWD with guest-exec without starting a shell diff --git a/results/classifier/108/other/1711316 b/results/classifier/108/other/1711316 new file mode 100644 index 000000000..9f184661f --- /dev/null +++ b/results/classifier/108/other/1711316 @@ -0,0 +1,99 @@ +other: 0.901 +graphic: 0.876 +permissions: 0.867 +debug: 0.854 +KVM: 0.846 +device: 0.841 +vnc: 0.836 +semantic: 0.830 +performance: 0.818 +PID: 0.810 +network: 0.787 +boot: 0.728 +files: 0.706 +socket: 0.691 + +fbsd strip(1) segfaults on aarch64 + +Hello, + +During port builds ld.lld(devel/boost-libs, www/node), and strip (textproc/libxml2 on xmlcatalog) are segfaulting. On physical boxes these things do work, as they should: + +root@build-aarch64:~ # strip xmlcatalog +Segmentation fault (core dumped) + +All the cores fail at the same assembly instruction, here's strip's backtrace: +# lldb -c strip.core strip +(lldb) target create "strip" --core "strip.core" +Core file '/root/strip.core' (aarch64) was loaded. +(lldb) t 1 +* thread #1, name = 'strip', stop reason = signal SIGSEGV + frame #0: 0x0000000040312f40 libc.so.7`memcpy + 192 +libc.so.7`memcpy: +-> 0x40312f40 <+192>: ldp x4, x3, [x4, #-0x10] + 0x40312f44 <+196>: stp x6, x7, [x0] + 0x40312f48 <+200>: stp x8, x9, [x0, #0x10] + 0x40312f4c <+204>: stp x10, x11, [x0, #0x20] +(lldb) bt +* thread #1, name = 'strip', stop reason = signal SIGSEGV + * frame #0: 0x0000000040312f40 libc.so.7`memcpy + 192 + frame #1: 0x000000004017ac70 libelf.so.2`_libelf_cvt_HALF_tom(dst=<unavailable>, dsz=<unavailable>, src=<unavailable>, count=<unavailable>, byteswap=<unavailable>) at libelf_convert.c:794 + frame #2: 0x0000000040177b34 libelf.so.2`elf_getdata(s=0x0000000040f355a0, ed=<unavailable>) at elf_data.c:155 + frame #3: 0x00000000000283d4 strip`copy_data(s=0x0000000040f36a40) at sections.c:1176 + frame #4: 0x0000000000027ea4 strip`copy_content(ecp=<unavailable>) at sections.c:594 + frame #5: 0x0000000000023ff4 strip`create_elf(ecp=0x0000000040ed6000) at main.c:381 + frame #6: 0x000000000002558c strip`create_file(ecp=<unavailable>, src=<unavailable>, dst=<unavailable>) at main.c:705 + frame #7: 0x0000000000024e20 strip`main [inlined] strip_main(argc=<unavailable>, argv=<unavailable>) at main.c:1192 + frame #8: 0x0000000000024cc8 strip`main(argc=<unavailable>, argv=<unavailable>) at main.c:1590 + frame #9: 0x0000000000020190 strip`__start + 376 + frame #10: 0x0000000040050018 ld-elf.so.1`.rtld_start at rtld_start.S:41 + +Host system information: +# uname -a +FreeBSD marvin.harmless.hu 11.0-STABLE FreeBSD 11.0-STABLE #0 r311927: Wed Jan 11 14:53:55 CET 2017 <email address hidden>:/usr/obj/usr/src/sys/MARVIN amd64 + +# qemu-system-aarch64 --version +QEMU emulator version 2.9.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +# pkg info | grep qemu +qemu-2.9.0 QEMU CPU Emulator +I also had this happening with 2.8.0 and 2.8.1 + +Guest information: +# uname -a +FreeBSD build-aarch64.marvin.harmless.hu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r322578: Wed Aug 16 18:08:43 CEST 2017 <email address hidden>:/tank/rpi3/obj/arm64.aarch64/tank/rpi3/src/sys/GENERIC-NODEBUG arm64 + +Startup: +zdev=/dev/zvol/tank/rpi3/qemu-image +qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ + -accel tcg,thread=single \ + -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ + -drive if=none,file=${image},id=hd0,format=raw \ + -device virtio-blk-device,drive=hd0 \ + -device e1000,netdev=net0 \ + -netdev tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh + +Tested with cortex A53 as well, does the same. + +I've attached a test image to reproduce with (340MB), if it's too big for an attachment, it can be downloaded from here: +http://czg.harmless.hu/qemu-bug-stripsigsegv/image.gz + +Reproduction steps: +1) log in as root, no password +2) strip xmlcatalog, it will segfault + +For a full reproduction with ld.lld as well, you need a ports tree, it's suggested to attach a bigger volume to /usr/ports over NFS first (it might need more space than the image has). Steps for it: +1) portsnap fetch extract +2) make -C /usr/ports/devel/boost-libs package-recursive +3) make -C /usr/ports/textproc/libxml2 package-recursive +4) make -C /usr/ports/www/node package-recursive + +Boost and node can take a day or more in a qemu VM. The build-time options I've be set already, /var/db/ports is populated, so you shouldn't have questions asked during the builds. + +I've saved the core dumps, those can be found at /root/cores/ in the image. + +I hope I've submitted all the required information. If anything else is needed, please let me know. + +Best regards, +Gergely + diff --git a/results/classifier/108/other/1711828 b/results/classifier/108/other/1711828 new file mode 100644 index 000000000..d807319a5 --- /dev/null +++ b/results/classifier/108/other/1711828 @@ -0,0 +1,76 @@ +other: 0.853 +device: 0.830 +semantic: 0.808 +graphic: 0.753 +permissions: 0.738 +performance: 0.731 +PID: 0.725 +network: 0.669 +socket: 0.634 +debug: 0.606 +vnc: 0.580 +files: 0.559 +boot: 0.460 +KVM: 0.448 + +lock mov non generated #UD + +qemu 2.8.1 debian 9.1 + +Could you please add a proper description to this bug? Please also try first whether your problem also occurs with the latest released version of QEMU (version 2.9 or the 2.10 release candidate), to see whether it has been fixed there already. + + + +sorry i english poor： + + +intel manual say： +The LOCK prefix can be prepended only to the following instructions and only to those forms of the instructions +where the destination operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, +CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG. If the LOCK prefix is used with one of +these instructions and the source operand is a memory operand, an undefined opcode exception (#UD) may be +generated. An undefined opcode exception will also be generated if the LOCK prefix is used with any instruction not +in the above list. The XCHG instruction always asserts the LOCK# signal regardless of the presence or absence of +the LOCK prefix. + + +but qemu NO! +lock mov forms of the instructions non generated #UD exception! +my OS : debian 9.1 +QEMU: qemu 2.8.1 + + + + + + + +At 2017-08-21 12:54:44, "Thomas Huth" <email address hidden> wrote: +>Could you please add a proper description to this bug? Please also try +>first whether your problem also occurs with the latest released version +>of QEMU (version 2.9 or the 2.10 release candidate), to see whether it +>has been fixed there already. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1711828 +> +>Title: +> lock mov non generated #UD +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> qemu 2.8.1 debian 9.1 +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1711828/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1712 b/results/classifier/108/other/1712 new file mode 100644 index 000000000..d60fcf86c --- /dev/null +++ b/results/classifier/108/other/1712 @@ -0,0 +1,24 @@ +device: 0.875 +graphic: 0.690 +PID: 0.538 +semantic: 0.458 +boot: 0.453 +files: 0.367 +permissions: 0.357 +debug: 0.333 +KVM: 0.281 +socket: 0.256 +network: 0.230 +vnc: 0.200 +other: 0.189 +performance: 0.178 + +Arabic keyboard layout wrong. +Description of problem: +After a while the compilation process starts, xkb gives an error about symbols/ar not found. According to my research, linux distros using "ara" for arabic layout. But qemu pc-bios/keymaps/ folder contains "ar" for arabic layout. +Steps to reproduce: +1.Configure +2.Build +3.Wait until error appears. +Additional information: + diff --git a/results/classifier/108/other/1712564 b/results/classifier/108/other/1712564 new file mode 100644 index 000000000..d1c1c04ec --- /dev/null +++ b/results/classifier/108/other/1712564 @@ -0,0 +1,47 @@ +graphic: 0.831 +PID: 0.802 +device: 0.723 +socket: 0.684 +vnc: 0.682 +performance: 0.667 +permissions: 0.655 +other: 0.642 +network: 0.640 +debug: 0.579 +semantic: 0.553 +files: 0.514 +boot: 0.466 +KVM: 0.410 + +loadvm fails twice in sequence + +13:38:23) shorne_: Hello, I was doing some testing with migrations for my OpenRISC SMP patch set, I noticed something that looks like a bug, wondering if someone else wants to confirm +(13:38:47) shorne_: Basically, calling loadvm 2 times causes crash +(13:38:54) shorne_: migration/savevm.c: qemu_event_set(&mis->main_thread_load_event) +(13:38:54) stefanha: fam: Here is my take at this change: https://paste.debian.net/982690/ +(13:38:56) shorne_: assert(ev->initialized) - fails inside +(13:39:32) stefanha: quintela davidgiluk: ^ +(13:41:23) ***davidgiluk looks +(13:41:40) shorne_: c096358e747 util/qemu-thread-posix.c (Fam Zheng 2017-07-04 20:23:25 +0800 397) assert(ev->initialized); +(13:41:51) davidgiluk: shorne_: So you're doing a loadvm to load a snapshot and then again? +(13:42:02) shorne_: Looks like adding that assert() was done really recently +(13:42:41) shorne_: yes, just loadvm 'a' ... then wait a bit longer, loadvm 'a' again (confirm clocks go back etc) +(13:42:50) stefanha: fam: While you're having dinner I'll work on turning my script into a qemu-iotests test case that we can merge. +(13:44:03) gpiccoli [~gpiccoli@0002093a.user.oftc.net] entered the room. +(13:44:21) davidgiluk: shorne_: Well, it looks like the c09635 assert is a sanity check to make sure we didn't do anything stupid, and well..... +(13:44:57) pm215: migration_incoming_get_current() and migration_incoming_state_destroy() seem a bit mismatched +(13:45:13) davidgiluk: pm215: Yep +(13:45:46) davidgiluk: pm215: Generally we've thought that an incoming migration normally only happens once - shorne_'s case is the exception +(13:46:03) shorne_: pm215: yeah, it looked something like that I just had a few seconds to look at today +(13:46:03) HariharanTS left the room (quit: Ping timeout: 480 seconds). +(13:46:03) shorne_ is now known as shorne +(13:48:05) shorne: davidgiluk: pm215: thanks for having a look. Unfortunately I need to head off to bed and put kids to sleep +(13:49:11) davidgiluk: shorne: Sleep well, no nightmares about event destroyers.... +(13:49:30) davidgiluk: pm215: Yeh this is fall out from b4b076daf32 + +Posted: +migration: Reset rather than destroy main_thread_load_event +snapshot/tests: Try loadvm twice + +Commit 5089e1862fe80b6f23ba4c494e2902cbe3d9d48e + diff --git a/results/classifier/108/other/1712818 b/results/classifier/108/other/1712818 new file mode 100644 index 000000000..a932f4bbd --- /dev/null +++ b/results/classifier/108/other/1712818 @@ -0,0 +1,86 @@ +device: 0.859 +PID: 0.803 +socket: 0.792 +graphic: 0.782 +KVM: 0.756 +other: 0.746 +boot: 0.738 +semantic: 0.662 +permissions: 0.623 +network: 0.616 +files: 0.595 +vnc: 0.588 +performance: 0.576 +debug: 0.567 + +live migration with storage encounter assert(!(bs->open_flags & BDRV_O_INACTIVE)) crashes + +The vm guest runs a iotest program, and i migrate it with virsh --copy-storage-all,then the qemu process on the source host happens to crash with the following message: + +kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed. +2017-08-24 11:43:45.919+0000: shutting down, reason=crashed + + +here is the release: +qemu 2.7 & 2.10.rc3 were tested. +libvirt 3.0.0 & 3.2.0 were tested. + +command line: +src_host:virsh migrate --verbose --live --persistent --copy-storage-all vm-core qemu+ssh://dst_host/system + +Resaon: After bdrv_inactivate_all() was called, mirror_run coroutine stills write the left dirty disk data to remote nbd server, which triggers the assertion. But I don't known how to avoid the problem, help is needed! Thanks. + +On 08/24/2017 07:59 AM, meeho yuen wrote: +> Public bug reported: +> +> The vm guest runs a iotest program, and i migrate it with virsh --copy- +> storage-all,then the qemu process on the source host happens to crash +> with the following message: +> +> kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed. +> 2017-08-24 11:43:45.919+0000: shutting down, reason=crashed + +> here is the release: +> qemu 2.7 & 2.10.rc3 were tested. + +The just-tagged 2.10-rc4 includes a fix that should be addressing that +issue during live migration; can you please re-test with that? (see +also https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04513.html) + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +Thank you,I will try it. + +hi,eblake,the problem still exists on qemu 2.10_rc4,although the possibility is less than before. + + +kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed. +2017-08-25 11:08:18.963+0000: shutting down, reason=crashed + + +I see the same thing: + +2017-12-28 21:36:26.837+0000: initiating migration +qemu-system-x86_64: block/io.c:1537: bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. +2017-12-28 21:36:40.516+0000: shutting down, reason=crashed +~ + +Running: +QEMU emulator version 2.10.1 +libvirtd (libvirt) 3.10.0 + + + +It seems that the following commit for libvirt fixed the problem. +https://github.com/libvirt/libvirt/blob/960326237764f8970250a3608e7b2b880e030715/src/qemu/qemu_migration.c + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1713 b/results/classifier/108/other/1713 new file mode 100644 index 000000000..c8e9f7974 --- /dev/null +++ b/results/classifier/108/other/1713 @@ -0,0 +1,55 @@ +other: 0.945 +graphic: 0.926 +PID: 0.893 +device: 0.891 +performance: 0.877 +debug: 0.875 +socket: 0.859 +files: 0.829 +permissions: 0.780 +vnc: 0.772 +network: 0.763 +semantic: 0.760 +boot: 0.706 +KVM: 0.652 + +hw/input/hid.c - Add Support for More Than Five Mouse Buttons in QEMU for evdev? +Additional information: +Sure enough, there appear to only be five buttons defined. + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/input/hid.c#L113 + +```c +[INPUT_BUTTON_LEFT] = 0x01, +[INPUT_BUTTON_RIGHT] = 0x02, +[INPUT_BUTTON_MIDDLE] = 0x04, +[INPUT_BUTTON_SIDE] = 0x08, +[INPUT_BUTTON_EXTRA] = 0x10, +``` + + +At this point, the existing naming schema cannot be continued... might I suggest: + +```c +[INPUT_BUTTON_SIX] = 0x??, +[INPUT_BUTTON_SEVEN] = 0x??, +[INPUT_BUTTON_EIGHT] = 0x??, +[INPUT_BUTTON_NINE] = 0x??, +[INPUT_BUTTON_TEN] = 0x??, +[INPUT_BUTTON_ELEVEN] = 0x??, +[INPUT_BUTTON_TWELVE] = 0x??, +``` +Although, I'm not sure if 12 buttons is future-proofed enough. + +I should also note that I found this post which states that there's no more space left in PS2 emulation, so I don't know if that would cause a conflict. +"ps/2 emulation looks like there are no unused bits for more buttons. Possibly we have to extend the usb mouse emulation for that." +https://listman.redhat.com/archives/vfio-users/2016-January/001596.html + +Unfortunately, I have never written a patch. I'm not even sure how I would apply a patch in Unraid, other than overwriting the bin file. So if this is ever fixed, I would simply hope that one day a new version of QEMU would get up-streamed into a new version of Unraid. + +So, here I am humbly asking for support. I don't know if it's as simple as just adding new definitions... and I have no idea what hex value to assign them. + +*edit* I also failed to get a temporary workaround to work by remapping the mouse buttons in the host VM using xmodmap using this command: + +`xmodmap -e "pointer = 1 12 3 4 5 6 7 8 9 10 11 2" &` +I tried saving `pointer = 1 12 3 4 5 6 7 8 9 10 11 2` in the host VM's root folder in .Xmodmap, but it did not propogate to guest VMs. The buttons were still their original mapping and running the xmod command had no effect. diff --git a/results/classifier/108/other/1713328 b/results/classifier/108/other/1713328 new file mode 100644 index 000000000..8922ade49 --- /dev/null +++ b/results/classifier/108/other/1713328 @@ -0,0 +1,33 @@ +graphic: 0.896 +device: 0.883 +semantic: 0.798 +performance: 0.795 +network: 0.703 +other: 0.691 +vnc: 0.647 +permissions: 0.616 +debug: 0.558 +PID: 0.492 +socket: 0.484 +boot: 0.405 +files: 0.324 +KVM: 0.222 + +Unable to C-a in -nographic if -serial telnet + +qemu-system-i386 (version 2.6.1, running on Linux/x86_64) started with: + +qemu-system-i386 -m 64M -machine type=pc -rtc base=localtime,clock=host -nographic -serial telnet:127.0.0.1:1234,server,nowait -net nic,model=ne2k_pci -net user,hostfwd=tcp:127.0.0.1:2200-:22,tftp=/ + +does not accept the escape key (C-a) to perform functions such as switching from monitor to console. Verified both in GNU screen and in the Linux console. + +If '-serial telnet:127.0.0.1:1234,server,nowait' is removed from the command line, the escape key is accepted (and Qemu doesn't enter the monitor immediately). + +Well, with your "-serial" setup, you've put the guest serial console on the telnet port, so there is nothing to switch on the host console here via the CTRL-a c key combination, i.e. this is the expected behavior. What exactly were you trying to do here? Access the serial console via two ways, one time via telnet and one time via the host console? AFAIK that's not possible. + +With '-serial telnet' I directed the serial port to telnet, not the console (I call "console" the VGA tty qemu would show without the -nographic option). + +Ah, ok, so you want to have the VGA output on the host console? Try the "-display curses" option for that. + +I tried it, but it doesn't really work well. Aside from showing 2 cursors, the real problem is that the keymap is all messed up in the guest (whereas it's perfect in Qemu's VGA monitor). + diff --git a/results/classifier/108/other/1713408 b/results/classifier/108/other/1713408 new file mode 100644 index 000000000..b5f4ea9b4 --- /dev/null +++ b/results/classifier/108/other/1713408 @@ -0,0 +1,115 @@ +other: 0.941 +KVM: 0.909 +vnc: 0.906 +graphic: 0.905 +permissions: 0.894 +files: 0.894 +performance: 0.886 +device: 0.880 +debug: 0.879 +semantic: 0.876 +PID: 0.859 +socket: 0.840 +network: 0.825 +boot: 0.793 + +qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to "maxcpus" + +# ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm,kvm-type=HV -m size=20g -device virtio-blk-pci,drive=rootdisk -drive file=/home/nasastry/avocado-fvt-wrapper/data/avocado-vt/images/pegas-1.0-ppc64le.qcow2,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -device nec-usb-xhci -smp 8,cores=1,threads=1,maxcpus=-12 + +(process:12149): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +From GDB: +[New Thread 0x3fffb5aceb60 (LWP 12190)] + +(process:12184): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libgcc-4.8.5-16.el7.ppc64le libstdc++-4.8.5-16.el7.ppc64le ncurses-libs-5.9-13.20130511.el7.ppc64le nss-3.28.4-8.el7.ppc64le nss-softokn-freebl-3.28.3-6.el7.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le +(gdb) bt +#0 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +#1 0x00003fffb796be9c in _g_log_abort () from /lib64/libglib-2.0.so.0 +#2 0x00003fffb796d4c4 in g_log_default_handler () from /lib64/libglib-2.0.so.0 +#3 0x00003fffb796d86c in g_logv () from /lib64/libglib-2.0.so.0 +#4 0x00003fffb796db00 in g_log () from /lib64/libglib-2.0.so.0 +#5 0x00003fffb796b694 in g_malloc0 () from /lib64/libglib-2.0.so.0 +#6 0x000000001018fa84 in spapr_possible_cpu_arch_ids (machine=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:3322 +#7 0x000000001018b444 in spapr_init_cpus (spapr=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2096 +#8 0x000000001018bc6c in ppc_spapr_init (machine=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2275 +#9 0x000000001041ca38 in machine_run_board_init (machine=0x11165660) at hw/core/machine.c:760 +#10 0x000000001037723c in main (argc=24, argv=0x3ffffffff108, envp=0x3ffffffff1d0) at vl.c:4633 +(gdb) i r +r0 0xfa 250 +r1 0x3fffffffe450 70368744170576 +r2 0x3fffb7608100 70367525765376 +r3 0x0 0 +r4 0x2f98 12184 +r5 0x5 5 +r6 0x0 0 +r7 0x3fffa8000020 70367267782688 +r8 0x2f98 12184 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fffb64fccb0 70367507893424 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x1 1 +r19 0x0 0 +r20 0x3fffb796d3f0 70367529325552 +r21 0x0 0 +r22 0x20000000 536870912 +r23 0x1 1 +r24 0x3fffb7a61498 70367530325144 +r25 0x3fffb7a614e8 70367530325224 +r26 0x3fffb7a61488 70367530325128 +r27 0x3fffa80008c0 70367267784896 +r28 0x3fffb79cd2a8 70367529718440 +r29 0x3fffb79cd2a8 70367529718440 +r30 0xffffffffffffffff 18446744073709551615 +r31 0x1 1 +pc 0x3fffb75e5408 0x3fffb75e5408 <raise+56> +msr 0x900000000000d033 10376293541461676083 +cr 0x42244842 1109674050 +lr 0x3fffb796be9c 0x3fffb796be9c <_g_log_abort+60> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x2f98 12184 +trap 0xc00 3072 + +Similar error observed on x86_64 and PPC64LE architectures. + +3308 static const CPUArchIdList *spapr_possible_cpu_arch_ids(MachineState *machine) +3309 { +3310 int i; +3311 int spapr_max_cores = max_cpus / smp_threads; <<<<<< max_cpus is -ve and spapr_max_cores will also be -ve + +... + +3321 +3322 machine->possible_cpus = g_malloc0(sizeof(CPUArchIdList) + +3323 sizeof(CPUArchId) * spapr_max_cores); + +g_malloc0(is getting a -ve value) and then fails with a trap. + +The above I am referring from hw/ppc/spapr.c + + + +Please don't add patches to the bug tracker, post them to the qemu-devel (and qemu-ppc in this case) mailing list instead. You even don't have to join the mailing lists if you don't like to, posting to them is allowed for everybody. See https://www.qemu.org/contribute/report-a-bug/ and http://wiki.qemu.org/Contribute/SubmitAPatch for details. Thanks! + +Looking at your patch, I think you should also check for "<= 0" instead of just "< 0" ... since maxcpus = 0 also does not make much sense. + +Sure will do the changes and update. Seems one of my colleague did it already (sent patch to devel list) +https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05345.html +I will pass your review comments to her for modification. + +Thanks for your review. + +Fixed in master, commit c0dd109919, which will be in the upcoming 2.11 release. + + diff --git a/results/classifier/108/other/1713434 b/results/classifier/108/other/1713434 new file mode 100644 index 000000000..24cbc8641 --- /dev/null +++ b/results/classifier/108/other/1713434 @@ -0,0 +1,489 @@ +device: 0.820 +permissions: 0.809 +graphic: 0.780 +performance: 0.767 +socket: 0.759 +boot: 0.758 +files: 0.751 +other: 0.698 +semantic: 0.664 +PID: 0.660 +debug: 0.654 +vnc: 0.635 +KVM: 0.614 +network: 0.536 + +prom-env-test test aborted and core dumped + +On ppc64le architecture machine the following test case Aborted and Core dumped. + +# tests/prom-env-test --quiet --keep-going -m=quick --GTestLogFD=6 +** +ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed: (qemu != NULL) +Aborted (core dumped) + +Steps to re-produce: +clone from the git +configure & compile +run the unit tests by 'make check' + +(gdb) bt +#0 0x00003fff9d60eff0 in raise () from /lib64/libc.so.6 +#1 0x00003fff9d61136c in abort () from /lib64/libc.so.6 +#2 0x00003fff9de1aa04 in g_assertion_message () from /lib64/libglib-2.0.so.0 +#3 0x00003fff9de1ab0c in g_assertion_message_expr () from /lib64/libglib-2.0.so.0 +#4 0x000000001000cc30 in qtest_get_arch () at tests/libqtest.c:628 +#5 0x00000000100048f0 in main (argc=5, argv=0x3ffff2145538) at tests/prom-env-test.c:82 +(gdb) i r +r0 0xfa 250 +r1 0x3ffff2144d30 70368510627120 +r2 0x3fff9d7b9900 70367091333376 +r3 0x0 0 +r4 0x12a7 4775 +r5 0x6 6 +r6 0x8 8 +r7 0x1 1 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fff9dfa1950 70367099623760 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x0 0 +r19 0x0 0 +r20 0x0 0 +r21 0x0 0 +r22 0x0 0 +r23 0x0 0 +r24 0x0 0 +r25 0x0 0 +r26 0x0 0 +r27 0x100287f8 268601336 +r28 0x16841b40 377756480 +r29 0x4c 76 +r30 0x3ffff2144de8 70368510627304 +r31 0x6 6 +pc 0x3fff9d60eff0 0x3fff9d60eff0 <raise+96> +msr 0x900000000280f033 10376293541503627315 +cr 0x42000842 1107298370 +lr 0x3fff9d61136c 0x3fff9d61136c <abort+396> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x12a7 4775 +trap 0xc00 3072 + +When running tests directly, you've got to specify the QEMU binary like this: + +QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/prom-env-test --quiet --keep-going -m=quick + +But the abort() is indeed ugly here and I think we should print out a user-friendly error message instead. + +The actual failure was the following + + LINK tests/test-hmp + GTESTER check-qtest-ppc64 +** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +GTester: last random seed: R02Sfb567618f7c703a032934c0c11e263c6 +make: *** [check-qtest-ppc64] Error 1 + +But I was going through found the above was aborting. so reported here. + + +The "ERROR:tests/prom-env-test.c:42:check_guest_memory" error is a timeout error... is it reproducible? Was the host you're testing on very loaded at that point in time? + +Host was not loaded at that time. And can be re-producable all the times + + GTESTER check-qtest-ppc64 +** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +GTester: last random seed: R02S5625099e4ad7700238a4e83dbd6576e0 + +this is with new seed. + + +That works for me - no problems with tests/prom-env-test on a POWER8 little endian system here. What host system are you using? Could you also check what happens if you run QEMU directly like this, and post the console output here: + +ppc64-softmmu/qemu-system-ppc64 -nographic -M pseries,accel=tcg -nodefaults -serial stdio -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr power-off' + + +I am using a Power9 machine. + +# ppc64-softmmu/qemu-system-ppc64 -nographic -M pseries,accel=tcg -nodefaults -serial stdio -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr power-off' + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 24 2017 15:15:46 + FW Version = git-89f519f09bf85091 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /pci@800000020000000 +(!) Executing code specified in nvramrc + SLOF Setup = Hello World! + +Hmm, that looks like -prom-env is working correctly with the pseries machine. I wonder whether the problem is somewhere else... Could you please run "make check-qtest-ppc64 V=1" to see whether it rather fails for the mac99 or g3beige machines? + +TEST: tests/prom-env-test... (pid=9915) + /ppc64/prom-env/mac99: OK + /ppc64/prom-env/g3beige: OK + /ppc64/prom-env/pseries: ** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +FAIL +GTester: last random seed: R02S765f0e192be9c96e793728ecc28d6395 +(pid=10152) +FAIL: tests/prom-env-test + +Weird. I managed to run the test on a POWER9 box today, too, and it works for me: + +TEST: tests/prom-env-test... (pid=18912) + /ppc64/prom-env/mac99: OK + /ppc64/prom-env/g3beige: OK + /ppc64/prom-env/pseries: OK +PASS: tests/prom-env-test + +Which OS and C compiler are you using? + +Also, could you please try to add this patch (to add "-serial /dev/stderr") and then post the console output of the prom-env-test: + +diff --git a/tests/prom-env-test.c b/tests/prom-env-test.c +--- a/tests/prom-env-test.c ++++ b/tests/prom-env-test.c +@@ -51,7 +51,7 @@ static void test_machine(const void *machine) + extra_args = strcmp(machine, "pseries") == 0 ? "-nodefaults" : ""; + + args = g_strdup_printf("-M %s,accel=tcg %s -prom-env 'use-nvramrc?=true' " +- "-prom-env 'nvramrc=%x %x l!' ", ++ "-prom-env 'nvramrc=%x %x l!' -serial /dev/stderr", + (const char *)machine, extra_args, MAGIC, ADDRESS); + + qtest_start(args); + + +Strange, + +# gcc --version +gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) +Copyright (C) 2015 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +OS is RHEL based. +# uname -a +Linux host 4.11.0-26.el7a.ppc64le #1 SMP Wed Aug 23 17:27:28 EDT 2017 ppc64le ppc64le ppc64le GNU/Linux + +TEST: tests/prom-env-test... (pid=6726) + /ppc64/prom-env/mac99: +>> ============================================================= +>> OpenBIOS 1.1 [Jul 13 2017 18:28] +>> Configuration device id QEMU version 1 machine id 3 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,970FX +milliseconds isn't unique. +OK + /ppc64/prom-env/g3beige: +>> ============================================================= +>> OpenBIOS 1.1 [Jul 13 2017 18:28] +>> Configuration device id QEMU version 1 machine id 2 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,750 +milliseconds isn't unique. +OK + /ppc64/prom-env/pseries: + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 24 2017 15:15:46 + FW Version = git-89f519f09bf85091 + Press "s" to enter Open Firmware. + +**500 +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +FAIL +GTester: last random seed: R02Sf6897626ac2ebaf5edd7aa24cc1999df +(pid=6951) +FAIL: tests/prom-env-test + +Very weird, looks like SLOF crashed at a very early stage here. I've got no further clue how to debug this ... could you maybe try it on another POWER9 host if possible? Or check whether slof.bin accidentially got corrupted (md5sum pc-bios/slof.bin should give you db83598b28052e9c12972d86c37b0c69)? Or maybe you could also ask Nikunj to have a look at this? + +# md5sum ./pc-bios/slof.bin +db83598b28052e9c12972d86c37b0c69 ./pc-bios/slof.bin + +Same as what you mentioned. + +Will try to get a different machine and try. If the problem still persists, I will check with Nikunj. + +Thanks a lot for your time. I have learned many things while interacting with you. + +On other machine with same OS and gcc level, it's working fine. Not getting what went wrong in the machine where I can re-produce this issue. +I guess this bug can be closed. Thank you. + + /ppc64/prom-env/pseries: + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 24 2017 15:15:46 + FW Version = git-89f519f09bf85091 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /pci@800000020000000 +(!) Executing code specified in nvramrc + SLOF Setup = OK +PASS: tests/prom-env-test + + + +OK, thanks for testing! Anyway, I'll keep the bug opened to track the original issue that you've mentioned in the description ("ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed") here. + +Similar failure seen with the following test too. + +# make check-qtest-sparc64 V=1 +(cd /home/nasastry/qemu; printf '#define QEMU_PKGVERSION '; if test -n ""; then printf '""\n'; else if test -d .git; then printf '" ('; git describe --match 'v*' 2>/dev/null | tr -d '\n'; if ! git diff-index --quiet HEAD &>/dev/null; then printf -- '-dirty'; fi; printf ')"\n'; else printf '""\n'; fi; fi) > qemu-version.h.tmp +if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi +make -C /home/nasastry/qemu/capstone CAPSTONE_SHARED=no BUILDDIR="/home/nasastry/qemu/capstone" CC="cc" AR="ar" LD="ld" CFLAGS="-fprofile-arcs -ftest-coverage -g -g -I/usr/include/pixman-1 -DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNCURSES_WIDECHAR -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/include/libpng15 -I/home/nasastry/qemu/capstone/include -I/home/nasastry/qemu/tests -DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86" BUILD_DIR=/home/nasastry/qemu /home/nasastry/qemu/capstone/libcapstone.a +make[1]: Entering directory `/home/nasastry/qemu/capstone' +make[1]: `/home/nasastry/qemu/capstone/libcapstone.a' is up to date. +make[1]: Leaving directory `/home/nasastry/qemu/capstone' +make BUILD_DIR=/home/nasastry/qemu -C sparc64-softmmu V="1" TARGET_DIR="sparc64-softmmu/" all +make[1]: Entering directory `/home/nasastry/qemu/sparc64-softmmu' +make[1]: Leaving directory `/home/nasastry/qemu/sparc64-softmmu' +QTEST_QEMU_BINARY=sparc64-softmmu/qemu-system-sparc64 QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/endianness-test tests/prom-env-test tests/qmp-test tests/device-introspect-test tests/qom-test tests/test-hmp +TEST: tests/endianness-test... (pid=72117) + /sparc64/endianness/sun4u: OK + /sparc64/endianness/split/sun4u: OK + /sparc64/endianness/combine/sun4u: OK +PASS: tests/endianness-test +TEST: tests/prom-env-test... (pid=72128) + /sparc64/prom-env/sun4u: ** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x00000000 == 0xcafec0de) +FAIL +GTester: last random seed: R02S54a8565ad2895d49d8d1b0dc99da7044 +(pid=74068) +FAIL: tests/prom-env-test +TEST: tests/qmp-test... (pid=74069) + /sparc64/qmp/protocol: OK + /sparc64/qmp/qom-list-types: OK + /sparc64/qmp/query-acpi-ospm-status: OK + /sparc64/qmp/query-balloon: OK + /sparc64/qmp/query-block: OK + /sparc64/qmp/query-block-jobs: OK + /sparc64/qmp/query-blockstats: OK + /sparc64/qmp/query-chardev: OK + /sparc64/qmp/query-chardev-backends: OK + /sparc64/qmp/query-command-line-options: OK + /sparc64/qmp/query-commands: OK + /sparc64/qmp/query-cpus: OK + /sparc64/qmp/query-dump: OK + /sparc64/qmp/query-dump-guest-memory-capability: OK + /sparc64/qmp/query-events: OK + /sparc64/qmp/query-fdsets: OK + /sparc64/qmp/query-hotpluggable-cpus: OK + /sparc64/qmp/query-iothreads: OK + /sparc64/qmp/query-kvm: OK + /sparc64/qmp/query-machines: OK + /sparc64/qmp/query-memdev: OK + /sparc64/qmp/query-memory-devices: OK + /sparc64/qmp/query-memory-size-summary: OK + /sparc64/qmp/query-mice: OK + /sparc64/qmp/query-migrate: OK + /sparc64/qmp/query-migrate-cache-size: OK + /sparc64/qmp/query-migrate-capabilities: OK + /sparc64/qmp/query-migrate-parameters: OK + /sparc64/qmp/query-name: OK + /sparc64/qmp/query-named-block-nodes: OK + /sparc64/qmp/query-qmp-schema: OK + /sparc64/qmp/query-rx-filter: OK + /sparc64/qmp/query-spice: OK + /sparc64/qmp/query-status: OK + /sparc64/qmp/query-target: OK + /sparc64/qmp/query-tpm: OK + /sparc64/qmp/query-tpm-models: OK + /sparc64/qmp/query-tpm-types: OK + /sparc64/qmp/query-uuid: OK + /sparc64/qmp/query-version: OK + /sparc64/qmp/query-vm-generation-id: OK + /sparc64/qmp/query-vnc: OK + /sparc64/qmp/query-vnc-servers: OK + /sparc64/qmp/query-xen-replication-status: OK +PASS: tests/qmp-test +TEST: tests/device-introspect-test... (pid=74165) + /sparc64/device/introspect/list: OK + /sparc64/device/introspect/list-fields: OK + /sparc64/device/introspect/none: OK + /sparc64/device/introspect/abstract: OK + /sparc64/device/introspect/concrete: OK + /sparc64/device/introspect/abstract-interfaces: OK +PASS: tests/device-introspect-test +TEST: tests/qom-test... (pid=74181) + /sparc64/qom/sun4v: OK + /sparc64/qom/none: OK + /sparc64/qom/sun4u: OK + /sparc64/qom/niagara: OK +PASS: tests/qom-test +TEST: tests/test-hmp... (pid=74199) + /sparc64/hmp/sun4v: OK + /sparc64/hmp/none: OK + /sparc64/hmp/sun4u: OK + /sparc64/hmp/niagara: OK + /sparc64/hmp/none+2MB: OK +PASS: tests/test-hmp +make: *** [check-qtest-sparc64] Error 1 + +Is that 100% reproducible? Which version of QEMU did you use here? And which host are you using, POWER9 again? The very latest git master branch is using a timeout of 10 minutes now, so that should be sufficient for all cases... + +Could you please try to run this manually: + +qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' + +... and then paste the output here? + +Git head is at 299d1ea9bb56bd9f45f905125489bdd7d543a1aa +latest today + +100% re-producible. This is different & working Power9 machine than the other day. + +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Unhandled Exception 0x0000000000000034 +PC = 0x00000000ffd0f704 NPC = 0x00000000ffd0f708 +Stopping execution + +and hung here. Not responding to ctrl+c or ctrl+z. + + + + + +Here is the md5sum of openbios-sparc64 + +# md5sum ./pc-bios/openbios-sparc64 +15418a4c9429d9ee9c637701b94c7ffb ./pc-bios/openbios-sparc64 + +> Could you please check with the QEMU 2.10 release to see whether this is a regression or whether it was already failing there? +Sure, I will update here. Most probably tomorrow. + +> I don't have access to POWER9 anymore, so I can't check this right now +No issues, I can check. + +> To quit QEMU, you've got to press "CTRL-a c" and then type "quit" at the monitor prompt. +Thank you. I am learning new things along with raising bugs :-) + +This test case was working till 2.10.0 and got broken in 2.10.1 + +I checked with 2.9.1, 2.10.0-rc2, 2.10.0-rc3, 2.10.0-rc4, 2.10.0 + +Working scenario: +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Hello World! +Welcome to OpenBIOS v1.1 built on Jul 13 2017 18:27 + Type 'help' for detailed information +Trying disk:a... +No valid state has been set by load or init-program + +0 > QEMU 2.10.0 monitor - type 'help' for more information +(qemu) quit + +The above problem is getting re-producible only with configure option "--enable-crypto-afalg" This got introduced in between 2.9.1 and 2.10.0. I will bisect it and update. + +When I tried earlier with 2.9.1 it complained saying "--enable-crypto-afalg" option is not available so I did with out it and continued that's the reason why it worked with 2.10.0 and till rc4. +Tested 2.10.1 with configure option "--enable-crypto-afalg" so it failed. + +So this information made me to say it broke in 2.10.1. + +When I disable this option "crypto-afalg" in 2.10.1 it's working fine and same with latest qemu (git head is at a4f0537db0cd68fa2da097995f6ec00747ca453c) + +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Hello World! +Welcome to OpenBIOS v1.1 built on Oct 19 2017 06:59 + Type 'help' for detailed information +Trying disk:a... +No valid state has been set by load or init-program + +0 > QEMU 2.10.50 monitor - type 'help' for more information +(qemu) quit + + + +After talking to Mark Cave-Ayland over e-mail, to make sure I have the proper versions of OpenBIOS binaries - removed the existing git tree and with a fresh clone not seeing the 'qemu-system-sparc64' related crash. +Before cleanup I was seeing the crash all the times. +Thanks!! + +Some times it's still puzzling, when I got the clean git tree still seeing crash with correct OpenBIOS file. + +[root@zzfp365-lp1 test]# git clone git://git.qemu.org/qemu.git +Cloning into 'qemu'... +remote: Counting objects: 349636, done. +remote: Compressing objects: 100% (66763/66763), done. +remote: Total 349636 (delta 284434), reused 346628 (delta 282016) +Receiving objects: 100% (349636/349636), 112.12 MiB | 1.28 MiB/s, done. +Resolving deltas: 100% (284434/284434), done. + +[root@zzfp365-lp1 qemu]# md5sum ./pc-bios/openbios-sparc64 +15418a4c9429d9ee9c637701b94c7ffb ./pc-bios/openbios-sparc64 + +[root@zzfp365-lp1 qemu]# git pull +Already up-to-date. + +did configure: +./configure --enable-attr --enable-bsd-user --enable-cap-ng --enable-coroutine-pool --enable-crypto-afalg --enable-curl --enable-curses --enable-debug --enable-debug-info --enable-debug-tcg --enable-fdt --enable-gcrypt --enable-gnutls --enable-gprof --enable-gtk --enable-guest-agent --enable-kvm --enable-libiscsi --enable-libssh2 --enable-linux-aio --enable-linux-user --enable-live-block-migration --enable-modules --enable-numa --enable-pie --enable-profiler --enable-qom-cast-debug --enable-rbd --enable-replication --enable-seccomp --enable-smartcard --enable-stack-protector --enable-system --enable-tcg --enable-tcg-interpreter --enable-tools --enable-tpm --enable-trace-backend=ftrace --enable-user --enable-vhost-net --enable-vhost-scsi --enable-vhost-user --enable-vhost-vsock --enable-virtfs --enable-vnc --enable-tpm --enable-vnc-png --enable-vnc-sasl --enable-werror --enable-xfsctl --enable-gcov --enable-debug-stack-usage + +make -j 32 + +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Unhandled Exception 0x0000000000000034 +PC = 0x00000000ffd0f704 NPC = 0x00000000ffd0f708 +Stopping execution +QEMU 2.10.90 monitor - type 'help' for more information +(qemu) quit + +# md5sum ./pc-bios/openbios-sparc64 +15418a4c9429d9ee9c637701b94c7ffb ./pc-bios/openbios-sparc64 + +git head is at b0fbe46ad82982b289a44ee2495b59b0bad8a842 + +Thomas thanks for your hint about the configuration option named "--enable-tcg-interpreter". By removing it the test case started working fine. + +[root@zzfp365-lp1 qemu]# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Hello World! +Welcome to OpenBIOS v1.1 built on Oct 19 2017 06:59 + Type 'help' for detailed information +Trying disk:a... +No valid state has been set by load or init-program + +0 > QEMU 2.10.90 monitor - type 'help' for more information +(qemu) quit + +OK, so this was "only" the TCG-interpreter that was causing the sparc64 problem here. Since there are known issues with the TCG-interpreter on certain architectures, this is not really related to the prom-env-test. And since the fix for the original "ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed" problem has been committed already ("commit db221e66d8117f8"), I'm marking the status of this bug now accordingly. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=db221e66d8117f810c804 + diff --git a/results/classifier/108/other/1713516 b/results/classifier/108/other/1713516 new file mode 100644 index 000000000..6ccc7e354 --- /dev/null +++ b/results/classifier/108/other/1713516 @@ -0,0 +1,104 @@ +other: 0.889 +device: 0.790 +graphic: 0.785 +permissions: 0.751 +semantic: 0.750 +vnc: 0.746 +network: 0.742 +debug: 0.735 +performance: 0.723 +files: 0.705 +KVM: 0.678 +boot: 0.667 +socket: 0.665 +PID: 0.607 + +qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to smp threads, cores + +After fixing other bug, +https://bugs.launchpad.net/qemu/+bug/1713408 +with the proposed patch +http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05357.html + +When tried smp core and thread as negative numbers seeing the following similar error. There is a need to fix for the following. + +Instead of fixing it for every variable/argument. Is there a common place to fix all of these issues? + + +cloned today's git (i.e. 28th Aug 2017) + +# ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm,kvm-type=HV -m size=200g -device virtio-blk-pci,drive=rootdisk -drive file=/home/nasastry/avocado-fvt-wrapper/data/avocado-vt/images/pegas-1.0-ppc64le.qcow2,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -device nec-usb-xhci -smp 8,cores=-1,threads=-1,maxcpus=12 + +(process:27477): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes +Trace/breakpoint trap + +[New Thread 0x3fffb63deb60 (LWP 27731)] +[New Thread 0x3fffb5aceb60 (LWP 27734)] + +(process:27726): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libgcc-4.8.5-16.el7.ppc64le libstdc++-4.8.5-16.el7.ppc64le ncurses-libs-5.9-13.20130511.el7.ppc64le nss-3.28.4-8.el7.ppc64le nss-softokn-freebl-3.28.3-6.el7.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le +(gdb) bt +#0 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +#1 0x00003fffb796be9c in _g_log_abort () from /lib64/libglib-2.0.so.0 +#2 0x00003fffb796d4c4 in g_log_default_handler () from /lib64/libglib-2.0.so.0 +#3 0x00003fffb796d86c in g_logv () from /lib64/libglib-2.0.so.0 +#4 0x00003fffb796db00 in g_log () from /lib64/libglib-2.0.so.0 +#5 0x00003fffb796b694 in g_malloc0 () from /lib64/libglib-2.0.so.0 +#6 0x000000001018fa84 in spapr_possible_cpu_arch_ids (machine=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:3322 +#7 0x000000001018b444 in spapr_init_cpus (spapr=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2096 +#8 0x000000001018bc6c in ppc_spapr_init (machine=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2275 +#9 0x000000001041ca80 in machine_run_board_init (machine=0x111651e0) at hw/core/machine.c:760 +#10 0x0000000010377284 in main (argc=22, argv=0x3ffffffff128, envp=0x3ffffffff1e0) at vl.c:4638 +(gdb) i r +r0 0xfa 250 +r1 0x3fffffffe470 70368744170608 +r2 0x3fffb7608100 70367525765376 +r3 0x0 0 +r4 0x6c4e 27726 +r5 0x5 5 +r6 0x0 0 +r7 0x3fffa8000020 70367267782688 +r8 0x6c4e 27726 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fffb64fccb0 70367507893424 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x1 1 +r19 0x0 0 +r20 0x3fffb796d3f0 70367529325552 +r21 0x0 0 +r22 0x20000000 536870912 +r23 0x1 1 +r24 0x3fffb7a61498 70367530325144 +r25 0x3fffb7a614e8 70367530325224 +r26 0x3fffb7a61488 70367530325128 +r27 0x3fffa80008c0 70367267784896 +r28 0x3fffb79cd2a8 70367529718440 +r29 0x3fffb79cd2a8 70367529718440 +r30 0xffffffffffffffff 18446744073709551615 +r31 0x1 1 +pc 0x3fffb75e5408 0x3fffb75e5408 <raise+56> +msr 0x900000000000d033 10376293541461676083 +cr 0x42244842 1109674050 +lr 0x3fffb796be9c 0x3fffb796be9c <_g_log_abort+60> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x6c4e 27726 +trap 0xc00 3072 + +I've confirmed with Seeteena and this bug was fixed by commit https://git.qemu.org/?p=qemu.git;a=commit;h=c0dd10991903c552811d8cbe9231055b1b3a7ebd + +commit c0dd10991903c552811d8cbe9231055b1b3a7ebd +Author: Seeteena Thoufeek <email address hidden> +Date: Mon Sep 4 13:13:51 2017 +0530 + + vl: exit if maxcpus is negative + diff --git a/results/classifier/108/other/1713825 b/results/classifier/108/other/1713825 new file mode 100644 index 000000000..4ffdbe75e --- /dev/null +++ b/results/classifier/108/other/1713825 @@ -0,0 +1,109 @@ +other: 0.975 +permissions: 0.964 +graphic: 0.963 +semantic: 0.959 +performance: 0.944 +device: 0.925 +network: 0.908 +debug: 0.904 +files: 0.902 +PID: 0.882 +boot: 0.877 +socket: 0.877 +vnc: 0.796 +KVM: 0.790 + +Booting Windows 2016 with qxl video crashes qemu + +launched from libvirt. + +qemu version: 2.9.0 +host: Linux <hostname> 4.9.34-gentoo #1 SMP Sat Jul 29 13:28:43 PDT 2017 x86_64 Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz GenuineIntel GNU/Linux +guest: Windows 2016 64 bit + +Thread 28 (Thread 0x7f0e2edff700 (LWP 29860)): +#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 + set = {__val = {18446744067266837079, 139698892694944, 139699853745096, 139700858749789, 4222451712, 139694281220640, 139694281220741, 139694281220640, 139694281220640, 139694281220810, + 139694281220940, 139694281220640, 139694281220940, 0, 0, 0}} + pid = <optimized out> + tid = <optimized out> +#1 0x00007f0ea40b644a in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x7f0e2edfe5c0, sa_sigaction = 0x7f0e2edfe5c0}, sa_mask = {__val = {139694281219872, 139698106269697, 139698892695344, 4, 2676511744, 0, 139698892695144, 0, + 139698892694912, 1, 4737316546111099904, 139700859888720, 4737316546111099904, 139700862161824, 139700911349760, 94211934977482}}, sa_flags = 416, + sa_restorer = 0x55af6ceb0500 <__PRETTY_FUNCTION__.36381>} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007f0ea40abab6 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55af6ceafdca "offset < qxl->vga.vram_size", + file=file@entry=0x55af6ceaeaa0 "/var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c", line=line@entry=416, + function=function@entry=0x55af6ceb0500 <__PRETTY_FUNCTION__.36381> "qxl_ram_set_dirty") at assert.c:92 + str = 0x7f0d1c026220 "\340r\002\034\r\177" + total = 4096 +#3 0x00007f0ea40abb81 in __GI___assert_fail (assertion=assertion@entry=0x55af6ceafdca "offset < qxl->vga.vram_size", + file=file@entry=0x55af6ceaeaa0 "/var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c", line=line@entry=416, + function=function@entry=0x55af6ceb0500 <__PRETTY_FUNCTION__.36381> "qxl_ram_set_dirty") at assert.c:101 +No locals. +#4 0x000055af6cc58805 in qxl_ram_set_dirty (qxl=<optimized out>, ptr=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c:416 + base = <optimized out> + offset = <optimized out> + qxl = <optimized out> + ptr = <optimized out> + base = <optimized out> + offset = <optimized out> +#5 0x000055af6cc5b9e2 in interface_release_resource (sin=0x55af71a91ed0, ext=...) at /var/tmp/portage/app-emulation/qemu-2.9.0-r2/work/qemu-2.9.0/hw/display/qxl.c:767 + qxl = 0x55af71a91450 + ring = <optimized out> + item = <optimized out> + id = 18446690739814400920 + __func__ = "interface_release_resource" +#6 0x00007f0ea510afa8 in red_drawable_unref (red_drawable=0x7f0d1c026120) at red-worker.c:101 +No locals. +#7 0x00007f0ea510b609 in red_drawable_unref (red_drawable=<optimized out>) at red-worker.c:104 +No locals. +#8 0x00007f0ea510eae9 in drawable_unref (drawable=drawable@entry=0x7f0e68285ac0) at display-channel.c:1438 + display = 0x55af71dbd3c0 + __FUNCTION__ = "drawable_unref" +#9 0x00007f0ea51109f7 in draw_until (display=display@entry=0x55af71dbd3c0, surface=surface@entry=0x7f0e6828aae8, last=0x7f0e68285ac0) at display-channel.c:1637 + container = 0x0 + now = 0x7f0e68285ac0 +#10 0x00007f0ea510f93f in display_channel_draw (display=0x55af71dbd3c0, area=0x7f0e2edfe8e0, surface_id=<optimized out>) at display-channel.c:1729 + surface = 0x7f0e6828aae8 + last = <optimized out> + __FUNCTION__ = "display_channel_draw" + __func__ = "display_channel_draw" + +I reproduce it on 2.10.0 + +Hi Maciej, + Can you clarify: + a) What version of the qxl drivers you have installed in windows + b) Does it crash immediately or only when you do something specific? + c) Can you give the qemu command line and/or libvirt xml + d) What resolution have you got the guest set at? + e) What version are your spice-server libraries at? + +Sorry - email with reply got misdirected in inbox: + +a) qxldod.sys 02/20/2017,10.0.0.16000 +b) Immediately during boot. I assume during loading the driver +c) Attached working configuration. For repro I change cirrus to qxl and delete arguments to have defaults set by libvirt. +d) 1920x1080 I think. I cannot double check as it, well, crashes +e) 0.13.90 + +Doesn't reproduce. It's a newer driver though (10.0.0.18000). +Does updating the driver help? + +It helps but I'm quite sure that lower level security systems (guest) should never be able to crash higher level security systems (hypervisor). + +PS. It repros in 2.10.0 as well. + +Guest triggerable assert() isn't exactly nice indeed. +But it's not a show stopper. +It doesn't allow exploiting the host, the guest can only DoS itself. +And you must be priviledged in the guest to do so. + +Most likely this is the driver placing the qxl commands in the wrong pci bar. See commit 86dbcdd9c7590d06db89ca256c5eaf0b4aba8858. Seems the impact is more than breaking live migration. So, I can raise a error irq and have qxl enter guest bug mode. That doesn't improve the situation much though, the guest will continue running but you will have broken display ... + +Does this issue still persist with the latest version of QEMU/libvirt/qxl-drivers ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1714 b/results/classifier/108/other/1714 new file mode 100644 index 000000000..cc4e01532 --- /dev/null +++ b/results/classifier/108/other/1714 @@ -0,0 +1,42 @@ +graphic: 0.904 +device: 0.822 +performance: 0.702 +other: 0.598 +semantic: 0.552 +socket: 0.479 +vnc: 0.477 +boot: 0.436 +debug: 0.425 +network: 0.421 +permissions: 0.406 +PID: 0.404 +KVM: 0.207 +files: 0.192 + +QEMU crashes on ARMv7 since at least commit 493c9b19 +Description of problem: +I'm trying to build QEMU for Android, Arm64 versions work well, but **Armv7** builds began to crash nearly since this series of commits (QEMU 7.2.50), related to 'TCG_TARGET_HAS_direct_jump' removal by @rth7680. +More precisely, this commit still works: + +https://gitlab.com/qemu-project/qemu/-/commit/82df11e78d0baef7ffb7e7933c6fb830ffed087c + +and this one crashes: + +https://gitlab.com/qemu-project/qemu/-/commit/493c9b19a7fb7f387c4fcf57d3836504d5242bf5 + +(I tracked commits of 'tcg' subfolder and didn't bisect finer, but it's possible if needed). + +Both qemu-system-x86_64 and qemu-system-i386 emulators crash. + +**The crash is related to translation buffer size** : if I don't specify "-accel tcg,thread=single **,tb-size=256** ", the machine works. + +The problem is that I can not run debugger on a phone, and crash dump does not show any useful information, just "segfault" reason ("Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe19b8000"). + +Even more, the Linux starts and runs, but it crashes only when I'm trying to run the GIMP, between splash screen and main interface appearance. + +I know that 1) Android is not officially supported and 2) 32-bit hosts were considered deprecated recently, but maybe it's possible to do something with these crashes? + +Recent master (https://gitlab.com/qemu-project/qemu/-/commit/5692a39f329413a00020a61fff95aff6b9884a73) doesn't work as well. +All 8.0.x Arm64 builds are runnable. + +Thanks in advance. diff --git a/results/classifier/108/other/1714331 b/results/classifier/108/other/1714331 new file mode 100644 index 000000000..51da3a8f6 --- /dev/null +++ b/results/classifier/108/other/1714331 @@ -0,0 +1,600 @@ +other: 0.816 +debug: 0.711 +KVM: 0.691 +performance: 0.686 +semantic: 0.675 +graphic: 0.650 +device: 0.648 +permissions: 0.641 +vnc: 0.624 +network: 0.622 +boot: 0.586 +files: 0.579 +PID: 0.566 +socket: 0.549 + +Virtual machines not working anymore on 2.10 + +Using 2.10, my virtual machine(s) don't work anymore. This happens 100% of the times. + +----- + +I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is the configure command: + + configure --target-list=x86_64-softmmu --enable-debug --enable-gtk --enable-spice --audio-drv-list=pa + +I have one virtual disk, with a Windows 10 64-bit, which I launch in two different ways; both work perfectly on 2.9 (and used to do on 2.8, but I haven't used it for a long time). + +This is the first way: + + qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 4096 + -display gtk + -vga qxl + -rtc base=localtime + -serial none + -parallel none + -usb + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user + +On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be repaired` windows screen; on 2.9, it boots regularly. + +This is the second way: + + qemu-system-x86_64 + -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp + -enable-kvm + -machine q35,accel=kvm,mem-merge=off + -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time + -smp 4,cores=4,sockets=1,threads=1 + -m 10240 + -vga none + -rtc base=localtime + -serial none + -parallel none + -usb + -device vfio-pci,host=01:00.0,multifunction=on + -device vfio-pci,host=01:00.1 + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device usb-host,vendorid=0xNNNN,productid=0xNNNN + -device virtio-scsi-pci,id=scsi + -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback + -device scsi-hd,drive=hdd1 + -net nic,model=virtio + -net user + +On QEMU 2.10, I get the debug window on the linux monitor, and blank screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU crashes without any message. +On 2.9, this works perfectly. + +----- + +I am able to perform a git bisect, if that helps, but if this is the case, I'd need this issue to be reviewed, since bisecting is going to take me a lot of time. + +Please try: -machine pc-q35-2.9,accel=kvm,mem-merge=off + +I'm not sure if it will make a difference in this case but it presents exactly the same onboard hardware as QEMU 2.9. The onboard hardware configuration may change unless you specify a precise version in the machine type, so I suggest using it instead of "q35". + +Did you build QEMU 2.9 from source with the same ./configure options? + +> Please try: -machine pc-q35-2.9,accel=kvm,mem-merge=off + +I've tried the first configuration (windowed) with the change you proposed, and I get the same behavior (windows recovery); I didnt' try the second configuration (VFIO). + +> Did you build QEMU 2.9 from source with the same ./configure options? + +Yes, you can see the command at the beginning of the bug report. + +I am also unable to boot Windows 10 64 bit since updating to 2.10.0. I was previously using 2.8.0 which worked perfectly. Windows gets stuck at the big Windows logo with the spinning dots underneath and QEMU uses 100% CPU of 1 core. I am using kernel 4.11.9 and the following command line: + +qemu-system-x86_64 +-serial none +-parallel none +-balloon none +-enable-kvm +-name Windows10 +-display none +-M q35,accel=kvm,mem-merge=off +-m 10240 +-cpu host,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_vendor_id=whatever +-smp 4,sockets=1,cores=4,threads=1 +-realtime mlock=on +-vga none +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 +-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on +-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 +-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/OVMF_CODE-pure-efi.fd +-drive if=pflash,format=raw,file=/usr/share/ovmf/OVMF_VARS-pure-efi.fd +-drive if=none,id=drive0,cache=directsync,aio=native,format=raw,file=/dev/mint-vg/windows +-object iothread,id=iothread0 +-device virtio-blk-pci,drive=drive0,scsi=off,iothread=iothread0 +-drive if=none,id=drive1,cache=directsync,aio=native,format=raw,file=/dev/evo-vg/windows2 +-object iothread,id=iothread1 -device virtio-blk-pci,drive=drive1,scsi=off,iothread=iothread1 +-net nic,model=virtio +-net bridge,br=br0 +-rtc base=localtime,clock=host +-usb +-device usb-host,bus=usb-bus.0,vendorid=0x1b1c,productid=0x1b22 +-device usb-host,bus=usb-bus.0,vendorid=0x1b1c,productid=0x1b15 + +I have now rolled back to 2.8.0 and it is working again. + + +Mary: If you have time to run a git bisect that would be very helpful, thanks! + + $ git bisect v2.10.0 v2.9.0 + +OK, I'll do that. It will take me a bit of time - I'll timeframe a week. + +Note that I can't know if both VFIO and non-VFIO context suffer the same bug. For simplicity, I'll peform the bisect using the non-VFIO version, then, once we have more information, we can decide how to proceed. + +I think my issue looks like the same. Sometimes I just get spinning dots, and sometimes there is the message about doing an automatic repair below the spinning dots before it stops and uses 100% cpu. I just did a git bisect: + +# git bisect log +# bad: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for v2.10.0 release +# good: [6c02258e143700314ebf268dae47eb23db17d1cf] Update version for v2.9.0 release +git bisect start 'v2.10.0' 'v2.9.0' +# bad: [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +git bisect bad 269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +# bad: [eba0161990af8509608332450ee7e338273cf5df] Merge remote-tracking branch 'rth/tags/pull-s390-20170512' into staging +git bisect bad eba0161990af8509608332450ee7e338273cf5df +# good: [9ea5ada76f34a0ef048b131c3a166d8564199bdb] audio: Use ARRAY_SIZE from qemu/osdep.h +git bisect good 9ea5ada76f34a0ef048b131c3a166d8564199bdb +# bad: [1effe6ad5eac1b2e50a077695ac801d172891d6a] Merge remote-tracking branch 'danpb/tags/pull-qcrypto-2017-05-09-1' into staging +git bisect bad 1effe6ad5eac1b2e50a077695ac801d172891d6a +# good: [f03f9f0c10dcfadee5811d43240f0a6af230f1ce] Merge remote-tracking branch 'cohuck/tags/s390x-3270-20170504' into staging +git bisect good f03f9f0c10dcfadee5811d43240f0a6af230f1ce +# good: [6c02258e143700314ebf268dae47eb23db17d1cf] qobject-input-visitor: Document full_name_nth() +git bisect good 6c02258e143700314ebf268dae47eb23db17d1cf +# bad: [95615ce5a1beffff1a5dd3597d8cb6ba83f0010e] vhost-scsi: create a vhost-scsi-common abstraction +git bisect bad 95615ce5a1beffff1a5dd3597d8cb6ba83f0010e +# bad: [31f5a726b59bda5580e2f9413867893501dd7d93] trace: add qemu mutex lock and unlock trace events +git bisect bad 31f5a726b59bda5580e2f9413867893501dd7d93 +# bad: [49e00a18708e27c815828d9440d5c9300d19547c] use _Static_assert in QEMU_BUILD_BUG_ON +git bisect bad 49e00a18708e27c815828d9440d5c9300d19547c +# bad: [6103451aeb749e92bf7d730429985189c6921c32] hw/i386: Build-time assertion on pc/q35 reset register being identical. +git bisect bad 6103451aeb749e92bf7d730429985189c6921c32 +# bad: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +git bisect bad 77af8a2b95b79699de650965d5228772743efe84 +# first bad commit: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. + + + +77af8a2b95b79699de650965d5228772743efe84 is the first bad commit +commit 77af8a2b95b79699de650965d5228772743efe84 +Author: Phil Dennis-Jordan <email address hidden> +Date: Wed Mar 15 19:20:26 2017 +1300 + + hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. + + This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register. + + The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions. + + The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content. + + Signed-off-by: Phil Dennis-Jordan <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +:040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M hw +:040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M include +:040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M tests + + +On Tue, Sep 05, 2017 at 06:42:06PM -0000, Chris Unsworth wrote: +> I think my issue looks like the same. Sometimes I just get spinning +> dots, and sometimes there is the message about doing an automatic repair +> below the spinning dots before it stops and uses 100% cpu. I just did a +> git bisect: + +Perfect, thanks Chris! + +I have CCed Phil and Paolo regarding the commit you identified. + +> +> # git bisect log +> # bad: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for v2.10.0 release +> # good: [6c02258e143700314ebf268dae47eb23db17d1cf] Update version for v2.9.0 release +> git bisect start 'v2.10.0' 'v2.9.0' +> # bad: [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check more get_try_int() cases +> git bisect bad 269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> # bad: [eba0161990af8509608332450ee7e338273cf5df] Merge remote-tracking branch 'rth/tags/pull-s390-20170512' into staging +> git bisect bad eba0161990af8509608332450ee7e338273cf5df +> # good: [9ea5ada76f34a0ef048b131c3a166d8564199bdb] audio: Use ARRAY_SIZE from qemu/osdep.h +> git bisect good 9ea5ada76f34a0ef048b131c3a166d8564199bdb +> # bad: [1effe6ad5eac1b2e50a077695ac801d172891d6a] Merge remote-tracking branch 'danpb/tags/pull-qcrypto-2017-05-09-1' into staging +> git bisect bad 1effe6ad5eac1b2e50a077695ac801d172891d6a +> # good: [f03f9f0c10dcfadee5811d43240f0a6af230f1ce] Merge remote-tracking branch 'cohuck/tags/s390x-3270-20170504' into staging +> git bisect good f03f9f0c10dcfadee5811d43240f0a6af230f1ce +> # good: [6c02258e143700314ebf268dae47eb23db17d1cf] qobject-input-visitor: Document full_name_nth() +> git bisect good 6c02258e143700314ebf268dae47eb23db17d1cf +> # bad: [95615ce5a1beffff1a5dd3597d8cb6ba83f0010e] vhost-scsi: create a vhost-scsi-common abstraction +> git bisect bad 95615ce5a1beffff1a5dd3597d8cb6ba83f0010e +> # bad: [31f5a726b59bda5580e2f9413867893501dd7d93] trace: add qemu mutex lock and unlock trace events +> git bisect bad 31f5a726b59bda5580e2f9413867893501dd7d93 +> # bad: [49e00a18708e27c815828d9440d5c9300d19547c] use _Static_assert in QEMU_BUILD_BUG_ON +> git bisect bad 49e00a18708e27c815828d9440d5c9300d19547c +> # bad: [6103451aeb749e92bf7d730429985189c6921c32] hw/i386: Build-time assertion on pc/q35 reset register being identical. +> git bisect bad 6103451aeb749e92bf7d730429985189c6921c32 +> # bad: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> git bisect bad 77af8a2b95b79699de650965d5228772743efe84 +> # first bad commit: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> +> +> 77af8a2b95b79699de650965d5228772743efe84 is the first bad commit +> commit 77af8a2b95b79699de650965d5228772743efe84 +> Author: Phil Dennis-Jordan <email address hidden> +> Date: Wed Mar 15 19:20:26 2017 +1300 +> +> hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest +> OS support. +> +> This updates the FADT generated for x86/64 machine types from +> Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The +> intention is to expose the reset register information to guest operating +> systems which require it, specifically OS X/macOS. Revision 1 FADTs do +> not contain the fields relating to the reset register. +> +> The new layout and contents remains backwards-compatible with +> operating systems which only support ACPI 1.0, as the existing fields +> are not modified by this change, as the 64-bit and 32-bit variants are +> allowed to co-exist according to the ACPI 2.0 standard. No regressions +> became apparent in tests with a range of Windows (XP-10) and Linux +> versions. +> +> The BIOS tables test suite's FADT checksum test has also been +> updated to reflect the new FADT layout and content. +> +> Signed-off-by: Phil Dennis-Jordan <email address hidden> +> Message-Id: <email address hidden> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M hw +> :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M include +> :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M tests +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1714331 +> +> Title: +> Virtual machines not working anymore on 2.10 +> +> Status in QEMU: +> New +> +> Bug description: +> Using 2.10, my virtual machine(s) don't work anymore. This happens +> 100% of the times. +> +> ----- +> +> I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is +> the configure command: +> +> configure --target-list=x86_64-softmmu --enable-debug --enable-gtk +> --enable-spice --audio-drv-list=pa +> +> I have one virtual disk, with a Windows 10 64-bit, which I launch in +> two different ways; both work perfectly on 2.9 (and used to do on 2.8, +> but I haven't used it for a long time). +> +> This is the first way: +> +> qemu-system-x86_64 +> -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> -enable-kvm +> -machine q35,accel=kvm,mem-merge=off +> -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time +> -smp 4,cores=4,sockets=1,threads=1 +> -m 4096 +> -display gtk +> -vga qxl +> -rtc base=localtime +> -serial none +> -parallel none +> -usb +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device virtio-scsi-pci,id=scsi +> -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback +> -device scsi-hd,drive=hdd1 +> -net nic,model=virtio +> -net user +> +> On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be +> repaired` windows screen; on 2.9, it boots regularly. +> +> This is the second way: +> +> qemu-system-x86_64 +> -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> -enable-kvm +> -machine q35,accel=kvm,mem-merge=off +> -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time +> -smp 4,cores=4,sockets=1,threads=1 +> -m 10240 +> -vga none +> -rtc base=localtime +> -serial none +> -parallel none +> -usb +> -device vfio-pci,host=01:00.0,multifunction=on +> -device vfio-pci,host=01:00.1 +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> -device virtio-scsi-pci,id=scsi +> -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback +> -device scsi-hd,drive=hdd1 +> -net nic,model=virtio +> -net user +> +> On QEMU 2.10, I get the debug window on the linux monitor, and blank screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU crashes without any message. +> On 2.9, this works perfectly. +> +> ----- +> +> I am able to perform a git bisect, if that helps, but if this is the +> case, I'd need this issue to be reviewed, since bisecting is going to +> take me a lot of time. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1714331/+subscriptions +> + + +Hi Stefan, + +What version of OVMF are you using? There were a bunch of bugs related to +FADT in OVMF which were fixed back in March. Specifically, commits +072060a, 78807f6, and 198a46d. If your version of OVMF doesn't include +these fixes, that's a likely source for your problems. + +Hope that helps. + +Phil + + +On 6 September 2017 at 16:34, Stefan Hajnoczi <email address hidden> wrote: + +> On Tue, Sep 05, 2017 at 06:42:06PM -0000, Chris Unsworth wrote: +> > I think my issue looks like the same. Sometimes I just get spinning +> > dots, and sometimes there is the message about doing an automatic repair +> > below the spinning dots before it stops and uses 100% cpu. I just did a +> > git bisect: +> +> Perfect, thanks Chris! +> +> I have CCed Phil and Paolo regarding the commit you identified. +> +> > +> > # git bisect log +> > # bad: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for +> v2.10.0 release +> > # good: [6c02258e143700314ebf268dae47eb23db17d1cf] Update version for +> v2.9.0 release +> > git bisect start 'v2.10.0' 'v2.9.0' +> > # bad: [269c20b2bbd2aa8531e0cdc741fb166f290d7a2b] tests/qdict: check +> more get_try_int() cases +> > git bisect bad 269c20b2bbd2aa8531e0cdc741fb166f290d7a2b +> > # bad: [eba0161990af8509608332450ee7e338273cf5df] Merge remote-tracking +> branch 'rth/tags/pull-s390-20170512' into staging +> > git bisect bad eba0161990af8509608332450ee7e338273cf5df +> > # good: [9ea5ada76f34a0ef048b131c3a166d8564199bdb] audio: Use +> ARRAY_SIZE from qemu/osdep.h +> > git bisect good 9ea5ada76f34a0ef048b131c3a166d8564199bdb +> > # bad: [1effe6ad5eac1b2e50a077695ac801d172891d6a] Merge remote-tracking +> branch 'danpb/tags/pull-qcrypto-2017-05-09-1' into staging +> > git bisect bad 1effe6ad5eac1b2e50a077695ac801d172891d6a +> > # good: [f03f9f0c10dcfadee5811d43240f0a6af230f1ce] Merge +> remote-tracking branch 'cohuck/tags/s390x-3270-20170504' into staging +> > git bisect good f03f9f0c10dcfadee5811d43240f0a6af230f1ce +> > # good: [6c02258e143700314ebf268dae47eb23db17d1cf] +> qobject-input-visitor: Document full_name_nth() +> > git bisect good 6c02258e143700314ebf268dae47eb23db17d1cf +> > # bad: [95615ce5a1beffff1a5dd3597d8cb6ba83f0010e] vhost-scsi: create a +> vhost-scsi-common abstraction +> > git bisect bad 95615ce5a1beffff1a5dd3597d8cb6ba83f0010e +> > # bad: [31f5a726b59bda5580e2f9413867893501dd7d93] trace: add qemu mutex +> lock and unlock trace events +> > git bisect bad 31f5a726b59bda5580e2f9413867893501dd7d93 +> > # bad: [49e00a18708e27c815828d9440d5c9300d19547c] use _Static_assert in +> QEMU_BUILD_BUG_ON +> > git bisect bad 49e00a18708e27c815828d9440d5c9300d19547c +> > # bad: [6103451aeb749e92bf7d730429985189c6921c32] hw/i386: Build-time +> assertion on pc/q35 reset register being identical. +> > git bisect bad 6103451aeb749e92bf7d730429985189c6921c32 +> > # bad: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: Use Rev3 +> FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> > git bisect bad 77af8a2b95b79699de650965d5228772743efe84 +> > # first bad commit: [77af8a2b95b79699de650965d5228772743efe84] hw/i386: +> Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support. +> > +> > +> > 77af8a2b95b79699de650965d5228772743efe84 is the first bad commit +> > commit 77af8a2b95b79699de650965d5228772743efe84 +> > Author: Phil Dennis-Jordan <email address hidden> +> > Date: Wed Mar 15 19:20:26 2017 +1300 +> > +> > hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest +> > OS support. +> > +> > This updates the FADT generated for x86/64 machine types from +> > Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The +> > intention is to expose the reset register information to guest operating +> > systems which require it, specifically OS X/macOS. Revision 1 FADTs do +> > not contain the fields relating to the reset register. +> > +> > The new layout and contents remains backwards-compatible with +> > operating systems which only support ACPI 1.0, as the existing fields +> > are not modified by this change, as the 64-bit and 32-bit variants are +> > allowed to co-exist according to the ACPI 2.0 standard. No regressions +> > became apparent in tests with a range of Windows (XP-10) and Linux +> > versions. +> > +> > The BIOS tables test suite's FADT checksum test has also been +> > updated to reflect the new FADT layout and content. +> > +> > Signed-off-by: Phil Dennis-Jordan <email address hidden> +> > Message-Id: <email address hidden> +> > Signed-off-by: Paolo Bonzini <email address hidden> +> > +> > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 +> 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M hw +> > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d +> 68f9368d8d78fd3267f609b603f97e8a74bdf528 M include +> > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff +> 8ed08cef10fddee7814e38ad62be11371592a75a M tests +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/1714331 +> > +> > Title: +> > Virtual machines not working anymore on 2.10 +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Using 2.10, my virtual machine(s) don't work anymore. This happens +> > 100% of the times. +> > +> > ----- +> > +> > I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is +> > the configure command: +> > +> > configure --target-list=x86_64-softmmu --enable-debug --enable-gtk +> > --enable-spice --audio-drv-list=pa +> > +> > I have one virtual disk, with a Windows 10 64-bit, which I launch in +> > two different ways; both work perfectly on 2.9 (and used to do on 2.8, +> > but I haven't used it for a long time). +> > +> > This is the first way: +> > +> > qemu-system-x86_64 +> > -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> > -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> > -enable-kvm +> > -machine q35,accel=kvm,mem-merge=off +> > -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_ +> spinlocks=0x1fff,hv_vapic,hv_time +> > -smp 4,cores=4,sockets=1,threads=1 +> > -m 4096 +> > -display gtk +> > -vga qxl +> > -rtc base=localtime +> > -serial none +> > -parallel none +> > -usb +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device virtio-scsi-pci,id=scsi +> > -drive file=/path/to/image-diff.img, +> id=hdd1,format=qcow2,if=none,cache=writeback +> > -device scsi-hd,drive=hdd1 +> > -net nic,model=virtio +> > -net user +> > +> > On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be +> > repaired` windows screen; on 2.9, it boots regularly. +> > +> > This is the second way: +> > +> > qemu-system-x86_64 +> > -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd +> > -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp +> > -enable-kvm +> > -machine q35,accel=kvm,mem-merge=off +> > -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_ +> spinlocks=0x1fff,hv_vapic,hv_time +> > -smp 4,cores=4,sockets=1,threads=1 +> > -m 10240 +> > -vga none +> > -rtc base=localtime +> > -serial none +> > -parallel none +> > -usb +> > -device vfio-pci,host=01:00.0,multifunction=on +> > -device vfio-pci,host=01:00.1 +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device usb-host,vendorid=0xNNNN,productid=0xNNNN +> > -device virtio-scsi-pci,id=scsi +> > -drive file=/path/to/image-diff.img, +> id=hdd1,format=qcow2,if=none,cache=writeback +> > -device scsi-hd,drive=hdd1 +> > -net nic,model=virtio +> > -net user +> > +> > On QEMU 2.10, I get the debug window on the linux monitor, and blank +> screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU +> crashes without any message. +> > On 2.9, this works perfectly. +> > +> > ----- +> > +> > I am able to perform a git bisect, if that helps, but if this is the +> > case, I'd need this issue to be reviewed, since bisecting is going to +> > take me a lot of time. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1714331/+subscriptions +> > +> + + +I'm using the Ubuntu artful version (0~20161202.7bbe0b3e-1), so I'll need to build a recent OVMF package to verify the solution. + +I was using a version of OVMF from about a year ago which works fine with QEMU 2.8 and 2.9 but doesn't work with 2.10. I just updated to the latest OVMF from master and everything's working now with QEMU 2.10 and WIndows 10 64 bit, so the old OVMF was the issue. + +Thanks for your help, +Chris + + +Building the OVMF from the `edk2` current master (89796c69d9) fixes both (non/vfio) issues. + +Should this be opened as a bug on the `ovmf` Ubuntu package (xenial/zesty/artful)? I'm very familiar with the Ubuntu version policies. + +See also LP#1725560. + +> Should this be opened as a bug on the `ovmf` Ubuntu package (xenial/zesty/artful)? I'm very familiar with the Ubuntu version policies. + +I've just noticed that I intended to write "I'm *not* very familiar with the Ubuntu version policies". + diff --git a/results/classifier/108/other/1714538 b/results/classifier/108/other/1714538 new file mode 100644 index 000000000..2533517fc --- /dev/null +++ b/results/classifier/108/other/1714538 @@ -0,0 +1,24 @@ +device: 0.780 +graphic: 0.680 +network: 0.600 +semantic: 0.491 +PID: 0.483 +boot: 0.326 +permissions: 0.302 +vnc: 0.237 +other: 0.228 +files: 0.147 +performance: 0.134 +socket: 0.123 +debug: 0.109 +KVM: 0.012 + +Support for Raspberry Pi 3 Model B + +The raspberry pi 3 B uses a 64-bit instruction set. It would be useful if qemu could emulate the boardn + +We have a raspi3 model in QEMU now, it will be available in the upcoming 2.12 release. + + +I saw that in the mailing list! Can't wait to try it out! + diff --git a/results/classifier/108/other/1715162 b/results/classifier/108/other/1715162 new file mode 100644 index 000000000..679188306 --- /dev/null +++ b/results/classifier/108/other/1715162 @@ -0,0 +1,92 @@ +other: 0.919 +graphic: 0.898 +KVM: 0.889 +debug: 0.888 +performance: 0.874 +permissions: 0.851 +semantic: 0.845 +device: 0.838 +vnc: 0.833 +PID: 0.821 +files: 0.806 +boot: 0.800 +socket: 0.781 +network: 0.773 + +qemu-user crashing when writing core dump + +I've a binary I'm running in qemux86-64 but it is segfaulting. Whilst qemu writes the core dump for that, qemu itself is segfaulting. + +(gdb) bt full +#0 0x00007efdd962e32e in sigsuspend () from /data/poky-tmp/master/build/sysroots-uninative/x86_64-linux/lib/libc.so.6 +No symbol table info available. +#1 0x0000559176d74da4 in dump_core_and_abort (target_sig=target_sig@entry=11) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:598 + cpu = <optimized out> + env = <optimized out> + ts = 0x55917a42d160 + core_dumped = <optimized out> + act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744067267099647, + 18446744073709551615 <repeats 15 times>}}, sa_flags = 0, sa_restorer = 0x559100004010} +#2 0x0000559176d75a38 in handle_pending_signal (cpu_env=cpu_env@entry=0x55917a41c2a0, sig=sig@entry=11, + k=k@entry=0x55917a42d190) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6596 + handler = <optimized out> + set = {__val = {4294967297, 4294967297, 94083256460867, 14, 128, 0, 8, 3, 0, 1, 0, 4243635, 139628765215104, + 94083255852784, 94083309703424, 3351315493}} + target_old_set = {sig = {0}} + sa = <optimized out> + ts = 0x55917a42d160 +#3 0x0000559176d765ac in process_pending_signals (cpu_env=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6674 + sig = 11 + ts = 0x55917a42d160 + set = {__val = {18446744067267100671, 18446744073709551615 <repeats 15 times>}} + blocked_set = <optimized out> +#4 0x0000559176d5e0d8 in cpu_loop (env=0x55917a41c2a0) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:369 + trapnr = 14 + pc = <optimized out> + ret = <optimized out> + info = {si_signo = 11, si_errno = 0, si_code = 196609, _sifields = {_pad = {101897450, 192, -647518572, 32509, + 842, 0, 1993519912, 21905, 2051194736, 21905, 1997320506, 21905, 2051195440, 21905, 1993546713, 0, + 12767276, 64, 1997233696, 21905, 42, 0, 1997233824, 21905, 1997320464, 21905, 350755584, -1438022877}, + _kill = {_pid = 101897450, _uid = 192}, _timer = {_timer1 = 101897450, _timer2 = 192}, _rt = { + _pid = 101897450, _uid = 192, _sigval = {sival_int = -647518572, sival_ptr = 139628739274388}}, + _sigchld = {_pid = 101897450, _uid = 192, _status = -647518572, _utime = 842, _stime = 94083252138792}, + _sigfault = {_addr = 824735618282}, _sigpoll = {_band = 101897450, _fd = 192}}} +#5 0x0000559176d2a4b8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:4862 + regs1 = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 0, r10 = 0, r9 = 0, r8 = 0, rax = 0, + rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 0, rip = 274888416832, cs = 0, eflags = 0, + rsp = 274888401360, ss = 0} + regs = 0x7ffda5b29fc0 + info1 = {load_bias = 274888413184, load_addr = 274877906944, start_code = 274877906944, + end_code = 274877917360, start_data = 274880015120, end_data = 274880016400, start_brk = 0, + brk = 274880016472, start_mmap = 183251939328, start_stack = 274888401360, stack_limit = 274880024576, + entry = 274888416832, code_offset = 0, data_offset = 0, saved_auxv = 274888402256, + auxv_len = 18446744073709550728, arg_start = 274888401368, arg_end = 274888401408, + arg_strings = 274888402550, env_strings = 274888402788, file_string = 274888413067, elf_flags = 0, + personality = 0} + info = 0x7ffda5b2a070 + bprm = { + buf = "\177ELF\002\001\001\000\000\000\000\000\000\000\000\000\003\000>\000\001\000\000\000@\016\000\000\000\000\000\000@\000\000\000\000\000\000\000\230`\002\000\000\000\000\000\000\000\000\000@\000\070\000\006\000@\000\027\000\026\000\001\000\000\000\005", '\000' <repeats 27 times>, "\264C\002\000\000\000\000\000\264C\002\000\000\000\000\000\000\000 \000\000\000\000\000\001\000\000\000\006\000\000\000\240G\002\000\000\000\000\000\240G\"\000\000\000\000\000\240G\"\000\000\000\000\000\330\027\000\000\000\000\000\000p\031\000\000\000\000\000\000\000\000 \000\000\000\000\000\002\000\000\000\006\000\000\000\030N\002\000\000\000\000\000\030N\"\000\000\000\000\000"..., p = 274888401360, fd = 3, + e_uid = 1000, e_gid = 1000, argc = 5, envc = 104, argv = 0x55917a42d120, envp = 0x55917a42a8f0, + filename = 0x7ffda5b2c683 "/data/poky-tmp/master/build/work/intel_corei7_64-poky-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache", core_dump = 0x559176d76ed0 <elf_core_dump>} + ts = <optimized out> + env = 0x55917a41c2a0 + cpu = 0x55917a414010 + target_environ = 0x55917a42a8f0 + wrk = 0x55917a42ac30 + target_argv = 0x55917a42d120 + target_argc = 5 + i = <optimized out> + ret = <optimized out> + execfd = <optimized out> + +(I'll reproduce this with glibc debug symbols shortly) + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1715203 b/results/classifier/108/other/1715203 new file mode 100644 index 000000000..c643eb2ef --- /dev/null +++ b/results/classifier/108/other/1715203 @@ -0,0 +1,331 @@ +KVM: 0.873 +other: 0.841 +permissions: 0.836 +graphic: 0.812 +PID: 0.809 +semantic: 0.806 +vnc: 0.800 +device: 0.785 +network: 0.766 +performance: 0.765 +debug: 0.760 +files: 0.744 +boot: 0.731 +socket: 0.721 + +Maintain Haiku support + +It was pointed out that the 2.10 release notes are pushing to drop Haiku support. The qemu port is currently working as-is under Haiku. + +Was there a reason this was recommended? Is there anything Haiku can do to keep it from being dropped? + +We're working on a docker container to cross-compile rust-lang for Haiku, could this be of some use to qemu when complete? + +On 5 September 2017 at 18:55, kallisti5 <email address hidden> wrote: +> It was pointed out that the 2.10 release notes are pushing to drop Haiku +> support. The qemu port is currently working as-is under Haiku. +> +> Was there a reason this was recommended? Is there anything Haiku can do +> to keep it from being dropped? + +Basically we don't want to try to support host systems where we +have no access to hardware that will let us compile and run +the test suite, and where there's nobody interacting with us +upstream to help fix issues that are Haiku related. + +If there's genuinely a community of Haiku QEMU users out there +who want to help us maintain the support in the QEMU codebase that's +great. What we don't want is to be carrying around code we can't +test and where we don't seem to have anybody using it. (For instance +we're about to drop support for AIX...) + +> We're working on a docker container to cross-compile rust-lang for +> Haiku, could this be of some use to qemu when complete? + +Cross-compilation won't let us run the test suite. + +thanks +-- PMM + + +Haiku recently got a virtio driver, so running a Haiku system in cloud infrastructure seems possible now. (I've personally run it on vultr.com) Does QEMU have some infrastructure available so we can stand up a x86_64 system? + +On 5 September 2017 at 19:14, kallisti5 <email address hidden> wrote: +> Haiku recently got a virtio driver, so running a Haiku system in cloud +> infrastructure seems possible now. (I've personally run it on vultr.com) +> Does QEMU have some infrastructure available so we can stand up a x86_64 +> system? + +Nope. We would be looking either for ssh login on a system somebody +else admins, or detailed instructions on how to set up a VM for it, +like the ones we have for BSD at https://wiki.qemu.org/index.php/Hosts/BSD + +thanks +-- PMM + + +Contacting our board of directors to see if I can get a VM deployed at Vultr. I'll keep this ticket updated. + +We're purchasing some new hardware, once we get it set up we'll setup a x86_64 Haiku machine to build qemu. + +Is there any update on this? Could you provide a machine with ssh login to the QEMU project where QEMU could be built and tested on Haiku? Or can Haiku be installed automatically without graphical UI interactions? In that case, would it be feasible that you provide a VM setup for our tests/vm/ files in QEMU? + +Hi! + +Sorry, I forgot about this one. + +Haiku has a lot of options.. we can setup a vm image if needed to move this along. +Haiku is graphical, but has ssh and all the standard tools. + +Vagrant also supports Haiku and provides some automation around it. +https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&provider=&q=haiku-os + +Let me check out tests/vm/ to see if I can PR something. + +ok.. a Haiku vm for QEMU is WIP here: + +https://github.com/kallisti5/qemu/tree/haiku-test-vm + + + +``` +$ ./haiku.x86_64 --build-image --image /tmp/haiku.img +### Downloading disk image ... +### Preparing disk image ... +./box.img +100% repochecksum-1 [65 bytes] +Validating checksum for Haiku...done. +100% repocache-2 [4.25 KiB] +Validating checksum for Haiku...done. +100% repochecksum-1 [64 bytes] +Validating checksum for HaikuPorts...done. +100% repocache-2 [1.26 MiB] +Validating checksum for HaikuPorts...done. +The following changes will be made: + in system: + install package bzip2_devel-1.0.8-1 from repository HaikuPorts + install package libgpg_error_devel-1.36-1 from repository HaikuPorts + install package gettext-0.19.8.1-7 from repository HaikuPorts + install package ncurses6_devel-6.2-1 from repository HaikuPorts + install package libtasn1_devel-4.15.0-1 from repository HaikuPorts + install package capstone-4.0.2-1 from repository HaikuPorts + install package dtc-1.4.7-2 from repository HaikuPorts + install package libffi_devel-3.2.1-6 from repository HaikuPorts + install package libpcre_devel-8.44-1 from repository HaikuPorts + install package libiconv_devel-1.16-1 from repository HaikuPorts + install package lzo-2.10-2 from repository HaikuPorts + install package nettle-3.5.1-1 from repository HaikuPorts + install package pixman-0.38.4-1 from repository HaikuPorts + install package snappy-1.1.7-2 from repository HaikuPorts + install package libssh2-1.9.0-2 from repository HaikuPorts + install package libusb-1.0.23-1 from repository HaikuPorts + install package p11_kit-0.23.18.1-1 from repository HaikuPorts + install package libunistring-0.9.10-1 from repository HaikuPorts + install package libidn2-2.0.5-1 from repository HaikuPorts + install package libtool_libltdl-2.4.6-2 from repository HaikuPorts + install package file_data-5.38-1 from repository HaikuPorts + install package libgcrypt_devel-1.8.5-1 from repository HaikuPorts + install package glib2-2.62.0-3 from repository HaikuPorts + install package capstone_devel-4.0.2-1 from repository HaikuPorts + install package dtc_devel-1.4.7-2 from repository HaikuPorts + install package lzo_devel-2.10-2 from repository HaikuPorts + install package nettle_devel-3.5.1-1 from repository HaikuPorts + install package pixman_devel-0.38.4-1 from repository HaikuPorts + install package snappy_devel-1.1.7-2 from repository HaikuPorts + install package libssh2_devel-1.9.0-2 from repository HaikuPorts + install package libusb_devel-1.0.23-1 from repository HaikuPorts + install package p11_kit_devel-0.23.18.1-1 from repository HaikuPorts + install package gnutls-3.6.10-2 from repository HaikuPorts + install package libsdl2-2.0.10-1 from repository HaikuPorts + install package file-5.38-1 from repository HaikuPorts + install package gnutls_devel-3.6.10-2 from repository HaikuPorts + install package libsdl2_devel-2.0.10-1 from repository HaikuPorts + install package python3-3.7.7-2 from repository HaikuPorts + install package glib2_devel-2.62.0-3 from repository HaikuPorts +Continue? [yes/no] (yes) : yes +100% bzip2_devel-1.0.8-1-x86_64.hpkg [119.14 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/bzip2_devel-1.0.8-1-x86_64.hpkg...done. +100% libgpg_error_devel-1.36-1-x86_64.hpkg [57.73 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libgpg_error_devel-1.36-1-x86_64.hpkg...done. +100% gettext-0.19.8.1-7-x86_64.hpkg [12.16 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gettext-0.19.8.1-7-x86_64.hpkg...done. +100% ncurses6_devel-6.2-1-x86_64.hpkg [844.82 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/ncurses6_devel-6.2-1-x86_64.hpkg...done. +100% libtasn1_devel-4.15.0-1-x86_64.hpkg [166.87 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libtasn1_devel-4.15.0-1-x86_64.hpkg...done. +100% capstone-4.0.2-1-x86_64.hpkg [1.80 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/capstone-4.0.2-1-x86_64.hpkg...done. +100% dtc-1.4.7-2-x86_64.hpkg [142.38 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/dtc-1.4.7-2-x86_64.hpkg...done. +100% libffi_devel-3.2.1-6-x86_64.hpkg [31.88 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libffi_devel-3.2.1-6-x86_64.hpkg...done. +100% libpcre_devel-8.44-1-x86_64.hpkg [1.26 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libpcre_devel-8.44-1-x86_64.hpkg...done. +100% libiconv_devel-1.16-1-x86_64.hpkg [901.83 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libiconv_devel-1.16-1-x86_64.hpkg...done. +100% lzo-2.10-2-x86_64.hpkg [166.74 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/lzo-2.10-2-x86_64.hpkg...done. +100% nettle-3.5.1-1-x86_64.hpkg [890.41 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/nettle-3.5.1-1-x86_64.hpkg...done. +100% pixman-0.38.4-1-x86_64.hpkg [1.43 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/pixman-0.38.4-1-x86_64.hpkg...done. +100% snappy-1.1.7-2-x86_64.hpkg [34.08 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/snappy-1.1.7-2-x86_64.hpkg...done. +100% libssh2-1.9.0-2-x86_64.hpkg [423.77 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libssh2-1.9.0-2-x86_64.hpkg...done. +100% libusb-1.0.23-1-x86_64.hpkg [50.38 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libusb-1.0.23-1-x86_64.hpkg...done. +100% p11_kit-0.23.18.1-1-x86_64.hpkg [987.54 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/p11_kit-0.23.18.1-1-x86_64.hpkg...done. +100% libunistring-0.9.10-1-x86_64.hpkg [610.86 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libunistring-0.9.10-1-x86_64.hpkg...done. +100% libidn2-2.0.5-1-x86_64.hpkg [196.76 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libidn2-2.0.5-1-x86_64.hpkg...done. +100% libtool_libltdl-2.4.6-2-x86_64.hpkg [64.24 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libtool_libltdl-2.4.6-2-x86_64.hpkg...done. +100% file_data-5.38-1-any.hpkg [300.96 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/file_data-5.38-1-any.hpkg...done. +100% libgcrypt_devel-1.8.5-1-x86_64.hpkg [158.77 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libgcrypt_devel-1.8.5-1-x86_64.hpkg...done. +100% glib2-2.62.0-3-x86_64.hpkg [4.10 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/glib2-2.62.0-3-x86_64.hpkg...done. +100% capstone_devel-4.0.2-1-x86_64.hpkg [1.03 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/capstone_devel-4.0.2-1-x86_64.hpkg...done. +100% dtc_devel-1.4.7-2-x86_64.hpkg [88.46 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/dtc_devel-1.4.7-2-x86_64.hpkg...done. +100% lzo_devel-2.10-2-x86_64.hpkg [314.15 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/lzo_devel-2.10-2-x86_64.hpkg...done. +100% nettle_devel-3.5.1-1-x86_64.hpkg [39.87 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/nettle_devel-3.5.1-1-x86_64.hpkg...done. +100% pixman_devel-0.38.4-1-x86_64.hpkg [1.81 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/pixman_devel-0.38.4-1-x86_64.hpkg...done. +100% snappy_devel-1.1.7-2-x86_64.hpkg [8.90 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/snappy_devel-1.1.7-2-x86_64.hpkg...done. +100% libssh2_devel-1.9.0-2-x86_64.hpkg [51.70 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libssh2_devel-1.9.0-2-x86_64.hpkg...done. +100% libusb_devel-1.0.23-1-x86_64.hpkg [378.12 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libusb_devel-1.0.23-1-x86_64.hpkg...done. +100% p11_kit_devel-0.23.18.1-1-x86_64.hpkg [19.07 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/p11_kit_devel-0.23.18.1-1-x86_64.hpkg...done. +100% gnutls-3.6.10-2-x86_64.hpkg [1.52 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gnutls-3.6.10-2-x86_64.hpkg...done. +100% libsdl2-2.0.10-1-x86_64.hpkg [2.29 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libsdl2-2.0.10-1-x86_64.hpkg...done. +100% file-5.38-1-x86_64.hpkg [103.26 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/file-5.38-1-x86_64.hpkg...done. +100% gnutls_devel-3.6.10-2-x86_64.hpkg [285.23 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gnutls_devel-3.6.10-2-x86_64.hpkg...done. +100% libsdl2_devel-2.0.10-1-x86_64.hpkg [294.06 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libsdl2_devel-2.0.10-1-x86_64.hpkg...done. +100% python3-3.7.7-2-x86_64.hpkg [9.85 MiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/python3-3.7.7-2-x86_64.hpkg...done. +100% glib2_devel-2.62.0-3-x86_64.hpkg [395.96 KiB] +Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/glib2_devel-2.62.0-3-x86_64.hpkg...done. +[system] Applying changes ... +[system] Changes applied. Old activation state backed up in "state_2020-09-05_14:46:23" +[system] Cleaning up ... +[system] Done. +### All done ... +``` + +$ ./haiku.x86_64 --verbose --image /tmp/haiku.img uname +Haiku + +./haiku.x86_64 --verbose --image /tmp/haiku.img "gcc -v" +Using built-in specs. +COLLECT_GCC=gcc +COLLECT_LTO_WRAPPER=/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/lto-wrapper +Target: x86_64-unknown-haiku +Configured with: /sources/gcc-8.3.0/configure --build=x86_64-unknown-haiku --prefix=/packages/gcc-8.3.0_2019_05_24-7/.self/develop/tools --libexecdir=/packages/gcc-8.3.0_2019_05_24-7/.self/develop/tools/lib --mandir=/packages/gcc-8.3.0_2019_05_24-7/.self/documentation/man --docdir=/packages/gcc-8.3.0_2019_05_24-7/.self/documentation/packages/gcc --enable-threads=posix --disable-nls --enable-shared --with-gnu-ld --with-gnu-as --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran,objc --enable-lto --enable-frame-pointer --with-pkgversion=2019_05_24 --enable-__cxa-atexit --with-system-zlib --enable-checking=release --with-bug-url=http://dev.haiku-os.org/ --with-default-libstdcxx-abi=gcc4-compatible --enable-libssp --disable-multilib +Thread model: posix +gcc version 8.3.0 (2019_05_24) + + +and away we go.. + +./haiku.x86_64 --image /tmp/haiku.img --build-qemu /home/kallisti5/Code/qemu +Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc' +Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 'slirp' +Submodule 'meson' (https://github.com/mesonbuild/meson/) registered for path 'meson' +Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) registered for path 'ui/keycodemapdb' +Submodule 'tests/fp/berkeley-softfloat-3' (https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 'tests/fp/berkeley-softfloat-3' +Submodule 'tests/fp/berkeley-testfloat-3' (https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 'tests/fp/berkeley-testfloat-3' +cross containers no + +NOTE: guest cross-compilers enabled: cc +The Meson build system +Version: 0.55.1 +Source dir: /boot/system/cache/tmp/qemu-test.oCwd7u/src +Build dir: /boot/system/cache/tmp/qemu-test.oCwd7u/build +Build type: native build +Project name: qemu +Project version: 5.1.50 +C compiler for the host machine: cc (gcc 8.3.0 "cc (2019_05_24) 8.3.0") +C linker for the host machine: cc ld.bfd 2.31.1 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or forwards compatibility and might not exist in future releases. +Program sh found: YES +Program python3 found: YES (/boot/system/bin/python3) +C++ compiler for the host machine: c++ (gcc 8.3.0 "c++ (2019_05_24) 8.3.0") +C++ linker for the host machine: c++ ld.bfd 2.31.1 +Configuring ninjatool using configuration +Library m found: YES +Library util found: NO +Library posix_error_mapper found: YES +Library network found: YES +Library bsd found: YES +Found pkg-config: /boot/system/bin/pkg-config (0.29.2) +Run-time dependency pixman-1 found: YES 0.38.4 +Library aio found: NO +Run-time dependency zlib found: YES 1.2.11 +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Library rt found: NO +Run-time dependency sdl2 found: YES 2.0.10 +Run-time dependency sdl2_image found: NO (tried pkgconfig) +Run-time dependency libpng found: YES 1.6.37 +Has header "jpeglib.h" : YES +. +. +/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp/src/tftp.c:113:50: error: 'O_BINARY' undeclared (first use in this function); did you mean 'L_INCR'? + spt->fd = open(spt->filename, O_RDONLY | O_BINARY); + ^~~~~~~~ + L_INCR +/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp/src/tftp.c:113:50: note: each undeclared identifier is reported only once for each function it appears in +Makefile:45: recipe for target '/boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/tftp.o' failed +make[1]: *** [/boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/tftp.o] Error 1 +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: *** Waiting for unfinished jobs.... +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/util.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/ip6_output.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/state.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/misc.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' + CC /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/bootp.o +make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp' +make[1]: *** wait: No child process. Stop. +Makefile:178: recipe for target 'slirp/all' failed +make: *** [slirp/all] Error 2 +make: *** Waiting for unfinished jobs.... +python3 -B /tmp/qemu-test.oCwd7u/src/meson/meson.py introspect --tests | python3 -B scripts/mtest2make.py > Makefile.mtest +./ninjatool -t ninja2make --omit clean dist uninstall cscope TAGS ctags < build.ninja > Makefile.ninja + + + +It looks like we have a few out-of-tree patches to fix that: + +https://github.com/haikuports/haikuports/blob/master/app-emulation/qemu/patches/qemu-2.11.1.patchset + +A patch for this work has been posted to the qemu-dev ML. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9fc33bf4e1d694225 +... the test suite is still failing, but at least we can compile test Haiku now. Thanks! + diff --git a/results/classifier/108/other/1715296 b/results/classifier/108/other/1715296 new file mode 100644 index 000000000..89564dba2 --- /dev/null +++ b/results/classifier/108/other/1715296 @@ -0,0 +1,37 @@ +other: 0.742 +semantic: 0.735 +device: 0.726 +network: 0.676 +performance: 0.589 +socket: 0.518 +graphic: 0.468 +vnc: 0.466 +files: 0.332 +PID: 0.300 +permissions: 0.284 +debug: 0.278 +boot: 0.258 +KVM: 0.141 + +qemu: invalid serial port configuration + +The tty_serial_init() function sets the port c_oflags as follows: +tty.c_oflag |= OPOST not clearing ONLCR, ONLRET and others. +The result is that the postprocess output is enabled and host translates 0xa (LF) to 0xd 0xa (CR LF) which breaks the binary transmissions on serial port even if you set the port to raw mode (no matters if on host and/or guest). +The issue has been reported 11 years ago on qemu-devel mailing list: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +There was also a FreeBSD patch including the fix: +https://lists.freebsd.org/pipermail/freebsd-ports/2006-October/036390.html + +I think the correct port configuration is: +tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL); +tty.c_oflag &= ~OPOST; + +In such case the host will perform no output processing and will pass the data as is. +And the guest will be able to configure input/output processing exactly as it wants. + +I believe the following bug is related: https://bugs.launchpad.net/qemu/+bug/1407813 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/108/other/1715573 b/results/classifier/108/other/1715573 new file mode 100644 index 000000000..26499e335 --- /dev/null +++ b/results/classifier/108/other/1715573 @@ -0,0 +1,29 @@ +performance: 0.873 +graphic: 0.843 +device: 0.743 +semantic: 0.710 +boot: 0.568 +other: 0.526 +vnc: 0.421 +network: 0.311 +permissions: 0.301 +PID: 0.300 +debug: 0.267 +socket: 0.262 +files: 0.201 +KVM: 0.008 + +Android-x86_64 guest - "Could not disable RealTimeClock events (20160831/evxfevnt-267)"; UI sluggish, ACPI doesn't work with QEMU 2.10.0 + +I'm running a custom-built Android-x86_64 guest in an Arch Linux host with the 4.12.10 kernel. + +Following the latest Arch Linux upgrade to QEMU 2.10.0-1, upon booting the virtual machine, I get the error mentioned in the title. Afterwards, the virtual machine becomes slower and slower. The ACPI functions (the libvirt's Shutdown button, for example) don't work. + +When I downgrade to QEMU 2.9.0-3 everything works fine once again. + +This is maybe a duplicate of https://bugs.launchpad.net/qemu/+bug/1714331 ... could you please try a newer version of the OVMF firmware (if you're using it)? + +It works with a newer OVMF version! + +Thank you. + diff --git a/results/classifier/108/other/1715715 b/results/classifier/108/other/1715715 new file mode 100644 index 000000000..dbc3fb577 --- /dev/null +++ b/results/classifier/108/other/1715715 @@ -0,0 +1,78 @@ +other: 0.682 +debug: 0.649 +performance: 0.631 +vnc: 0.626 +permissions: 0.624 +semantic: 0.622 +device: 0.622 +graphic: 0.614 +KVM: 0.609 +network: 0.601 +socket: 0.600 +PID: 0.591 +files: 0.579 +boot: 0.574 + +[qemu-ppc] Segfault when booting from HD after MacOS9 install + +I created an empty 128G qcow2 image and booted from a Mac OS 9.2.1 Install CD, in which I was able to install the OS successfully to the hard drive. Upon reboot, this time from the hard drive directly, qemu-system-ppc segfaults. + +qemu --version reports "v2.10.0-244-gb07d1c2-dirty", but I used git commit b07d1c2f5607489d4d4a6a65ce36a3e896ac065e and built with "./configure --target-list=ppc-softmmu --enable-debug --disable-strip". + +Here is the command-line arguments: + +qemu-system-ppc -boot c -g 1024x768x32 -M mac99 -m 256 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' -drive file=../os9.img,format=raw,media=cdrom -drive file=MacOS9.qcow2,format=qcow2,media=disk -spice port=5901,password=XXX -net nic,model=rtl8139 -net user -monitor stdio + +And the GDB backtrace: + +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000559065fe7d3a in timer_mod (ts=0x0, expire_time=888960717010) at util/qemu-timer.c:462 +462 timer_mod_ns(ts, expire_time * ts->scale); +[Current thread is 1 (Thread 0x7f60e43cb700 (LWP 9853))] +(gdb) bt +#0 0x0000559065fe7d3a in timer_mod (ts=0x0, expire_time=888960717010) at util/qemu-timer.c:462 +#1 0x0000559065d63769 in openpic_tmr_set_tmr (tmr=0x5590676fa7e0, val=96, enabled=true) at hw/intc/openpic.c:861 +#2 0x0000559065d63995 in openpic_tmr_write (opaque=0x5590676f71f0, addr=16, val=96, len=4) at hw/intc/openpic.c:912 +#3 0x0000559065b02811 in memory_region_write_accessor (mr=0x5590676f7710, addr=32, value=0x7f60e43c7da8, size=4, shift=0, mask=4294967295, attrs=...) at /home/bp/qemu/memory.c:529 +#4 0x0000559065b02a29 in access_with_adjusted_size (addr=32, value=0x7f60e43c7da8, size=1, access_size_min=4, access_size_max=4, access=0x559065b02727 <memory_region_write_accessor>, mr=0x5590676f7710, attrs=...) at /home/bp/qemu/memory.c:595 +#5 0x0000559065b051eb in memory_region_dispatch_write (mr=0x5590676f7710, addr=32, data=96, size=1, attrs=...) at /home/bp/qemu/memory.c:1337 +#6 0x0000559065aa3a36 in address_space_write_continue (as=0x559067614d90, addr=2147750160, attrs=..., buf=0x7f60e43c7ed0 "`_'\310`\177", len=1, addr1=32, l=1, mr=0x5590676f7710) at /home/bp/qemu/exec.c:2942 +#7 0x0000559065aa3b84 in address_space_write (as=0x559067614d90, addr=2147750160, attrs=..., buf=0x7f60e43c7ed0 "`_'\310`\177", len=1) at /home/bp/qemu/exec.c:2987 +#8 0x0000559065aa2ec0 in subpage_write (opaque=0x7f60c8275fc0, addr=272, value=96, len=1, attrs=...) at /home/bp/qemu/exec.c:2565 +#9 0x0000559065b02906 in memory_region_write_with_attrs_accessor (mr=0x7f60c8275fc0, addr=272, value=0x7f60e43c7fc8, size=1, shift=0, mask=255, attrs=...) at /home/bp/qemu/memory.c:555 +#10 0x0000559065b029d3 in access_with_adjusted_size (addr=272, value=0x7f60e43c7fc8, size=1, access_size_min=1, access_size_max=8, access=0x559065b02818 <memory_region_write_with_attrs_accessor>, mr=0x7f60c8275fc0, attrs=...) at /home/bp/qemu/memory.c:590 +#11 0x0000559065b0523a in memory_region_dispatch_write (mr=0x7f60c8275fc0, addr=272, data=96, size=1, attrs=...) at /home/bp/qemu/memory.c:1344 +#12 0x0000559065b175db in io_writex (env=0x7f60e43d42a0, iotlbentry=0x7f60e43e8130, mmu_idx=3, val=96, addr=2147750160, retaddr=140054158295744, size=1) at /home/bp/qemu/accel/tcg/cputlb.c:807 +#13 0x0000559065b18055 in io_writeb (env=0x7f60e43d42a0, mmu_idx=3, index=65, val=96 '`', addr=2147750160, retaddr=140054158295744) at /home/bp/qemu/softmmu_template.h:265 +#14 0x0000559065b181ea in helper_ret_stb_mmu (env=0x7f60e43d42a0, addr=2147750160, val=96 '`', oi=3, retaddr=140054158295744) at /home/bp/qemu/softmmu_template.h:300 +#15 0x00007f60e65ac2c0 in code_gen_buffer () +#16 0x0000559065b1ff26 in cpu_tb_exec (cpu=0x7f60e43cc010, itb=0x7f60e65ac5c0 <code_gen_buffer+935318>) at /home/bp/qemu/accel/tcg/cpu-exec.c:166 +#17 0x0000559065b20bfd in cpu_loop_exec_tb (cpu=0x7f60e43cc010, tb=0x7f60e65ac5c0 <code_gen_buffer+935318>, last_tb=0x7f60e43c8678, tb_exit=0x7f60e43c8674) at /home/bp/qemu/accel/tcg/cpu-exec.c:578 +#18 0x0000559065b20eed in cpu_exec (cpu=0x7f60e43cc010) at /home/bp/qemu/accel/tcg/cpu-exec.c:676 +#19 0x0000559065aebc3d in tcg_cpu_exec (cpu=0x7f60e43cc010) at /home/bp/qemu/cpus.c:1270 +#20 0x0000559065aebe64 in qemu_tcg_rr_cpu_thread_fn (arg=0x7f60e43cc010) at /home/bp/qemu/cpus.c:1365 +#21 0x00007f60f56f06ba in start_thread (arg=0x7f60e43cb700) at pthread_create.c:333 +#22 0x00007f60f542682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + + +Any idea what is going on? + +I've just tested MacOS 9.2.1 as part of my QEMU pre-release testing and it works fine for me with latest QEMU git and the following command line: + +qemu-system-ppc -M mac99 -m 256 -drive file=os921.qcow2,format=qcow2,media=disk -net nic,model=rtl8139 -net user + +Note that the QEMU mac99 machine now defaults to using the sungem device which should give out-of-the-box networking for supported OS 9 and OS X versions, including 9.2.1 as you mention, if you simply specify "-net nic,model=sungem -net user" instead. Otherwise you will need to make sure that the rtl8139 MacOS 9 drivers have been installed inside the guest. + +If that doesn't help then does it work if you disable spice and/or reduce the size of the disk image? Many older OSs will struggle to read disks that are 128G in size so you may find that your image is corrupted - perhaps try using something around 4G instead? + +I just tried the latest git and it actually boots fine with your command... so I guess whatever issue I was having (the null dereference in the timer code I pasted above) must have been fixed... however I've noticed another issue with a different command that causes the bootup to hang: + +qemu-system-ppc -boot c -g 1024x768x32 -M mac99 -m 256 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' -drive file=os9.2.1.iso,format=raw,media=cdrom -drive file=os921.qcow2,format=qcow2,media=disk -spice port=5901,password=XXX -net nic,model=sungem -net user -monitor stdio + +This hangs at bootup at "Trying hd:,\\:tbxi" and never progresses any further. If I remove the cdrom then it boots fine... however, simply adding the cdrom to your working command, it still works there... not sure what's going on, but thanks for the help. I have something that works now. + + +Looking through old bug tickets ... can you still reproduce the segfault with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1716028 b/results/classifier/108/other/1716028 new file mode 100644 index 000000000..09145840d --- /dev/null +++ b/results/classifier/108/other/1716028 @@ -0,0 +1,544 @@ +permissions: 0.906 +files: 0.899 +other: 0.882 +device: 0.874 +graphic: 0.864 +boot: 0.860 +PID: 0.845 +debug: 0.834 +KVM: 0.829 +network: 0.818 +socket: 0.810 +vnc: 0.810 +semantic: 0.805 +performance: 0.778 + +qemu 2.10 locks images with no feature flag + +1) % lsb_release -rd +Description: Ubuntu Artful Aardvark (development branch) +Release: 17.10 + +2) % apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.10~rc3+dfsg-0ubuntu1 + Candidate: 1:2.10+dfsg-0ubuntu1 + Version table: + 1:2.10+dfsg-0ubuntu1 500 + 500 http://archive.ubuntu.com//ubuntu devel/main amd64 Packages + *** 1:2.10~rc3+dfsg-0ubuntu1 100 + 100 /var/lib/dpkg/status + +3) qemu locks image files with no way to discover this feature nor how to disable it + +4) qemu provides a way to query if it supports image locking, and what the default value is, and how to disable the locking via cli + +qemu 2.10 now will lock image files and warn if an image is currently locked. This prevent qemu from running (and possibly corrupting said image). + +However, qemu does not provide any way to determine if a qemu binary actually has this capability. Normally behavior changing features are exposed via some change to the qemu help menu or QMP/QAPI output of capabilities. + +I believe this slipped through since libvirt already does image locking, but direct cli users will be caught by this change. + +In particular, we have a use-case where we simulate multipath disks by creating to disks which point to the same file which now breaks without adding the 'file.locking=off' to the -drive parameters; which is also completely undocumented and unexposed. + +Some parts of the cli like -device allow querying of settable options (qemu-system-x86 -device scsi_hd,?) but nothing equivalent exists for -drive parameters. + +ProblemType: Bug +DistroRelease: Ubuntu 17.10 +Package: qemu-system-x86 1:2.10~rc3+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5 +Uname: Linux 4.12.0-11-generic x86_64 +NonfreeKernelModules: zfs zunicode zavl zcommon znvpair +ApportVersion: 2.20.6-0ubuntu7 +Architecture: amd64 +Date: Fri Sep 8 12:56:53 2017 +JournalErrors: + Hint: You are currently not seeing messages from other users and the system. + Users in groups 'adm', 'systemd-journal' can see all messages. + Pass -q to turn off this notice. + -- Logs begin at Mon 2017-01-30 11:56:02 CST, end at Fri 2017-09-08 12:56:46 CDT. -- + -- No entries -- +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +MachineType: HP ProLiant DL360 Gen9 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.12.0-11-generic root=UUID=45354276-e0c0-4bf6-9083-f130b89411cc ro --- console=ttyS1,115200 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 03/05/2015 +dmi.bios.vendor: HP +dmi.bios.version: P89 +dmi.chassis.type: 23 +dmi.chassis.vendor: HP +dmi.modalias: dmi:bvnHP:bvrP89:bd03/05/2015:svnHP:pnProLiantDL360Gen9:pvr:cvnHP:ct23:cvr: +dmi.product.family: ProLiant +dmi.product.name: ProLiant DL360 Gen9 +dmi.sys.vendor: HP + + + +Thanks Ryan for filing this bug, as I said in IRC all the file locking is rather new and I think this is for upstream qemu to address. +Might just be a missed use case for them as well. + +I'll be adding an upstream qemu task to get their attention. +@Rayn - It would be nice if - from the multipath tests - you could copy in here a commandline that worked before but fails now. + +Added a qemu task, this seems to be a use case affected by the file locking. +In particular a (formerly working) case for multipath tests that use the same image files multiple times intentionally. + +So far the workaround is to set file.locking=off for all these, which might be just the right thing to do. +But then as outlined by the reporter there currently is no way to query if file locking is supported, nor if it is the current default - so at least adding that might be required to be added in qemu. + +The correct way to query whether file locking is supported is 'query-qmp-schema', which will expose the 'locking' option for the 'file' branch of the 'blockdev-add' command then. + +As a first comment, in your setup, completely disabling file locking is probably a too big hammer. It is preferable to just allow multiple writers on the same image by setting share-rw=on for the block device (e.g. '-device virtio-blk-pci,drive=foo,share-rw=on'). This will allow all guest devices to share the same image, but will still protect the image against other users like an incorrect qemu-img invocation while the VM is running. + +However, note that opening the same image file twice is not the best approach to the problem anyway. This happens to work with raw images (except for the locking), but it would cause corruption for any other image format. + +The better solution (though it may require more changes to your management application) is to open the image once and assign a node-name to it, and then let two guest devices point to the same node. Like above, this requires that share-rw=on be set for guest devices, but it will also work with non-raw image formats because the image file is now opened only once and the sharing is done internally in qemu. + +An example command line fragment might look like this: + + -blockdev node-name=disk,driver=file,filename=hd.img + -device virtio-blk,drive=disk,share-rw=on + -device virtio-blk,drive=disk,share-rw=on + +Technically, you can also keep using -drive instead of -blockdev, but it will result in a mixed state of modern node-name based block device management and the traditional drive based configuration, which might be confusing at times. + +Kevin, + +Thanks for the information. A couple of points for feedback: + +1) there doesn't appear to be a way to run qmp query-schema without spawning a qemu instance in -qmp mode and having a second client issue the query-schema; certainly a qemu-system-$arch -qmp-schema would be quite useful when examining feature availability. While I know the QMP/QAPI introspection is where most of the work has gone to describing how to interact with qemu it's quite cumbersome at best: + +searching for blockdev-add, find arg-type: 48, read arg-type-48, find list of 'variants', know that locking feature is part of 'file', find type: 207, see member 'locking' in list[A], which is of type 296, find type: 296, which is an enum of 'on', 'off', 'auto' + +A. Interesting enough, qapi says the default is None, however qemu certainly locks files by default which would seem to imply a mismatch between qapi defaults and qemu behavior. + +That's pretty heavy; Maybe that warning message qemu prints could provide some hints as to what a user could do (or refer to a manpage on locking?). + +2) share-rw appears to be a blockdev parameter (I see it available via most block devices via qemu-system-$arch -device {scsi-hd,ide-hd,virtio-blk}? However there is no equivalent -blockdev for dumping the default options that a -blockdev parameter takes. The qmp-schema also does not include any information about 'share-rw' w.r.t what values are available that I could find after dumping the schema. + +Thanks smoser: + +#!/bin/sh +qemu-system-x86_64 -S -nodefaults -nographic \ + -serial none -monitor none -qmp stdio <<EOF | +{ "execute": "qmp_capabilities" } +{ "execute": "query-qmp-schema" } +{ "execute": "quit" } +EOF + python3 -c ' +import json, sys +data = json.loads(sys.stdin.read().splitlines()[2]) +print(json.dumps(data, indent=1, sort_keys=True, + separators=(",", ": ")))' + + + + + + + +In our multipath case, the initial open succeeds (it's not locked by anything else) and the second lock attempt fails, however, IIUC the fcntl structure[1] includes the locking pid, which should be our invocation of QEMU; + +Can we not check if the locking pid matches the current pid and not fail? This appears to be the original goal of protecting locked images from being manipulated by external processes. + + + +Having a single QEMU process open the same qcow2 file twice is just as dangerous as having two separate QEMU processes open the same qcow2 file concurrently. In both cases you have qcow2 state cached in a BlockDriverState and nothing is able to invalidate the cache in the other BlockDriverState. So short-circuiting locking if the current pid matches would be wrong. + +Kevin, +Thanks for the suggestion of share-rw=on. I figured I'd try to change our 'xkvm' wrapper around qemu to use that. + +Unfortunately, it looks like , at least in our version of qemu (QEMU emulator +version 2.10.0(Debian 1:2.10+dfsg-0ubuntu1)), that this does not work +with the -drive path. + +$ qemu-img create -f qcow2 disk1.img 1G +$ qemu-system-x86_64 \ + -device virtio-net-pci,netdev=net00 \ + -netdev type=user,id=net00 \ + -drive id=drive01,file=disk1.img,format=qcow2,share-rw=on \ + -device drive=drive01,serial=sn-drive01,driver=virtio-blk,index=1 \ + -device drive=drive01,serial=sn-drive01,driver=virtio-blk,index=2 +qemu-system-x86_64: -drive id=drive01,file=disk1.img,format=qcow2,share-rw=on: Block format 'qcow2' does not support the option 'share-rw' + +I had thought you were suggesting the above, right? + + +The share-rw=on option belongs to -device, not to -drive/-blockdev. + +Your example does work (using -blockdev), but I can't get it to work with +-drive. + +$ qemu-system-x86_64 \ + -drive id=d01,file=disk1.img,format=qcow2 \ + -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on \ + -device drive=d01,serial=s01,driver=virtio-blk,index=2,share-rw=on +warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +qemu-system-x86_64: -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on: Drive 'd01' is already in use because it has been automatically connected to another device (did you need 'if=none' in the drive options?) + + +## ok, fix that error, add 'if=none' to the -drive. + +$ qemu-system-x86_64 \ + -drive id=d01,file=disk1.img,format=qcow2,if=none \ + -device virtio-blk,drive=d01,serial=s01,index=1,share-rw=on \ + -device virtio-blk,drive=d01,serial=s01,index=2,share-rw=on +qemu-system-x86_64: -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on: Property '.index' not found + +## ok, index belongs on the -drive (which I should have known from +## the past, but which seems not the right place). Try that anyway. + +$ qemu-system-x86_64 \ + -drive id=d01,file=disk1.img,format=qcow2,if=none,index=1 \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on +qemu-system-x86_64: -device drive=d01,serial=s01,driver=virtio-blk,share-rw=on: Drive 'd01' is already in use by another device + +## Huh? Isn't that what I said to explicitly allow with share-rw=on? + +Note that I've also tried with 'format=raw'. Is there something I'm +missing to try to use -drive and -device ? + +Lastly (if you're still reading), how do you specify the format of +the file to -blockdev ? adding 'format=qcow2' makes qemu complain that +"'format' is unexpected". + +Thanks for your time. + + +I see the answer to my question above. 'format' is now driver=qcow2. + + +The important difference between your -drive command line and my -blockdev example is that I used the node-name to reference the image. You can specify a node-name with -drive, too (having both id and node-name is one of the main things that I meant what I said mixing both styles can be confusing). + +I also don't think that index=1 does anything useful when used with if=none, so you can leave that out. + +Putting everything together, we get this: + +$ qemu-system-x86_64 \ + -drive node-name=d01,file=disk1.img,format=qcow2,if=none \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on + +Kevin, +thanks again. You've provided enough support for me at this point. I had looked at trying to coalesce multiple -drive values into a single one, and that can definitely be made to work with the newer qemu, but i'm not sure I can make it work with older. + +the goal there would be to do something like: +$ qemu-system-x86_64 \ + -drive id=d01,file.filename=disk1.img,format=qcow2,if=none -\ + -device virtio-blk,drive=d01,serial=s01 \ + -device virtio-blk,drive=d01,serial=s02 + +on newer qemu, that works if i change 'id=' to 'node-name', but on older qemu I can't convince it to let me have 1 drive associated to multiple -device. + +What we ended up doing is at + https://code.launchpad.net/~smoser/curtin/trunk.lp1716028-hack-file-locking-in-qemu/+merge/330456 + + + +Note that 'share-rw' was introduced earlier (commit dabd18f6, qemu 2.9) than 'locking' (commit 16b48d5d, qemu 2.10), so if qemu 2.9 is relevant for you, your hacky check doesn't work. + +We had a discussion today on how to workaround if you drive qmeu via libvirt. +While discussions often and up at the correctness of such setups they exists, I think it is worth to document until libvirt supports that officially. + +TL:DR: +- no native libvirt feature yet +- discussions if <shareable/> should set it +- workaround available via cmdline + +Details on the workaround: +- To use the workaround you have to check your log usually in /var/log/libvirt/qemu/<guestname>.log +- Get the id of the device that matters to you +- then use [1] to tweak qemu cmdline +- example is from [2] to [3] + +[1]: http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html +[2]: https://gist.github.com/anonymous/a2ce3cbf7878995537212f0dafd06d99 +[3]: https://gist.github.com/anonymous/07a357af9e34172b60c83d410fe63fdd + +Note: Depending on the case you might also get lucky with "shareable" and/or "readonly" disk attributes. + + +Umm, the latter is the official way to go, but only in latter libvirt versions. +https://libvirt.org/git/?p=libvirt.git;a=commit;h=28907b0043fbf71085a798372ab9c816ba043b93 + +I'm adding a libvirt bug task for the bionic merge to pick that up "explicitly" + +Also on the qemu side this is "works as intended" and workarounds are documented in this bug. +So we should set that bug status as well - looking back given it was mostly a discussion I guess "opinion" is the best close status in this case. + +I've taked this qemu-file-locking just so we can group/easily find other bugs that have this tag. +link to search for all bugs with that tag is: https://goo.gl/W2aT2T + +or the longer form: +https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.tag=qemu-file-locking + + + +Libvirt will make this "easier" to be avoided by +commit 28907b0043fbf71085a798372ab9c816ba043b93 +Author: Peter Krempa <email address hidden> +Date: Wed Nov 15 15:21:14 2017 +0100 + + qemu: command: Mark <shared/> disks as such in qemu + + Qemu has now an internal mechanism for locking images to fix specific + cases of disk corruption. This requires libvirt to mark the image as + shared so that qemu lifts certain restrictions. + + Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1378242 + +commit 860a3c4bea1d24773d8a495f213d5de3ac48a462 +Author: Peter Krempa <email address hidden> +Date: Wed Nov 15 15:02:58 2017 +0100 + + qemu: caps: Add capability for 'share-rw' disk option + + 'share-rw' for the disk device configures qemu to allow concurrent + access to the backing storage. + + The capability is checked in various supported disk frontend buses since + it does not make sense to partially backport it. + +Once this is complete in bionic by taking the new upstream I'll take a look at how backportable that is (changes look ok, but might need some testing in the SRU spirit of things). + +This bug was fixed in the package libvirt - 4.0.0-1ubuntu1 + +--------------- +libvirt (4.0.0-1ubuntu1) bionic; urgency=medium + + * Merged with Debian unstable (4.0) + This closes several bugs: + - Error generating apparmor profile when hostname contains spaces + (LP: #799997) + - qemu 2.10 locks files, libvirt shared now sets share-rw=on (LP: #1716028) + - libvirt usb passthrough throws apparmor denials related to + /run/udev/data/+usb (LP: #1727311) + - AppArmor denies access to /sys/block/*/queue/max_segments (LP: #1729626) + - iohelper improvements to let bypass-cache work without opening up the + apparmor isolation (LP: #1719579) + - nodeinfo on s390x to contain more CPU info (LP: #1733688) + - Upgrade libvirt >= 4.0 (LP: #1745934) + * Remaining changes: + - Disable libssh2 support (universe dependency) + - Disable firewalld support (universe dependency) + - Disable selinux + - Set qemu-group to kvm (for compat with older ubuntu) + - Additional apport package-hook + - Modifications to adapt for our delayed switch away from libvirt-bin (can + be dropped >18.04). + + d/p/ubuntu/libvirtd-service-add-bin-alias.patch: systemd: define alias + to old service name so that old references work + + d/p/ubuntu/libvirtd-init-add-bin-alias.patch: sysv init: define alias + to old service name so that old references work + + d/control: transitional package with the old name and maintainer + scripts to handle the transition + - Backwards compatible handling of group rename (can be dropped >18.04). + - config details and autostart of default bridged network. Creating that is + now the default in general, yet our solution provides the following on + top as of today: + + autostart the default network by default + + do not autostart if subnet is already taken (e.g. in guests). + - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is + the group based access to libvirt functions as it was used in Ubuntu + for quite long. + + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests + due to the group access change. + - ubuntu/parallel-shutdown.patch: set parallel shutdown by default. + - d/p/ubuntu/enable-kvm-spice.patch: compat with older Ubuntu qemu/kvm + which provided a separate kvm-spice. + - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The + section that adapts the path of the emulator to the Debian/Ubuntu + packaging is kept. + - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto + set VRAM to minimum requirements + - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts + - Add libxl log directory + - libvirt-uri.sh: Automatically switch default libvirt URI for users on + Xen dom0 via user profile (was missing on changelogs before) + - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from + included_files to avoid build failures due to duplicate definitions. + - Update README.Debian with Ubuntu changes + - Convert libvirt0, libnss_libvirt and libvirt-dev to multi-arch. + - Enable some additional features on ppc64el and s390x (for arch parity) + + systemtap, zfs, numa and numad on s390x. + + systemtap on ppc64el. + - fix conffile upgrade handling to avoid obsolete files + and inactive duplicates (LP 1694159) + - d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making + vmlinuz available and accessible (Debian bug 848314) + - d/test/smoke-lxc workaround for debbug 848317/867379 + - d/t/control, d/t/smoke-lxc: fix up lxc smoke test (Debian bug 848317) + - Add dnsmasq configuration to work with system wide dnsmasq (drop >18.04, + no more UCA onto Xenial then which has global dnsmasq by default). + - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx + - conffile handling of files dropped in 3.5 (can be dropped >18.04) + + /etc/init.d/virtlockd was sysv init only + + /etc/apparmor.d/local/usr.sbin.libvirtd and + /etc/apparmor.d/local/usr.lib.libvirt.virt-aa-helper are now generated + by dh_apparmor as needed + - Reworked apparmor Delta, especially the more complex delta is dropped + now, also our former delta is now split into logical pieces, has + improved comments and is part of a continuous upstreaming effort. + Listing related remaining changes: + + d/p/0001-apparmor-Allow-pygrub-to-run-on-Debian-Ubuntu.patch: apparmor: + Allow pygrub to run on Debian/Ubuntu + + d/p/0003-apparmor-libvirt-qemu-Allow-read-access-to-overcommi.patch: + apparmor, libvirt-qemu: Allow read access to overcommit_memory + + d/p/0007-apparmor-libvirt-qemu-Allow-owner-read-access-to-PRO.patch: + apparmor, libvirt-qemu: Allow owner read access to @{PROC}/*/auxv + + d/p/0017-apparmor-virt-aa-helper-Allow-access-to-tmp-director.patch: + apparmor, virt-aa-helper: Allow access to tmp directories + + d/p/ubuntu-aa/0020-virt-aa-helper-ubuntu-storage-paths.patch: + apparmor, virt-aa-helper: Allow various storage pools and image + locations + + d/p/0021-apparmor-virt-aa-helper-Add-openvswitch-support.patch: + apparmor, virt-aa-helper: Add openvswitch support + + d/p/0025-apparmor-fix-newer-virt-manager-1.4.0.patch: Add Apparmor + permissions so virt-manager 1.4.0 viewing works (LP 1668681). + + d/p/0029-appmor-libvirt-qemu-Add-9p-support.patch: appmor, + libvirt-qemu: Add 9p support + + d/p/0030-virt-aa-helper-Complete-9p-support.patch: virt-aa-helper: + add l to 9p file options. + + d/p/0031-virt-aa-helper-Ask-for-no-deny-rule-for-readonly-dis.patch: + virt-aa-helper: Ask for no deny rule for readonly disk (renamed and + reworded, was virt-aa-helper-no-explicity-deny-for-basefiles.patch) + + d/p/0032-apparmor-libvirt-qemu-Allow-reading-charm-specific-c.patch: + apparmor, libvirt-qemu: Allow reading charm-specific ceph config + + d/p/0033-UBUNTU-only-apparmor-for-kvm.powerpc-LP-1680384.patch: allow + commands executed by ubuntu only kvm wrapper on ppc64el (LP 1686621). + + d/p/0034-apparmor-virt-aa-helper-access-for-snapped-nova.patch: + apparmor, virt-aa-helper: access for snapped nova + * Dropped Changes (Upstream): + - d/p/0005-apparmor-libvirt-qemu-Allow-use-of-sgabios.patch: apparmor, + libvirt-qemu: Allow use of sgabios + - d/p/0006-apparmor-libvirt-qemu-Silence-lttng-related-deny-mes.patch: + apparmor, libvirt-qemu: Silence lttng related deny messages + - d/p/0008-apparmor-libvirt-qemu-Allow-read-access-to-sysfs-sys.patch: + apparmor, libvirt-qemu: Allow read access to sysfs system info + - d/p/0009-apparmor-libvirt-qemu-Allow-read-access-to-max_mem_r.patch: + apparmor, libvirt-qemu: Allow read access to max_mem_regions + - d/p/0010-apparmor-libvirt-qemu-Allow-qemu-block-extra-librari.patch: + apparmor, libvirt-qemu: Allow qemu-block-extra libraries + - d/p/0012-apparmor-libvirtd-Allow-access-to-netlink-sockets.patch: + apparmor, libvirtd: Allow access to netlink sockets + - d/p/0013-apparmor-Add-rules-for-mediation-support.patch: + apparmor: Add rules for mediation support + - d/p/0015-apparmor-virt-aa-helper-Allow-access-to-ecryptfs-fil.patch: + apparmor, virt-aa-helper: Allow access to ecryptfs files + - d/p/0016-apparmor-libvirtd-Allow-ixr-to-var-lib-libvirt-virtd.patch: + apparmor, libvirtd: Allow ixr to /var/lib/libvirt/virtd* + - d/p/0018-apparmor-virt-aa-helper-Add-ipv6-network-policy.patch: + apparmor, virt-aa-helper: Add ipv6 network policy + - d/p/0019-apparmor-virt-aa-helper-Allow-access-to-sys-bus-usb-.patch: + apparmor, virt-aa-helper: Allow access to /sys/bus/usb/devices + - d/p/0023-apparmor-qemu-won-t-call-qemu-nbd.patch: apparmor: qemu + won't call qemu-nbd + - d/p/0027-apparmor-allow-reading-cmdline-of-shutdown-signal.patch: + apparmor: allow to parse cmdline of the pid that send the shutdown + signal (LP 1680384). + - d/p/0028-apparmor-add-default-pki-path-of-lbvirt-spice.patch: + apparmor: add default pki path of lbvirt-spice (LP 1690140) + - d/p/ubuntu-aa/0035-virt-aa-helper-locking-disk-files-for-qemu-2.10.patch: + for compatibility with the behavior of qemu 2.10 this adds locking + permission to rules generated for disk files (LP 1709818) + - d/p/ubuntu-aa/0036-virt-aa-helper-locking-loader-nvram-for-qemu-2.10.patch: + for compatibility with the behavior of qemu 2.10 this adds locking + permission to rules generated for loader/nvram (LP 1710960) + - d/p/ubuntu-aa/0037-virt-aa-helper...: grant locking permission on append + files (LP 1726804) + - d/p/ubuntu-aa/0038-virt-aa-helper-fix-paths-for-usb-hostdevs.patch: + fix path generation for USB host devices (LP 1552241) + - d/p/ubuntu-aa/0039-virt-aa-helper-fix-libusb-access-to-udev-usb-data.patch: + generate valid rules on usb passthrough (LP 1686324) + - d/p/avoid-double-locking.patch: fix a deadlock that could occur when + libvirtd interactions raced with dbus causing a deadlock (LP 1714254). + - d/p/u/gnulib-getopt-posix-Fix-build-failure-when-using-ac_cv_head.patch: + fix FTBFS with glibc 2.26 (LP 1718668) + - Extended handling of apparmor profiles - clear lost profiles via cron + (now cleared by virt-aa-helper on domain stop) + - nat only on some ports <port start='1024' end='65535'/> (upstream + default now if nothing is specified, actually dropped last cycle) + * Dropped Changes (In Debian or no more important): + - d/p/0002-apparmor-libvirt-qemu-Allow-macvtap-access.patch: apparmor, + libvirt-qemu: Allow macvtap access + - d/p/0004-apparmor-Explicit-deny-for-setpcap.patch: apparmor: Explicit + deny for setpcap (LP 522845). + - d/p/0014-apparmor-virt-aa-helper-Improve-comment-about-backin.patch: + apparmor, virt-aa-helper: Improve comment about backing store + - d/p/0022-apparmor-drop-references-to-qemu-kvm.patch: apparmor: drop + references to qemu-kvm + - d/p/0024-apparmor-virt-aa-helper-Allow-access-to-name-service.patch: + apparmor, virt-aa-helper: Allow access to name services + - d/p/0026-apparmor-add-generic-base-vfio-device.patch: apparmor: add + /dev/vfio for vf (hot) attach (LP 1680384) (added by virt-aa-helper per + guest if needed). + - d/p/0011-apparmor-libvirt-qemu-Allow-access-to-hugepage-mount.patch: + apparmor, libvirt-qemu: Allow access to hugepage mounts + - Disable sheepdog (was for universe dependency, but is now only a suggest) + - d/p/ubuntu/storage-disable-gluster-test: gluster not enabled, skip test + * Dropped Changes (In Debian/Upstream now based on interim 3.10 work) some of + these were never released, but important to mention for the bug references: + - libnss-libvirt once enabled causes apt to call getdents + avoid this being an issue by dropping a apt conf that allows + this in seccomp (LP: #1732030). + - d/libvirt-daemon-system.postrm: clean up more libvirt directories on + purge + - d/p/ubuntu-aa/0041-apparmor-allow-unix-stream-for-p2p-migrations.patch: + apparmor: allow unix stream for p2p migrations + - d/p/ubuntu-aa/0043-security-apparmor-implement-domainSetPathLabel.patch: + this replaces the hugepage rules and fixes many more formerly missing + - d/p/ubuntu-aa/0044-security-full-path-option-for-DomainSetPathLabel.patch: + allowing to have path wildcards on labels set by domain callbacks + - d/p/ubuntu-aa/0045-security-apparmor-add-Set-Restore-ChardevLabel.patch: + apparmor implementation of security callback + - d/p/ubuntu-aa/0046-apparmor-virt-aa-helper-drop-static-channel-rule.patch: + this is now covered by chardev label callbacks + * Added Changes: + - Revert Debian change "Drop libvirt-bin upgrade handling" + This is needed in Ubuntu one last time (drop >18.04) + - Revert Debian change "Drop maintscript helpers for versions predating + jessie and wheezy-backports". This is needed in Ubuntu one last + time (drop >18.04) + - Refreshed d/p/* to match new version (only fuzz, no semantic change) + - d/libvirt-daemon-system.postrm: change order of libvirt-qemu removal + to avoid error messages on purge + - remove no more used libvirt-dnsmasq user (drop >18.04) + - d/p/ubuntu-aa/0040-apparmor-add-mediation-rules-for-unconfined.patch: + apparmor: add mediation rules for unconfined guests + - d/p/ubuntu-aa/0042-security-introduce-virSecurityManager-Set-Restore-Ch + .patch: backport upstream cahnge to expose already used chardev calls. + - d/libvirt-daemon-system.postrm: Remove the default.xml network link + set up by postinst. + - d/libvirt-daemon-system.maintscript: remove the now dropped conffile + /etc/cron.daily/libvirt-daemon-system + - d/libvirt-daemon-system.postinst: fixups for autostart default network + - use modern shell syntax + - try more default networks before giving up to enable by default + - d/p/ubuntu-aa/0020-virt-aa-helper-ubuntu-storage-paths.patch: + add multipass image path and mark as ubuntu only change. + - d/rules: install virtlockd correctly with defaults file (LP: #1729516) + - extended d/p/0025-apparmor-fix-newer-virt-manager-1.4.0.patch to cover + the slightly changed behavior of libvirt 4.0 (LP: #1741617) + - d/control: make libvirt-daemon-driver-storage-rbd a recommend instead of + just a suggest to have 3rd party relying on rbd out of the box working. + This is deprecated and users of rbd backend should start depending on + this package for it will be dropped to a suggest in future releases. + + -- Christian Ehrhardt <email address hidden> Thu, 14 Dec 2017 14:15:55 +0100 + +The avoidance for libvirt driven cases to map </shared> onto share-rw is complete in Bionic now, so I started to look into a potential SRU. + +But looking back it seems in the meantime everybody learned how to use it. +I have not seen any more dups coming in recently. +The same is true for openstack and likely everyone else. + +Therefore I'll set Won't Fix for Artful, we would have to wait for an upcoming security fix to be out of the queue anyway. If until that is done someone steps up and explains why this really still is needed in Artful I'll backport them, but otherwise I think we are good with Won't fix. + diff --git a/results/classifier/108/other/1716292 b/results/classifier/108/other/1716292 new file mode 100644 index 000000000..334fd2fc5 --- /dev/null +++ b/results/classifier/108/other/1716292 @@ -0,0 +1,77 @@ +other: 0.961 +network: 0.952 +semantic: 0.951 +debug: 0.949 +PID: 0.945 +device: 0.943 +permissions: 0.940 +graphic: 0.937 +performance: 0.936 +files: 0.933 +vnc: 0.933 +socket: 0.922 +boot: 0.869 +KVM: 0.841 + +User mode emulation returns wrong value for write(fd, NULL, 0) + +QEMU version: latest master (fcea73709b966a7ded9efa7b106ea50c7fe9025c) +OS version: Ubuntu 14.04.3 +Configured with: ../configure --target-list=x86_64-linux-user + +QEMU Linux usermode emulation does not handle write() syscalls with zero length and a null pointer correctly: on Linux this returns 0, but in emulation this returns -1. + +I ran into this while using an aarch64 abuild-tar from Alpine Linux in user-mode emulation; here's the minimized reproduction test case: + +zhuowei@zhuowei-tablet:/tmp$ cat writezerobytes.c +#include <stdio.h> +#include <unistd.h> +#include <fcntl.h> + +int main() { + ssize_t ret = write(STDOUT_FILENO, NULL, 0); + fprintf(stderr, "write returned %ld\n", ret); + return 0; +} +zhuowei@zhuowei-tablet:/tmp$ gcc -o writezerobytes writezerobytes.c +zhuowei@zhuowei-tablet:/tmp$ uname -a +Linux zhuowei-tablet 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux +zhuowei@zhuowei-tablet:/tmp$ ./writezerobytes +write returned 0 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 ./writezerobytes +write returned -1 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 --version +qemu-x86_64 version 2.10.50 (v2.10.0-471-gfcea737-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +This happens for me also, with qemu version 2.12.0 (Debian 1:2.12+dfsg-3). + +An initial patch was proposed here: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg08073.html + +Discussion pointed out some problems, and the patch languished and was not accepted. + +Here is a summary of the changes needed for it to be more likely for the patch to be accepted: https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg03964.html + + - change from "ret = 0" to something like "ret = get_errno(safe_write(arg1, NULL, 0))" + - change TARGET_NR_read to do the same, instead of its current short-circuit behaviour for count==0 + - check pread64/pwrite64 to see if they need a similar change as well + + + +On 09/07/2018 06:51 AM, Tony Garnock-Jones wrote: +> ** Patch added: "0001-Bring-linux-user-write-2-handling-into-line-with-lin.patch" +> https://bugs.launchpad.net/qemu/+bug/1716292/+attachment/5186008/+files/0001-Bring-linux-user-write-2-handling-into-line-with-lin.patch + +While a developer can chase a URL, our CI tools can't. Can you please +also send that patch directly to <email address hidden>, so that it gets +the same level of review as other patches? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +Fix has been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=58cfa6c2e6eb51b23cc98 + diff --git a/results/classifier/108/other/1716510 b/results/classifier/108/other/1716510 new file mode 100644 index 000000000..26bec7e61 --- /dev/null +++ b/results/classifier/108/other/1716510 @@ -0,0 +1,35 @@ +permissions: 0.849 +performance: 0.838 +other: 0.831 +files: 0.807 +vnc: 0.795 +KVM: 0.778 +boot: 0.777 +semantic: 0.769 +debug: 0.759 +graphic: 0.743 +device: 0.742 +socket: 0.728 +network: 0.664 +PID: 0.652 + +qemu 2.10.0 cannot boot Windows 10 familly + +On qemu 2.10.0 Windows 10 and Windows Server 2016 hangs during boot. Below is setup of Windows Server 2016. Downgrading to 2.9 fixes the problem. + +/usr/bin/qemu-system-x86_64 -name guest=<name>,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-<name>/master-key.aes -machine pc-q35-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu host,nx=on,hv_relaxed,hv_vapic,hv_spinlocks=0x1000,hv_vpindex,hv_runtime,hv_synic,hv_reset,kvm=off -drive file=/usr/local/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd,if=pflash,format=raw,unit=0 -drive file=/var/lib/libvirt/qemu/nvram/<name>_VARS.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 12,sockets=1,cores=6,threads=2 -object iothread,id=iothread1 -object iothread,id=iothread2 -object iothread,id=iothread3 -object iothread,id=iothread4 -object iothread,id=iothread5 -object iothread,id=iothread6 -object iothread,id=iothread7 -object iothread,id=iothread8 -object iothread,id=iothread9 -object iothread,id=iothread10 -object iothread,id=iothread11 -object iothread,id=iothread12 -uuid <uuid> -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-<name>/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-shutdown -boot strict=on -device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device ioh3420,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device ioh3420,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device ioh3420,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device ioh3420,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device ioh3420,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=2 -drive if=none,media=cdrom,id=drive-sata0-0-1,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=1 -drive file=/dev/mapper/<boot disk>,format=raw,if=none,id=drive-sata0-0-2 -device ide-hd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2,bootindex=3 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=<mac>,bus=pci.1,addr=0x0 -netdev tap,fd=24,id=hostnet1,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=<mac>,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice unix,addr=/var/lib/libvirt/qemu/domain-2-<name>/spice.sock,disable-ticketing,image-compression=auto_glz,seamless-migration=on -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device vhost-scsi-pci,wwpn=<wwpn>,vhostfd=26,id=hostdev0,bus=pcie.0,addr=0x9 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1024,period=1000,bus=pci.5,addr=0x0 -msg timestamp=o + +Possibly a duplicate of: + +https://bugs.launchpad.net/qemu/+bug/1714331 +or +https://bugs.launchpad.net/qemu/+bug/1715700 + +Can you share with us the version of OVMF you are using and potentially try a newer version (see lp 1714331) If not, keep your eye on lp 1715700 for updates. + +Ok. It looks like EDK was added to my distro and using it fixed it - https://packages.gentoo.org/packages/sys-firmware/edk2-ovmf (at least W16 - I'll try W10 tonight). + +Unfortunately when I run strings on edk I haven't seen anything which looked like version. + +Since this seems to be fixed when using EDK, I'm marking this ticket as Fix Released + diff --git a/results/classifier/108/other/1717414 b/results/classifier/108/other/1717414 new file mode 100644 index 000000000..a93230df1 --- /dev/null +++ b/results/classifier/108/other/1717414 @@ -0,0 +1,50 @@ +graphic: 0.810 +vnc: 0.727 +device: 0.662 +other: 0.640 +semantic: 0.615 +network: 0.578 +permissions: 0.564 +performance: 0.554 +socket: 0.521 +PID: 0.479 +debug: 0.412 +files: 0.305 +boot: 0.294 +KVM: 0.268 + +Sending certain keysyms results in wrong symbol input + +I develop bVNC, an Android VNC client. I noticed that when I connect to qemu VMs that have a VNC console, Keysyms that are usually sent over with SHIFT modifier when connecting from a PC have wrong symbols typed within the VM. A very short list of examples: + +exclam 33 0x0021 + +results in "1" typed in the VM. + +at 64 0x0040 + +results in "2" + +plus 43 0x002b + +results in "=" + +asterisk 42 0x002a + +results in "8" + +On Android, KEYCODEs that correspond to the above keysyms do not come with SHIFT metastate. Therefore, the keysyms that they correspond to are not sent over with any modifiers and must just work. + +The issue was reproduced with bVNC and RealVNC viewers connecting to many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The qemu version that comes with oVirt 4.1 is 2.6.0, commit hash bfc766d38e1fae5767d43845c15c79ac8fa6d6af. + +Sincerely, +iordan + +There have been quite a bunch of improvements in the keysyms handling during the past years ... can you still reproduce your issue with the latest version of QEMU? + +Seems to work fine now. Thank you!! + +iordan + +Thanks for testing! So I'm closing the ticket now. + diff --git a/results/classifier/108/other/1717708 b/results/classifier/108/other/1717708 new file mode 100644 index 000000000..45c95b643 --- /dev/null +++ b/results/classifier/108/other/1717708 @@ -0,0 +1,183 @@ +other: 0.647 +graphic: 0.607 +semantic: 0.569 +vnc: 0.544 +performance: 0.527 +debug: 0.518 +PID: 0.517 +KVM: 0.511 +permissions: 0.507 +network: 0.503 +boot: 0.500 +files: 0.480 +device: 0.478 +socket: 0.458 + +QEMU aarch64 can't run Windows ARM64 iso's + +Hi, +recently Windows ARM64 ISOs have been posted on the internet.. +just checked with latest QEMU 2.10 release from +https://qemu.weilnetz.de/w64/qemu-w64-setup-20170830.exe +"h:\qemu\qemu-system-aarch64.exe" -boot d -cdrom h:\iso\16353.1000.170825-1423.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_ES-ES.ISO -m 2048 -cpu cortex-a57 -smp 1 -machine virt +seems no video output.. +checked various machine options for example versatilepb (says guest has not initialized the guest).. + +so don't know if it's a QEMU bug or lacking feature but can support running Windows ARM64 builds (would be nice if you can add a Snapdragon835 machine type which is which first machines will be running..) + + +note running a Windows x64 ISO with similar parameters works (removing -cpu and -machine as not needed) + +thanks.. + +I meant: "says guest has not initialized the display".. + +It's expected behaviour that you don't have any video output, because by default the "virt" board has no graphics device. Most people use a serial console here. It should also be possible to set it up with a virtio gpu graphics device, but I don't know whether Windows supports that. + + +"D:\Program Files\qemu\qemu-system-aarch64.exe" -device virtio-scsi-pci,id=scsi -drive if=none,id=cd,file=\path\to\iso -device scsi-cd,drive=cd,bootindex=0 -m 2048 -cpu cortex-a57 -smp 4 -machine virt -device virtio-gpu-pci -bios "QEMU_EFI .fd" -device usb-ehci -device usb-kbd -device usb-mouse -usb + +The QEMU_EFI .fd is downloaded from https://releases.linaro.org/reference-platform/enterprise/17.08/uefi/release/qemu64/QEMU_EFI.fd + +While I've tried the 16353.1000.170825-1423.RS_PRERELEASE_CLIENTENTERPRISE_VOL_ARM64FRE_ES-ES.ISO, bios could find the EFI/BOOT/BOOTAA64.EFI file, but the installer doesn't boot up. + +thanks Peter.. +Shannon, +using your launch arguments seems to go as you write.. +nice progress.. + +any info on if running QEMU on Linux will be better right now than Windows? + +as I thought virtio-gpu was for Linux but I'm very new to QEMU so probably bad knowledge.. + +also don't know how mature ARM64 platform emulation is right now and how fast is progressing.. could be, that say next QEMU 2.11 could handle Windows ARM64 installation and booting correctly via some patches? + +thanks.. + + + + + +The virtio-gpu is not Linux specific. If windows could include the device driver, it can be used on windows as well like other virtio devices on windows x86. + +I'm not sure what's the requirements for booting Windows on ARM64 virt machine since the OS is not open source. So it would be better someone from MS solves this problem or points what we missed for support Windows. + +virtio-gpu-pci will not work for booting Windows. + +Per https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requirements-that-apply-to-all-windows-platforms, Windows currently requires a linear framebuffer to be exposed through the UEFI Graphics Output Protocol: + +"Windows requires the Graphics Output Protocol (GOP). Specific frame buffer requirements are: + + For integrated displays, HorizontalResolution and VerticalResoluton must be the native resolution of the panel. + + For External displays, HorizontalResolution and VerticalResoluton must be the native resolution of the display, or, if this is not supported, then the highest values supported by both the video adapter and the connected display. + + PixelsPerScanLine must be equal to HorizontalResolution. + + PixelFormat must be PixelBlueGreenRedReserved8BitPerColor. Note that a physical frame buffer is required; PixelBltOnly is not supported. + +When execution is handed off to a UEFI boot application, the firmware boot manager and firmware must not use the frame buffer for any purpose. The frame buffer must continue to be scanned out after boot services have exited." + +The virtio-gpu driver uses PixelBltOnly, which Windows explicitly doesn't support. Also, IIRC the Gop->Blt() handler of virtio-gpu is only available while UEFI Boot Services are active (before ExitBootServices() is called, which is something the Windows boot manager does very early), so even if Microsoft tried to implement Gop->Blt() support in the MSBDA driver, it couldn't be used with virtio-gpu, as its Gop->Blt() is not available at run time. + +Instead, "-device VGA" is required. + +Mainline edk2 is currently unable to boot any Windows images due to some required features being removed as they aren't compatible with KVM (I don't quite get it - UEFI for aarch64 virt is supposed to be for qemu in general, not exclusive to KVM...), however I actually have a fork with these features restored, available at https://github.com/Googulator/edk2/releases. This is able to boot the leaked Windows Server 2016 beta builds 14282, 14324 and 14877, but not 14901 or any of the Windows 10 Insider builds, due to an exception loop very similar to that seen when trying to run SBSA-ACS. + +Also, the only storage option Windows can actually read and boot from is USB mass storage over EHCI - anything else is either lacking drivers (virtio-scsi and the various emulated LSI Logic adapters) or fails to start due to a resource conflict (AHCI, UAS, USB mass storage over XHCI). Detailed instructions for booting the leaked builds are available here: https://www.betaarchive.com/forum/viewtopic.php?p=426768#p426768 The same instructions cause the previously mentioned exception loop when tried with the Insider builds. + +Plain linear framebuffer won't work with KVM, unfortunately. The best fix is for Windows to support virtio-gpu, then it will work in KVM as well as pure emulation. + + +I know it won't work in KVM. I'm arguing that something not working in KVM is not grounds for removal from the UEFI image, since qemu != KVM. + +If you want to argue for things being in UEFI images, you're in the wrong place, because this is the QEMU bug tracker, not a UEFI one... + + +(1) See also <https://bugs.launchpad.net/qemu/+bug/1717708>. + +(2) One idea is (a) letting Windows use VirtioGpuDxe's GOP (blt only) until it calls ExitBootServices() -- which I have already confirmed to work with an ARM64 Windows Server variant that I was legally given access to --, and (b) once available, injecting a native ARM64 virtio-gpu-pci driver into the installer image, which Windows could start using right after ExitBootServices(). + +(3) BTW, Gerd recently posted + +[Qemu-devel] [PATCH 0/4] ramfb: simple boot framebuffer, no legacy vga +http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg03299.html + +which could be an alternative. (Albeit -- in my opinion! -- inferior to (2).) + +(4) In the above-referenced article at <https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/uefi-requirements-that-apply-to-all-windows-platforms>, Microsoft write, "Microsoft welcomes feedback and comments from implementers on this set of requirements". That sounds awesome: for a change, how about we stop reverse engineering Windows boot (off of lawfully obtained media of course) and engage in a conversation. Writing VirtioGpuDxe wasn't trivial, and I'm not amused at the thought of (a) it being a waste, (b) struggling with more and more hacks / custom devices & drivers until one set happens to work. We should stop fabricating one-sided hacks for placating Windows. + +(5) Can we please stop making references to leaked or otherwise unlawfully obtained Windows media, and warez sites. In the upstream QEMU bug tracker no less. Thanks. + +Sigh, in bullet (1) of comment #10, I obviously didn't mean to link this same LP entry. Instead I meant <https://bugzilla.tianocore.org/show_bug.cgi?id=785>. Sorry. + +I just noticed this bug via qemu-devel. For the record, recent QEMU (2.11-rc1 and later) can run recent arm64 Windows images using -M virt and the virtio storage/input/networking drivers in the guest. I was using older UEFI build that still includes the VGA framebuffer support. (I only just learned via this bug that it had been removed, but as PeterM pointed out this isn't the right place to discuss it.) + +Here's a sample invocation: +qemu-system-aarch64 -M virt -cpu cortex-a57 -m 4G -smp 4 -bios QEMU_EFI-arm64.fd \ + -serial stdio -device VGA -device virtio-keyboard-pci -device virtio-mouse-pci \ + -netdev user,id=net0 -device virtio-net-pci,disable-legacy=on,netdev=net0,mac=00:11:22:33:44:55,addr=08 \ + -drive if=none,file=myimage.vhdx,id=hd0 -device virtio-blk-pci,drive=hd0 + +@Andrew: are you implying that you successfully rebuilt the virtio guest drivers for ARM64 Windows? If that's the case, could you please share specifics about the build setup? I'm not the one working on the virtio GPU driver for Windows, but I assume your aarch64 build steps would apply to that driver similarly. Thank you. + +@Laszlo, I got the binaries from someone else, but they from a parallel build system... nothing particularly special: some preprocessor rules to build against the newer WDK, and also it was just those three drivers (netkvm, vioinput, viostor). I imagine you can get the same result by tweaking the VS-based build (sln/vcxproj files), but haven't tried. Sorry that's not terribly helpful. + +@Andrew can you upload these three drivers somewhere for the lazy people? +thanks.. + +2017-11-21 0:11 GMT+01:00 Andrew Baumann <email address hidden>: + +> @Laszlo, I got the binaries from someone else, but they from a parallel +> build system... nothing particularly special: some preprocessor rules to +> build against the newer WDK, and also it was just those three drivers +> (netkvm, vioinput, viostor). I imagine you can get the same result by +> tweaking the VS-based build (sln/vcxproj files), but haven't tried. +> Sorry that's not terribly helpful. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1717708 +> +> Title: +> QEMU aarch64 can't run Windows ARM64 iso's +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> recently Windows ARM64 ISOs have been posted on the internet.. +> just checked with latest QEMU 2.10 release from +> https://qemu.weilnetz.de/w64/qemu-w64-setup-20170830.exe +> "h:\qemu\qemu-system-aarch64.exe" -boot d -cdrom +> h:\iso\16353.1000.170825-1423.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_ES-ES.ISO +> -m 2048 -cpu cortex-a57 -smp 1 -machine virt +> seems no video output.. +> checked various machine options for example versatilepb (says guest has +> not initialized the guest).. +> +> so don't know if it's a QEMU bug or lacking feature but can support +> running Windows ARM64 builds (would be nice if you can add a +> Snapdragon835 machine type which is which first machines will be +> running..) +> +> +> note running a Windows x64 ISO with similar parameters works (removing +> -cpu and -machine as not needed) +> +> thanks.. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1717708/+subscriptions +> + + +Has anyone been able to find a workaround to run this with KVM from an ARM64 host? What exactly is the problem with Qemu/KVM/Aarch64 that stops KVM from working - and are any efforts being made to get around it? + +I encountered same problem. No video output when I start win10 with kvm enabled on arm64 host. +Is there any update? + +No need to keep this open any longer (no activity for 19 months). Please follow the links captured above to the past discussions. There's nothing new to add wrt. the situation. + diff --git a/results/classifier/108/other/1718118 b/results/classifier/108/other/1718118 new file mode 100644 index 000000000..d343da16c --- /dev/null +++ b/results/classifier/108/other/1718118 @@ -0,0 +1,76 @@ +debug: 0.867 +files: 0.864 +device: 0.855 +graphic: 0.851 +permissions: 0.843 +other: 0.839 +boot: 0.838 +PID: 0.836 +socket: 0.836 +performance: 0.835 +network: 0.835 +KVM: 0.831 +vnc: 0.820 +semantic: 0.807 + +qemu crashes with hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) + +Qemu crashes with error "hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev)" when memory hotplug and hotunplug was done continuously. + +Steps to re-produce: +1. git clone (today's i.e 19th Sept) +2. Bring up ppc64le guest with memory hotplug capabilities ( I used libvirt xml to do this). +3. And do continuous memory hotplug and unplug using the following memory xml (mem_hp_8g.xml) +<memory model='dimm'> +<target> +<size unit='KiB'>8388608</size> +<node>1</node> +</target> +</memory> +4. Run the following +for i in `seq 1 100`; do virsh attach-device nrs mem_hp_8g.xml --live; virsh detach-device nrs mem_hp_8g.xml --live; done +5. Guest will crash +6. Following is from qemu log + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-ppc64 -name guest=nrs,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-nrs/master-key.aes -machine pseries-2.10,accel=kvm,usb=off,dump-guest-core=off -m size=8388608k,slots=256,maxmem=419430400k -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -numa node,nodeid=1,cpus=2-3,mem=4096 -uuid d7987973-2467-43ff-b8d2-acefc6ac59e5 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-19-nrs/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/nasastry/pegas-1.0-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:89:8a:8b,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -s -msg timestamp=on +2017-09-19 06:59:07.878+0000: Domain id=19 is tainted: custom-argv +2017-09-19T06:59:07.918273Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/5 (label charserial0) +** +ERROR:/home/nasastry/qemu/hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) +2017-09-19 06:59:51.428+0000: shutting down, reason=crashed + +(gdb) bt +#0 0x00003fffb24beff0 in raise () at /lib64/libc.so.6 +#1 0x00003fffb24c136c in abort () at /lib64/libc.so.6 +#2 0x00003fffb2bcaa04 in g_assertion_message () at /lib64/libglib-2.0.so.0 +#3 0x00003fffb2bcab0c in g_assertion_message_expr () at /lib64/libglib-2.0.so.0 +#4 0x00000000101b85a0 in spapr_drc_detach (drc=0x2fc31220) at /home/nasastry/qemu/hw/ppc/spapr_drc.c:417 +#5 0x00000000101972e0 in spapr_memory_unplug_request (hotplug_dev=0x2faa60b0, dev=0x2fb8fb10, errp=0x3fffe92bfa90) at /home/nasastry/qemu/hw/ppc/spapr.c:3084 +#6 0x000000001019856c in spapr_machine_device_unplug_request (hotplug_dev=0x2faa60b0, dev=0x2fb8fb10, errp=0x3fffe92bfa90) + at /home/nasastry/qemu/hw/ppc/spapr.c:3354 +#7 0x00000000104461a8 in hotplug_handler_unplug_request (plug_handler=0x2faa60b0, plugged_dev=0x2fb8fb10, errp=0x3fffe92bfa90) at hw/core/hotplug.c:45 +#8 0x000000001036e15c in qdev_unplug (dev=0x2fb8fb10, errp=0x3fffe92bfa90) at qdev-monitor.c:878 +#9 0x000000001036e1e4 in qmp_device_del (id=0x2fab2880 "dimm0", errp=0x3fffe92bfa90) at qdev-monitor.c:888 +#10 0x000000001038975c in qmp_marshal_device_del (args=0x30658db0, ret=0x3fffe92bfb50, errp=0x3fffe92bfb48) at qmp-marshal.c:1462 +#11 0x000000001081fd98 in do_qmp_dispatch (cmds=0x10c0e078 <qmp_commands>, request=0x3093ebf0, errp=0x3fffe92bfbc0) at qapi/qmp-dispatch.c:104 +#12 0x000000001081ff84 in qmp_dispatch (cmds=0x10c0e078 <qmp_commands>, request=0x3093ebf0) at qapi/qmp-dispatch.c:131 +#13 0x00000000100983dc in handle_qmp_command (parser=0x2fae1e80, tokens=0x2faa44e0) at /home/nasastry/qemu/monitor.c:3852 +#14 0x000000001082aef0 in json_message_process_token (lexer=0x2fae1e88, input=0x2faa2420, type=JSON_RCURLY, x=70, y=374) at qobject/json-streamer.c:105 +#15 0x000000001086d5d0 in json_lexer_feed_char (lexer=0x2fae1e88, ch=125 '}', flush=false) at qobject/json-lexer.c:323 +#16 0x000000001086d7c4 in json_lexer_feed (lexer=0x2fae1e88, buffer=0x3fffe92bff88 "}", size=1) at qobject/json-lexer.c:373 +#17 0x000000001082b004 in json_message_parser_feed (parser=0x2fae1e80, buffer=0x3fffe92bff88 "}", size=1) at qobject/json-streamer.c:124 +#18 0x000000001009863c in monitor_qmp_read (opaque=0x2fae1df0, buf=0x3fffe92bff88 "}", size=1) at /home/nasastry/qemu/monitor.c:3894 +#19 0x000000001078e3c8 in qemu_chr_be_write_impl (s=0x2fab36b0, buf=0x3fffe92bff88 "}", len=1) at chardev/char.c:167 +#20 0x000000001078e484 in qemu_chr_be_write (s=0x2fab36b0, buf=0x3fffe92bff88 "}", len=1) at chardev/char.c:179 +#21 0x000000001079a910 in tcp_chr_read (chan=0x2fbfbbc0, cond=G_IO_IN, opaque=0x2fab36b0) at chardev/char-socket.c:441 +#22 0x00000000107be3d4 in qio_channel_fd_source_dispatch (source=0x2fab4770, callback=0x1079a760 <tcp_chr_read>, user_data=0x2fab36b0) at io/channel-watch.c:84 +#23 0x00003fffb2b93ab0 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#24 0x0000000010837e9c in glib_pollfds_poll () at util/main-loop.c:213 +#25 0x0000000010838064 in os_host_main_loop_wait (timeout=-1) at util/main-loop.c:261 +#26 0x000000001083818c in main_loop_wait (nonblocking=0) at util/main-loop.c:515 +#27 0x00000000103771c4 in main_loop () at vl.c:1999 +#28 0x0000000010381828 in main (argc=54, argv=0x3fffe92c1988, envp=0x3fffe92c1b40) at vl.c:4877 + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2a129767ebb13ffc29dad + diff --git a/results/classifier/108/other/1718964 b/results/classifier/108/other/1718964 new file mode 100644 index 000000000..af438b77d --- /dev/null +++ b/results/classifier/108/other/1718964 @@ -0,0 +1,132 @@ +graphic: 0.905 +semantic: 0.871 +KVM: 0.861 +other: 0.858 +performance: 0.852 +debug: 0.812 +network: 0.811 +PID: 0.805 +permissions: 0.801 +device: 0.801 +vnc: 0.777 +files: 0.751 +boot: 0.695 +socket: 0.669 + +Memory leak when using websocket over a low speed network + +Description of problem +------------------------- + +When VNC is connected to QEMU via websocket over a low speed network (e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer update, the VNC Client will get stuck, the cursor is almost impossible to move, which may result in accumulation of a large number of data in the QEMU process (memory consumption will keep increasing). + + +Environment +------------------------- +All of the following versions have been tested: + +QEMU: 2.5.1 / 2.6.0 / 2.8.1.1 / 2.9.0 / 2.10.0 +Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 +Guest OS: Windows 7 64bit / Ubuntu 16.04 Desktop LTS +Client OS: Windows 7 64bit / Windows 10 64bit +Client Browser: IE 11.0.9600 / Chrome 60.0.3112 / Firefox 55.0.2 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 +VNC Web Client: noVNC 0.5.1 / noVNC 0.61 / noVNC 0.62 +VNC Server: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 + + +Steps to reproduce: +------------------------- +100% reproducible. + +1. Launch a QEMU instance with websocket option: +qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :1,websocket=5701 + +2. Open VNC Web Client (noVNC/vnc.html) in browser and connect to QEMU VM via websocket + +3. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) + +4. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) + +5. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move + +6. Observe QEMU process on the host, more and more data are accumulated in the process, the consumption of memory continues to keep increasing + + +Current result: +------------------------- +[Top - Initial status] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7229144 5.910g 23024 S 16.3 18.9 0:12.84 qemu-system-x86_64 + +[Top - After an hour's playing w/o limit (6-8MB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7370284 6.046g 23132 S 28.0 19.3 35:58.15 qemu-system-x86_64 + +[Top - Limit the bandwidth and continue to playing for another an hour (300KB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 11.029g 8.853g 23132 S 20.0 28.2 72:14.17 qemu-system-x86_64 + +Also test several other combinations in the same environment: + +1. Client(VNC Viewer) - Server(QEMU) +2. Client(VNC Viewer) - Server(tigervnc/x11vnc/tightvnc) +3. Client(noVNC) - Server(tigervnc/x11vnc/tightvnc) + +Likewise, the client's inbound bandwidth is limited to 300KB/S, +although a lot of frame are lost, all of they still works (at least the mouse is movable). + +It's found that when connect to QEMU via websocket, it never drop any frames. +QEMU still sends a lot of data to its websocket even when the network is congested, +the process is continually consuming more memory, then it gets stack. + + +Expected results: +------------------------- +When the network is poor (non-LAN), QEMU would reduce the VNC data send to its websocket correspondingly, and the memory usage remains stable. + +Thanks for your report. I've not tried reproducing yet, but from the looking at the code I think I can see why this happens. Code in vnc_update_client discards incoming frame updates from the guest if the output buffer has data pending in it, but it only checks the main VNC server output buffer usage. It fails to check the websockets output buffer usage. + +In the modern code this needs fixing in the io/channel-websock.c impl - it is checking the output buffer limit against the wrong buffer - it uses 'rawoutput' instead of 'encoutput', so this fix is easy enough there. + +The code is in fact broken all the way back to day1 of the introduction of websockets support though in QEMU 1.2.1 In the historical code it can be fixed by checking ws_output.offset in vnc_update_client as I mentioned previously + +We are experiencing the same problem. + +At first, we thought the bug is in QEMU's websocket code then we tried using a standalone websocket proxy (websockify). Unfortunately, problems persisted. + +We also tried various other VNC servers (with websockify), all of them work fine. It seems that the issue is specific to QEMU. + +This has been assigned CVE-2017-15268 + +http://www.openwall.com/lists/oss-security/2017/10/12/4 + +commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 +Author: Daniel P. Berrange <email address hidden> +Date: Mon Oct 9 14:43:42 2017 +0100 + + io: monitor encoutput buffer size from websocket GSource + + The websocket GSource is monitoring the size of the rawoutput + buffer to determine if the channel can accepts more writes. + The rawoutput buffer, however, is merely a temporary staging + buffer before data is copied into the encoutput buffer. Thus + its size will always be zero when the GSource runs. + + This flaw causes the encoutput buffer to grow without bound + if the other end of the underlying data channel doesn't + read data being sent. This can be seen with VNC if a client + is on a slow WAN link and the guest OS is sending many screen + updates. A malicious VNC client can act like it is on a slow + link by playing a video in the guest and then reading data + very slowly, causing QEMU host memory to expand arbitrarily. + + This issue is assigned CVE-2017-15268, publically reported in + + https://bugs.launchpad.net/qemu/+bug/1718964 + + Reviewed-by: Eric Blake <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + + diff --git a/results/classifier/108/other/1719 b/results/classifier/108/other/1719 new file mode 100644 index 000000000..aaa91c5fc --- /dev/null +++ b/results/classifier/108/other/1719 @@ -0,0 +1,22 @@ +graphic: 0.650 +device: 0.591 +semantic: 0.539 +socket: 0.454 +other: 0.422 +network: 0.408 +PID: 0.397 +vnc: 0.367 +files: 0.247 +boot: 0.217 +performance: 0.167 +permissions: 0.111 +debug: 0.108 +KVM: 0.017 + +Allow TCG plugins to read memory +Additional information: +* `include/qemu/plugin.h` +* `include/qemu/qemu-plugin.h` +* `plugin/api.c` + +PANDA implemented this already (not sure if this solution is acceptable for the mainline QEMU): https://github.com/qemu/qemu/commit/72c661a7f141ab41fbce5e95eb3593b69f40e246 diff --git a/results/classifier/108/other/1719282 b/results/classifier/108/other/1719282 new file mode 100644 index 000000000..1ddc2ba8f --- /dev/null +++ b/results/classifier/108/other/1719282 @@ -0,0 +1,146 @@ +other: 0.914 +graphic: 0.866 +PID: 0.828 +performance: 0.823 +device: 0.818 +permissions: 0.798 +vnc: 0.781 +semantic: 0.773 +socket: 0.764 +debug: 0.763 +boot: 0.757 +network: 0.729 +KVM: 0.708 +files: 0.697 + +Unable to boot after drive-mirror + +Hi, +I am using "drive-mirror" qmp block-job command to transfer VM disk image to other path (different physical disk on host). +Unfortunately after shutting down and starting from new image, VM is unable to boot and qrub enters rescue mode displaying following error: +``` +error: file '/grub/i386-pc/normal.mod' not found. +Entering rescue mode... +grub rescue> +``` + +To investigate the problem, I compared both RAW images using linux "cmp -l" command and found out that they differ in 569028 bytes starting from address 185598977 to 252708864 which are located on /boot partition. + +So I mounted /boot partition of mirrored RAW image on host OS and it seems that file-system is broken and grub folder is not recognized. But /boot on original RAW image has no problem. + +Mirrored Image: +ls -l /mnt/vm-boot/ +ls: cannot access /mnt/vm-boot/grub: Structure needs cleaning +total 38168 +-rw-r--r-- 1 root root 157721 Oct 19 2016 config-3.16.0-4-amd64 +-rw-r--r-- 1 root root 129281 Sep 20 2015 config-3.2.0-4-amd64 +d????????? ? ? ? ? ? grub +-rw-r--r-- 1 root root 15739360 Nov 2 2016 initrd.img-3.16.0-4-amd64 +-rw-r--r-- 1 root root 12115412 Oct 10 2015 initrd.img-3.2.0-4-amd64 +drwxr-xr-x 2 root root 12288 Oct 7 2013 lost+found +-rw-r--r-- 1 root root 2679264 Oct 19 2016 System.map-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2114662 Sep 20 2015 System.map-3.2.0-4-amd64 +-rw-r--r-- 1 root root 3126448 Oct 19 2016 vmlinuz-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2842592 Sep 20 2015 vmlinuz-3.2.0-4-amd64 + +Original Image: +ls /mnt/vm-boot/ -l +total 38173 +-rw-r--r-- 1 root root 157721 Oct 19 2016 config-3.16.0-4-amd64 +-rw-r--r-- 1 root root 129281 Sep 20 2015 config-3.2.0-4-amd64 +drwxr-xr-x 5 root root 5120 Nov 2 2016 grub +-rw-r--r-- 1 root root 15739360 Nov 2 2016 initrd.img-3.16.0-4-amd64 +-rw-r--r-- 1 root root 12115412 Oct 10 2015 initrd.img-3.2.0-4-amd64 +drwxr-xr-x 2 root root 12288 Oct 7 2013 lost+found +-rw-r--r-- 1 root root 2679264 Oct 19 2016 System.map-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2114662 Sep 20 2015 System.map-3.2.0-4-amd64 +-rw-r--r-- 1 root root 3126448 Oct 19 2016 vmlinuz-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2842592 Sep 20 2015 vmlinuz-3.2.0-4-amd64 + +ls /mnt/vm-boot/grub/ -l +total 2376 +-rw-r--r-- 1 root root 48 Oct 7 2013 device.map +drwxr-xr-x 2 root root 1024 Oct 10 2015 fonts +-r--r--r-- 1 root root 9432 Nov 2 2016 grub.cfg +-rw-r--r-- 1 root root 1024 Oct 7 2013 grubenv +drwxr-xr-x 2 root root 6144 Aug 6 2016 i386-pc +drwxr-xr-x 2 root root 1024 Aug 6 2016 locale +-rw-r--r-- 1 root root 2400500 Aug 6 2016 unicode.pf2 + +qemu Version: 2.7.0-10 + +Host OS: Debian 8x64 +Guest OS: Debian 8x64 + +QMP Commands log: +socat UNIX-CONNECT:/var/run/qemu-server/48016.qmp STDIO +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 7, "major": 2}, "package": "pve-qemu-kvm_2.7.0-10"}, "capabilities": []}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "drive-mirror", + "arguments": { + "device": "drive-ide0", + "target": "/diskc/48016/vm-48016-disk-2.raw", + "sync": "full", + "mode": "absolute-paths", + "speed": 0 + } +} +{"return": {}} +{"timestamp": {"seconds": 1506331591, "microseconds": 623095}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-ide0", "len": 269445758976, "offset": 269445758976, "speed": 0, "type": "mirror"}} +{"timestamp": {"seconds": 1506332641, "microseconds": 245272}, "event": "SHUTDOWN"} +{"timestamp": {"seconds": 1506332641, "microseconds": 377751}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-ide0", "len": 271707340800, "offset": 271707340800, "speed": 0, "type": "mirror"}} + +Do you have more information on the sequence of commands issued to QEMU? I see the drive-mirror invocation, but then I don't see what causes the shutdown or the BLOCK_JOB_COMPLETED event. Usually this is in response to a user command. I'm wondering if the exact sequence issued is safe. + +Do you have a reproducer that I could try on my system to examine the behavior? + +Also, 2.7 is a bit old at this point; do you have the ability to try a version currently supported by the upstream project? (2.9 or 2.10?) + + + +In last try, vm shutdown before completing blockjob. +So i tried again and these are the exact qmp commands which i used: + +Sequence of qmp commands: + +socat UNIX-CONNECT:/var/run/qemu-server/48016.qmp STDIO +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 7, "major": 2}, "package": "pve-qemu-kvm_2.7.0-10"}, "capabilities": []}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "drive-mirror", + "arguments": { + "device": "drive-ide0", + "target": "/diskb/48016/vm-48016-disk-1.raw", + "sync": "full", + "mode": "absolute-paths", + "speed": 0 + } +} +{"return": {}} +{"timestamp": {"seconds": 1506434603, "microseconds": 633439}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-ide0", "len": 268479496192, "offset": 268479496192, "speed": 0, "type": "mirror"}} +{ "execute": 'block-job-complete', 'arguments': { 'device': 'drive-ide0' } } +{"return": {}} +{"timestamp": {"seconds": 1506494590, "microseconds": 735601}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-ide0", "len": 278522167296, "offset": 278522167296, "speed": 0, "type": "mirror"}} + +Then i poweroff VM and start it again from new image, but grub starts in rescue mode. + +It *looks* to me at a glance like the sequence should be safe, but I don't have any hunches for what could be going wrong, or why. + +Can you please post: + +(1) The command-line used to launch QEMU on the source machine, and +(2) The command-line used to launch QEMU on the destination machine from the mirrored image? + +There is no source or destination machine. I used drive-mirror to transfer VM Image to different physical disk on same machine ("mode": "absolute-paths"). After block-job-complete and shutting down vm, I start vm again with same command with different drive path pointing to mirrored image. "-drive 'file=MIRRORED_IMAGE_PATH..". + +* Command line used to launch VM: +``` +/usr/bin/kvm -id 48016 -chardev 'socket,id=qmp,path=/var/run/qemu-server/48016.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/48016.pid -daemonize -smbios 'type=1,uuid=7a4b5ebc-a230-4e57-8ebc-4979a7b5a378' -name srv34197 -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vga cirrus -vnc unix:/var/run/qemu-server/48016.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 8192 -k en-us -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -chardev 'socket,path=/var/run/qemu-server/48016.qga,server,nowait,id=qga0' -device 'virtio-serial,id=qga0,bus=pci.0,addr=0x8' -device 'virtserialport,chardev=qga0,name=org.qemu.guest_agent.0' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:6f368eef312d' -drive 'file=/var/lib/vz/images/48016/vm-48016-disk-1.raw,if=none,id=drive-ide0,format=raw,cache=none,aio=native,detect-zeroes=on' -device 'ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100' -drive 'file=/var/lib/vz/template/iso/sysresccd-v03.iso,if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -netdev 'type=tap,id=net0,ifname=tap48016i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' -device 'rtl8139,mac=D6:89:56:3F:38:1F,netdev=net0,bus=pci.0,addr=0x12,id=net0' -netdev 'type=tap,id=net1,ifname=tap48016i1,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' -device 'rtl8139,mac=66:92:13:4A:6B:7E,netdev=net1,bus=pci.0,addr=0x13,id=net1' +``` + + +OK, so we're only talking about migrating a disk and not a whole VM, I misunderstood. However... are you using qemu *2.7*? That's quite old! Before digging into this further I need to insist that you try on a supported release, either 4.0.1, 4.1.1, or 4.2.0. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1719339 b/results/classifier/108/other/1719339 new file mode 100644 index 000000000..4f5e76b0e --- /dev/null +++ b/results/classifier/108/other/1719339 @@ -0,0 +1,53 @@ +KVM: 0.614 +vnc: 0.506 +other: 0.456 +device: 0.429 +network: 0.422 +permissions: 0.420 +files: 0.413 +performance: 0.372 +boot: 0.370 +debug: 0.362 +semantic: 0.350 +socket: 0.341 +graphic: 0.337 +PID: 0.333 + +serial8250: too much work for irq3 + +It's know issue and sometimes mentioned since 2007. But it seems not fixed. + +http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00140.html +https://bugzilla.redhat.com/show_bug.cgi?id=986761 +http://old-list-archives.xenproject.org/archives/html/xen-devel/2009-02/msg00696.html + +I don't think fixes like increases PASS_LIMIT (/drivers/tty/serial/8250.c) or remove this annoying message (https://patchwork.kernel.org/patch/3920801/) is real fix. Some fix was proposed by H. Peter Anvin https://lkml.org/lkml/2008/2/7/485. + +Can reproduce on Debian Strech host (Qemu 1:2.8+dfsg-6+deb9u2), Ubuntu 16.04.2 LTS (Qemu 1:2.5+dfsg-5ubuntu10.15) also tried to use master branch (QEMU emulator version 2.10.50 (v2.10.0-766-ga43415ebfd-dirty)) if we write a lot of message into console (dmesg or dd if=/dev/zero of=/dev/ttyS1). + +/usr/local/bin/qemu-system-x86_64 -name guest=ultra1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-ultra1/master-key.aes -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Client,ds=on,acpi=on,ss=on,ht=on,tm=on,pbe=on,dtes64=on,monitor=on,ds_cpl=on,vmx=on,smx=on,est=on,tm2=on,xtpr=on,pdcm=on,osxsave=on,tsc_adjust=on,clflushopt=on,pdpe1gb=on -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 4537ca29-73b2-40c3-9b43-666de182ba5f -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-27-ultra1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8.0x7 -drive file=/home/dzagorui/csr/csr_disk.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:a9:4c:86,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4000,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4001,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 -msg timestamp=on + +Use simpler setup for reproducing. +Was used only qemu-system-x86_64 (without using high-level wrappers and managers of virtual machines: libvirt, virsh, virt-install, virt-manager etc..). My setup with two consoles: + +/usr/local/bin/qemu-system-x86_64 -cpu host -enable-kvm -m 256 -smp 4 -kernel /home/dzagorui//bzImage -append 'root=/dev/ram0 loglevel=9 rw console=ttyS0' -initrd /home/dzagorui/initrd.cpio -display none -chardev socket,id=charserial0,host=127.0.0.1,port=4002,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4003,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 + +I noticed one thing, that -smp parameter affects this issue. When -smp 1 i can't reproduce this issue at all, when -smp 2 i can produce this issue only in second console (ttyS1), when -smp 4 and higher the issue produces on both consoles (ttyS1/ttyS0). +My Host cpu i5-6200U has 2 cores and 4 threads. + +For reproducing was used this commands (no matter what console we use ttyS1 or ttyS0): +#dmesg > /dev/ttyS* +#dd if=/dev/zero of=/dev/ttyS* + +I'm seeing this on AWS EC2 when there's (apparently) high logging volume to the console, very similarly to https://www.reddit.com/r/sysadmin/comments/6zuqad/mongodb_aws_ec2_serial8250_too_much_work_for_irq4/ + +On further investigation of my instance, there appeared to be no high logging volume to the console, nor anything using the /dev/ttyS0 other than agetty. Switching from the generic kernel to the AWS kernel seems to have stabilised it. + +Further update: AWS kernel experienced the same error messages after just over 3 hours of runtime. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1719870 b/results/classifier/108/other/1719870 new file mode 100644 index 000000000..974c7b214 --- /dev/null +++ b/results/classifier/108/other/1719870 @@ -0,0 +1,102 @@ +other: 0.970 +permissions: 0.948 +performance: 0.943 +device: 0.934 +semantic: 0.931 +graphic: 0.917 +socket: 0.911 +debug: 0.900 +boot: 0.898 +files: 0.884 +PID: 0.878 +network: 0.859 +vnc: 0.721 +KVM: 0.687 + +Converting 100G VHDX fixed image to QCOW2 fails + +Virtual Size recognized incorrectly for VHDX fixed disk and conversion fails with error Expression: !qiov || bytes == qiov->size + + + +PS > & 'C:\Program Files\qemu\qemu-img.exe' --version +qemu-img version 2.10.0 (v2.10.0-11669-g579e69bd5b-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Command capture, + +PS > & 'C:\Program Files\qemu\qemu-img.exe' --version +qemu-img version 2.10.0 (v2.10.0-11669-g579e69bd5b-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +PS > Get-VHD .\VM.vhdx +ComputerName : Server1 +Path : \VM.vhdx +VhdFormat : VHDX +VhdType : Fixed +FileSize : 107378376704 +Size : 107374182400 +MinimumSize : 107374182400 +LogicalSectorSize : 4096 +PhysicalSectorSize : 4096 +BlockSize : 0 +ParentPath : +DiskIdentifier : 53fd4aa7-562e-4bed-bc1c-2db71222e07e +FragmentationPercentage : 0 +Alignment : 1 +Attached : False +DiskNumber : +Key : +IsDeleted : False +Number : +PS > & 'C:\Program Files\qemu\qemu-img.exe' convert -O qcow2 .\VM.vhdx .\VM.qcow2 +Assertion failed! +Program: C:\Program Files\qemu\qemu-img.exe +File: /home/stefan/src/qemu/repo.or.cz/qemu/ar7/block/io.c, Line 1034 +Expression: !qiov || bytes == qiov->size +PS > & 'C:\Program Files\qemu\qemu-img.exe' info .\VM.qcow2 +image: .\VM.qcow2 +file format: qcow2 +virtual size: 13G (13421772800 bytes) +disk size: 1.4G +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +Bug is reproducible with setting VHDX Fixed Logicalsectorsize to 4096bytes +>10G image created reflects as 1.2G virtual size in Qemu-img +PS F:\> new-vhd -path test.vhdx -BlockSizeBytes 134217728 -SizeBytes 10737418240 -Fixed -LogicalSectorSizeBytes 4096 +ComputerName : XXXX +Path : F:\test.vhdx +VhdFormat : VHDX +VhdType : Fixed +FileSize : 10741612544 +Size : 10737418240 +MinimumSize : +LogicalSectorSize : 4096 +PhysicalSectorSize : 4096 +BlockSize : 0 +ParentPath : +DiskIdentifier : dfa84293-86f2-4ddf-aaff-14c04dae5df9 +FragmentationPercentage : 0 +Alignment : 1 +Attached : False +DiskNumber : +Key : +IsDeleted : False +Number : +PS F:\> C:\temp\qemu-img\qemu-img.exe info .\test.vhdx +image: .\test.vhdx +file format: vhdx +virtual size: 1.2G (1342177280 bytes) +disk size: 10G +cluster_size: 134217728 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1719984 b/results/classifier/108/other/1719984 new file mode 100644 index 000000000..52cf7e734 --- /dev/null +++ b/results/classifier/108/other/1719984 @@ -0,0 +1,29 @@ +graphic: 0.887 +device: 0.786 +network: 0.762 +semantic: 0.650 +boot: 0.624 +performance: 0.608 +socket: 0.597 +vnc: 0.595 +permissions: 0.511 +PID: 0.511 +files: 0.420 +KVM: 0.312 +other: 0.185 +debug: 0.183 + +wrgsbase misemulated in x86_64-softmmu + +qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4 +command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true ' + +On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1. In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference. + +For further data, the faulting instruction is +f3 48 0f ae df wrgsbase %rdi + +Fix is in staging: https://github.com/ehabkost/qemu/commit/cdcc80d41360e278b45c91de29a29d797264e85d + +Fix is in master: https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550 + |