diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/232 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2320 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2321 | 55 | ||||
| -rw-r--r-- | results/classifier/108/other/2322 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2323 | 41 | ||||
| -rw-r--r-- | results/classifier/108/other/2324 | 62 | ||||
| -rw-r--r-- | results/classifier/108/other/2326 | 39 | ||||
| -rw-r--r-- | results/classifier/108/other/23270873 | 702 | ||||
| -rw-r--r-- | results/classifier/108/other/2329 | 16 |
9 files changed, 963 insertions, 0 deletions
diff --git a/results/classifier/108/other/232 b/results/classifier/108/other/232 new file mode 100644 index 000000000..4a1b67efe --- /dev/null +++ b/results/classifier/108/other/232 @@ -0,0 +1,16 @@ +device: 0.846 +performance: 0.609 +network: 0.566 +socket: 0.518 +graphic: 0.368 +debug: 0.254 +vnc: 0.197 +PID: 0.193 +other: 0.127 +semantic: 0.109 +files: 0.078 +boot: 0.063 +permissions: 0.040 +KVM: 0.016 + +I/O write make QXL abort in qxl_set_mode() diff --git a/results/classifier/108/other/2320 b/results/classifier/108/other/2320 new file mode 100644 index 000000000..a86e5cc77 --- /dev/null +++ b/results/classifier/108/other/2320 @@ -0,0 +1,16 @@ +device: 0.670 +network: 0.647 +performance: 0.485 +socket: 0.392 +files: 0.387 +vnc: 0.366 +permissions: 0.303 +graphic: 0.289 +semantic: 0.288 +PID: 0.275 +boot: 0.250 +other: 0.234 +debug: 0.208 +KVM: 0.135 + +-Wchar-subscripts warnings in target/i386/tcg/decode-new.c.inc diff --git a/results/classifier/108/other/2321 b/results/classifier/108/other/2321 new file mode 100644 index 000000000..c08e812e7 --- /dev/null +++ b/results/classifier/108/other/2321 @@ -0,0 +1,55 @@ +KVM: 0.876 +graphic: 0.855 +other: 0.846 +permissions: 0.833 +performance: 0.812 +vnc: 0.811 +debug: 0.808 +semantic: 0.794 +files: 0.788 +device: 0.788 +socket: 0.765 +PID: 0.757 +boot: 0.721 +network: 0.714 + +Segfault when hibernating a KVM VM with QEMU 8.2.3 +Description of problem: +Attempting to hibernate the machine crashes QEMU. +Steps to reproduce: +This involves Nix, please tell me if you want a reproducer that doesn't. + +1. nix build github:NixOS/nixpkgs#nixosTests.hibernate.driver +2. ./result/bin/nixos-test-driver +3. Observe crash +Additional information: +Backtrace: + +``` +#0 kvm_virtio_pci_vq_vector_release (proxy=0x55bd979fd130, vector=<optimized out>) at ../hw/virtio/virtio-pci.c:834 +#1 kvm_virtio_pci_vector_release_one (proxy=proxy@entry=0x55bd979fd130, queue_no=queue_no@entry=0) at ../hw/virtio/virtio-pci.c:965 +#2 0x000055bd9380c430 in virtio_pci_set_vector (vdev=0x55bd97a05500, proxy=0x55bd979fd130, queue_no=0, old_vector=1, new_vector=65535) + at ../hw/virtio/virtio-pci.c:1445 +#3 0x000055bd939c5490 in memory_region_write_accessor (mr=0x55bd979fdc70, addr=26, value=<optimized out>, size=2, shift=<optimized out>, + mask=<optimized out>, attrs=...) at ../system/memory.c:497 +#4 0x000055bd939c4d56 in access_with_adjusted_size (addr=addr@entry=26, value=value@entry=0x7ff49d1ff3e8, size=size@entry=2, + access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55bd939c5410 <memory_region_write_accessor>, mr=<optimized out>, + attrs=...) at ../system/memory.c:573 +#5 0x000055bd939c5081 in memory_region_dispatch_write (mr=mr@entry=0x55bd979fdc70, addr=addr@entry=26, data=<optimized out>, op=<optimized out>, + attrs=attrs@entry=...) at ../system/memory.c:1528 +#6 0x000055bd939ccb0c in flatview_write_continue (fv=fv@entry=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=..., attrs@entry=..., + ptr=ptr@entry=0x7ff4a082d028, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x55bd979fdc70) at ../system/physmem.c:2714 +#7 0x000055bd939ccd83 in flatview_write (fv=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, + len=len@entry=2) at ../system/physmem.c:2756 +#8 0x000055bd939d0099 in address_space_write (len=2, buf=0x7ff4a082d028, attrs=..., addr=61572651286554, as=0x55bd94a4e720 <address_space_memory>) + at ../system/physmem.c:2863 +#9 address_space_rw (as=0x55bd94a4e720 <address_space_memory>, addr=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, len=2, + is_write=<optimized out>) at ../system/physmem.c:2873 +#10 0x000055bd93a24548 in kvm_cpu_exec (cpu=cpu@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-all.c:2915 +#11 0x000055bd93a25795 in kvm_vcpu_thread_fn (arg=arg@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-accel-ops.c:51 +#12 0x000055bd93bb5fa8 in qemu_thread_start (args=0x55bd96294940) at ../util/qemu-thread-posix.c:541 +#13 0x00007ff4a19fd272 in start_thread (arg=<optimized out>) at pthread_create.c:447 +#14 0x00007ff4a1a78dcc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 +``` + +Bisected to https://gitlab.com/qemu-project/qemu/-/commit/fcbb086ae590e910614fe5b8bf76e264f71ef304, reverting that change seems to make things work again. diff --git a/results/classifier/108/other/2322 b/results/classifier/108/other/2322 new file mode 100644 index 000000000..e2d93269c --- /dev/null +++ b/results/classifier/108/other/2322 @@ -0,0 +1,16 @@ +device: 0.907 +graphic: 0.583 +network: 0.579 +performance: 0.461 +files: 0.426 +permissions: 0.396 +boot: 0.391 +semantic: 0.320 +PID: 0.312 +socket: 0.254 +debug: 0.246 +other: 0.201 +vnc: 0.181 +KVM: 0.004 + +Qemu 9 make install failed on Ubuntu 23.10 ARM64 diff --git a/results/classifier/108/other/2323 b/results/classifier/108/other/2323 new file mode 100644 index 000000000..a6411dc38 --- /dev/null +++ b/results/classifier/108/other/2323 @@ -0,0 +1,41 @@ +graphic: 0.822 +device: 0.767 +files: 0.577 +performance: 0.543 +debug: 0.531 +other: 0.525 +semantic: 0.522 +socket: 0.455 +PID: 0.419 +permissions: 0.407 +vnc: 0.403 +boot: 0.369 +network: 0.292 +KVM: 0.089 + +Win/Super key not working correctly under Windows hosts +Description of problem: +I accidentally noticed `Win` key (VK_LWIN) not working correctly on Windows hosts, more specifically: + +1. It is impossible to "hold" `Win`. If one presses and holds `Win`, the guest is spammed with `Win` keypresses, instead of receiving a single `Win` keypress at the point of releasing the button (VK_LWIN button up). +2. It is impossible to make key combinations (shortcuts, hotkeys etc.) that involve the `Win/Super` key. Maybe implicitly solved by fixing #1. + +This behavior is present starting from bc8e883065f36581e4f2352c31a1dfa5f65a82f2 (ui/sdl2: disable SDL_HINT_GRAB_KEYBOARD on Windows). Before it, on the SDL2 keyboard hook `Win/Super` key worked correctly. I demonstrate the problem on Fedora/WinXP, but it affects all guests. +Steps to reproduce: +1. (see additional information) +2. +3. +Additional information: +Short video demonstration on a WinXP guest and a Fedora 39 guest. The qemus used are (qemu-8.0.2 e0968d21e27ef9c406f709180a39a076e786efbe; working correctly) and (qemu-9.0.0 from the release tarball qemu-9.0.0.tar.xz; buggy) + +1. In the WinXP video, I'm pressing and holding the `Win` key for about 3 seconds. In the correct version, the start menu is opened only at the point of release. In the buggy version, the start menu is opened repeatedly tens of times (flickering). You can see the point of release in Nirsoft's KeyboardStateView, when VK_LWIN loses the "pressed" asterisk. + + At the end of the video I'm trying to use the `Win+e` shortcut for WinExplorer. In the buggy version, Outlook is opened instead. This is because the keypresses are processed individually, first `Win` opens the start menu and then `e` opens email application (in this case outlook). In the correct version WinExplorer is opened. + +  +  + +2. In the Fedora video, I'm trying to set up a simple shortcut, I'm pressing on my keyboard `LCTRL+LALT+Super+E`. In the buggy version, the `Super` key is not picked up. All the shortcut combinations involving `Super` are therefore not working. + +  +  diff --git a/results/classifier/108/other/2324 b/results/classifier/108/other/2324 new file mode 100644 index 000000000..a5799e05a --- /dev/null +++ b/results/classifier/108/other/2324 @@ -0,0 +1,62 @@ +other: 0.795 +graphic: 0.718 +semantic: 0.689 +debug: 0.688 +performance: 0.685 +PID: 0.679 +socket: 0.678 +permissions: 0.677 +KVM: 0.666 +device: 0.664 +network: 0.660 +files: 0.639 +vnc: 0.623 +boot: 0.595 + +SELinux is preventing some qemu-kvm operations on CentOS Stream 9 +Description of problem: +Some operations are being denied by SELinux. + +First it was read access on file max_map_count, then open and getattr access on /proc/sys/vm/max_map_count (same file but with full path). + +All have been fixed by creating and applying a semodule with the TE policy shown on "Additional Information" below. + +``` +May 2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count. For complete SELinux messages run: sealert -l c92d5506-0b40-4bc8-be6a-133fe360014d +May 2 18:01:00 rd02 setroubleshoot[14757]: SELinux is preventing /usr/libexec/qemu-kvm from read access on the file max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t 'max_map_count'#012# restorecon -v 'max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed read access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + +--- + +May 3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l 655af27c-6bc7-4278-9aad-7fc99929d24b +May 3 10:24:58 rd02 setroubleshoot[3981]: SELinux is preventing /usr/libexec/qemu-kvm from open access on the file /proc/sys/vm/max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed open access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + +--- + +May 3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count. For complete SELinux messages run: sealert -l db78c5b9-3890-44d4-a40e-d4011ad42913 +May 3 10:41:17 rd02 setroubleshoot[6894]: SELinux is preventing /usr/libexec/qemu-kvm from getattr access on the file /proc/sys/vm/max_map_count.#012#012***** Plugin qemu_file_image (98.8 confidence) suggests *******************#012#012If max_map_count is a virtualization target#012Then you need to change the label on max_map_count'#012Do#012# semanage fcontext -a -t virt_image_t '/proc/sys/vm/max_map_count'#012# restorecon -v '/proc/sys/vm/max_map_count'#012#012***** Plugin catchall (2.13 confidence) suggests **************************#012#012If you believe that qemu-kvm should be allowed getattr access on the max_map_count file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm#012# semodule -X 300 -i my-qemukvm.pp#012 + + +``` +Steps to reproduce: +1. On a CentOS Stream 9 system with a selinux enforced, create a VM and install an OS with cockpit or with virt-install. + - example with virt-install: + `virt-install --connect qemu:///system --os-variant centos-stream9 --reinstall ipa03 --wait -1 --location /mnt/CentOS-Stream9.iso` +2. Check the SELinux logs, either on cockpit or on /var/log/messages +Additional information: +TE module that solved the issue, created with `ausearch -c 'qemu-kvm' --raw | audit2allow -M my-qemukvm` + +``` +module my-qemukvm 1.1; + +require { + type sysctl_vm_t; + type svirt_t; + class file { getattr open read }; +} + +#============= svirt_t ============== + +#!!!! This avc is allowed in the current policy +allow svirt_t sysctl_vm_t:file read; +allow svirt_t sysctl_vm_t:file { getattr open }; +``` diff --git a/results/classifier/108/other/2326 b/results/classifier/108/other/2326 new file mode 100644 index 000000000..55caceaed --- /dev/null +++ b/results/classifier/108/other/2326 @@ -0,0 +1,39 @@ +debug: 0.854 +graphic: 0.852 +boot: 0.716 +device: 0.648 +semantic: 0.631 +network: 0.621 +vnc: 0.582 +socket: 0.507 +permissions: 0.491 +PID: 0.454 +performance: 0.453 +files: 0.183 +other: 0.126 +KVM: 0.010 + +qemu-system-arm regression with Qemu 9.0.0 +Description of problem: +Bootup of the userland crashes: +``` +[ 1.713693] Run /init as init process +[ 2.372470] Alignment trap: not handling instruction f8530b04 at [<0001225a>] +[ 2.391053] 8<--- cut here --- +[ 2.392942] Unhandled fault: alignment exception (0x001) at 0x00035335 +[ 2.397042] [00035335] *pgd=6066b831, *pte=6030734f, *ppte=6030783f +``` +Steps to reproduce: +wget https://debug.openadk.org/vexpress-v2p-ca9.dtb + +wget https://debug.openadk.org/qemu-arm-vexpress-a9-initramfspiggyback-kernel + +qemu-system-arm -M vexpress-a9 -nographic -cpu cortex-a9 -net user -net nic,model=lan9118 -dtb vexpress-v2p-ca9.dtb -kernel qemu-arm-vexpress-a9-initramfspiggyback-kernel -qmp tcp:127.0.0.1:4444,server,nowait -no-reboot +Additional information: +It works fine for ARM instruction set, but not for Thumb2. + +Git bisect showed following commit as the problematic one:<br> +From 59754f85ed35cbd5f4bf2663ca2136c78d5b2413 Mon Sep 17 00:00:00 2001<br> +From: Richard Henderson <richard.henderson@linaro.org><br> +Date: Fri, 1 Mar 2024 10:41:09 -1000<br> +Subject: [PATCH] target/arm: Do memory type alignment check when translation disabled<br> diff --git a/results/classifier/108/other/23270873 b/results/classifier/108/other/23270873 new file mode 100644 index 000000000..0140ac0a4 --- /dev/null +++ b/results/classifier/108/other/23270873 @@ -0,0 +1,702 @@ +other: 0.839 +boot: 0.830 +vnc: 0.820 +device: 0.810 +KVM: 0.803 +permissions: 0.802 +debug: 0.788 +network: 0.768 +graphic: 0.764 +socket: 0.758 +semantic: 0.752 +performance: 0.744 +PID: 0.731 +files: 0.730 + +[Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed + +Hi, + +I am seeing some strange QEMU assertion failures for qemu on s390x, +which prevents a guest from starting. + +Git bisecting points to the following commit as the source of the error. + +commit ed6e2161715c527330f936d44af4c547f25f687e +Author: Nishanth Aravamudan <address@hidden> +Date: Fri Jun 22 12:37:00 2018 -0700 + + linux-aio: properly bubble up errors from initialization + + laio_init() can fail for a couple of reasons, which will lead to a NULL + pointer dereference in laio_attach_aio_context(). + + To solve this, add a aio_setup_linux_aio() function which is called + early in raw_open_common. If this fails, propagate the error up. The + signature of aio_get_linux_aio() was not modified, because it seems + preferable to return the actual errno from the possible failing + initialization calls. + + Additionally, when the AioContext changes, we need to associate a + LinuxAioState with the new AioContext. Use the bdrv_attach_aio_context + callback and call the new aio_setup_linux_aio(), which will allocate a +new AioContext if needed, and return errors on failures. If it +fails for +any reason, fallback to threaded AIO with an error message, as the + device is already in-use by the guest. + + Add an assert that aio_get_linux_aio() cannot return NULL. + + Signed-off-by: Nishanth Aravamudan <address@hidden> + Message-id: address@hidden + Signed-off-by: Stefan Hajnoczi <address@hidden> +Not sure what is causing this assertion to fail. Here is the qemu +command line of the guest, from qemu log, which throws this error: +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-s390x -name +guest=rt_vm1,debug-threads=on -S -object +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-rt_vm1/master-key.aes +-machine s390-ccw-virtio-2.12,accel=kvm,usb=off,dump-guest-core=off -m +1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -object +iothread,id=iothread1 -uuid 0cde16cd-091d-41bd-9ac2-5243df5c9a0d +-display none -no-user-config -nodefaults -chardev +socket,id=charmonitor,fd=28,server,nowait -mon +chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +-boot strict=on -drive +file=/dev/mapper/360050763998b0883980000002a000031,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native +-device +virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device +virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:3a:c8:67:95:84,devno=fe.0.0000 +-netdev tap,fd=32,id=hostnet1,vhost=on,vhostfd=33 -device +virtio-net-ccw,netdev=hostnet1,id=net1,mac=52:54:00:2a:e5:08,devno=fe.0.0002 +-chardev pty,id=charconsole0 -device +sclpconsole,chardev=charconsole0,id=console0 -device +virtio-balloon-ccw,id=balloon0,devno=fe.3.ffba -sandbox +on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny +-msg timestamp=on +2018-07-17 15:48:42.252+0000: Domain id=21 is tainted: high-privileges +2018-07-17T15:48:42.279380Z qemu-system-s390x: -chardev +pty,id=charconsole0: char device redirected to /dev/pts/3 (label +charconsole0) +qemu-system-s390x: util/async.c:339: aio_get_linux_aio: Assertion +`ctx->linux_aio' failed. +2018-07-17 15:48:43.309+0000: shutting down, reason=failed + + +Any help debugging this would be greatly appreciated. + +Thank you +Farhan + +On 17.07.2018 [13:25:53 -0400], Farhan Ali wrote: +> +Hi, +> +> +I am seeing some strange QEMU assertion failures for qemu on s390x, +> +which prevents a guest from starting. +> +> +Git bisecting points to the following commit as the source of the error. +> +> +commit ed6e2161715c527330f936d44af4c547f25f687e +> +Author: Nishanth Aravamudan <address@hidden> +> +Date: Fri Jun 22 12:37:00 2018 -0700 +> +> +linux-aio: properly bubble up errors from initialization +> +> +laio_init() can fail for a couple of reasons, which will lead to a NULL +> +pointer dereference in laio_attach_aio_context(). +> +> +To solve this, add a aio_setup_linux_aio() function which is called +> +early in raw_open_common. If this fails, propagate the error up. The +> +signature of aio_get_linux_aio() was not modified, because it seems +> +preferable to return the actual errno from the possible failing +> +initialization calls. +> +> +Additionally, when the AioContext changes, we need to associate a +> +LinuxAioState with the new AioContext. Use the bdrv_attach_aio_context +> +callback and call the new aio_setup_linux_aio(), which will allocate a +> +new AioContext if needed, and return errors on failures. If it fails for +> +any reason, fallback to threaded AIO with an error message, as the +> +device is already in-use by the guest. +> +> +Add an assert that aio_get_linux_aio() cannot return NULL. +> +> +Signed-off-by: Nishanth Aravamudan <address@hidden> +> +Message-id: address@hidden +> +Signed-off-by: Stefan Hajnoczi <address@hidden> +> +> +> +Not sure what is causing this assertion to fail. Here is the qemu command +> +line of the guest, from qemu log, which throws this error: +> +> +> +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +> +QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-s390x -name +> +guest=rt_vm1,debug-threads=on -S -object +> +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-rt_vm1/master-key.aes +> +-machine s390-ccw-virtio-2.12,accel=kvm,usb=off,dump-guest-core=off -m 1024 +> +-realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -object +> +iothread,id=iothread1 -uuid 0cde16cd-091d-41bd-9ac2-5243df5c9a0d -display +> +none -no-user-config -nodefaults -chardev +> +socket,id=charmonitor,fd=28,server,nowait -mon +> +chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot +> +strict=on -drive +> +file=/dev/mapper/360050763998b0883980000002a000031,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native +> +-device +> +virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on +> +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device +> +virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:3a:c8:67:95:84,devno=fe.0.0000 +> +-netdev tap,fd=32,id=hostnet1,vhost=on,vhostfd=33 -device +> +virtio-net-ccw,netdev=hostnet1,id=net1,mac=52:54:00:2a:e5:08,devno=fe.0.0002 +> +-chardev pty,id=charconsole0 -device +> +sclpconsole,chardev=charconsole0,id=console0 -device +> +virtio-balloon-ccw,id=balloon0,devno=fe.3.ffba -sandbox +> +on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg +> +timestamp=on +> +> +> +> +2018-07-17 15:48:42.252+0000: Domain id=21 is tainted: high-privileges +> +2018-07-17T15:48:42.279380Z qemu-system-s390x: -chardev pty,id=charconsole0: +> +char device redirected to /dev/pts/3 (label charconsole0) +> +qemu-system-s390x: util/async.c:339: aio_get_linux_aio: Assertion +> +`ctx->linux_aio' failed. +> +2018-07-17 15:48:43.309+0000: shutting down, reason=failed +> +> +> +Any help debugging this would be greatly appreciated. +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish + +On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish +Hi Nishant, +From the coredump of the guest this is the call trace that calls +aio_get_linux_aio: +Stack trace of thread 145158: +#0 0x000003ff94dbe274 raise (libc.so.6) +#1 0x000003ff94da39a8 abort (libc.so.6) +#2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +#3 0x000003ff94db634c __assert_fail (libc.so.6) +#4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +#5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +#6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +#7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +#8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +#9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +#10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +#11 0x000003ff94f879a8 start_thread (libpthread.so.0) +#12 0x000003ff94e797ee thread_start (libc.so.6) + + +Thanks for taking a look and responding. + +Thanks +Farhan + +On 07/18/2018 09:42 AM, Farhan Ali wrote: +On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish +Hi Nishant, +From the coredump of the guest this is the call trace that calls +aio_get_linux_aio: +Stack trace of thread 145158: +#0Â 0x000003ff94dbe274 raise (libc.so.6) +#1Â 0x000003ff94da39a8 abort (libc.so.6) +#2Â 0x000003ff94db62ce __assert_fail_base (libc.so.6) +#3Â 0x000003ff94db634c __assert_fail (libc.so.6) +#4Â 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +#5Â 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +#6Â 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +#7Â 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +#8Â 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +#9Â 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +#10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +#11 0x000003ff94f879a8 start_thread (libpthread.so.0) +#12 0x000003ff94e797ee thread_start (libc.so.6) + + +Thanks for taking a look and responding. + +Thanks +Farhan +Trying to debug a little further, the block device in this case is a +"host device". And looking at your commit carefully you use the +bdrv_attach_aio_context callback to setup a Linux AioContext. +For some reason the "host device" struct (BlockDriver bdrv_host_device +in block/file-posix.c) does not have a bdrv_attach_aio_context defined. +So a simple change of adding the callback to the struct solves the issue +and the guest starts fine. +diff --git a/block/file-posix.c b/block/file-posix.c +index 28824aa..b8d59fb 100644 +--- a/block/file-posix.c ++++ b/block/file-posix.c +@@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { + .bdrv_refresh_limits = raw_refresh_limits, + .bdrv_io_plug = raw_aio_plug, + .bdrv_io_unplug = raw_aio_unplug, ++ .bdrv_attach_aio_context = raw_aio_attach_aio_context, + + .bdrv_co_truncate = raw_co_truncate, + .bdrv_getlength = raw_getlength, +I am not too familiar with block device code in QEMU, so not sure if +this is the right fix or if there are some underlying problems. +Thanks +Farhan + +On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +> +> +On 07/18/2018 09:42 AM, Farhan Ali wrote: +> +> +> +> +> +> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +> +> > iiuc, this possibly implies AIO was not actually used previously on this +> +> > guest (it might have silently been falling back to threaded IO?). I +> +> > don't have access to s390x, but would it be possible to run qemu under +> +> > gdb and see if aio_setup_linux_aio is being called at all (I think it +> +> > might not be, but I'm not sure why), and if so, if it's for the context +> +> > in question? +> +> > +> +> > If it's not being called first, could you see what callpath is calling +> +> > aio_get_linux_aio when this assertion trips? +> +> > +> +> > Thanks! +> +> > -Nish +> +> +> +> +> +> Hi Nishant, +> +> +> +> From the coredump of the guest this is the call trace that calls +> +> aio_get_linux_aio: +> +> +> +> +> +> Stack trace of thread 145158: +> +> #0Â 0x000003ff94dbe274 raise (libc.so.6) +> +> #1Â 0x000003ff94da39a8 abort (libc.so.6) +> +> #2Â 0x000003ff94db62ce __assert_fail_base (libc.so.6) +> +> #3Â 0x000003ff94db634c __assert_fail (libc.so.6) +> +> #4Â 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +> +> #5Â 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +> +> #6Â 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +> +> #7Â 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +> +> #8Â 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +> +> #9Â 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +> +> #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +> +> #11 0x000003ff94f879a8 start_thread (libpthread.so.0) +> +> #12 0x000003ff94e797ee thread_start (libc.so.6) +> +> +> +> +> +> Thanks for taking a look and responding. +> +> +> +> Thanks +> +> Farhan +> +> +> +> +> +> +> +> +Trying to debug a little further, the block device in this case is a "host +> +device". And looking at your commit carefully you use the +> +bdrv_attach_aio_context callback to setup a Linux AioContext. +> +> +For some reason the "host device" struct (BlockDriver bdrv_host_device in +> +block/file-posix.c) does not have a bdrv_attach_aio_context defined. +> +So a simple change of adding the callback to the struct solves the issue and +> +the guest starts fine. +> +> +> +diff --git a/block/file-posix.c b/block/file-posix.c +> +index 28824aa..b8d59fb 100644 +> +--- a/block/file-posix.c +> ++++ b/block/file-posix.c +> +@@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { +> +.bdrv_refresh_limits = raw_refresh_limits, +> +.bdrv_io_plug = raw_aio_plug, +> +.bdrv_io_unplug = raw_aio_unplug, +> ++ .bdrv_attach_aio_context = raw_aio_attach_aio_context, +> +> +.bdrv_co_truncate = raw_co_truncate, +> +.bdrv_getlength = raw_getlength, +> +> +> +> +I am not too familiar with block device code in QEMU, so not sure if +> +this is the right fix or if there are some underlying problems. +Oh this is quite embarassing! I only added the bdrv_attach_aio_context +callback for the file-backed device. Your fix is definitely corect for +host device. Let me make sure there weren't any others missed and I will +send out a properly formatted patch. Thank you for the quick testing and +turnaround! + +-Nish + +On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: +> +On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +> +> +> +> +> On 07/18/2018 09:42 AM, Farhan Ali wrote: +> +>> +> +>> +> +>> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +> +>>> iiuc, this possibly implies AIO was not actually used previously on this +> +>>> guest (it might have silently been falling back to threaded IO?). I +> +>>> don't have access to s390x, but would it be possible to run qemu under +> +>>> gdb and see if aio_setup_linux_aio is being called at all (I think it +> +>>> might not be, but I'm not sure why), and if so, if it's for the context +> +>>> in question? +> +>>> +> +>>> If it's not being called first, could you see what callpath is calling +> +>>> aio_get_linux_aio when this assertion trips? +> +>>> +> +>>> Thanks! +> +>>> -Nish +> +>> +> +>> +> +>> Hi Nishant, +> +>> +> +>> From the coredump of the guest this is the call trace that calls +> +>> aio_get_linux_aio: +> +>> +> +>> +> +>> Stack trace of thread 145158: +> +>> #0Â 0x000003ff94dbe274 raise (libc.so.6) +> +>> #1Â 0x000003ff94da39a8 abort (libc.so.6) +> +>> #2Â 0x000003ff94db62ce __assert_fail_base (libc.so.6) +> +>> #3Â 0x000003ff94db634c __assert_fail (libc.so.6) +> +>> #4Â 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +> +>> #5Â 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +> +>> #6Â 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +> +>> #7Â 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +> +>> #8Â 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +> +>> #9Â 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +> +>> #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +> +>> #11 0x000003ff94f879a8 start_thread (libpthread.so.0) +> +>> #12 0x000003ff94e797ee thread_start (libc.so.6) +> +>> +> +>> +> +>> Thanks for taking a look and responding. +> +>> +> +>> Thanks +> +>> Farhan +> +>> +> +>> +> +>> +> +> +> +> Trying to debug a little further, the block device in this case is a "host +> +> device". And looking at your commit carefully you use the +> +> bdrv_attach_aio_context callback to setup a Linux AioContext. +> +> +> +> For some reason the "host device" struct (BlockDriver bdrv_host_device in +> +> block/file-posix.c) does not have a bdrv_attach_aio_context defined. +> +> So a simple change of adding the callback to the struct solves the issue and +> +> the guest starts fine. +> +> +> +> +> +> diff --git a/block/file-posix.c b/block/file-posix.c +> +> index 28824aa..b8d59fb 100644 +> +> --- a/block/file-posix.c +> +> +++ b/block/file-posix.c +> +> @@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { +> +> .bdrv_refresh_limits = raw_refresh_limits, +> +> .bdrv_io_plug = raw_aio_plug, +> +> .bdrv_io_unplug = raw_aio_unplug, +> +> + .bdrv_attach_aio_context = raw_aio_attach_aio_context, +> +> +> +> .bdrv_co_truncate = raw_co_truncate, +> +> .bdrv_getlength = raw_getlength, +> +> +> +> +> +> +> +> I am not too familiar with block device code in QEMU, so not sure if +> +> this is the right fix or if there are some underlying problems. +> +> +Oh this is quite embarassing! I only added the bdrv_attach_aio_context +> +callback for the file-backed device. Your fix is definitely corect for +> +host device. Let me make sure there weren't any others missed and I will +> +send out a properly formatted patch. Thank you for the quick testing and +> +turnaround! +Farhan, can you respin your patch with proper sign-off and patch description? +Adding qemu-block. + +Hi Christian, + +On 19.07.2018 [08:55:20 +0200], Christian Borntraeger wrote: +> +> +> +On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: +> +> On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +>> +> +>> +> +>> On 07/18/2018 09:42 AM, Farhan Ali wrote: +<snip> + +> +>> I am not too familiar with block device code in QEMU, so not sure if +> +>> this is the right fix or if there are some underlying problems. +> +> +> +> Oh this is quite embarassing! I only added the bdrv_attach_aio_context +> +> callback for the file-backed device. Your fix is definitely corect for +> +> host device. Let me make sure there weren't any others missed and I will +> +> send out a properly formatted patch. Thank you for the quick testing and +> +> turnaround! +> +> +Farhan, can you respin your patch with proper sign-off and patch description? +> +Adding qemu-block. +I sent it yesterday, sorry I didn't cc everyone from this e-mail: +http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00516.html +Thanks, +Nish + diff --git a/results/classifier/108/other/2329 b/results/classifier/108/other/2329 new file mode 100644 index 000000000..094f93e16 --- /dev/null +++ b/results/classifier/108/other/2329 @@ -0,0 +1,16 @@ +device: 0.803 +graphic: 0.523 +performance: 0.478 +permissions: 0.336 +semantic: 0.295 +boot: 0.125 +PID: 0.100 +other: 0.075 +debug: 0.059 +files: 0.048 +vnc: 0.042 +network: 0.037 +KVM: 0.024 +socket: 0.011 + +Windows 64-bit, qemu-monitor, change |