diff options
Diffstat (limited to 'results/classifier/118/virtual')
156 files changed, 9655 insertions, 0 deletions
diff --git a/results/classifier/118/virtual/101 b/results/classifier/118/virtual/101 new file mode 100644 index 00000000..a8cf83d3 --- /dev/null +++ b/results/classifier/118/virtual/101 @@ -0,0 +1,31 @@ +virtual: 0.995 +architecture: 0.941 +hypervisor: 0.844 +device: 0.843 +VMM: 0.803 +performance: 0.740 +KVM: 0.615 +vnc: 0.611 +arm: 0.606 +risc-v: 0.596 +TCG: 0.541 +graphic: 0.501 +register: 0.491 +network: 0.469 +PID: 0.433 +boot: 0.394 +ppc: 0.319 +socket: 0.295 +semantic: 0.292 +permissions: 0.191 +mistranslation: 0.163 +kernel: 0.160 +files: 0.156 +peripherals: 0.114 +assembly: 0.020 +debug: 0.017 +user-level: 0.017 +x86: 0.016 +i386: 0.002 + +Running a virtual machine on a Haswell system produces machine check events diff --git a/results/classifier/118/virtual/104 b/results/classifier/118/virtual/104 new file mode 100644 index 00000000..849f8ef3 --- /dev/null +++ b/results/classifier/118/virtual/104 @@ -0,0 +1,31 @@ +virtual: 0.958 +performance: 0.892 +graphic: 0.850 +device: 0.740 +hypervisor: 0.584 +arm: 0.458 +mistranslation: 0.346 +peripherals: 0.336 +architecture: 0.300 +VMM: 0.281 +network: 0.231 +debug: 0.215 +permissions: 0.207 +boot: 0.147 +TCG: 0.145 +PID: 0.116 +vnc: 0.102 +files: 0.099 +register: 0.093 +risc-v: 0.047 +ppc: 0.043 +semantic: 0.035 +user-level: 0.025 +i386: 0.025 +socket: 0.021 +assembly: 0.016 +KVM: 0.008 +x86: 0.007 +kernel: 0.005 + +Cursor jumps on shape change with vmware vga diff --git a/results/classifier/118/virtual/1094 b/results/classifier/118/virtual/1094 new file mode 100644 index 00000000..08d3cfb4 --- /dev/null +++ b/results/classifier/118/virtual/1094 @@ -0,0 +1,38 @@ +virtual: 0.972 +graphic: 0.935 +device: 0.900 +VMM: 0.896 +performance: 0.879 +semantic: 0.728 +architecture: 0.695 +PID: 0.648 +debug: 0.599 +user-level: 0.598 +mistranslation: 0.558 +i386: 0.513 +permissions: 0.495 +register: 0.473 +x86: 0.460 +hypervisor: 0.313 +assembly: 0.313 +boot: 0.302 +vnc: 0.231 +TCG: 0.195 +risc-v: 0.171 +ppc: 0.157 +socket: 0.155 +arm: 0.145 +network: 0.130 +KVM: 0.091 +files: 0.088 +peripherals: 0.061 +kernel: 0.028 + +Ubuntu's 22.04 Qemu high RAM usage (memory leak maybe) +Description of problem: +After starting/using my VM for a while, RAM fills up to the 32gb maximum, and firefox starts closing tabs and etc. This didn't happen in ubuntu 21.10 or earlier ubuntus. I've been using virt-manager + qemu for years and only had this after upgrading to ubuntu 22.04. +Steps to reproduce: +1. Launch virt-manager ubuntu VM with 12gb ram maximum (as an example) +2. RAM entire 32gb gets filled but nothing in gnome-system-monitor shows what is using all that RAM +3. Firefox starts closing tabs because RAM is full. Remember that only a 12gb RAM vm and firefox with a few tabs are running, and it fills all 32gb of RAM. Ram starts filling slowly and in 1 hour it fills the entire 32gb. For some reason htop shows a smaller usage, but I'm pretty sure all 32gb are being used as the computer starts freezing and almost crashing (I think swap is being used so it slows down but do not crash) +4. have to restart the computer for RAM to get normal again diff --git a/results/classifier/118/virtual/1094564 b/results/classifier/118/virtual/1094564 new file mode 100644 index 00000000..b4bd3b25 --- /dev/null +++ b/results/classifier/118/virtual/1094564 @@ -0,0 +1,384 @@ +virtual: 0.883 +debug: 0.866 +permissions: 0.845 +architecture: 0.818 +semantic: 0.818 +user-level: 0.813 +graphic: 0.806 +register: 0.805 +performance: 0.792 +boot: 0.784 +assembly: 0.783 +mistranslation: 0.782 +kernel: 0.778 +network: 0.775 +device: 0.766 +PID: 0.754 +peripherals: 0.727 +files: 0.715 +vnc: 0.712 +arm: 0.684 +ppc: 0.683 +hypervisor: 0.666 +socket: 0.665 +risc-v: 0.661 +TCG: 0.652 +VMM: 0.638 +KVM: 0.521 +x86: 0.384 +i386: 0.288 + +images used as scsi disks not readable (qemu-system-arm, macos 10.8) + +Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my disk, I get as far as mounting root and then get SCSI errors with 1.3.0 and the current origin/master. git bisect says the issue is + +commit f563a5d7a820424756f358e747238f03e866838a +Merge: a273652 aee0bf7 +Author: Paolo Bonzini <email address hidden> +Date: Wed Oct 31 10:42:51 2012 +0100 + + Merge remote-tracking branch 'origin/master' into threadpool + + Signed-off-by: Paolo Bonzini <email address hidden> + + +I am using: +qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 + +Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: +CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu + +I duplicated this as well. I tried both the qemu-system-arm available in macports and also from homebrew with the same results. Host system is also 10.8 "mountain lion". + +My boot command: qemu-system-arm -kernel kernel/zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1" -hda pifi-4g.img -redir tcp:5022::22 + +I'm running QEMU emulator version 1.4.1 on OS X 10.8.3 +Interestingly, this exact same boot command works perfectly on my Ubuntu virtual (in virtualbox) running QEMU emulator version 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) + +So the bug would seem to either be specific to OS X or to the 1.4.1 release. + +See the attached screenshot to see what happens in the boot process. + +I managed to capture a little more info about this bug by passing -drive file='myharddrive.img'. The kernel panic is happening in the sym53c8xx driver. See the attached screenshot for detail. + +I can also attach the kernel that I'm using if needed. Just let me know. + + +I suspect this may be because we were defaulting to a broken coroutine backend (a bug fixed with commit 7c2acc7). Can you retry with the current 1.5 release candidate? (source download available at http://wiki.qemu.org/Download) + + +Hi Peter, + +Thanks, that made an improvement. Now I'm just stuck in a loop of the kernel resetting the scsi bus :) + +(see attachment) + +And the same QEMU/kernel/image works fine on a Linux host? + +If you can provide the files I need to reproduce I might be able to take a look at it. (If it did the same thing on linux host that would be higher priority for me, so if you can cross-check that would be helpful.) + + +I just compiled 1.5.0-rc1 on my Linux host with the same configure/compiler flags and duplicated the error (see screenshot). The configure flags are: +./configure --disable-guest-agent --disable-bsd-user --enable-sdl --target-list="arm-linux-user armeb-linux-user arm-softmmu" + +As before, it goes into an infinite loop of reseting the scsi controller for each (emulated) channel. Note that the Ubuntu provided qemu-system-arm works perfectly. They are using 1.4.0 with a rather large number of patches ( I did a `dpkg source qemu` to examine the Ubuntu build setup). + +Looking through the Ubuntu patches, this one looks like a likely fix: +dpkg-source: info: applying patches-arm-1.4.0/0002-hw-sd-Expose-sd_reset-as-public-function.patch + +Please find a zip of my raspberrypi image (hda) and the kernel that I built from https://github.com/raspberrypi/linux.git +at https://www.dropbox.com/sh/mbz8jh4fcjvdj4m/Gh3bKFyJyC + +I included the boot command in a txt file in the tarball. + +cheers, +Joss + + + +It's very unlikely to be the patch you mention, since that's for SD card emulation and you're not using SD card emulation. It's probably just a regression between 1.4 and 1.5, and I'm fairly sure it's in some changes I made to the versatilepb PCI controller model -- I will investigate. + + +Ah, I interpreted it to mean "scsi disk" instead of SD card :) + +I'll leave this to the experts. Thanks so much for looking into this and please let me know if I can be of further assistance. + +-Joss + +Hi Peter, + +Thanks so much for the patch and including me on the thread. I can confirm that it did fix the problem running on a Linux host, but the OS X bug cited by myself and the OP still remains elusive. It's rather puzzling as I pulled from HEAD and built using the same options on both. I've gotten a bit better with the qemu options now, so I will paste the console output here instead of doing yet another screenshot :) As you can see, it's still getting a fatal exception in the interrupt code. Do you know of a kernel version that would be better behaved than the 3.6.11+ from the "raspberrypi/linux" repo on github? Could I provide a core file that would help? + +Thanks again for your efforts. +Joss + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +phoenix:RaspberryPi mysfitt$ qemu-system-arm -kernel kernel/zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 console=ttyAMA0" -redir tcp:5022::22 -bt hci,null -global versatile_pci.broken-irq-mapping=1 pifi-4g.img +Uncompressing Linux... done, booting the kernel. +Booting Linux on physical CPU 0 +Linux version 3.6.11+ (root@jossibox) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #1 Fri May 10 16:46:40 EDT 2013 +CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d +CPU: VIPT aliasing data cache, unknown instruction cache +Machine: ARM-Versatile PB +Memory policy: ECC disabled, Data cache writeback +sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 +Kernel command line: root=/dev/sda2 panic=1 console=ttyAMA0 +PID hash table entries: 1024 (order: 0, 4096 bytes) +Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) +Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) +Memory: 256MB = 256MB total +Memory: 255388k/255388k available, 6756k reserved, 0K highmem +Virtual kernel memory layout: + vector : 0xffff0000 - 0xffff1000 ( 4 kB) + fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) + vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) + lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) + modules : 0xbf000000 - 0xc0000000 ( 16 MB) + .text : 0xc0008000 - 0xc03f6458 (4026 kB) + .init : 0xc03f7000 - 0xc04162bc ( 125 kB) + .data : 0xc0418000 - 0xc043fb60 ( 159 kB) + .bss : 0xc043fb84 - 0xc045abb0 ( 109 kB) +NR_IRQS:192 +VIC @f1140000: id 0x00041190, vendor 0x41 +FPGA IRQ chip 0 "SIC" @ f1003000, 21 irqs +Console: colour dummy device 80x30 +Calibrating delay loop... 626.68 BogoMIPS (lpj=3133440) +pid_max: default: 32768 minimum: 301 +Mount-cache hash table entries: 512 +CPU: Testing write buffer coherency: ok +Setting up static identity map for 0x305ce0 - 0x305d3c +devtmpfs: initialized +NET: Registered protocol family 16 +DMA: preallocated 256 KiB pool for atomic coherent allocations +Serial: AMBA PL011 UART driver +dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 12) is a PL011 rev1 +console [ttyAMA0] enabled +dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 13) is a PL011 rev1 +dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 14) is a PL011 rev1 +fpga:09: ttyAMA3 at MMIO 0x10009000 (irq = 38) is a PL011 rev1 +PCI core found (slot 11) +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [io 0x0000-0xffff] +pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff] +pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff pref] +pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] +PCI: bus0: Fast back to back transfers disabled +pci 0000:00:0c.0: BAR 2: assigned [mem 0x50000000-0x50001fff] +pci 0000:00:0c.0: BAR 1: assigned [mem 0x50002000-0x500023ff] +pci 0000:00:0c.0: BAR 0: can't assign io (size 0x100) +bio: create slab <bio-0> at 0 +vgaarb: loaded +SCSI subsystem initialized +Switching to clocksource timer3 +NET: Registered protocol family 2 +TCP established hash table entries: 8192 (order: 4, 65536 bytes) +TCP bind hash table entries: 8192 (order: 3, 32768 bytes) +TCP: Hash tables configured (established 8192 bind 8192) +TCP: reno registered +UDP hash table entries: 256 (order: 0, 4096 bytes) +UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) +NET: Registered protocol family 1 +RPC: Registered named UNIX socket transport module. +RPC: Registered udp transport module. +RPC: Registered tcp transport module. +RPC: Registered tcp NFSv4.1 backchannel transport module. +NetWinder Floating Point Emulator V0.97 (double precision) +Installing knfsd (copyright (C) 1996 <email address hidden>). +jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. +ROMFS MTD (C) 2007 Red Hat, Inc. +fuse init (API version 7.20) +msgmni has been set to 498 +Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) +io scheduler noop registered +io scheduler deadline registered +io scheduler cfq registered (default) +clcd-pl11x dev:20: PL110 rev0 at 0x10120000 +clcd-pl11x dev:20: Versatile hardware, VGA display +Console: switching to colour frame buffer device 80x30 +brd: module loaded +PCI: enabling device 0000:00:0c.0 (0100 -> 0102) +sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 27 +sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking +sym0: SCSI BUS has been reset. +scsi0 : sym-2.2.3 +sym0: unknown interrupt(s) ignored, ISTAT=0x5 DSTAT=0x80 SIST=0x0 +scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 1.4. PQ: 0 ANSI: 5 +scsi target0:0:0: tagged command queuing enabled, command queue depth 16. +scsi target0:0:0: Beginning Domain Validation +scsi target0:0:0: Domain Validation skipping write tests +scsi target0:0:0: Ending Domain Validation +scsi 0:0:2:0: CD-ROM QEMU QEMU CD-ROM 1.4. PQ: 0 ANSI: 5 +scsi target0:0:2: tagged command queuing enabled, command queue depth 16. +scsi target0:0:2: Beginning Domain Validation +scsi target0:0:2: Domain Validation skipping write tests +scsi target0:0:2: Ending Domain Validation +sr0: scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray +cdrom: Uniform CD-ROM driver Revision: 3.20 +sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB) +sd 0:0:0:0: [sda] Write Protect is off +sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +physmap platform flash device: 04000000 at 34000000 +physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 +Intel/Sharp Extended Query Table at 0x0031 +Using buffer write method + sda: sda1 sda2 sda3 sda4 +smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <email address hidden> +eth0: SMC91C11xFD (rev 1) at d09ca000 IRQ 25 [nowait] +eth0: Ethernet addr: 52:54:00:12:34:56 +sd 0:0:0:0: [sda] Attached SCSI disk +mousedev: PS/2 mouse device common for all mice +TCP: cubic registered +NET: Registered protocol family 17 +VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 +input: AT Raw Set 2 keyboard as /devices/fpga:06/serio0/input/input0 +input: ImExPS/2 Generic Explorer Mouse as /devices/fpga:07/serio1/input/input1 +EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240) +EXT2-fs (sda2): error: couldn't mount because of unsupported optional features (240) +EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) +VFS: Mounted root (ext4 filesystem) readonly on device 8:2. +devtmpfs: mounted +Freeing init memory: 124K +sd 0:0:0:0: [sda] ABORT operation started +scsi target0:0:0: control msgout: + 80 20 51 d. +sd 0:0:0:0: ABORT operation complete. +Unable to handle kernel NULL pointer dereference at virtual address 00000358 +pgd = c0004000 +[00000358] *pgd=00000000 +Internal error: Oops: 5 [#1] ARM +Modules linked in: +CPU: 0 Not tainted (3.6.11+ #1) +PC is at sym_interrupt+0x7c8/0x1b88 +LR is at sym53c8xx_intr+0x40/0x7c +pc : [<c02193a0>] lr : [<c0214e0c>] psr: 80000193 +sp : c0419e30 ip : cf844800 fp : 00000001 +r10: cf935400 r9 : c043fb00 r8 : d0804084 +r7 : 00000012 r6 : c045588c r5 : 00000000 r4 : d0804000 +r3 : 00000008 r2 : 0000000d r1 : 00000000 r0 : 00000000 +Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel +Control: 00c5387d Table: 0fb40008 DAC: 00000017 +Process swapper (pid: 0, stack limit = 0xc0418268) +Stack: (0xc0419e30 to 0xc041a000) +9e20: 1be06241 00000000 00000001 00200200 +9e40: cf997af0 c004256c cf997ac0 cf844800 c0427898 c043fae4 c0418000 00000100 +9e60: c0419e7c cf9cbca0 c045587c 00000000 00000000 0000001b c043fb00 c0428e54 +9e80: 00000001 c0214e0c 00000001 00000080 0000001b cf9cbca0 0000001b c0054620 +9ea0: c0445420 c0419ec0 00000000 c0428e54 0000001b 00000000 c043fee8 00000000 +9ec0: cf997ac0 c0307e44 c0419f74 c00547a8 c0428e54 c0056860 c04321e8 c0053fe4 +9ee0: 000000c0 c001470c c043fee8 c0419f10 00000000 c00084f8 c003f840 20000013 +9f00: ffffffff c0419f44 c04223d8 c00134c0 00000000 00000000 00000002 cfb20c8c +9f20: cfb20c60 cf997ac0 00000001 c0427898 c04223d8 cf997ac0 c0307e44 c0419f74 +9f40: 00000000 c0419f58 c030536c c003f840 20000013 ffffffff 00000000 00000000 +9f60: c0427898 c0418000 c0427898 c04223d8 c0419fa4 c030536c c04230c0 cfb20c60 +9f80: c0423348 c0418000 c0418000 c043fc68 c0418000 c04230c0 410fb767 c0423348 +9fa0: 00000000 c0014a18 c0425fbc c04200d0 ffffffff c04123fc c065b880 00004008 +9fc0: 00410e7c c03f771c ffffffff ffffffff c03f728c 00000000 00000000 c04123fc +9fe0: 00000000 00c5387d c042004c c04123f8 c04230b4 00008040 00000000 00000000 +[<c02193a0>] (sym_interrupt+0x7c8/0x1b88) from [<c0214e0c>] (sym53c8xx_intr+0x40/0x7c) +[<c0214e0c>] (sym53c8xx_intr+0x40/0x7c) from [<c0054620>] (handle_irq_event_percpu+0x50/0x1b0) +[<c0054620>] (handle_irq_event_percpu+0x50/0x1b0) from [<c00547a8>] (handle_irq_event+0x28/0x38) +[<c00547a8>] (handle_irq_event+0x28/0x38) from [<c0056860>] (handle_level_irq+0x80/0xd4) +[<c0056860>] (handle_level_irq+0x80/0xd4) from [<c0053fe4>] (generic_handle_irq+0x24/0x38) +[<c0053fe4>] (generic_handle_irq+0x24/0x38) from [<c001470c>] (handle_IRQ+0x30/0x84) +[<c001470c>] (handle_IRQ+0x30/0x84) from [<c00084f8>] (vic_handle_irq+0x58/0x98) +[<c00084f8>] (vic_handle_irq+0x58/0x98) from [<c00134c0>] (__irq_svc+0x40/0x54) +Exception stack(0xc0419f10 to 0xc0419f58) +9f00: 00000000 00000000 00000002 cfb20c8c +9f20: cfb20c60 cf997ac0 00000001 c0427898 c04223d8 cf997ac0 c0307e44 c0419f74 +9f40: 00000000 c0419f58 c030536c c003f840 20000013 ffffffff +[<c00134c0>] (__irq_svc+0x40/0x54) from [<c003f840>] (finish_task_switch.constprop.68+0x78/0xec) +[<c003f840>] (finish_task_switch.constprop.68+0x78/0xec) from [<c030536c>] (__schedule+0x1a0/0x3bc) +[<c030536c>] (__schedule+0x1a0/0x3bc) from [<c0014a18>] (cpu_idle+0xa4/0xc0) +[<c0014a18>] (cpu_idle+0xa4/0xc0) from [<c03f771c>] (start_kernel+0x26c/0x2bc) +Code: e5d42540 e3a03008 e5c43540 e5842550 (e5951358) +---[ end trace 25ce2cfc77dea57b ]--- +Kernel panic - not syncing: Fatal exception in interrupt + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +On May 14, 2013, at 6:58 AM, Peter Maydell <email address hidden> wrote: + +> It's very unlikely to be the patch you mention, since that's for SD card +> emulation and you're not using SD card emulation. It's probably just a +> regression between 1.4 and 1.5, and I'm fairly sure it's in some changes +> I made to the versatilepb PCI controller model -- I will investigate. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1094564 +> +> Title: +> images used as scsi disks not readable (qemu-system-arm, macos 10.8) +> +> Status in The MacPorts Project: +> New +> Status in QEMU: +> New +> +> Bug description: +> Using a arm1176 kernel and the raspbian image (10-28 or 12-16) as my +> disk, I get as far as mounting root and then get SCSI errors with +> 1.3.0 and the current origin/master. git bisect says the issue is +> +> commit f563a5d7a820424756f358e747238f03e866838a +> Merge: a273652 aee0bf7 +> Author: Paolo Bonzini <email address hidden> +> Date: Wed Oct 31 10:42:51 2012 +0100 +> +> Merge remote-tracking branch 'origin/master' into threadpool +> +> Signed-off-by: Paolo Bonzini <email address hidden> +> +> +> I am using: +> qemu-system-arm -no-reboot -M versatilepb -cpu arm1176 -m 256 -hda 2012-12-16-wheezy-raspbian.img -kernel kernel-qemu -append "root=/dev/sda2 rootfstype=ext4 elevator=deadline rootwait panic=1" -serial stdio -usbdevice tablet -net nic -net user,hostfwd=tcp::40022-:22 +> +> Configured on MacOS 10.8.2 with current Xcode and MacPorts installed, thus: +> CPATH=/opt/local/include CFLAGS="-pipe -O2 -arch x86_64" CPPFLAGS="-I/opt/local/include" CXXFLAGS="-pipe -O2 -arch x86_64" LIBRARY_PATH="/opt/local/lib" MACOSX_DEPLOYMENT_TARGET="10.8" CXX="/usr/bin/clang++" LDFLAGS="-L/opt/local/lib -arch x86_64" OBJC=/usr/bin/clang FCFLAGS="-pipe -O2 -m64" INSTALL="/usr/bin/install -c" OBJCFLAGS="-pipe -O2 -arch x86_64" CC="/usr/bin/clang" ./configure --prefix=/opt/local --cpu=x86_64 --cc=/usr/bin/clang --objcc=/usr/bin/clang --host-cc=/usr/bin/clang --python=/opt/local/bin/python2.7 --target-list=arm-softmmu +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/macports/+bug/1094564/+subscriptions + + + +On 15 May 2013 19:02, Joss Reeves <email address hidden> wrote: +> Thanks so much for the patch and including me on the thread. I can +> confirm that it did fix the problem running on a Linux host, but the OS +> X bug cited by myself and the OP still remains elusive. It's rather +> puzzling as I pulled from HEAD and built using the same options on both. + +QEMU itself actually hangs in my tests (the main loop is waiting +to lock the iothread but it never does; the cpu thread seems to +be stuck trying to do a bdrv_aio_cancel for the scsi device model). +This should never happen, regardless of what the guest does... + +I suspect that if you configure on linux with --with-coroutine=sigaltstack +you might then find they both behave the same (MacOSX can't do the +ucontext coroutines we default to on linux). OTOH it might also +involve some of MacOSX's slightly different signal behaviour. + +I'll continue to prod, though past experience is that MacOSX +gdb is weirdly broken and things behave differently when run +under it, which doesn't help :-( + +-- PMM + + +On 15 May 2013 21:18, Peter Maydell <email address hidden> wrote: +> I suspect that if you configure on linux with --with-coroutine=sigaltstack +> you might then find they both behave the same (MacOSX can't do the +> ucontext coroutines we default to on linux). + +They don't, so it's a MacOSX specific issue of some kind. +PS: you don't need "-global versatile_pci.broken-irq-mapping=1" +in the command line because we do correctly autodetect and +handle your kernel now. + +thanks +-- PMM + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + diff --git a/results/classifier/118/virtual/1157368 b/results/classifier/118/virtual/1157368 new file mode 100644 index 00000000..7740f96b --- /dev/null +++ b/results/classifier/118/virtual/1157368 @@ -0,0 +1,68 @@ +virtual: 0.903 +graphic: 0.651 +semantic: 0.221 +mistranslation: 0.186 +VMM: 0.159 +device: 0.127 +user-level: 0.100 +files: 0.088 +hypervisor: 0.057 +risc-v: 0.055 +peripherals: 0.045 +x86: 0.030 +performance: 0.028 +architecture: 0.025 +vnc: 0.024 +PID: 0.023 +i386: 0.022 +ppc: 0.017 +permissions: 0.011 +debug: 0.011 +register: 0.006 +boot: 0.006 +network: 0.005 +socket: 0.005 +arm: 0.005 +assembly: 0.003 +TCG: 0.002 +kernel: 0.001 +KVM: 0.001 + +Desktop background messed up when running Raring in a QEMU-based virtual machine + +Screenshot attached. + +Problem occurs only when choosing the default cirrus graphics card. The other graphics cards do not show this problem but are very unstable. + +The screenshot is of the whole desktop with a Virtual Machine Manager window containing the desktop of the VM. You see that its actual background is messed up and also the background images which you can choose when right-clicking the background and choosing "Change Desktop Background". + + + +It does not matter whether the host machine is Quantal or Raring, currently my host machine is Raring, so I can easily test Raring packages for the fix of this bug. + +Thanks I'll try to reproduce later tonight. + +For additional info see the files attached to bug 1157066, they are for the same virtual machine. + +I see this behavior over vnc as well. The desktop is rendered correctly using spice. You can use that by adding eg + + -vga qxl -spice port=5990,disable-ticketing + +and connect using + + spicy -h localhost -p 5990 + +I also don't get this with the vmware vga driver. The background is fine for that with both sdl and vnc. + +(lowering priority since there are more than one workarounds) + +Sorry, I had misread the original description and thought you said the other graphics cards *also* showed this problem :) + +Thanks again for submitting this bug. I'll test against upstream qemu to see if we can report this there. + +Also reproduced with git://git.qemu.org/qemu.git (using vga -cirrus) + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +This did never occur again for me. So this can get closed. + diff --git a/results/classifier/118/virtual/1161 b/results/classifier/118/virtual/1161 new file mode 100644 index 00000000..aad87e39 --- /dev/null +++ b/results/classifier/118/virtual/1161 @@ -0,0 +1,31 @@ +virtual: 0.846 +mistranslation: 0.652 +performance: 0.496 +device: 0.455 +vnc: 0.365 +graphic: 0.359 +boot: 0.289 +files: 0.205 +network: 0.204 +register: 0.184 +VMM: 0.130 +risc-v: 0.127 +arm: 0.108 +ppc: 0.098 +user-level: 0.095 +hypervisor: 0.084 +TCG: 0.074 +x86: 0.069 +i386: 0.054 +semantic: 0.052 +PID: 0.035 +architecture: 0.035 +debug: 0.033 +peripherals: 0.030 +socket: 0.028 +kernel: 0.019 +permissions: 0.016 +assembly: 0.012 +KVM: 0.008 + +revise docs/interop/virtio-balloon-stats.rst diff --git a/results/classifier/118/virtual/1181 b/results/classifier/118/virtual/1181 new file mode 100644 index 00000000..dcc12d0d --- /dev/null +++ b/results/classifier/118/virtual/1181 @@ -0,0 +1,31 @@ +virtual: 0.868 +device: 0.861 +mistranslation: 0.348 +performance: 0.339 +boot: 0.232 +risc-v: 0.225 +graphic: 0.206 +semantic: 0.200 +permissions: 0.198 +register: 0.146 +arm: 0.143 +assembly: 0.137 +i386: 0.096 +ppc: 0.092 +vnc: 0.077 +hypervisor: 0.070 +debug: 0.048 +kernel: 0.041 +x86: 0.030 +architecture: 0.029 +network: 0.028 +VMM: 0.018 +PID: 0.008 +socket: 0.008 +TCG: 0.007 +KVM: 0.006 +files: 0.005 +peripherals: 0.003 +user-level: 0.003 + +Question for AVR experts... diff --git a/results/classifier/118/virtual/1192065 b/results/classifier/118/virtual/1192065 new file mode 100644 index 00000000..e90d0775 --- /dev/null +++ b/results/classifier/118/virtual/1192065 @@ -0,0 +1,39 @@ +virtual: 0.972 +mistranslation: 0.848 +performance: 0.770 +graphic: 0.760 +device: 0.732 +semantic: 0.667 +VMM: 0.578 +risc-v: 0.532 +kernel: 0.529 +hypervisor: 0.528 +x86: 0.507 +PID: 0.505 +boot: 0.489 +architecture: 0.484 +i386: 0.483 +user-level: 0.483 +vnc: 0.469 +network: 0.462 +permissions: 0.456 +ppc: 0.451 +register: 0.449 +socket: 0.441 +debug: 0.436 +TCG: 0.384 +assembly: 0.359 +files: 0.334 +arm: 0.319 +KVM: 0.306 +peripherals: 0.270 + +qemu release memory to system + +Qemu pre-allocates the maximum balloon amount which is inconvinient if all of the memory is used up and some other system needs to be added memory resource + +eg:- I have 4GB RAM with 4 virtual systems to be run. +I want each of them to start with 1GB RAM with maximum 2GB possible. This is not achievable since qemu pre-allocates the maximum balloon amount which is 2GBx4 systems . So to start all 4 systems the system needs 8GB RAM rather than 4GB RAM to start with although I have told initial balloon amount to be 1GB. + +Looking through old bug tickets... I think you should rather use hotpluggable memory here for the guests instead - or use a big swap partition on the host. Anyway, this is not a bug, so closing this ticket now. + diff --git a/results/classifier/118/virtual/1199 b/results/classifier/118/virtual/1199 new file mode 100644 index 00000000..412a9cb3 --- /dev/null +++ b/results/classifier/118/virtual/1199 @@ -0,0 +1,40 @@ +virtual: 0.939 +device: 0.846 +VMM: 0.734 +kernel: 0.614 +vnc: 0.601 +hypervisor: 0.589 +graphic: 0.506 +boot: 0.492 +architecture: 0.457 +register: 0.455 +PID: 0.448 +risc-v: 0.376 +debug: 0.370 +KVM: 0.366 +network: 0.359 +permissions: 0.352 +performance: 0.322 +semantic: 0.265 +i386: 0.263 +arm: 0.251 +socket: 0.249 +x86: 0.234 +TCG: 0.226 +mistranslation: 0.189 +peripherals: 0.161 +ppc: 0.142 +assembly: 0.115 +files: 0.089 +user-level: 0.059 + +Prevent virtual machine memory leakage +Description of problem: +The data written in the virtual machine does not clear the memory after the virtual machine is shut down. When the virtual machine with large memory is started, it may access the data of the previous virtual machine +Steps to reproduce: +1. create a virtual machine with large size memory( 80% of the host's Physical memory) +2. Request all free memory and write the characteristic string in vm +3. restart the vm +4. Request all free memory and query the last character string written +Additional information: + diff --git a/results/classifier/118/virtual/1210212 b/results/classifier/118/virtual/1210212 new file mode 100644 index 00000000..2c58398a --- /dev/null +++ b/results/classifier/118/virtual/1210212 @@ -0,0 +1,57 @@ +virtual: 0.877 +device: 0.716 +debug: 0.666 +graphic: 0.665 +x86: 0.664 +arm: 0.564 +ppc: 0.559 +semantic: 0.553 +mistranslation: 0.533 +socket: 0.530 +kernel: 0.500 +network: 0.499 +vnc: 0.499 +risc-v: 0.489 +user-level: 0.445 +VMM: 0.441 +permissions: 0.441 +boot: 0.428 +i386: 0.408 +PID: 0.394 +performance: 0.394 +architecture: 0.388 +register: 0.381 +hypervisor: 0.286 +TCG: 0.283 +KVM: 0.232 +files: 0.212 +peripherals: 0.154 +assembly: 0.152 + +qemu core dumps with -serial mon:vc + +qemu 1.5.2-1 dumps core when asked to put the monitor on a virtual console. For example, suppose you want to monitor the second serial port, you might try something like: + +qemu-system-x86_64 -serial null -serial mon:vc + +But that creates a core dump. In fact, even re-creating what should be the default dumps core: + +$ qemu-system-x86_64 -serial mon:vc:80Cx25C +Segmentation fault (core dumped) + +I'm not including a backtrace because the bug is so easy to reproduce, but I can provide more info if necessary. + +Hi, + +This problem has been solved by + +commit 7b7ab18d0b9769b5f39e663fa55caed461b1202e: +Author: Michael Roth <email address hidden> +Date: Tue Jul 30 13:04:22 2013 -0500 + +chardev: fix CHR_EVENT_OPENED events for mux chardevs + +Patch link: +http://patchwork.ozlabs.org/patch/263458/ + + diff --git a/results/classifier/118/virtual/1241569 b/results/classifier/118/virtual/1241569 new file mode 100644 index 00000000..d7e71b9b --- /dev/null +++ b/results/classifier/118/virtual/1241569 @@ -0,0 +1,42 @@ +virtual: 0.998 +kernel: 0.756 +device: 0.728 +semantic: 0.716 +mistranslation: 0.712 +graphic: 0.696 +performance: 0.600 +i386: 0.548 +user-level: 0.548 +boot: 0.545 +architecture: 0.504 +x86: 0.426 +VMM: 0.380 +vnc: 0.374 +debug: 0.308 +ppc: 0.300 +network: 0.298 +TCG: 0.294 +arm: 0.221 +hypervisor: 0.213 +peripherals: 0.199 +PID: 0.174 +register: 0.168 +risc-v: 0.160 +socket: 0.146 +permissions: 0.120 +assembly: 0.093 +files: 0.091 +KVM: 0.074 + +qemu-system-alpha console unresponsive + +I have created a virtual machine using the QEMU Alpha emulator (very basic, 1 scsi disc, 1 scsi CDROM, 1gb memory). The machine starts, but entering any system commands at the prompt just echs back the command typed. For example + +>>> show device +got: show device +>>> + +Obviously booting any OS from this is not possible. + +I think that firmware prompt is not really useful. Anyway, according to https://virtuallyfun.superglobalmegacorp.com/2014/02/19/alpha-linux-on-qemu/ you currently have to specify the (uncompressed) vmlinux kernel with the "-kernel" option of QEMU. Then you should be able to start Linux with qemu-system-alpha, too. + diff --git a/results/classifier/118/virtual/1252270 b/results/classifier/118/virtual/1252270 new file mode 100644 index 00000000..43568abd --- /dev/null +++ b/results/classifier/118/virtual/1252270 @@ -0,0 +1,65 @@ +virtual: 0.876 +user-level: 0.734 +graphic: 0.714 +ppc: 0.679 +PID: 0.640 +device: 0.596 +semantic: 0.577 +architecture: 0.574 +hypervisor: 0.573 +network: 0.560 +mistranslation: 0.526 +kernel: 0.524 +socket: 0.518 +debug: 0.512 +performance: 0.496 +vnc: 0.451 +permissions: 0.434 +files: 0.403 +arm: 0.371 +register: 0.360 +VMM: 0.355 +risc-v: 0.331 +assembly: 0.325 +boot: 0.318 +peripherals: 0.310 +TCG: 0.304 +x86: 0.169 +i386: 0.145 +KVM: 0.107 + +installing NT4 on MIPS Magnum/Jazz asserts + +While installing NT4 on MIPS Magnum (Jazz), when the NT Installer tries to format the harddisk, QEmu 1.6.1 crashes with an assertion: + +qemu-system-mips64el: g364: invalid read at [0000000000102000] +qemu-system-mips64el: hw/scsi/scsi-bus.c:1577: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed. +./nt4mips.sh: line 3: 20336 Aborted (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384 + +This assertion also occurred with the stock Ubuntu version of QEmu (1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)) which I tried before. + +Note that to even get this far, you need the patch mentioned in BUG1245924, otherwise QEmu 1.6.1 won't even start/boot at all + +NT4 installation guide I'm following: +http://gunkies.org/wiki/Installing_Windows_NT_4.0_on_Qemu(MIPS) +http://virtuallyfun.superglobalmegacorp.com/?p=2255 + +As a side note, that "invalid read at..." warning is unrelated, as it happens right on startup + +This bug is still present in qemu 1.7.0: + +qemu-system-mips64el: g364: invalid read at [0000000000102000] +qemu-system-mips64el: hw/scsi/scsi-bus.c:1578: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed. +./nt4mips.sh: line 3: 26409 Aborted (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384 + + +We're about to release 2.0, so it would be more interesting to know whether it still happens in latest qemu.git. + +And since this seems to depend on .iso and nvram.bin files that we don't have available for reproducing, some tracing on your part might help narrow down whether this is caused by a bug in MIPS-specific or generic SCSI code and what exactly it's been trying to do at the point of assertion. Running it in gdb to get a backtrace on SIGABRT would be a start. --enable-trace-backend= and -trace would be further options to investigate. + +Indeed the crash doesn't happen in current git anymore. Setup still doesn't copy anything off the CD (hangs on the first file) but at least the crash is fixed and formatting the harddisk works now. + +I'll investigate the other issue and maybe open up a new bug for that. + +This bug here can be closed. Thank you! + diff --git a/results/classifier/118/virtual/1261320 b/results/classifier/118/virtual/1261320 new file mode 100644 index 00000000..d1b9fe79 --- /dev/null +++ b/results/classifier/118/virtual/1261320 @@ -0,0 +1,77 @@ +virtual: 0.863 +performance: 0.649 +semantic: 0.468 +user-level: 0.461 +device: 0.459 +mistranslation: 0.442 +hypervisor: 0.407 +PID: 0.389 +architecture: 0.386 +graphic: 0.364 +ppc: 0.348 +assembly: 0.329 +kernel: 0.291 +register: 0.280 +socket: 0.275 +risc-v: 0.269 +permissions: 0.269 +i386: 0.265 +files: 0.263 +VMM: 0.256 +boot: 0.246 +x86: 0.242 +KVM: 0.231 +TCG: 0.218 +vnc: 0.218 +arm: 0.216 +network: 0.197 +debug: 0.196 +peripherals: 0.181 + +Virtual Disk with over 16TB + +Hi, + +is there a option to create a disk for a vm with a size over 16TB. + +the problem that after the diskfile reach 16TB, the disk get a state of read-only at this limit. +I know, that 16TB file size is max, is there a option to create the disk in mutliple files? +we want to use 22 TB. in the VM + +To attach a partition directly to the vm, is not what we want to do. + +best regards + +Chris + +On Mon, Dec 16, 2013 at 09:37:34AM -0000, Chris Weltzien wrote: +> is there a option to create a disk for a vm with a size over 16TB. +> +> the problem that after the diskfile reach 16TB, the disk get a state of read-only at this limit. +> I know, that 16TB file size is max, is there a option to create the disk in mutliple files? +> we want to use 22 TB. in the VM + +Basically no, not in a clean way for a production VM. Can you attach +multiple disks to the guest and then use software RAID0 or LVM to get a +22 TB device inside the guest? + +If not, here are some options: +1. Switch to a different file system (XFS is your best bet) +2. Use LVM (and get a slight performance boost for free!) +3. Tweak file system settings (e.g. bigger block size may allow larger +files) + +Stefan + + +Hi Stefan, + +thank you for your response. + +We're decided to only use 16Tb as vhd for the system. + + +best regards + +Chris + diff --git a/results/classifier/118/virtual/1312561 b/results/classifier/118/virtual/1312561 new file mode 100644 index 00000000..40e36cf1 --- /dev/null +++ b/results/classifier/118/virtual/1312561 @@ -0,0 +1,108 @@ +virtual: 0.862 +permissions: 0.857 +semantic: 0.851 +network: 0.840 +kernel: 0.833 +architecture: 0.828 +device: 0.827 +risc-v: 0.807 +assembly: 0.804 +PID: 0.792 +register: 0.786 +debug: 0.780 +peripherals: 0.773 +arm: 0.771 +performance: 0.771 +vnc: 0.753 +socket: 0.749 +hypervisor: 0.720 +mistranslation: 0.719 +graphic: 0.718 +files: 0.714 +user-level: 0.673 +TCG: 0.672 +ppc: 0.646 +KVM: 0.641 +boot: 0.637 +VMM: 0.525 +x86: 0.327 +i386: 0.280 + +libstdc++-6.dll is missing from your computer + +qemu-w64-setup-20140418.exe + +Windows 7 64 bit PC. + +qemu-system-armw -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda c:\11\rasimg\test.vhd + + +qemu-system-armw.exe - System Error +The program can't start because libstdc++-6.dll is missing from your computer. + +Try reinstalling the program to fix this problem. + +I tried reinstalling, but no change. + +Also getting same error when running the following command on Windows 7 64 bit. + +qemu-system-arm -cpu? + +I also reinstalled qemu without any luck. + +Also getting same error when running the following command on Windows 7 64 bit. + +qemu-system-arm -cpu? + +I also reinstalled qemu without any luck. + +That DLL is the mingw C++ runtime library. We should probably make our Windows executables build with a static libstdc++. + +Ok, so we need to wait for a recompiled version I guess. +I did after your post get the dll from the mingw site, and that error went away, but then replaced by application failed with (0x000007b) error. +How much of the mingw package would we need to install to fix the problem if a recompiled version is some time away please? + +I think dynamic is fine, after all how is libstdc++ different from glib? Both of them need to be deployed together with the executable on Windows, because they aren't a common prerequisite. + +Ah, we're dynamically linking with glib too? In that case, yes, whatever mechanism we're currently using to distribute the glib DLL we should use for the libstdc++ too. + +So the answer to my basic question, how to make this work is Download the mingw windows installer from here. +http://cznic.dl.sourceforge.net/project/mingwbuilds/mingw-builds-install/mingw-builds-install.exe + +Install for W 64 posix or win32 and VERSION 4.6.3 (later one doesn't work with qemu-w64-setup-20140418.exe. +Add to the environment path (Something like +C:\Program Files\mingw-builds\x64-4.6.3-posix-sjlj-rev2\mingw\bin or +C:\Program Files\mingw-builds\x64-4.6.3-win32-sjlj-rev2\mingw\bin both seem to work. + +Hi... + This is still a problem with the latest build(qemu-wXX-setup-20150510.exe). + +I've tried with several different versions from the MinGW, neither work +So, which is the correct NinGW version ? + Thanks + JR + +Hello, + +Same problem here with qemu-w64-setup-20150510.exe. +As suggested above I tried to install mingw 4.6.3 posix and set path like: +set PATH=C:\Program Files\mingw-builds\x64-4.6.3-posix-sjlj-rev2\;C:\Program Files\mingw-builds\x64-4.6.3-posix-sjlj-rev2\bin;%PATH% + +I do not have the libstdc++-6.dll missing error message anymore, but now I have a entry point "__gxx_personality_seh0" missing from libstdc++-6.dll error message, so this is not the appropriate runtime. + + + +Forgot to tell I am running Windows 7 x64, and trying to launch qemu-system-arm. + +This is not a QEMU bug, but a problem of some installers from http://qemu.weilnetz.de/. +http://qemu.weilnetz.de/w64/qemu-w64-setup-20150424.exe should work. + +Get the missing dll from http://qemu.weilnetz.de/w64/dll/. + +Reporting problems to the right address (here the owner of weilnetz.de) would help to +get a faster response in the future. + +Regards +Stefan + + diff --git a/results/classifier/118/virtual/1314293 b/results/classifier/118/virtual/1314293 new file mode 100644 index 00000000..49f6777a --- /dev/null +++ b/results/classifier/118/virtual/1314293 @@ -0,0 +1,43 @@ +virtual: 0.847 +VMM: 0.806 +device: 0.786 +graphic: 0.728 +performance: 0.710 +network: 0.658 +semantic: 0.632 +mistranslation: 0.584 +architecture: 0.520 +vnc: 0.514 +risc-v: 0.509 +kernel: 0.507 +socket: 0.489 +debug: 0.472 +PID: 0.462 +i386: 0.458 +ppc: 0.452 +TCG: 0.434 +KVM: 0.431 +register: 0.429 +hypervisor: 0.425 +boot: 0.391 +x86: 0.371 +files: 0.352 +user-level: 0.320 +permissions: 0.276 +peripherals: 0.271 +arm: 0.270 +assembly: 0.266 + +screendump with qxl + spice shows stale data + +The monitor 'screendump' command returns stale data for VMs using qxl + spice. If you perform multiple screendumps, screendump #N will show roughly the display from the time screendump #N-1 was taken. This affects 'virsh screenshot' and libvirt screenshot APIs by association. + +Gerd explains that new monitor commands/infrastructure is likely required to handle this correctly: + +https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03840.html + +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/118/virtual/1341032 b/results/classifier/118/virtual/1341032 new file mode 100644 index 00000000..167c8ce3 --- /dev/null +++ b/results/classifier/118/virtual/1341032 @@ -0,0 +1,42 @@ +virtual: 0.814 +x86: 0.811 +graphic: 0.695 +architecture: 0.590 +performance: 0.506 +debug: 0.490 +device: 0.425 +semantic: 0.413 +network: 0.350 +mistranslation: 0.347 +boot: 0.256 +i386: 0.238 +VMM: 0.228 +hypervisor: 0.222 +permissions: 0.200 +PID: 0.198 +user-level: 0.166 +socket: 0.149 +register: 0.145 +vnc: 0.140 +files: 0.139 +peripherals: 0.130 +risc-v: 0.083 +kernel: 0.082 +TCG: 0.077 +ppc: 0.069 +KVM: 0.059 +arm: 0.051 +assembly: 0.008 + +no-shutdown does not fire SHUTDOWN event for some guests + +Currently using: qemu-x86_64 version 2.0.0 +Steps to reproduce: Create virtual machine with the arguments -no-shutdown, such as used by libvirt. Attach to the json event system. Load a guest such as Ubuntu 14.04 and run the 'halt' command. Guest ceases to execute, qemu freezes CPUs however no SHUTDOWN event is fired to the monitor. + +Now load a guest such as finnix or Debian 7. Run the same sequence of steps and note that the SHUTDOWN event is fired to the monitor. + +This seems like a qemu bug as the execution of the guest has ceased. + +Thanks +Michael + diff --git a/results/classifier/118/virtual/1349972 b/results/classifier/118/virtual/1349972 new file mode 100644 index 00000000..766cd46f --- /dev/null +++ b/results/classifier/118/virtual/1349972 @@ -0,0 +1,70 @@ +virtual: 0.908 +user-level: 0.906 +graphic: 0.896 +performance: 0.862 +files: 0.861 +mistranslation: 0.857 +KVM: 0.836 +semantic: 0.816 +device: 0.812 +architecture: 0.805 +PID: 0.805 +ppc: 0.792 +hypervisor: 0.791 +TCG: 0.776 +debug: 0.770 +vnc: 0.735 +kernel: 0.729 +VMM: 0.728 +permissions: 0.696 +network: 0.692 +socket: 0.682 +risc-v: 0.670 +peripherals: 0.669 +register: 0.645 +i386: 0.640 +arm: 0.638 +boot: 0.601 +assembly: 0.600 +x86: 0.488 + + qcow2-refcount: qemu-io crashes on 'discard' command + +qemu-io is killed by SIGIOT at the 'discard' command on the image having no refcount information. + +Sequence: +1. Unpack test.img and backing_img.qed in the same directory (see the attached archives for images) +2. Make a copy of test.img to copy.img (qemu-io modifies the image before being kill, therefore the image backup is necessary) +3. Run the command + +qemu-io copy.img -c 'discard 2210816 2856448' + +Result: qemu-io is killed by SIGIOT with the reason: + +qemu-io: block/qcow2-refcount.c:468: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed. + + +The image was generated by the image fuzzer. + +qemu.git HEAD: 1d80eb7a680d + + + +FWIW: + +While trying to restore (apply) a snapshot on a Windows VM (ie: qemu-img snapshot -a snapshotname windows.qcow2 where the image file is 150gb in size,) I got the above error: + +qemu-img: /build/buildd/qemu-2.0.0+dfsg/block/qcow2-refcount.c:467: update_refcount_discard: Assertion `d->bytes + length == new_end - new_start' failed. + +(My VM is now broken.) + +This is the only reference that I found using Google. + +HTH + +I sent a patch that fixes the original problem that Maria reported. It's hard to say whether this is the same problem as you saw, Sam, but it's quite possible. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ecbda7a22576591a84 +... so I think it should be OK now to mark this ticket as fixed. + diff --git a/results/classifier/118/virtual/1359 b/results/classifier/118/virtual/1359 new file mode 100644 index 00000000..03aca758 --- /dev/null +++ b/results/classifier/118/virtual/1359 @@ -0,0 +1,31 @@ +virtual: 0.981 +vnc: 0.755 +risc-v: 0.717 +hypervisor: 0.708 +performance: 0.676 +device: 0.659 +VMM: 0.641 +KVM: 0.620 +arm: 0.601 +ppc: 0.563 +register: 0.499 +network: 0.484 +permissions: 0.474 +TCG: 0.468 +architecture: 0.466 +graphic: 0.451 +files: 0.451 +boot: 0.444 +PID: 0.422 +socket: 0.374 +peripherals: 0.361 +mistranslation: 0.330 +x86: 0.329 +i386: 0.299 +semantic: 0.270 +user-level: 0.269 +kernel: 0.204 +debug: 0.116 +assembly: 0.111 + +open virtual format diff --git a/results/classifier/118/virtual/1359394 b/results/classifier/118/virtual/1359394 new file mode 100644 index 00000000..fb9ae95c --- /dev/null +++ b/results/classifier/118/virtual/1359394 @@ -0,0 +1,74 @@ +virtual: 0.822 +device: 0.786 +boot: 0.780 +mistranslation: 0.678 +performance: 0.484 +semantic: 0.481 +hypervisor: 0.439 +graphic: 0.418 +architecture: 0.372 +PID: 0.339 +user-level: 0.320 +ppc: 0.301 +kernel: 0.287 +x86: 0.271 +i386: 0.265 +register: 0.239 +debug: 0.227 +socket: 0.223 +peripherals: 0.221 +vnc: 0.169 +network: 0.156 +assembly: 0.142 +KVM: 0.127 +permissions: 0.103 +VMM: 0.096 +risc-v: 0.086 +arm: 0.071 +TCG: 0.057 +files: 0.049 + +virtio block device hangs after "virtio_blk virtio3: requests:id 0 is not a head!" + +The virtual machine is running block layer workloads, interrupted by unclean reboots (echo b > /proc/sysrq-trigger). Kernel version is 3.14. + +Sometimes, I get this message on boot: + +"virtio_blk virtio3: requests:id 0 is not a head!" + +Then, I/O to the virtio block devices just hangs. + +Unfortunately I don't have a test case and this is kind of hard to reproduce, but it seems related to having I/O in flight when the kernel is forced to reboot. + +On Wed, Aug 20, 2014 at 08:37:46PM -0000, Slava Pestov wrote: +> The virtual machine is running block layer workloads, interrupted by +> unclean reboots (echo b > /proc/sysrq-trigger). Kernel version is 3.14. +> +> Sometimes, I get this message on boot: +> +> "virtio_blk virtio3: requests:id 0 is not a head!" +> +> Then, I/O to the virtio block devices just hangs. +> +> Unfortunately I don't have a test case and this is kind of hard to +> reproduce, but it seems related to having I/O in flight when the kernel +> is forced to reboot. + +Hi Slava, +Sounds like the virtio device was not reset properly. + +The guest kernel is looking for completed responses from the host. The +host has indicated that descriptor 0 is the next completed response but +the guest does not remember having submitted it. + +Do you have a kernel stack trace when this was encountered? + +Stefan + + +You mean a kernel stack trace when the message was printed? I don't have that but I guess I could add a dump_stack() call in there. + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU and the kernel? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1405 b/results/classifier/118/virtual/1405 new file mode 100644 index 00000000..d58227d7 --- /dev/null +++ b/results/classifier/118/virtual/1405 @@ -0,0 +1,151 @@ +register: 0.931 +virtual: 0.929 +semantic: 0.917 +device: 0.914 +arm: 0.914 +PID: 0.910 +assembly: 0.910 +graphic: 0.903 +i386: 0.901 +debug: 0.899 +kernel: 0.893 +permissions: 0.884 +risc-v: 0.878 +socket: 0.878 +architecture: 0.873 +performance: 0.869 +vnc: 0.868 +files: 0.863 +boot: 0.847 +TCG: 0.834 +x86: 0.833 +user-level: 0.832 +network: 0.821 +VMM: 0.816 +ppc: 0.796 +KVM: 0.792 +peripherals: 0.792 +hypervisor: 0.778 +mistranslation: 0.643 + +linux-user: calling SYS_get_thread_area and SYS_get_thread_area has incorrent result on multithread environment +Description of problem: + +Steps to reproduce: +1. Compile test.out by Command and source code: +``` +gcc -m32 -g test.c -lpthread -o test.out +``` +``` +#include <sys/syscall.h> +#include <unistd.h> +#include <stdio.h> +#include <pthread.h> +#include <asm/ldt.h> + +static inline int set_thread_area( struct user_desc *ptr ) +{ + return syscall( SYS_set_thread_area, ptr ); +} + +static inline int get_thread_area( struct user_desc *ptr ) +{ + return syscall( SYS_get_thread_area, ptr ); +} + +static unsigned int entry_number; + +static void* start_routine(void* ptr) +{ + struct user_desc user_desc0 = { entry_number }; + struct user_desc user_desc1 = { entry_number }; + struct user_desc user_desc2 = { entry_number }; + get_thread_area(&user_desc0); + printf("child thread: %u\n", user_desc0.base_addr); + + user_desc1.base_addr = 2; + user_desc1.limit = 0xFFF; + user_desc1.seg_32bit = 1; + set_thread_area( &user_desc1 ); + + get_thread_area(&user_desc2); + printf("child thread: %u\n", user_desc2.base_addr); + return NULL; +} + +int main(void) { + struct user_desc user_desc0 = { -1 }, user_desc1 = { 0 }, user_desc2 = { 0 }; + user_desc0.seg_32bit = 1; + user_desc0.useable = 1; + set_thread_area( &user_desc0 ); + + entry_number = user_desc0.entry_number; + + user_desc1.entry_number = entry_number; + user_desc1.base_addr = 1; + user_desc1.limit = 0xFFF; + user_desc1.seg_32bit = 1; + set_thread_area( &user_desc1 ); + + pthread_t thread_id; + pthread_create(&thread_id, NULL, &start_routine, NULL); + pthread_join(thread_id, NULL); + + user_desc2.entry_number = entry_number; + get_thread_area(&user_desc2); + printf("main thread: %u\n", user_desc2.base_addr); // main thread: 1 + return 0; +} + ``` +2. Correct Result: +``` +child thread: 1 +child thread: 2 +main thread: 1 +``` +qemu-i386 Print Result: +``` +child thread: 1 +child thread: 2 +main thread: 2 +``` +Additional information: +patch for fix the bug: + +https://lists.nongnu.org/archive/html/qemu-devel/2023-02/msg02203.html + +CPUX86State::gdt::base on differect threads must have different vaules, but it points to same memory. +value of CPUX86State::gdt::base must be copied when clone thread. + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/tls.c + +SYS_set_thread_area call do_set_thread_area in kernel, it set user_desc to different memroy area on differernt threads. tls_array is in thread local memory. + +``` +static void set_tls_desc(struct task_struct *p, int idx, + const struct user_desc *info, int n) +{ + struct thread_struct *t = &p->thread; + struct desc_struct *desc = &t->tls_array[idx - GDT_ENTRY_TLS_MIN]; + int cpu; + + /* + * We must not get preempted while modifying the TLS. + */ + cpu = get_cpu(); + + while (n-- > 0) { + if (LDT_empty(info) || LDT_zero(info)) + memset(desc, 0, sizeof(*desc)); + else + fill_ldt(desc, info); + ++info; + ++desc; + } + + if (t == ¤t->thread) + load_TLS(t, cpu); + + put_cpu(); +} +``` diff --git a/results/classifier/118/virtual/1407808 b/results/classifier/118/virtual/1407808 new file mode 100644 index 00000000..27125c04 --- /dev/null +++ b/results/classifier/118/virtual/1407808 @@ -0,0 +1,49 @@ +virtual: 0.838 +semantic: 0.800 +performance: 0.767 +graphic: 0.736 +architecture: 0.699 +device: 0.624 +user-level: 0.552 +peripherals: 0.518 +network: 0.475 +debug: 0.425 +permissions: 0.415 +register: 0.401 +mistranslation: 0.384 +socket: 0.363 +hypervisor: 0.362 +vnc: 0.341 +kernel: 0.311 +files: 0.299 +boot: 0.289 +ppc: 0.258 +risc-v: 0.251 +x86: 0.211 +i386: 0.210 +PID: 0.207 +assembly: 0.200 +VMM: 0.189 +arm: 0.182 +TCG: 0.169 +KVM: 0.158 + +virtual console gives strange response to ANSI DSR + +With "-serial vc" (which is the default), qemu make strange responses to the ANSI DSR escape sequence (\033[6n) which can confuse guests. + +Terminal emulators supporting the ANSI escape sequences usually support the "Device Status Report" escape sequence, \033[6n, to which as a response the terminal injects as input the response \033[n;mR, containing the current cursor position. An application running in the guest can use this escape sequence to, for example, figure out the size of the terminal it is running under, which can be useful as the guest has no other standard way to figure out a "size" for the serial port. + +Unfortunately, it seems that qemu when run with "-serial vc" (which appears to be the default), when qemu gets the \033[6n escape sequence on the serial port, it just responds with a single \033, and that's it! This can confuse an application, could concievably assume that a terminal either supports this escape sequence and injects the correct response (\033[n;mR), or doesn't support it and injects absolutely nothing as input - but not something in between. + +This caused a problem on one shell implementation on OSv that tried to figure out the terminal's size, and had to work around this unexpected behavior (see https://github.com/cloudius-systems/osv/commit/b79223584be40459861d1c12e1cb67e3e49e2a12). + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +The bug still very much exists (I tested qemu 4.2.1): +If you don't use "-serial stdio" (or its newer variants), by default Qemu opens a new black "console" to run the application. It is not clear to me exactly which terminal this console is supposed to emulate, but it does seem to support most ANSI escape sequences I tried. However, it supports the ANSI "DSR" (Device Status Report) escape sequence, ESC [ 6 n (see https://en.wikipedia.org/wiki/ANSI_escape_code), incorrectly, just as I reported in the original issue. This is still true today. + +This should be fixed in head-of-git by commit 8eb13bbbac08a, which will be in QEMU 6.0. (The underlying bug is that when the GTK front-end tries to send sequences of more than one byte to a UART, it didn't account for UARTs which don't have a FIFO capable of holding the whole sequence at once.) + + diff --git a/results/classifier/118/virtual/1459622 b/results/classifier/118/virtual/1459622 new file mode 100644 index 00000000..890297fb --- /dev/null +++ b/results/classifier/118/virtual/1459622 @@ -0,0 +1,58 @@ +virtual: 0.954 +x86: 0.943 +architecture: 0.910 +performance: 0.894 +device: 0.861 +kernel: 0.778 +graphic: 0.741 +PID: 0.727 +KVM: 0.723 +hypervisor: 0.669 +user-level: 0.655 +ppc: 0.641 +vnc: 0.635 +register: 0.594 +network: 0.552 +permissions: 0.543 +boot: 0.524 +i386: 0.514 +semantic: 0.484 +mistranslation: 0.450 +socket: 0.342 +VMM: 0.327 +risc-v: 0.315 +arm: 0.311 +files: 0.310 +peripherals: 0.283 +assembly: 0.241 +debug: 0.185 +TCG: 0.173 + +firefox hang with virtfs + +Firefox hangs once it starts to load pages. I tried to delete .cache/mozilla/ and .mozilla/ but it doesn't help. But if I mount tmpfs on to .mozilla (not necessary for .cache/mozilla/), pages loads fine. + +I started the vm as root (sudo) with the following command: qemu-system-x86_64 -enable-kvm -m 4G -virtfs local,mount_tag=qemu,security_model=passthrough,path=/mnt/qemu/ -kernel /mnt/qemu/boot/vmlinuz-linux -initrd /mnt/qemu/boot/initramfs-linux-fallback.img -append 'rw root=qemu fstype=9p' -usbdevice tablet -vga qxl -spice port=12345,disable-ticketing + +/mnt/qemu is a btrfs snapshot of the subvolume used as the host root + +Arch Linux, qemu 2.3.0, firefox 38.0.1 + + + +Same situation here: +Firefox can't handle ~/.mozilla to be a virtio-9p mount. +Here the subvolume is ext4, mounted only at /home. + +I also noticed that chromium is working, but it complains about some errors: +getrlimit(RLIMIT_NOFILE) failed +[4809:4839:0804/230514:ERROR:backend_impl.cc(1365)] Unable to map Index file +[4809:4839:0804/230514:ERROR:backend_impl.cc(1365)] Unable to map Index file +[4809:4840:0804/230514:ERROR:cache_creator.cc(133)] Unable to create cache +[4845:4845:0804/230514:ERROR:sandbox_linux.cc(340)] InitializeSandbox() called with multiple threads in process gpu-process + + +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/118/virtual/1464 b/results/classifier/118/virtual/1464 new file mode 100644 index 00000000..024ed9c4 --- /dev/null +++ b/results/classifier/118/virtual/1464 @@ -0,0 +1,33 @@ +virtual: 0.957 +graphic: 0.854 +device: 0.547 +performance: 0.355 +mistranslation: 0.291 +arm: 0.244 +semantic: 0.181 +debug: 0.159 +permissions: 0.157 +network: 0.126 +architecture: 0.116 +boot: 0.080 +hypervisor: 0.051 +vnc: 0.042 +VMM: 0.041 +register: 0.038 +peripherals: 0.037 +risc-v: 0.033 +files: 0.033 +PID: 0.028 +ppc: 0.023 +user-level: 0.017 +assembly: 0.014 +kernel: 0.014 +i386: 0.011 +socket: 0.011 +TCG: 0.006 +KVM: 0.002 +x86: 0.002 + +qemu-img resize fails due to inconsistent bitmap(s) +Additional information: +This is on a oVirt env diff --git a/results/classifier/118/virtual/1465 b/results/classifier/118/virtual/1465 new file mode 100644 index 00000000..bb75f290 --- /dev/null +++ b/results/classifier/118/virtual/1465 @@ -0,0 +1,31 @@ +virtual: 0.903 +device: 0.827 +graphic: 0.501 +arm: 0.471 +debug: 0.437 +risc-v: 0.333 +semantic: 0.257 +ppc: 0.153 +boot: 0.141 +performance: 0.139 +i386: 0.119 +mistranslation: 0.111 +x86: 0.103 +architecture: 0.072 +PID: 0.066 +vnc: 0.058 +VMM: 0.030 +peripherals: 0.027 +user-level: 0.020 +files: 0.020 +assembly: 0.014 +KVM: 0.013 +network: 0.010 +register: 0.010 +TCG: 0.006 +kernel: 0.004 +socket: 0.004 +permissions: 0.004 +hypervisor: 0.002 + +MBR/Partition table corruption/loss , probably related to virtual sata disks and backup diff --git a/results/classifier/118/virtual/1485180 b/results/classifier/118/virtual/1485180 new file mode 100644 index 00000000..a785e36c --- /dev/null +++ b/results/classifier/118/virtual/1485180 @@ -0,0 +1,56 @@ +virtual: 0.904 +graphic: 0.822 +performance: 0.779 +device: 0.725 +mistranslation: 0.701 +semantic: 0.668 +architecture: 0.638 +user-level: 0.507 +hypervisor: 0.413 +permissions: 0.357 +assembly: 0.335 +register: 0.317 +x86: 0.314 +debug: 0.297 +network: 0.267 +peripherals: 0.246 +socket: 0.241 +vnc: 0.238 +ppc: 0.223 +TCG: 0.220 +i386: 0.220 +boot: 0.215 +files: 0.214 +PID: 0.208 +arm: 0.165 +risc-v: 0.162 +kernel: 0.098 +VMM: 0.050 +KVM: 0.038 + +Ctrl Alt G -- Multiple Virtual Machines + +I'm using Fedora 22. + +Firstly, what works: +A single VM instance, running Windows. Although, I am keeping this (GTK) window focused. + +What really fails: +If I have two running VM's, WIndows XP and Windows Vista: +1. I press Ctrl-Alt-G to get the focus. +2. That works first time. +3. Then I press Ctrl-Alt-G again. +4. Then Alt-Tab to the other machine (switching from XP to Vista, or back.) +5. Then press Ctrl-Alt-G to gain focus: +- Problem is that now the Ctrl-Alt-G, although showing in the title bar, only grabs the mouse, but NOT the keyboard. That is to say, whilst in Ctrl-Alt-G mode the second time, pressing Alt-Tab jumps back to the other VM! + +Pressing Alt-F4 quits!!!!!!!!!!!!! Regardless of whether Ctrl-Alt-G mode or not! +But only when running two VM's. + +Thanks +Misha + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU (version 3.0)? Which window manager were you using here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1486768 b/results/classifier/118/virtual/1486768 new file mode 100644 index 00000000..a062c8e6 --- /dev/null +++ b/results/classifier/118/virtual/1486768 @@ -0,0 +1,54 @@ +virtual: 0.843 +graphic: 0.817 +peripherals: 0.792 +mistranslation: 0.788 +device: 0.783 +performance: 0.760 +hypervisor: 0.738 +ppc: 0.684 +files: 0.683 +PID: 0.676 +socket: 0.672 +vnc: 0.663 +network: 0.658 +kernel: 0.627 +semantic: 0.615 +user-level: 0.596 +debug: 0.586 +arm: 0.572 +architecture: 0.572 +register: 0.532 +x86: 0.475 +risc-v: 0.466 +assembly: 0.451 +VMM: 0.400 +permissions: 0.395 +boot: 0.382 +TCG: 0.280 +KVM: 0.184 +i386: 0.170 + +BlackMagic USB3 video capture returns only blank frames in Windows (xHCI issue) + +Hi, + +I've got an Intensity Shuttle USB3; it's a HDMI video capture card. It doesn't have any Linux drivers, so I'm trying to get it to work in a Windows 10 guest inside QEMU. I'm running latest git as of today (2015-08-20). I use this command line: + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -device nec-usb-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x1edb,productid=0xbd3b -usbdevice tablet + +(I will add that the seemingly logical “host:1edb:bd3b,bus=xhci.0” did _not_ add the device at all. I don't know why, probably some parser issue?) + +The card is properly detected, and the driver thinks everything is fine, running on the virtualized USB3 host and all. Looking at usbmon, there's lots of isochronous frames during capture, and they reach the host (looking at USBpcap on the Windows 10 side). However, the driver refuses to capture any video—all frames become black in all applications I try (well, Media Express seems to hardly store any frames at all in the .avi). However, audio is captured without a hitch. Curiously enough, no dropped frames are reported. There's no sign of CPU shortage; both host and guest seem to be happy around 20% of one core. + +I am fairly certain this is an issue with the xHCI driver in QEMU, because if I give it the entire USB controller via VT-d, it works flawlessly, with video and all. For reference, here's the associated command line I use for that (after I've unbound it from the Linux system): + +sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 -acpitable file=/sys/firmware/acpi/tables/MSDM -drive file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0 -monitor stdio -usbdevice tablet -device pci-assign,host=00:14.0 + +I can get USB pcap logs from both sides if you want, but they are huge (gigabytes) since the data rate is so high. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I haven't tried this in a long time, and I already managed to do what I wanted to do (which was to write a free Linux driver :-) ). I guess you can close this; not because I believe it's fixed, but because it's not that important to me anymore. + +OK, thanks for your reply ... so I'm closing this ticket now + diff --git a/results/classifier/118/virtual/1490886 b/results/classifier/118/virtual/1490886 new file mode 100644 index 00000000..5091f0c4 --- /dev/null +++ b/results/classifier/118/virtual/1490886 @@ -0,0 +1,81 @@ +virtual: 0.825 +PID: 0.799 +peripherals: 0.785 +network: 0.772 +ppc: 0.751 +kernel: 0.708 +device: 0.688 +graphic: 0.682 +socket: 0.679 +arm: 0.659 +hypervisor: 0.653 +files: 0.651 +performance: 0.596 +debug: 0.596 +boot: 0.568 +architecture: 0.564 +register: 0.562 +vnc: 0.548 +KVM: 0.539 +permissions: 0.529 +TCG: 0.522 +risc-v: 0.507 +i386: 0.494 +VMM: 0.489 +semantic: 0.435 +user-level: 0.420 +mistranslation: 0.340 +x86: 0.276 +assembly: 0.247 + +spice-qemu-char.c Assert + +spice-qemu-char.c:173: spice_chr_add_watch: Assertion `cond == G_IO_OUT' failed. +I trace the code virtio-console.c: +ret = qemu_chr_fe_write(vcon->chr, buf, len); + trace_virtio_console_flush_buf(port->id, len, ret); + + if (ret < len) { + VirtIOSerialPortClass *k = VIRTIO_SERIAL_PORT_GET_CLASS(port); + + /* + * Ideally we'd get a better error code than just -1, but + * that's what the chardev interface gives us right now. If + * we had a finer-grained message, like -EPIPE, we could close + * this connection. + */ + if (ret < 0) + ret = 0; + if (!k->is_console) { + virtio_serial_throttle_port(port, true); + if (!vcon->watch) { + vcon->watch = qemu_chr_fe_add_watch(vcon->chr, + G_IO_OUT|G_IO_HUP, + chr_write_unblocked, vcon); + } + } + } +and spice-qemu-char.c in function:spice_chr_add_watch +assert(cond == G_IO_OUT); +so run in this code,will trigger this assert. + +My qemu version is 2.3.0 and spice-server version is 0.12.5 + +called param is G_IO_OUT|G_IO_HUP,but assert (cond == G_IO_OUT) + +I think this is fixed by: + +commit f7a8beb5e6a13dc924895244777d9ef08b23b367 +Author: Marc-André Lureau <email address hidden> +Date: Thu May 28 15:04:58 2015 +0200 + + spice: fix spice_chr_add_watch() pre-condition + + Since e02bc6de30c44fd668dc0d6e1cd1804f2eed3ed3, add_watch() is called + with G_IO_HUP. Even if spice-qemu-char ignores this flag, the + precondition must be changed. + + https://bugzilla.redhat.com/show_bug.cgi?id=1128992 + +Which is in 2.4.0 + diff --git a/results/classifier/118/virtual/1574246 b/results/classifier/118/virtual/1574246 new file mode 100644 index 00000000..e587fccb --- /dev/null +++ b/results/classifier/118/virtual/1574246 @@ -0,0 +1,110 @@ +virtual: 0.854 +hypervisor: 0.837 +KVM: 0.830 +debug: 0.825 +ppc: 0.821 +TCG: 0.814 +semantic: 0.804 +VMM: 0.794 +user-level: 0.793 +vnc: 0.783 +graphic: 0.781 +register: 0.778 +socket: 0.768 +peripherals: 0.765 +device: 0.764 +performance: 0.763 +arm: 0.759 +x86: 0.753 +permissions: 0.737 +PID: 0.737 +risc-v: 0.734 +boot: 0.725 +assembly: 0.718 +architecture: 0.717 +files: 0.715 +network: 0.698 +kernel: 0.684 +mistranslation: 0.635 +i386: 0.558 + +Drunken keyboard in go32v2 programs + +QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a while, though. + +Steps to reproduce: + +# Create a VM image, install DOS in it (doesn't matter which) and launch it. +# Launch a "bare DOS" DPMI host (not an operating system) in it; I tested with CWSDPMI and HDPMI32. +# Run a go32v2 program which reads keyboard input (say, the Lua interpreter: <http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/devel/lua.zip>; the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem unaffected). +# Quickly type in something random (e.g. alternate between hitting "p" and "q"), then optionally move the cursor left and right. +# Observe how some keystrokes are missed, and some are caught twice. + +The issue does NOT arise: +* on bare metal DOS, +* in VirtualBox, +* in Bochs with stock Plex86 BIOS, +* in Bochs with SeaBIOS, +* in DOSEMU, +* in DOSBox, +* in QEMU when the DPMI host is Windows 3.11/9x +so at this point I'm reasonably sure that it's the fault of either QEMU or SeaBIOS, and probably the former. The issue arises regardless of whether KVM is enabled. + +I compiled the latest git snapshot (tag: v2.6.0-rc4, calling itself 2.5.94; with GTK frontend) and could only half-reproduce the bug; keys do not longer "jam", but arrow keys are still captured twice. I woudn't make much of that difference; this bug seems very timing-sensitive. It could be that the GTK frontend adds sufficient latency to the interface to avoid triggering it. + +I enabled some debugging switches and recompiled both QEMU and the latest git snapshot of SeaBIOS (1.9.0-127; commit c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a). This is what I got when running programs affected by this bug: + +(key press) +[qemu ] ps2_queue(0xe0) +[qemu ] ps2_queue(0x4d) +(IRQ1) +[qemu ] KBD: kbd: read data=0xe0 ← (***) +[seabios] handle_09 +[qemu ] KBD: kbd: read status=0x1d +[qemu ] KBD: kbd: read data=0x4d +[seabios] i8042_command cmd=ae +[seabios] i8042_wait_write +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: write cmd=0xae +(IRQ1) +[qemu ] KBD: kbd: read data=0x4d ← (***) +[seabios] handle_09 +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: read data=0x4d +[seabios] i8042_command cmd=ae +[seabios] i8042_wait_write +[qemu ] KBD: kbd: read status=0x1c +[qemu ] KBD: kbd: write cmd=0xae + +Reads marked (***) do not appear when running unaffected programs. So it appears something is making reads from the keyboard controller before SeaBIOS has a chance to put scancodes in the ring buffer. And indeed: DJGPP libc installs a custom IRQ1 handler which does it to detect whether it should raise SIGINT in response to Ctrl+C; it can be found in the file src/libc/go32/exceptn.S in the djcrx package[1]. Free Pascal incorporates this handler into its RTL with almost no changes; it's found in rtl/go32v2/exceptn.as[2]. I also noticed I can reproduce this bug with Borland Pascal 7; lo and behold, the Turbo Vision library does something similar. + +SeaBIOS gets extra confused when I send some mouse events to QEMU (grab the mouse, move it around, ungrab); it reacts with a "ps2 keyboard irq but found mouse data?!" message and refuses to put keys in the ring buffer until the queue of mouse events becomes empty. + +That's the culprit, I think. It also explains why the bug doesn't appear under Windows; because port 0x60 reads from DPMI are simulated, they don't correspond to actual port 0x60 reads in the guest. I don't know what the fix ought be; documentation about the i8042 that I found is unclear about what real hardware does in this case. + +If I'm reading the code correctly, DOSEMU[3] (also the DOSEMU2 fork[4]), DOSBox[5], Bochs[6] and VirtualBox[7] keep one value to be read from 0x60 at until the next interrupt, avoiding the issue. + +[1] <http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/go32/exceptn.S?rev=1.7>; function ___djgpp_kbd_hdlr +[2] <http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/exceptn.as?revision=8210&view=co>; function ___djgpp_kbd_hdlr +[3] <https://sourceforge.net/p/dosemu/code/ci/8897222f8830e0bd2769935f611a0e5c3271bcb9/tree/src/plugin/kbd_unicode/serv_8042.c> +[4] <https://github.com/stsp/dosemu2/blob/69419c7a5430f0109f9df45b179d9b223b075550/src/plugin/kbd_unicode/serv_8042.c> +[5] <https://sourceforge.net/p/dosbox/code-0/3961/tree/dosbox/trunk/src/ints/bios_keyboard.cpp> +[6] <https://sourceforge.net/p/bochs/code/12853/tree/trunk/bochs/iodev/keyboard.cc> +[7] <https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Input/DevPS2.cpp?rev=60404> + + +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 please 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/118/virtual/1575607 b/results/classifier/118/virtual/1575607 new file mode 100644 index 00000000..69f7aecf --- /dev/null +++ b/results/classifier/118/virtual/1575607 @@ -0,0 +1,89 @@ +virtual: 0.927 +device: 0.724 +hypervisor: 0.657 +graphic: 0.611 +KVM: 0.586 +performance: 0.584 +mistranslation: 0.508 +kernel: 0.506 +peripherals: 0.495 +user-level: 0.493 +register: 0.485 +vnc: 0.452 +architecture: 0.437 +ppc: 0.410 +semantic: 0.402 +PID: 0.392 +boot: 0.363 +debug: 0.339 +permissions: 0.315 +socket: 0.310 +assembly: 0.284 +network: 0.284 +i386: 0.271 +VMM: 0.252 +x86: 0.242 +arm: 0.175 +risc-v: 0.169 +files: 0.160 +TCG: 0.087 + + vm startup failed, qemu returned "kvm run failed Bad address" + + create a virtual machine and start by libvirt. vm startup failed, qemu returned "kvm run failed Bad address" + the error log is : + +error: kvm run failed Bad address + +EAX=7ffc0000 EBX=7ffbffd0 ECX=fffffff0 EDX=0000002c + +ESI=00006f5c EDI=7ffbffd0 EBP=7ffc0000 ESP=00006f34 + +EIP=000dec7b EFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 + +ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] + +SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] + +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT + +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy + +GDT= 000f6a80 00000037 + +IDT= 000f6abe 00000000 + +CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 + +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 + +DR6=00000000ffff0ff0 DR7=0000000000000400 + +EFER=0000000000000000 + +Code=c3 29 d3 21 cb 39 c3 77 27 3b 5e 0c 72 22 85 ff 75 02 89 df <89> 5f 08 01 da 89 57 0c 89 47 10 89 5e 10 8b 56 04 89 f8 e8 8c fc ff ff 89 d8 eb 06 8b 36 + + we add numa in the vm, the numatune info is: + <numatune> + + <memory mode='strict' placement='auto'/> + + </numatune> + + the version of qemu is 2.5.0. + +have resolved it？ + + +Can you still reproduce this issue with the latest version of QEMU and the latest version of the Linux kernel? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1579 b/results/classifier/118/virtual/1579 new file mode 100644 index 00000000..b72445da --- /dev/null +++ b/results/classifier/118/virtual/1579 @@ -0,0 +1,34 @@ +virtual: 0.929 +files: 0.917 +network: 0.856 +graphic: 0.853 +mistranslation: 0.829 +device: 0.751 +performance: 0.720 +hypervisor: 0.436 +user-level: 0.435 +ppc: 0.416 +boot: 0.358 +semantic: 0.349 +architecture: 0.314 +arm: 0.273 +PID: 0.231 +x86: 0.224 +i386: 0.221 +debug: 0.204 +VMM: 0.198 +peripherals: 0.187 +TCG: 0.181 +vnc: 0.180 +socket: 0.145 +register: 0.144 +risc-v: 0.092 +KVM: 0.071 +permissions: 0.065 +kernel: 0.063 +assembly: 0.007 + +Cache vdpa initialization & startup slow ioctls +Additional information: +* vring groups are cached in this patch, still not upstream [this example patch](https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg05961.html). +* hw/virtio/vhost-vdpa.c and net/vhost-vdpa.c are both files that worth exploring. diff --git a/results/classifier/118/virtual/1586613 b/results/classifier/118/virtual/1586613 new file mode 100644 index 00000000..d3833a75 --- /dev/null +++ b/results/classifier/118/virtual/1586613 @@ -0,0 +1,44 @@ +virtual: 0.954 +device: 0.952 +VMM: 0.926 +KVM: 0.926 +vnc: 0.891 +peripherals: 0.889 +performance: 0.884 +hypervisor: 0.865 +graphic: 0.843 +semantic: 0.803 +kernel: 0.793 +network: 0.782 +PID: 0.769 +ppc: 0.757 +architecture: 0.746 +permissions: 0.746 +socket: 0.730 +x86: 0.670 +i386: 0.668 +risc-v: 0.664 +arm: 0.655 +user-level: 0.635 +mistranslation: 0.613 +register: 0.592 +debug: 0.564 +files: 0.562 +TCG: 0.543 +boot: 0.466 +assembly: 0.290 + +usb-hub can not be detached when detach usbdevice VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle + diff --git a/results/classifier/118/virtual/1603779 b/results/classifier/118/virtual/1603779 new file mode 100644 index 00000000..270016f2 --- /dev/null +++ b/results/classifier/118/virtual/1603779 @@ -0,0 +1,57 @@ +virtual: 0.873 +i386: 0.809 +device: 0.697 +graphic: 0.601 +architecture: 0.426 +mistranslation: 0.332 +ppc: 0.332 +performance: 0.331 +x86: 0.322 +hypervisor: 0.300 +semantic: 0.262 +boot: 0.233 +network: 0.227 +vnc: 0.197 +VMM: 0.185 +peripherals: 0.157 +socket: 0.155 +PID: 0.148 +arm: 0.142 +permissions: 0.141 +risc-v: 0.136 +register: 0.113 +kernel: 0.100 +debug: 0.098 +TCG: 0.086 +user-level: 0.084 +files: 0.083 +assembly: 0.048 +KVM: 0.027 + +AC97 can allocate ~500MB of host RAM + +While working with qtest test cases generated via fuzzing with QEMU 2.5.0, I discovered some odd behavior for the AC97 virtual device with qemu-system-i386. If AC97_MIC_ADC_RATE is set to the value of 1, the QEMU process allocates over 500MB of additional host RAM. You probably would not normally notice this on a modern PC, except that I was using a "ulimit" command to restrict the maximum amount of virtual memory allowed for the QEMU process, so the process would crash with a SIGTRAP (signal 5) on the failed memory allocation. + +My minimized qtest code to reproduce the issue is: + +static void test_crash(void) +{ + uint64_t barsize; + dev = get_device(); + + dev_base[0] = qpci_iomap(dev, 0, &barsize); + dev_base[1] = qpci_iomap(dev, 1, &barsize); + qpci_device_enable(dev); + qpci_io_writew(dev, dev_base[0]+0x32, 0x00000001); +} + +I ran a "ulimit -sv 650000" command and then launched the tests/ac97-test binary with this crash test case included in it. I can then see the QEMU process crash on an allocation of 722538464 bytes. I can gradually increase the ulimit memory limit to ~1200000 and then no longer see the issue, hence my estimate of 500 MB of RAM allocated by the device. + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/71 + + diff --git a/results/classifier/118/virtual/1604303 b/results/classifier/118/virtual/1604303 new file mode 100644 index 00000000..c0f28674 --- /dev/null +++ b/results/classifier/118/virtual/1604303 @@ -0,0 +1,50 @@ +virtual: 0.967 +network: 0.963 +KVM: 0.959 +x86: 0.940 +device: 0.898 +graphic: 0.843 +hypervisor: 0.734 +peripherals: 0.720 +kernel: 0.708 +architecture: 0.683 +boot: 0.657 +socket: 0.650 +mistranslation: 0.633 +PID: 0.613 +vnc: 0.603 +i386: 0.573 +files: 0.564 +semantic: 0.553 +risc-v: 0.548 +ppc: 0.535 +register: 0.530 +VMM: 0.522 +performance: 0.511 +permissions: 0.489 +user-level: 0.482 +arm: 0.472 +TCG: 0.373 +debug: 0.315 +assembly: 0.185 + +Solaris on KVM/QEMU: WARNING rtls0: Failure resetting PHY + +When running Solaris (both version 10 and 11) on a QEMU/KVM virtual host, the Solaris guest displays this warning just after starting the system: +WARNING rtls0: Failure resetting PHY. + +Although the networking seems to work fine. + +I have this network device model selected for the Solaris guest: rtl8139 + +See also: +http://www.linux-kvm.org/page/Guest_Support_Status#UNIX_Family:_Solaris.2FOpenSolaris + +version: qemu-system-x86.x86_64 2:2.6.0-5.fc24 + +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/118/virtual/1607 b/results/classifier/118/virtual/1607 new file mode 100644 index 00000000..1ad30011 --- /dev/null +++ b/results/classifier/118/virtual/1607 @@ -0,0 +1,31 @@ +virtual: 0.976 +device: 0.866 +architecture: 0.857 +hypervisor: 0.651 +performance: 0.607 +arm: 0.537 +network: 0.493 +graphic: 0.464 +VMM: 0.460 +vnc: 0.373 +semantic: 0.358 +peripherals: 0.338 +i386: 0.290 +risc-v: 0.287 +debug: 0.270 +boot: 0.241 +x86: 0.240 +ppc: 0.220 +KVM: 0.203 +PID: 0.117 +permissions: 0.108 +TCG: 0.102 +mistranslation: 0.097 +socket: 0.086 +files: 0.066 +kernel: 0.063 +register: 0.024 +user-level: 0.021 +assembly: 0.003 + +QEMU calls glXMakeCurrent which is current in another thread when running VM with SDL diff --git a/results/classifier/118/virtual/161 b/results/classifier/118/virtual/161 new file mode 100644 index 00000000..c93a3aca --- /dev/null +++ b/results/classifier/118/virtual/161 @@ -0,0 +1,31 @@ +virtual: 0.959 +device: 0.863 +network: 0.733 +mistranslation: 0.599 +performance: 0.502 +kernel: 0.466 +socket: 0.422 +PID: 0.400 +files: 0.397 +arm: 0.375 +register: 0.348 +boot: 0.338 +architecture: 0.338 +vnc: 0.294 +ppc: 0.269 +semantic: 0.256 +debug: 0.242 +permissions: 0.237 +peripherals: 0.216 +i386: 0.213 +x86: 0.211 +graphic: 0.199 +hypervisor: 0.185 +KVM: 0.177 +risc-v: 0.142 +TCG: 0.137 +VMM: 0.129 +user-level: 0.056 +assembly: 0.008 + +virtio-scsi gives improper discard sysfs entries diff --git a/results/classifier/118/virtual/1615079 b/results/classifier/118/virtual/1615079 new file mode 100644 index 00000000..1cff6617 --- /dev/null +++ b/results/classifier/118/virtual/1615079 @@ -0,0 +1,46 @@ +virtual: 0.942 +mistranslation: 0.934 +x86: 0.833 +device: 0.788 +graphic: 0.768 +vnc: 0.418 +performance: 0.416 +peripherals: 0.404 +semantic: 0.395 +i386: 0.316 +risc-v: 0.275 +PID: 0.239 +network: 0.232 +ppc: 0.224 +architecture: 0.222 +permissions: 0.204 +TCG: 0.196 +register: 0.163 +arm: 0.148 +debug: 0.135 +boot: 0.126 +VMM: 0.121 +socket: 0.114 +user-level: 0.103 +kernel: 0.091 +KVM: 0.047 +hypervisor: 0.024 +files: 0.013 +assembly: 0.007 + +GTK+ UI virtual consoles scrolling broken + +"In the virtual consoles, you can use Ctrl-Up, Ctrl-Down, Ctrl-PageUp and Ctrl-PageDown to move in the back log." + +the scrolling bar does not appear either + +these are broken on gtk2 and gtk3 + +VTE is required for this to work? + +if yes, the configure script should have info about the dependency + +Are you talking about serial console? Or graphical (VGA) console? Which QEMU target (x86? ... and which machine?)? How did you start QEMU? ... this bug report clearly lacks some more information... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1640 b/results/classifier/118/virtual/1640 new file mode 100644 index 00000000..a38171f0 --- /dev/null +++ b/results/classifier/118/virtual/1640 @@ -0,0 +1,55 @@ +arm: 0.955 +virtual: 0.943 +architecture: 0.942 +graphic: 0.924 +device: 0.922 +kernel: 0.808 +PID: 0.804 +network: 0.803 +vnc: 0.793 +performance: 0.793 +VMM: 0.786 +socket: 0.771 +files: 0.744 +hypervisor: 0.737 +peripherals: 0.712 +boot: 0.704 +ppc: 0.692 +register: 0.632 +risc-v: 0.616 +permissions: 0.589 +debug: 0.572 +TCG: 0.553 +user-level: 0.441 +semantic: 0.435 +mistranslation: 0.420 +x86: 0.225 +assembly: 0.139 +i386: 0.139 +KVM: 0.100 + +aarch64: usb_mtp_get_data: Assertion `(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed +Description of problem: +When attempting to write to an MTP device in QEMU 8.0.0 on arm64, QEMU will crash at runtime with the following error: +`qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.` + +This was observed in Nixpkgs where we use QEMU to provide automated testing of MTP devices for GVFS and jmtpfs, the full log for that test run that crashes due to this QEMU regression on arm64 is available here https://hydra.nixos.org/build/218858556/nixlog/1 +Steps to reproduce: +1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0 +2. Mount the MTP device using something like: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + dd if=/dev/urandom of=./mtpDevice/file + ``` +4. Observe that QEMU will crash when trying to write to the device, like this: + ``` + client # 10+0 records in + client # 10+0 records out + client # 10485760 bytes (10 MB, 10 MiB) copied, 0.0318363 s, 329 MB/s + client # qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.error + ``` +Additional information: + diff --git a/results/classifier/118/virtual/1641 b/results/classifier/118/virtual/1641 new file mode 100644 index 00000000..eb64206a --- /dev/null +++ b/results/classifier/118/virtual/1641 @@ -0,0 +1,54 @@ +virtual: 0.916 +x86: 0.875 +KVM: 0.831 +i386: 0.825 +device: 0.773 +graphic: 0.766 +architecture: 0.588 +vnc: 0.570 +semantic: 0.555 +PID: 0.497 +hypervisor: 0.481 +ppc: 0.466 +mistranslation: 0.465 +kernel: 0.457 +performance: 0.452 +VMM: 0.425 +debug: 0.417 +risc-v: 0.405 +TCG: 0.384 +network: 0.383 +peripherals: 0.358 +permissions: 0.355 +socket: 0.348 +register: 0.290 +boot: 0.241 +arm: 0.204 +files: 0.190 +assembly: 0.185 +user-level: 0.167 + +[abrt] qemu-system-x86-core: do_patch_instruction(): qemu-system-x86_64 killed by SIGABRT +Description of problem: +Copied from downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2195952 + +Description of problem: +Virtualizing a Windows XP system which tried to reboot. + +Version-Release number of selected component: +qemu-system-x86-core-2:7.2.1-1.fc38 + +Additional info: +reason: qemu-system-x86_64 killed by SIGABRT +backtrace_rating: 4 +crash_function: do_patch_instruction +comment: Virtualizing a Windows XP system which tried to reboot. + +Truncated backtrace: +Thread no. 1 (6 frames) + #4 do_patch_instruction at ../hw/i386/kvmvapic.c:439 + #5 process_queued_cpu_work at ../cpus-common.c:347 + #6 qemu_wait_io_event at ../softmmu/cpus.c:435 + #7 kvm_vcpu_thread_fn at ../accel/kvm/kvm-accel-ops.c:56 + #8 qemu_thread_start at ../util/qemu-thread-posix.c:505 + #10 clone3 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 diff --git a/results/classifier/118/virtual/1669 b/results/classifier/118/virtual/1669 new file mode 100644 index 00000000..b7887a9e --- /dev/null +++ b/results/classifier/118/virtual/1669 @@ -0,0 +1,41 @@ +virtual: 0.986 +architecture: 0.982 +arm: 0.976 +device: 0.835 +vnc: 0.818 +peripherals: 0.763 +VMM: 0.754 +debug: 0.633 +ppc: 0.619 +graphic: 0.550 +PID: 0.525 +boot: 0.523 +semantic: 0.517 +socket: 0.497 +risc-v: 0.482 +permissions: 0.479 +register: 0.434 +hypervisor: 0.393 +TCG: 0.361 +kernel: 0.328 +network: 0.311 +files: 0.299 +KVM: 0.289 +performance: 0.231 +mistranslation: 0.228 +user-level: 0.192 +i386: 0.162 +assembly: 0.051 +x86: 0.005 + +In the ARM environment, using pci-ohci with specific OS (CentOS-8-aarch64-1905-dvd1.iso) to start a virtual machine, will cause the memory leak +Description of problem: + +Steps to reproduce: +1.Using the pci-ohci as the USB controller to start the VM; + +2.install the OS using the CentOS-8-aarch64-1905-dvd1.iso ; + +3.The QEMU process is taking up more and more memory, which looks like Memory leak +Additional information: + diff --git a/results/classifier/118/virtual/1675 b/results/classifier/118/virtual/1675 new file mode 100644 index 00000000..0de1ff3c --- /dev/null +++ b/results/classifier/118/virtual/1675 @@ -0,0 +1,31 @@ +virtual: 0.953 +kernel: 0.896 +device: 0.839 +performance: 0.826 +network: 0.745 +graphic: 0.743 +architecture: 0.736 +VMM: 0.658 +register: 0.630 +KVM: 0.616 +risc-v: 0.569 +boot: 0.543 +hypervisor: 0.540 +debug: 0.527 +arm: 0.510 +vnc: 0.505 +PID: 0.499 +socket: 0.499 +TCG: 0.477 +permissions: 0.468 +peripherals: 0.413 +ppc: 0.405 +files: 0.209 +mistranslation: 0.208 +semantic: 0.193 +x86: 0.144 +user-level: 0.065 +i386: 0.029 +assembly: 0.013 + +virtual machines still randomly crashing on kernel 6.1.30 diff --git a/results/classifier/118/virtual/1677492 b/results/classifier/118/virtual/1677492 new file mode 100644 index 00000000..f3dc1178 --- /dev/null +++ b/results/classifier/118/virtual/1677492 @@ -0,0 +1,79 @@ +virtual: 0.931 +semantic: 0.781 +hypervisor: 0.773 +PID: 0.715 +device: 0.713 +performance: 0.579 +graphic: 0.560 +ppc: 0.557 +mistranslation: 0.500 +user-level: 0.457 +vnc: 0.455 +kernel: 0.443 +register: 0.399 +network: 0.367 +peripherals: 0.365 +x86: 0.346 +arm: 0.317 +architecture: 0.310 +risc-v: 0.307 +debug: 0.304 +i386: 0.280 +boot: 0.273 +TCG: 0.272 +permissions: 0.243 +VMM: 0.206 +files: 0.179 +socket: 0.147 +assembly: 0.136 +KVM: 0.054 + +block_set_io_throttle complaints Need exactly one of 'device' and 'id' + +All of sudden, after a qemu update, block_set_io_throttle does not work anymore. + +Full command to QEMU monitor -- + +(qemu) block_set_io_throttle db 0 0 0 0 0 0 +Need exactly one of 'device' and 'id' + +The help text still point to the same old syntax, which no longer works. + +On 03/30/2017 02:14 AM, dE wrote: +> Public bug reported: +> +> All of sudden, after a qemu update, block_set_io_throttle does not work +> anymore. +> +> Full command to QEMU monitor -- +> +> (qemu) block_set_io_throttle db 0 0 0 0 0 0 +> Need exactly one of 'device' and 'id' +> +> The help text still point to the same old syntax, which no longer works. + +Broken in 2.8, fixed here (will be in 2.9): + +commit 3f35c3b166c18043596768448e5d91b5d52f8353 +Author: Eric Blake <email address hidden> +Date: Fri Jan 20 17:03:59 2017 -0600 + + hmp: fix block_set_io_throttle + + Commit 7a9877a made the 'device' parameter to BlockIOThrottle + optional, favoring 'id' instead. But it forgot to update the + HMP usage to set has_device, which makes all attempts to change + throttling via HMP fail with "Need exactly one of 'device' and 'id'" + + CC: <email address hidden> + Signed-off-by: Eric Blake <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Stefan Hajnoczi <email address hidden> + Signed-off-by: Dr. David Alan Gilbert <email address hidden> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + diff --git a/results/classifier/118/virtual/1689367 b/results/classifier/118/virtual/1689367 new file mode 100644 index 00000000..bcdaaa5d --- /dev/null +++ b/results/classifier/118/virtual/1689367 @@ -0,0 +1,137 @@ +virtual: 0.842 +permissions: 0.839 +risc-v: 0.838 +x86: 0.825 +architecture: 0.824 +user-level: 0.820 +ppc: 0.818 +graphic: 0.818 +performance: 0.816 +TCG: 0.814 +device: 0.811 +hypervisor: 0.805 +semantic: 0.804 +vnc: 0.792 +peripherals: 0.792 +KVM: 0.789 +files: 0.767 +arm: 0.762 +register: 0.762 +i386: 0.749 +network: 0.747 +assembly: 0.741 +PID: 0.739 +VMM: 0.726 +socket: 0.710 +mistranslation: 0.709 +debug: 0.702 +kernel: 0.666 +boot: 0.572 + +In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ? + +On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via + + /usr/sbin/qemu-binfmt-conf.sh + +from + + qemu-linux-user-2.9.0-374.1.x86_64 + +on the host, inside the chroot any compile activity is laced with repetitions of + + qemu: Unsupported syscall: 384 + +messages. + +This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim. These messages appear to be non-fatal, with no particular effect at all; at least not so far ... + +From a chat in #IRC, + + [10:05] davidgiluk clever/pgnd: I see it as getrandom + [10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html sort it on the ARM table and you can easily see it + [10:05] clever arch/arm/tools/syscall.tbl:384 common getrandom sys_getrandom + [10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom + [10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational? + [10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point + +arm32 syscall 384 is indeed getrandom, but QEMU implemented this in commit f894efd19917321 as of Feb 2016, which should be in 2.6 or later. I've just checked and the LTP test cases for getrandom all pass with qemu-arm-user and do invoke the getrandom syscall and don't provoke the warning from QEMU. + +Can you check that the qemu-arm-static binary inside the chroot is really 2.9 and not an older version? + + +The statically linked qemu files in chroot are cp'd from the host env + + file $(which qemu-arm) $(which qemu-arm-binfmt) + /usr/bin/qemu-arm: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.0.0, BuildID[sha1]=a6c50ab9b8f1845daab2f41d85936712aabafd89, not stripped + /usr/bin/qemu-arm-binfmt: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.0.0, BuildID[sha1]=ff78e29b45699433557fab5396b79f07211fd3d5, not stripped + +where + + rpm -q --whatprovides $(which qemu-arm) $(which qemu-arm-binfmt) + qemu-linux-user-2.10.1-412.1.x86_64 + qemu-linux-user-2.10.1-412.1.x86_64 + +pkg + + qemu-linux-user-2.10.1-412.1.x86_64 + +is sourced/installed from the openSUSE 'Virtualization' repo, + + https://build.opensuse.org/package/show/Virtualization/qemu-linux-user + +and, + + rpm -q --changelog qemu-linux-user-2.10.1-412.1.x86_64 | head -n 20 + * Thu Oct 19 2017 <email address hidden> + - Patch queue updated from git://github.com/openSUSE/qemu.git opensuse-2.10 + * Patches added: + 0040-io-monitor-encoutput-buffer-size-fr.patch + 0041-cirrus-fix-oob-access-in-mode4and5-.patch + 0042-9pfs-use-g_malloc0-to-allocate-spac.patch + + * Tue Oct 03 2017 <email address hidden> + - Update to v2.10.1 a stable, bug-fix-only release + * Patches dropped (upstream): + 0034-slirp-fix-clearing-ifq_so-from-pend.patch + 0035-s390-ccw-Fix-alignment-for-CCW1.patch + 0038-s390x-ais-for-2.10-stable-disable-a.patch + 0039-s390x-cpumodel-remove-ais-from-z14-.patch + * Patches renamed: + 0036-target-i386-cpu-Add-new-EPYC-CPU-mo.patch + - > 0034-target-i386-cpu-Add-new-EPYC-CPU-mo.patch + 0037-chardev-baum-fix-baum-that-releases.patch + - > 0035-chardev-baum-fix-baum-that-releases.patch + 0040-io-fix-temp-directory-used-by-test-.patch + + +Can you just run /usr/bin/qemu-arm-static --version in the chroot, please ? (or whatever suse calls its statically linked binary). + + +The other interesting question is what version of the (host) kernel headers the QEMU binary was built against -- if that's earlier than 3.17 then the headers won't define __NR_getrandom for the host system and we won't implement the syscall. + + +> Can you just run /usr/bin/qemu-arm-static --version in the chroot, +please ? (or whatever suse calls its statically linked binary). + +Yep, as soon as I'm sitting back in front of the machine with the chroot on it. Bit later ... + +> The other interesting question is what version of the (host) kernel headers the QEMU binary was built against -- if that's earlier than 3.17 then the headers won't define __NR_getrandom for the host system and we won't implement the syscall. + +The qemu build uses headers from a repo which tracks Kernel/Stable's regular releases. It _currently_ holds kernel 4.13.10. + + +> run /usr/bin/qemu-arm-static --version in the chroot + +:/# /usr/bin/qemu-arm --version + qemu-arm version 2.10.1 + Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +In that case I'm confused about what is happening here -- the emulation of getrandom() for arm guests on x86-64 targets works for me. The only other thing I can suggest is that you try building an upstream QEMU -- perhaps there's something odd going on with the SUSE patches or build environment. + + +[Expired for QEMU because there has been no activity for 60 days.] + +I am able to reproduce using docker and qemu-arm version 1.5.93 + diff --git a/results/classifier/118/virtual/1701 b/results/classifier/118/virtual/1701 new file mode 100644 index 00000000..b9db292d --- /dev/null +++ b/results/classifier/118/virtual/1701 @@ -0,0 +1,35 @@ +virtual: 0.998 +graphic: 0.948 +boot: 0.910 +device: 0.910 +semantic: 0.800 +vnc: 0.777 +mistranslation: 0.740 +VMM: 0.667 +performance: 0.436 +debug: 0.432 +architecture: 0.372 +i386: 0.348 +KVM: 0.330 +x86: 0.315 +TCG: 0.299 +register: 0.277 +files: 0.271 +network: 0.258 +risc-v: 0.246 +hypervisor: 0.209 +PID: 0.188 +user-level: 0.178 +socket: 0.119 +arm: 0.116 +assembly: 0.104 +ppc: 0.095 +kernel: 0.088 +permissions: 0.075 +peripherals: 0.028 + +-boot menu=on that vm is hangs +Description of problem: +virtual machine hangs, stop at press ESC for boot menu. +Additional information: + diff --git a/results/classifier/118/virtual/1707297 b/results/classifier/118/virtual/1707297 new file mode 100644 index 00000000..83aa0b34 --- /dev/null +++ b/results/classifier/118/virtual/1707297 @@ -0,0 +1,86 @@ +virtual: 0.851 +performance: 0.824 +user-level: 0.712 +hypervisor: 0.689 +architecture: 0.615 +device: 0.608 +arm: 0.603 +semantic: 0.600 +KVM: 0.591 +ppc: 0.579 +socket: 0.570 +network: 0.569 +kernel: 0.566 +permissions: 0.554 +mistranslation: 0.553 +x86: 0.551 +peripherals: 0.546 +graphic: 0.542 +PID: 0.532 +debug: 0.475 +register: 0.447 +vnc: 0.406 +VMM: 0.400 +boot: 0.399 +risc-v: 0.389 +assembly: 0.322 +TCG: 0.308 +files: 0.236 +i386: 0.229 + +qemu became more picky parsing -m option + +With qemu-kvm-2.9.0-3.fc26.x86_64 I am no longer to specify the memory size using something like "-m 1.00000GiB" but with qemu-kvm-2.7.1-7.fc25.x86_64 I could without any problem. I now get an error message like: + +qemu-system-x86_64: -m 1.00000GiB: Parameter 'size' expects a non-negative number below 2^64 +Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta- +and exabytes, respectively. + + +Is this expected or a regression? + +On 07/31/2017 03:34 AM, Markus Armbruster wrote: +> John Florian <email address hidden> writes: +> +>> Public bug reported: +>> +>> With qemu-kvm-2.9.0-3.fc26.x86_64 I am no longer to specify the memory +>> size using something like "-m 1.00000GiB" but with qemu- +>> kvm-2.7.1-7.fc25.x86_64 I could without any problem. I now get an error +>> message like: +>> +>> qemu-system-x86_64: -m 1.00000GiB: Parameter 'size' expects a non-negative number below 2^64 +>> Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta- +>> and exabytes, respectively. +>> +>> +>> Is this expected or a regression? +> +> We recognize suffix "G". Before commit 75cdcd1 (v2.9.0), trailing +> garbage after a recognized suffix was silently ignored. "1.0G", +> "1.0GiB", "1.0Garbage-trucks-of-RAM" were all the same to QEMU. No +> more. +> +> All clear? + +That said, virsh from libvirt manages to recognize 'G' and 'GiB' as +synonyms (powers of 2), as well as 'GB' (powers of 10); we could justify +patching qemu's parser to accept more valid suffixes, particularly since +'GiB' is a typical suffix that has seen use (in spite of it not being +documented). + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +Not sure why I can only see Markus' comment here as part of Eric's but anyway... the behavior change *is* expected. + +Can qemu behave more like virsh then? That would be ideal IMHO. I prefer to specify my RAM in powers of 2 and disk in powers of 10 so that when I test virtually using qemu I more closely match the exact constraints of real hardware. For the embedded work I do fitting in tight confines, it can make a significant difference. + +(I actually to this with a wrapper I have around qemu, which is why you see a floating point value for GiB in my example above. My wrapper behaves like virsh and takes any *B, *iB format and regurgitates it into something qemu accepts.) + +Looks like nobody cared to implement this within 3 years ... and IMHO it's maybe even better to not overload the CLI syntax too much ... so I'm closing this ticket now. + diff --git a/results/classifier/118/virtual/1707587 b/results/classifier/118/virtual/1707587 new file mode 100644 index 00000000..42f95722 --- /dev/null +++ b/results/classifier/118/virtual/1707587 @@ -0,0 +1,44 @@ +virtual: 0.922 +device: 0.901 +performance: 0.888 +graphic: 0.861 +network: 0.831 +architecture: 0.754 +mistranslation: 0.682 +hypervisor: 0.681 +semantic: 0.653 +socket: 0.652 +permissions: 0.643 +vnc: 0.632 +VMM: 0.630 +peripherals: 0.617 +register: 0.612 +ppc: 0.603 +x86: 0.588 +PID: 0.577 +boot: 0.555 +files: 0.546 +risc-v: 0.531 +i386: 0.513 +debug: 0.510 +user-level: 0.505 +arm: 0.468 +TCG: 0.462 +assembly: 0.401 +KVM: 0.378 +kernel: 0.376 + +Read certificate from USB key failed + +QEMU release version: qemu-2.9.0 +VM operation system: win7 32bit + +I have an usb key which can be redirected and recognized in VM. However, it is failed to get the certificate when using the official application for this usb key. What's more, the whole app is stalled untill this usb key detached from VM. + +As I researched, this usb key uses interrupt transfers when application trying to read certificate from it. Problem is that some certificate data abandoned by "usbredir_stop_interrupt_receiving" and "usbredir_stop_ep". The two functions use "usbredir_free_bufpq" to clear the buffered usb packets, even the certificate remain in the bufpq. + +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". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1715573 b/results/classifier/118/virtual/1715573 new file mode 100644 index 00000000..2d41d777 --- /dev/null +++ b/results/classifier/118/virtual/1715573 @@ -0,0 +1,44 @@ +virtual: 0.897 +performance: 0.873 +graphic: 0.843 +mistranslation: 0.821 +hypervisor: 0.815 +x86: 0.809 +device: 0.743 +semantic: 0.710 +architecture: 0.635 +boot: 0.568 +vnc: 0.421 +user-level: 0.393 +arm: 0.368 +network: 0.311 +permissions: 0.301 +PID: 0.300 +peripherals: 0.268 +debug: 0.267 +VMM: 0.263 +socket: 0.262 +ppc: 0.254 +register: 0.253 +risc-v: 0.245 +files: 0.201 +kernel: 0.178 +TCG: 0.160 +assembly: 0.130 +i386: 0.070 +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/118/virtual/1716 b/results/classifier/118/virtual/1716 new file mode 100644 index 00000000..88523fc0 --- /dev/null +++ b/results/classifier/118/virtual/1716 @@ -0,0 +1,39 @@ +virtual: 0.996 +i386: 0.979 +performance: 0.976 +architecture: 0.970 +graphic: 0.967 +ppc: 0.944 +hypervisor: 0.922 +PID: 0.910 +semantic: 0.907 +x86: 0.904 +peripherals: 0.869 +user-level: 0.857 +files: 0.856 +debug: 0.844 +VMM: 0.840 +permissions: 0.828 +vnc: 0.822 +network: 0.812 +register: 0.808 +device: 0.798 +mistranslation: 0.782 +kernel: 0.741 +assembly: 0.734 +risc-v: 0.729 +socket: 0.704 +TCG: 0.698 +arm: 0.693 +KVM: 0.628 +boot: 0.586 + +Cannot raise low memory using max-ram-below-4g on current i440fx +Description of problem: +We have a use case where we have a virtual machine with at least 8 Gb of RAM and at least 3.5Gb of it in the low memory. However, I could not achieve it this far with QEMU, only on the deprecated i440fx 1.7 architecture. The size of lowmem is never greater than 3 Gb, except if I assign memory to the vm between 3 Gb and 3.5 Gb. If I go even a slightly above 3.5 Gb then it falls back to 3 Gb. + +I did some research and I found the source file hw/i386/pc_piix.c. There is a piece of code which is responsible for setting the low memory at the beginning of function pc_init1(). It seems that the problem lies in the property `gigabyt_align` of all i440fx architectures newer than 1.7. The comment which explains this piece of code does not mention at all that raising lowmem does not work on newer pc architectures. According to the comments setting the size of lowmem based of the `max-ram-below-4g` option should happen before the gigabyte alignment, not after it. Anyway, it does not make sense because with default being 3 Gb gigabyte alignment always means 3 Gb so raising is not possible at all. The last example of the comment clearly states that raising should be possible using the newest `pc` architecture: `qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)`. However, according to the code below the comment this is not the way it works because gigabyte alignment happens after. + +To solve the problem there are two possibilities: if this is a bug then the solution is obvious, the gigabyte aligment should happen before applying the `max-ram-below-4g` option. If this is not a bug but the expected way of working then there could be an option to override the `gigabyte_align` attribute from command line. + +What do you think? diff --git a/results/classifier/118/virtual/1730 b/results/classifier/118/virtual/1730 new file mode 100644 index 00000000..6719755b --- /dev/null +++ b/results/classifier/118/virtual/1730 @@ -0,0 +1,46 @@ +virtual: 0.985 +graphic: 0.889 +vnc: 0.835 +device: 0.823 +boot: 0.789 +performance: 0.773 +x86: 0.749 +mistranslation: 0.718 +semantic: 0.646 +VMM: 0.525 +architecture: 0.487 +peripherals: 0.479 +permissions: 0.451 +risc-v: 0.440 +network: 0.430 +user-level: 0.419 +debug: 0.338 +i386: 0.320 +PID: 0.315 +ppc: 0.302 +TCG: 0.297 +assembly: 0.287 +kernel: 0.280 +hypervisor: 0.256 +files: 0.246 +arm: 0.218 +register: 0.215 +socket: 0.180 +KVM: 0.134 + +Virtual console in GTK input uses wrong color for dark gray +Description of problem: +The virtual console in the GTK window uses black to draw dark gray text. This becomes unintelligible if drawing on black background. +Steps to reproduce: +1. Boot any distro to shell prompt with `-serial vc`. +2. Switch to serial console in QEMU GTK window (Ctrl+Alt+3). +4. Run `echo -e "\e[1;30mDark Greay\e[m"`. +5. Output is black on black. + +or + +1. `qemu-system-x86_64 -bios /usr/share/edk2/x64/OVMF.fd` +2. Enter EFI internal shell +3. `cls 0 8` +4. Run `help cls` and observe correct colors in VGA window. +5. Switch to serial console and observe black on black colors. diff --git a/results/classifier/118/virtual/1746394 b/results/classifier/118/virtual/1746394 new file mode 100644 index 00000000..e98a20f9 --- /dev/null +++ b/results/classifier/118/virtual/1746394 @@ -0,0 +1,66 @@ +virtual: 0.897 +graphic: 0.883 +user-level: 0.812 +debug: 0.703 +device: 0.703 +performance: 0.664 +mistranslation: 0.625 +vnc: 0.623 +semantic: 0.612 +architecture: 0.545 +PID: 0.527 +network: 0.460 +x86: 0.445 +peripherals: 0.444 +register: 0.442 +permissions: 0.442 +ppc: 0.437 +boot: 0.408 +hypervisor: 0.382 +socket: 0.361 +kernel: 0.360 +VMM: 0.356 +files: 0.352 +risc-v: 0.300 +TCG: 0.285 +i386: 0.285 +assembly: 0.280 +KVM: 0.271 +arm: 0.238 + +No provider of glEGLImageTargetTexture2DOES found with NVIDIA proprietary driver + +https://github.com/anholt/libepoxy/issues/148 + +I'm hitting this issue on Fedora 30 after an in-place upgrade. Using gnome-boxes, I click on a virtual machine to open the console viewer and it crashes after a hang. Terminal output looks like this: + +[chris@gereon ~]$ gnome-boxes + +(gnome-boxes:15640): Gtk-WARNING **: 17:21:17.105: GtkFlowBox with a model will ignore sort and filter functions + +(gnome-boxes:15640): Gtk-WARNING **: 17:21:17.107: GtkListBox with a model will ignore sort and filter functions +Memory pressure relief: Total: res = 11759616/11722752/-36864, res+swap = 7540736/7540736/0 +No provider of glEGLImageTargetTexture2DOES found. Requires one of: + GL extension "GL_OES_EGL_image" +Aborted (core dumped) + +nvidia driver version: 418.56 + +01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1) + +Web searches lead me to the closed libepoxy bug posted by the OP. I'm happy to provide more details about my system. + +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 please 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/118/virtual/1753186 b/results/classifier/118/virtual/1753186 new file mode 100644 index 00000000..fd41078a --- /dev/null +++ b/results/classifier/118/virtual/1753186 @@ -0,0 +1,83 @@ +virtual: 0.851 +graphic: 0.817 +device: 0.804 +PID: 0.782 +network: 0.762 +hypervisor: 0.756 +peripherals: 0.750 +performance: 0.749 +architecture: 0.747 +semantic: 0.746 +KVM: 0.744 +user-level: 0.742 +socket: 0.730 +files: 0.707 +arm: 0.705 +vnc: 0.702 +permissions: 0.701 +mistranslation: 0.701 +ppc: 0.692 +risc-v: 0.688 +assembly: 0.688 +kernel: 0.676 +x86: 0.674 +VMM: 0.666 +debug: 0.628 +i386: 0.621 +register: 0.613 +boot: 0.549 +TCG: 0.521 + +qemu-nbd: always first snapshot loaded from VDI images with snapshots + +When mounting a virtual box disk image of a VM with snapshots, always the state of the first snapshot is shown. + +How to reproduce: +1. Create a new VirtualBox VM or use an existing one, while choosing VDI as the disk image format. +2. Create a snapshot of the VM. +3. Modify the file system from within the VM enough that differences to the snapshotted version are apparent. +4. Create another snapshot. +5. Shut down the VM. +6. Mount the partition from the disk image with `qemu-nbd -c /dev/nbd0 /path/to/disk.vdi; mount /dev/nbd0pX /mnt` + +Expected result: The mounted disk image shall represent the latest state of the VM +Actual result: The mounted disk image represents the VM state at the first snapshot + +version information: qemu-nbd-2.11.1(openSUSE Tumbleweed) + +Hi, + +As far as I can tell that's because only the first snapshot is actually stored in the VDI. +(1) I've created a VM with /tmp/foo.vdi as storage +(2) Executed "echo 'snapshot' > /dev/sda" in the guest +(3) Took a snapshot +(4) Executed "echo 'next snapshot' > /dev/sda" in the guest +(5) Took a snapshot +(6) Executed "echo 'active layer' > /dev/sda" in the guest + +$ strings /tmp/foo.vdi +<<< Oracle VM VirtualBox Disk Image >>> +snapshot +$ ls ~/VirtualBox\ VMs/foo/Snapshots +{c9a75c86-6c0d-4aaa-9d24-cbd4456c74fb}.vdi {ce16e224-fa61-4b26-a5c5-21d92062ced7}.vdi +$ strings ~/VirtualBox\ VMs/foo/Snapshots/\{ce16e224-fa61-4b26-a5c5-21d92062ced7\}.vdi +<<< Oracle VM VirtualBox Disk Image >>> +next snapshot +$ strings ~/VirtualBox\ VMs/foo/Snapshots/\{c9a75c86-6c0d-4aaa-9d24-cbd4456c74fb\}.vdi +<<< Oracle VM VirtualBox Disk Image >>> +active layer + +So snapshots in VDI apparently are what qemu calls external snapshots, so they work through backing file links -- and the original file is simply the bottom-most backing file (that is, the oldest snapshot). So the file you'd want to open is {c9a75c86-6c0d-4aaa-9d24-cbd4456c74fb}.vdi. + However: +$ qemu-img info \{ce16e224-fa61-4b26-a5c5-21d92062ced7\}.vdi +qemu-img: Could not open '{ce16e224-fa61-4b26-a5c5-21d92062ced7}.vdi': unsupported VDI image (non-NULL link UUID) + +So qemu doesn't support this now. The current behavior is more or less correct (because the file only contains the data of the oldest snapshot), supporting snapshots would be a feature request. + +Max + +Closing this as WontFix since it works as expected, and keeping it open as wishlist item does not make too much sense. + +The QEMU project normally doesn't implement new features like these external snapshots on demand; they're a lot of work to do. Instead we simply code-review and incorporate such features as and when people decide to write them and submit the patches. So there's not much point in having a 'wishlist' bug in the bug tracker saying "support for feature X would be nice", because it will likely never happen, unless by the coincidence that somebody happened to implement and submit it to us anyway. Sorry for the inconvenience and thanks for your understanding. + + diff --git a/results/classifier/118/virtual/176 b/results/classifier/118/virtual/176 new file mode 100644 index 00000000..1cc1bd70 --- /dev/null +++ b/results/classifier/118/virtual/176 @@ -0,0 +1,31 @@ +virtual: 0.979 +device: 0.866 +performance: 0.730 +VMM: 0.716 +architecture: 0.682 +vnc: 0.489 +PID: 0.452 +TCG: 0.438 +risc-v: 0.402 +arm: 0.375 +permissions: 0.371 +ppc: 0.366 +graphic: 0.365 +hypervisor: 0.364 +x86: 0.344 +i386: 0.339 +KVM: 0.294 +files: 0.273 +peripherals: 0.265 +debug: 0.265 +semantic: 0.264 +mistranslation: 0.245 +boot: 0.161 +network: 0.140 +register: 0.133 +socket: 0.107 +kernel: 0.090 +user-level: 0.045 +assembly: 0.038 + +virtual machine cpu soft lockup when qemu attach disk diff --git a/results/classifier/118/virtual/1779650 b/results/classifier/118/virtual/1779650 new file mode 100644 index 00000000..cb2e6389 --- /dev/null +++ b/results/classifier/118/virtual/1779650 @@ -0,0 +1,40 @@ +virtual: 0.977 +graphic: 0.968 +device: 0.905 +mistranslation: 0.834 +performance: 0.770 +semantic: 0.675 +vnc: 0.630 +network: 0.629 +peripherals: 0.565 +register: 0.538 +socket: 0.497 +risc-v: 0.486 +architecture: 0.484 +debug: 0.387 +i386: 0.357 +VMM: 0.350 +ppc: 0.345 +arm: 0.333 +user-level: 0.321 +permissions: 0.313 +x86: 0.296 +boot: 0.291 +files: 0.243 +kernel: 0.240 +PID: 0.215 +assembly: 0.186 +TCG: 0.155 +hypervisor: 0.100 +KVM: 0.079 + +The display stays black after waking up a domain via SPICE with a QXL card + +As the title says, in a jessie VM, waking up a VM via the spice remote view works with a VGA graphic card. With a QXL card though, the domain wakes up but the display stays black (the keyboard is working though). + +Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b + +Does the problem still persist with the latest version of QEMU? Did you maybe try to report it to the Spice project (https://www.spice-space.org/support.html)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1780928 b/results/classifier/118/virtual/1780928 new file mode 100644 index 00000000..f70b4499 --- /dev/null +++ b/results/classifier/118/virtual/1780928 @@ -0,0 +1,87 @@ +virtual: 0.895 +debug: 0.885 +permissions: 0.877 +semantic: 0.862 +register: 0.861 +architecture: 0.859 +assembly: 0.858 +graphic: 0.847 +performance: 0.827 +PID: 0.824 +network: 0.815 +files: 0.815 +device: 0.805 +user-level: 0.793 +hypervisor: 0.786 +socket: 0.768 +kernel: 0.755 +boot: 0.750 +arm: 0.744 +ppc: 0.739 +risc-v: 0.739 +VMM: 0.704 +KVM: 0.686 +vnc: 0.657 +peripherals: 0.573 +mistranslation: 0.566 +TCG: 0.514 +x86: 0.464 +i386: 0.298 + +v2.12.0-2321-gb34181056c: vcpu hotplug crashes qemu-kvm with segfault + +vcpu hotplug crashes upstream qemu(v2.12.0-2321-gb34181056c), vcpu hotplug works fine in v2.12.0-rc4. + +Host: Power8, kernel: 4.18.0-rc2-00037-g6f0d349d922b +Guest: Power8, kernel: 4.18.0-rc3-00183-gc42c12a90545 (base image: fedora27 ppc64le) + +/usr/share/avocado-plugins-vt/build/qemu/ppc64-softmmu/qemu-system-ppc64 -M pseries,accel=kvm,max-cpu-compat=power8 -m 8192 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-ppc64le.qcow2,format=qcow2,if=none,id=drive1 -device scsi-hd,drive=drive1,bus=scsi0.0 -smp 1,cores=1,threads=1,sockets=1,maxcpus=8 -serial /dev/pts/0 -monitor stdio -vga none -nographic -kernel /home/kvmci/linux/vmlinux -append 'root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' -nic user,model=virtio-net-pci +QEMU 2.12.50 monitor - type 'help' for more information +(qemu) device_add host-spapr-cpu-core,id=core1,core-id=1 +Segmentation fault (core dumped) + + +Guest initial cpu: +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 1 +On-line CPU(s) list: 0 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.1 (pvr 004b 0201) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 64K +L1i cache: 32K +NUMA node0 CPU(s): 0 + +Reverting the below comment makes CPU hotplug work again: + +commit a028dd423ee6dfd091a8c63028240832bf10f671 + + ppc/xics: introduce ICP DeviceRealize and DeviceReset handlers + + This changes the ICP realize and reset handlers in DeviceRealize and + DeviceReset handlers. parent handlers are now called from the + inheriting classes which is a cleaner object pattern. + + + +The parent class (ie, TYPE_ICP) doesn't implement DeviceClass::reset(). It directly registers a reset handler with qemu_register_reset() instead. This is needed for cold plugged ICPs to be reset during machine reset since they're not SysBus devices. + +Cedric's patch missed that, but rather than reverting it, I'd rather go forward and: +- introduce an abstract TYPE_ICP_BASE class that implements DeviceClass::reset() +- have the current TYPE_ICP and all other specialized ICP types to derive from TYPE_ICP_BASE +- have all specialized ICP types to register reset handlers with qemu_register_reset() + +This would match what was recently done with the ICS types. + + +Fixed by: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b585395b655a6c1f9d9ebf1f0890e76d0708eed6 + diff --git a/results/classifier/118/virtual/1784919 b/results/classifier/118/virtual/1784919 new file mode 100644 index 00000000..41bf2233 --- /dev/null +++ b/results/classifier/118/virtual/1784919 @@ -0,0 +1,56 @@ +virtual: 0.896 +architecture: 0.799 +files: 0.765 +device: 0.759 +network: 0.746 +performance: 0.698 +ppc: 0.682 +graphic: 0.581 +hypervisor: 0.576 +VMM: 0.567 +kernel: 0.564 +socket: 0.541 +vnc: 0.539 +mistranslation: 0.539 +register: 0.535 +semantic: 0.524 +arm: 0.516 +PID: 0.496 +user-level: 0.481 +KVM: 0.479 +permissions: 0.472 +peripherals: 0.395 +risc-v: 0.392 +boot: 0.368 +TCG: 0.336 +i386: 0.334 +x86: 0.319 +debug: 0.278 +assembly: 0.213 + +native libgfapi glusterfs support for virtio 9p filesystem passthrough + +I can add block devices on glusterfs natively to my virtual machines since qemu 1.3 +I would like to see the same feature for virtio 9p filesystems added on my VM. + +Accessing a filesystem mounted on the Metal is my favorite solution for storage that is to be shared between more than one VM. But because my VMs are not running as root, they are not able to passthrough userids and gids to gluster-fuse. uid mapping is also not possible because no xattr support. + +So all I can do is either setting up seperate NFS Servers to bring the Filesystem in via Network, or to start qemu as root or to add fuse_xattr on top of glusterfs_fuse. I do expect however that the fastest and most relieable solution is to make something like this possible: + +-fsdev local,id=test_dev,path=gluster://this.node/test_mount,security_model=passthrough -device virtio-9p-pci,fsdev=test_dev,mount_tag=test_mount + +regards + + Hans + +There are currently no plans to implement a GlusterFS fs driver backend for 9pfs in QEMU. + +Right now the status of 9p in QEMU is "odd fixes", which means there are currently no paid developers maintaining 9p, nor do current 9p maintainers have sufficient time to work on it on a daily basis. New 9p features for that reason are only likely to appear if there is an effort for the feature coming from outside. + +As xattrs are apparently not available with GlusterFS yet, you might want to try security_model=mapped-file with 9p as workaround instead: +https://wiki.qemu.org/Documentation/9psetup + + + +Ok, then let's mark this ticket as WONTFIX since nobody will be working on it in the near future. + diff --git a/results/classifier/118/virtual/1789 b/results/classifier/118/virtual/1789 new file mode 100644 index 00000000..5a282388 --- /dev/null +++ b/results/classifier/118/virtual/1789 @@ -0,0 +1,47 @@ +virtual: 0.995 +performance: 0.956 +device: 0.940 +graphic: 0.899 +PID: 0.892 +debug: 0.857 +vnc: 0.830 +hypervisor: 0.813 +semantic: 0.812 +VMM: 0.783 +risc-v: 0.772 +architecture: 0.758 +boot: 0.725 +x86: 0.719 +network: 0.719 +KVM: 0.690 +socket: 0.675 +permissions: 0.672 +i386: 0.658 +user-level: 0.615 +arm: 0.596 +ppc: 0.567 +kernel: 0.514 +register: 0.511 +TCG: 0.502 +mistranslation: 0.440 +assembly: 0.349 +peripherals: 0.343 +files: 0.233 + +First connection to spice hangs after 1 min +Description of problem: +After starting a VM the first connection to spice logs this errors: + +``` +2023-07-25T16:00:47.497042Z qemu-system-x86_64: warning: Spice: main:0 (0x7f1a3fca5b90): invalid net test stage, ping id 0 test id 0 stage 4 +2023-07-25T16:00:47.497170Z qemu-system-x86_64: warning: Spice: main:0 (0x7f1a3fca5b90): invalid net test stage, ping id 0 test id 0 stage 0 +``` + +And after 60 seconds the spice viewer is closed with this error: +``` +2023-07-25T16:01:47.384207Z qemu-system-x86_64: warning: Spice: main:0 (0x7f1a3fca5b90): rcc 0x7f1a1968cb60 has been unresponsive for more than 30000 ms, disconnecting +``` +Steps to reproduce: +1. Start vm with spice +2. Connect to spice +3. Wait for at least 60 seconds and the viewer will close diff --git a/results/classifier/118/virtual/1792193 b/results/classifier/118/virtual/1792193 new file mode 100644 index 00000000..e6a47793 --- /dev/null +++ b/results/classifier/118/virtual/1792193 @@ -0,0 +1,75 @@ +virtual: 0.881 +x86: 0.849 +architecture: 0.829 +graphic: 0.819 +user-level: 0.767 +device: 0.766 +debug: 0.754 +hypervisor: 0.744 +semantic: 0.721 +mistranslation: 0.700 +performance: 0.668 +kernel: 0.666 +files: 0.663 +ppc: 0.595 +KVM: 0.584 +permissions: 0.563 +peripherals: 0.539 +vnc: 0.530 +risc-v: 0.523 +i386: 0.518 +arm: 0.511 +PID: 0.508 +register: 0.503 +assembly: 0.485 +boot: 0.453 +VMM: 0.447 +network: 0.414 +socket: 0.411 +TCG: 0.339 + +AMD Athlon(tm) X2 Dual-Core QL-64 bug + +I upgrade my qemu 2.12.0-2 => 3.0.0-1. After that I can't load virtual machine with "-cpu host" option. Full command line is +qemu-system-x86_64 \ + -monitor stdio \ + -enable-kvm \ + -cpu host \ + -smp cpus=2 \ + -m 1G \ + -vga virtio \ + -display gtk,gl=on \ + -soundhw ac97 \ + -drive file=/ehdd/qemu/arch_hw_12_08_2018/arch_shrinked.raw,format=raw,if=virtio +I have Arch Linux on virtual machine. When I start QEMU, GRUB tries to load initial ramdisk and stops. System doesn't load. If I try to start virtual machine with "-cpu athlon" option then get the same bug. +I downgrade back to qemu 2.12.0-2 and virtual machine works fine, system loads. +My processor is AMD Athlon(tm) X2 Dual-Core QL-64. + +Hi Kirill, + That's a bit tricky to debug; could you build qemu from git and try and bisect between 2.12.0 and 3.0 to see which commit broke it? + +Yes I could, but it rebuilds too long. I will report results later, when find broke commit. + +I try to bisect git version. When I run git bisect bad v3.0.0 it says: +Bisecting: 1298 revisions left to test after this (roughly 10 steps) +error: Your local changes to the following files would be overwritten by checkout: + configure + po/bg.po + po/de_DE.po + po/fr_FR.po + po/hu.po + po/it.po + po/messages.po + po/tr.po + po/zh_CN.po +Please commit your changes or stash them before you switch branches. +Aborting +Something is wrong, isn't it? + +I can't do bisect, but I have installed qemu version 3.0.50 (v3.0.0-614-g19b599f766-dirty) from git and this works fine. + +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/118/virtual/1795148 b/results/classifier/118/virtual/1795148 new file mode 100644 index 00000000..cf057ce4 --- /dev/null +++ b/results/classifier/118/virtual/1795148 @@ -0,0 +1,53 @@ +x86: 0.988 +virtual: 0.978 +architecture: 0.950 +graphic: 0.891 +performance: 0.869 +device: 0.848 +semantic: 0.829 +register: 0.825 +hypervisor: 0.813 +files: 0.804 +network: 0.793 +arm: 0.792 +ppc: 0.773 +PID: 0.770 +VMM: 0.746 +user-level: 0.741 +mistranslation: 0.737 +i386: 0.706 +socket: 0.692 +vnc: 0.687 +peripherals: 0.661 +risc-v: 0.660 +kernel: 0.645 +debug: 0.642 +boot: 0.630 +permissions: 0.623 +TCG: 0.598 +assembly: 0.587 +KVM: 0.446 + +address_space_stw_le_cached: Assertion `addr < cache->len && 2 <= cache ->len - addr' failed + +When running OpenBSD-current as a guest, the following assertion is hit after a few seconds, resulting in the virtual machine to crash: + +``` +qemu-system-x86_64: /build/qemu/src/qemu-3.0.0/include/exec/memory_ldst_cached.inc.h:85: address_space_stw_le_cached: Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +``` + +Host is Arch Linux stable, running on x86_64. + +Qemu version is 3.0.0, installed via the standard Arch Linux package. + +Version 2.12.1 didn't exhibit this behavior. + +Do you know how to use "git bisect"? If so, could you maybe try to bisect which commit between v2.12.0 and v3.0.0 introduced this problem? + +I suspect this is a known bug, fixed in master in commit db812c4073c77. You could test that by cherry-picking it to 3.0 or just testing against master. + + + +In the absence of further information from the submitter, it seems reasonable to assume that this is indeed the bug fixed by commit db812c4073c77 (which resulted in this assertion when running OpenBSD guests). That commit is in 3.1, which was released in December. + + diff --git a/results/classifier/118/virtual/1798434 b/results/classifier/118/virtual/1798434 new file mode 100644 index 00000000..2e52f750 --- /dev/null +++ b/results/classifier/118/virtual/1798434 @@ -0,0 +1,43 @@ +virtual: 0.901 +graphic: 0.812 +peripherals: 0.802 +performance: 0.768 +architecture: 0.733 +user-level: 0.731 +device: 0.725 +mistranslation: 0.716 +semantic: 0.708 +kernel: 0.706 +permissions: 0.569 +socket: 0.568 +network: 0.551 +register: 0.542 +vnc: 0.531 +hypervisor: 0.524 +i386: 0.518 +boot: 0.497 +x86: 0.478 +risc-v: 0.422 +files: 0.418 +PID: 0.399 +ppc: 0.382 +arm: 0.373 +debug: 0.357 +VMM: 0.355 +TCG: 0.355 +KVM: 0.307 +assembly: 0.296 + +[Feature Request] Automatic device configuration discovery + +Would it be possible to have a script that enumerates the device tree of a Linux host and generates a qemu command line that would recreate it under emulation? The user would have to customize the arguments (for instance to point to disk image files), but it would take a lot of the guesswork out. + +Similarly, is there information that can be gleaned from the kernel build config that would help with configuration? + +This is occasionally asked for but unfortunately not in the general case possible. Device trees contain enough information for a guest OS to use the hardware; they do not contain a full description of how the hardware is actually configured and connected together, and they don't say anything about parts of the hardware that are "discoverable" (ie probeable, like PCI). So there isn't enough information to produce a full board model, and the parts that correspond to QEMU command line options (like pluggable devices such as ethernet cards) aren't usually in the DT at all. + +The expected workflow goes the other way around -- you start by picking a machine type that QEMU models, and then configure the kernel and use the device tree that is intended for it, in the same way you would if you wanted to get Linux running on a real hardware board. + + +Right, and since QEMU also only supports a limited set of devices, there is no chance that you can mirror an arbitrary host this way. But if you want to convert a host into a VM and do not care whether each and every detail can be mirrored, have a look at http://libguestfs.org/virt-p2v.1.html - that's likely the best solution so far. + diff --git a/results/classifier/118/virtual/1804 b/results/classifier/118/virtual/1804 new file mode 100644 index 00000000..b10967a8 --- /dev/null +++ b/results/classifier/118/virtual/1804 @@ -0,0 +1,41 @@ +virtual: 0.984 +device: 0.897 +graphic: 0.860 +peripherals: 0.820 +VMM: 0.723 +architecture: 0.594 +hypervisor: 0.584 +debug: 0.578 +PID: 0.578 +performance: 0.553 +semantic: 0.551 +vnc: 0.549 +mistranslation: 0.527 +register: 0.485 +arm: 0.467 +boot: 0.429 +permissions: 0.398 +network: 0.369 +risc-v: 0.363 +TCG: 0.320 +socket: 0.284 +ppc: 0.282 +assembly: 0.252 +x86: 0.176 +files: 0.175 +i386: 0.152 +user-level: 0.089 +kernel: 0.053 +KVM: 0.030 + +Virtual Machines Do Not Recognize Mouse 5 and 6 +Description of problem: +Trying to click the mouse buttons 5 and 6 to go forwards and backwards in Firefox does not work. It seems that those buttons are not recognized by the virtual machine. Tested with both `libvirt` and `aqemu`. Though `libvirt` testing was done on a Fedora host a few months prior. + +Running Fedora 38 VM in virtualbox does not have this problem, the guest recognizes button 5 and 6, going forwards and backwards in Firefox. +Steps to reproduce: +1. Install aqemu or libvirt on Debian 12 +2. Create a Fedora 38 Guest machine +3. Open Firefox and navigate to a few pages, then try to go backwards and forwards in history using the mouse buttons. +Additional information: + diff --git a/results/classifier/118/virtual/1809252 b/results/classifier/118/virtual/1809252 new file mode 100644 index 00000000..ffdd0fc3 --- /dev/null +++ b/results/classifier/118/virtual/1809252 @@ -0,0 +1,77 @@ +virtual: 0.932 +semantic: 0.906 +device: 0.862 +mistranslation: 0.842 +hypervisor: 0.841 +performance: 0.804 +architecture: 0.786 +network: 0.783 +vnc: 0.776 +permissions: 0.755 +peripherals: 0.737 +arm: 0.732 +risc-v: 0.726 +register: 0.715 +socket: 0.701 +ppc: 0.690 +kernel: 0.677 +graphic: 0.653 +debug: 0.618 +x86: 0.617 +user-level: 0.616 +files: 0.613 +VMM: 0.560 +PID: 0.550 +assembly: 0.541 +KVM: 0.539 +i386: 0.531 +boot: 0.515 +TCG: 0.502 + +Password authentication in FIPS-compliant mode + +The documentation states, that: + +"The VNC protocol has limited support for password based authentication. (...) Password authentication is not supported when operating in FIPS 140-2 compliance mode as it requires the use of the DES cipher." + +Would it be possible for qemu to use a different cipher and re-enable password as an option in VNC console? Is there a technical reason for not using a stronger cipher? + +On 12/20/18 6:59 AM, Tomasz Barański wrote: +> Public bug reported: +> +> The documentation states, that: +> +> "The VNC protocol has limited support for password based authentication. +> (...) Password authentication is not supported when operating in FIPS +> 140-2 compliance mode as it requires the use of the DES cipher." +> +> Would it be possible for qemu to use a different cipher and re-enable +> password as an option in VNC console? Is there a technical reason for +> not using a stronger cipher? + +The technical reason is that there are no other VNC endpoints out there +that support a different cipher. The VNC protocol itself declares what +all compliant servers/clients must use - and that spec is what makes the +non-FIPS-compliant requirement. You wouldn't have to patch just qemu, +but every other VNC endpoint out there that you want to interoperate +with a patched qemu. But it's really not worth doing that when there +are already better solutions available. That is, rather than trying to +fix VNC, just use an alternative protocol that doesn't have a baked-in +authentication limitation in the first place - namely, Spice. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +The VNC password authentication scheme is not extensible. It is unfixably broken by design. + +QEMU provides the SASL authentication scheme for VNC which allows for strong authentication, when combined with the VeNCrypt authentication scheme that uses TLS. + +These extensions are supported by the gtk-vnc client used by remote-viewer, virt-viewer, virt-manager, GNOME Boxes and more. Other VNC clients are also known to implement VeNCrypt, though SASL support is less wide spread. + +From a QEMU POV, there's nothing more we need todo really - any remaining gaps are client side. + +I understand. Thank you, guys! + diff --git a/results/classifier/118/virtual/1811916 b/results/classifier/118/virtual/1811916 new file mode 100644 index 00000000..529f1807 --- /dev/null +++ b/results/classifier/118/virtual/1811916 @@ -0,0 +1,44 @@ +virtual: 0.930 +debug: 0.858 +device: 0.821 +graphic: 0.779 +performance: 0.735 +user-level: 0.733 +mistranslation: 0.732 +semantic: 0.716 +peripherals: 0.691 +vnc: 0.609 +i386: 0.595 +architecture: 0.568 +network: 0.559 +VMM: 0.524 +permissions: 0.522 +kernel: 0.522 +ppc: 0.517 +hypervisor: 0.506 +x86: 0.496 +files: 0.489 +risc-v: 0.477 +register: 0.475 +socket: 0.456 +PID: 0.449 +TCG: 0.425 +assembly: 0.365 +boot: 0.319 +arm: 0.315 +KVM: 0.284 + +SDL2 interface didn't follow the current X11 keyboard layout for hotkeys + +My X11 was configured to use Dvorak keyboard layout, with setxkbmap(1). Despite the window title said 'Press Ctrl-Alt-G to exit grab' after it grabbed the mouse, pressing this hotkey don't have any effects, and I has to switch to a virtual terminal to kill(1) that qemu process. By debugging the program I found it is using the raw key code to handle the key events, so I must use CTRL-ALT-I to exit the grab, in my keyboard. + +Also affects SDL 1.2 UI in QEMU 2.12.1 + +I'm currently reverted the commit f8d2c9369b8302f65f4f43f14ed3987c2268a02a to use only CTRL-ALT. +https://gist.github.com/Low-power/822eace3f37c893bc6aad3af647b4c7d + +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/118/virtual/1815078 b/results/classifier/118/virtual/1815078 new file mode 100644 index 00000000..0d628955 --- /dev/null +++ b/results/classifier/118/virtual/1815078 @@ -0,0 +1,89 @@ +risc-v: 0.986 +virtual: 0.959 +register: 0.950 +mistranslation: 0.920 +files: 0.907 +user-level: 0.906 +semantic: 0.882 +performance: 0.830 +permissions: 0.810 +arm: 0.801 +graphic: 0.792 +PID: 0.777 +architecture: 0.768 +device: 0.766 +hypervisor: 0.750 +network: 0.736 +vnc: 0.732 +ppc: 0.724 +debug: 0.723 +socket: 0.713 +peripherals: 0.711 +kernel: 0.697 +boot: 0.647 +VMM: 0.640 +KVM: 0.616 +i386: 0.613 +TCG: 0.605 +assembly: 0.555 +x86: 0.535 + +Qemu 3.1.0 risc-v mie.MEIE + +Hello all, + +There is a bug in qemu for Risc-v, related to the mie register: when we try to set the MEIE bit (11) nothing is done, even when we are running at machine mode. + +Li a0 , 1 << 11 +Csrs mie , a0 + +And when we read mie it is as though nothing was done. + +Going through the qemu source code I was able to correct it: on file op_helper.c, line 94, the variable all_ints should be initialized with: + +uint64_t all_ints = delegable_ints | MIP_MSIP | MIP_MTIP | MIP_MEIP; + +That is, the MIP_MEIP was missing. + +I've successfully triggered uart interrupts with this patch (virt machine). + +All the best, +Pharos team + +It looks like this is fixed as of c7b951718815 ("RISC-V: Implement modular CSR helper interface"), which was merged on January 14th. + +Good news, + +Thanks + +LMK if that patch doesn't fix your issue. QEMU master is pretty stable for RISC-V right now and since there's a handful of intertwined patches the best bet is probably just to use the commit hash above. + +This should be fixed in the 4.0 release, which is targeted for the middle of April. + +OK, I'll give it a try and give you some feedback. + +Thanks + +So I tried it but got the error: + +ERROR: missing file ../qemu-3.1.0/ui/keycodemapdb/README + +This is not a GIT checkout but module content appears to +be missing. Do not use 'git archive' or GitHub download links +to acquire QEMU source archives. Non-GIT builds are only +supported with source archives linked from: + + https://www.qemu.org/download/ + +Developers working with GIT can use scripts/archive-source.sh +if they need to create valid source archives. + +Makefile.cross-compiler:259: recipe for target 'qemu-3.1' failed +make: *** [qemu-3.1] Error 1 + + + +Get this is standard error, but I don't have time now to see how to work around it. Maybe later I can + + + diff --git a/results/classifier/118/virtual/1816189 b/results/classifier/118/virtual/1816189 new file mode 100644 index 00000000..30c3dfb5 --- /dev/null +++ b/results/classifier/118/virtual/1816189 @@ -0,0 +1,67 @@ +virtual: 0.849 +device: 0.836 +VMM: 0.829 +graphic: 0.807 +kernel: 0.726 +PID: 0.722 +hypervisor: 0.715 +architecture: 0.710 +socket: 0.705 +user-level: 0.700 +files: 0.645 +performance: 0.631 +assembly: 0.628 +register: 0.613 +x86: 0.611 +debug: 0.574 +permissions: 0.570 +mistranslation: 0.564 +ppc: 0.561 +semantic: 0.538 +peripherals: 0.530 +vnc: 0.502 +network: 0.481 +risc-v: 0.466 +boot: 0.378 +arm: 0.373 +TCG: 0.323 +i386: 0.298 +KVM: 0.273 + +Unable to create or revert snapshots + +With an update to Qemu (3.1.x) I am unable to revert snapshots using virt-manager or virsh. Virtual Machines existing before the update seem to function properly. It is only after creating a new machine that snapshots are misbehaving. I tested spinning up vms of tumbleweed, leap15, and ubuntu 18.04. Each of them had the following issues: + +- With the machine running, live reversions act like they apply, but no changes are actually made. +- With the machine paused, reversion also does not apply. +- With the machine turned off, reversion is not possible. Virsh is unable to find the snapshot, and virt-manager errors out with: + +Error running snapshot 'FreshInstall': internal error: qemu unexpectedly closed the monitor: 2019-01-15T19:19:46.020247Z qemu-system-x86_64: Device 'drive-virtio-disk0' does not have the requested snapshot 'FreshInstall' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1105, in revert_to_snapshot + self._backend.revertToSnapshot(snap.get_backend()) + File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2024, in revertToSnapshot + if ret == -1: raise libvirtError ('virDomainRevertToSnapshot() failed', dom=self) + +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-01-15T19:19:46.020247Z qemu-system-x86_64: Device 'drive-virtio-disk0' does not have the requested snapshot 'FreshInstall' + +After doing some digging, the error occurs because of the following commit: +d98f26073bebddcd3da0ba1b86c3a34e840c0fb8 + + + +Adding System Information + +Before kernel 4.20.x this was not an issue as nested virtualization was not enabled by default. In any distribution using 4.20.x or later, snapshots and migration do not work. + +Can you still reproduce this issue with the latest version of QEMU and libvirt? Anyway, since the problem occurs with libvirt, have you already tried to report this issue to the libvirt project instead? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1833048 b/results/classifier/118/virtual/1833048 new file mode 100644 index 00000000..8223542d --- /dev/null +++ b/results/classifier/118/virtual/1833048 @@ -0,0 +1,54 @@ +virtual: 0.990 +graphic: 0.824 +files: 0.732 +device: 0.727 +semantic: 0.652 +performance: 0.639 +hypervisor: 0.599 +mistranslation: 0.589 +VMM: 0.557 +architecture: 0.549 +user-level: 0.538 +PID: 0.530 +ppc: 0.516 +risc-v: 0.504 +permissions: 0.502 +i386: 0.496 +register: 0.493 +network: 0.489 +x86: 0.467 +socket: 0.432 +KVM: 0.431 +vnc: 0.427 +boot: 0.425 +debug: 0.387 +peripherals: 0.311 +TCG: 0.302 +arm: 0.272 +kernel: 0.271 +assembly: 0.262 + +Guest Agent get-fsinfo doesn't show ZFS volumes + +Calling get-fsinfo on a virtual machine does not include ZFS volumes. Calling on a system with a single ZFS disk (ZFS as root fs) simply returns '[]', if other disks exist on the guest it only shows these. + +Expected behaviour: Show file system details like with other fs formats. + +Tried with debian stretch default qemu-guest-agent package and v4.0.0 from git, compiled locally - result is the same. +Host is using QEMU 3.0.1, but that shouldn't matter, right? + +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 please 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/118/virtual/1836430 b/results/classifier/118/virtual/1836430 new file mode 100644 index 00000000..aad65116 --- /dev/null +++ b/results/classifier/118/virtual/1836430 @@ -0,0 +1,47 @@ +virtual: 0.985 +graphic: 0.770 +mistranslation: 0.764 +user-level: 0.601 +device: 0.520 +performance: 0.508 +architecture: 0.495 +semantic: 0.475 +socket: 0.321 +vnc: 0.313 +network: 0.286 +files: 0.284 +ppc: 0.275 +kernel: 0.237 +permissions: 0.224 +hypervisor: 0.217 +PID: 0.216 +KVM: 0.191 +boot: 0.189 +assembly: 0.178 +risc-v: 0.176 +register: 0.175 +VMM: 0.166 +peripherals: 0.164 +debug: 0.161 +arm: 0.117 +x86: 0.110 +TCG: 0.083 +i386: 0.053 + +Can't install on Windows 10 + +Latest release (20190712) 64-bit doesn't install: + +The setup seems to work fine at first and actually extract all the files needed for qemu in the correct location, but after it has done that, it proceeds to delete every file and leaves no trace of qemu except the installation folder. +The setup then finishes and notifies the user that it has been installed succesfully. + +I downloaded the previous release and it installs correctly. + +I just ran the installer from: + + https://qemu.weilnetz.de/w64/qemu-w64-setup-20190713.exe + +on a Win10 VM and it successfully installed and I checked for the files in Program Files and they were all there. Can you re-test with the latest installer please? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1841 b/results/classifier/118/virtual/1841 new file mode 100644 index 00000000..426d1e8b --- /dev/null +++ b/results/classifier/118/virtual/1841 @@ -0,0 +1,42 @@ +virtual: 0.983 +graphic: 0.976 +device: 0.915 +performance: 0.856 +VMM: 0.785 +hypervisor: 0.765 +architecture: 0.758 +vnc: 0.748 +risc-v: 0.711 +debug: 0.698 +peripherals: 0.673 +PID: 0.657 +semantic: 0.639 +x86: 0.610 +network: 0.600 +permissions: 0.572 +boot: 0.558 +register: 0.556 +i386: 0.548 +ppc: 0.543 +TCG: 0.534 +arm: 0.529 +files: 0.487 +user-level: 0.476 +socket: 0.467 +KVM: 0.429 +mistranslation: 0.396 +assembly: 0.293 +kernel: 0.051 + +qemu version with 7.2.5 or earlier than 7.2.5 with nvme disk has I/O QID 22 timeout, Aborting errors +Description of problem: +When I use the 7.2.5 version of qemu or versions earlier than 7.2.5 to compile and start the virtual machine, the machine has an nvme disk which is SAMSUNG MZQL23T8HCLS-00B7C and passed through by VFIO. When i use fio to perform pressure test on the nvme disk in vm, dmesg shows message like this nvme nvme0: I/O QID 22 timeout, Aborting, the picture below shows its details. Howerver, when i use 8.0.0 version of qemu to compile and start vm, and using fio to perform pressure test on the nvme disk in vm, it does not have the problem like that. I have using different kernel version, however, the probelem persists, so i think this is not a kernel issue, but a qemu problem. + + +if the irqbalance is running in vm, the problem happens very often, however if the irqbalance is stopped, the problem disappear. + + +Steps to reproduce: +1. using the 7.2.5 or versions earlier than 7.2.5 and start vm which has an nvme disk +2. the nvme disk is passed through by VFIO +3. using FIO to perform pressure test on the nvme disk in vm diff --git a/results/classifier/118/virtual/1845 b/results/classifier/118/virtual/1845 new file mode 100644 index 00000000..afe68b9c --- /dev/null +++ b/results/classifier/118/virtual/1845 @@ -0,0 +1,39 @@ +architecture: 0.996 +virtual: 0.987 +graphic: 0.931 +peripherals: 0.891 +device: 0.873 +VMM: 0.831 +semantic: 0.646 +debug: 0.575 +PID: 0.565 +boot: 0.510 +mistranslation: 0.486 +hypervisor: 0.465 +performance: 0.463 +network: 0.407 +permissions: 0.379 +socket: 0.378 +register: 0.350 +vnc: 0.346 +KVM: 0.343 +arm: 0.316 +kernel: 0.255 +TCG: 0.182 +risc-v: 0.175 +user-level: 0.169 +files: 0.125 +ppc: 0.115 +assembly: 0.029 +x86: 0.024 +i386: 0.021 + +qemu-xhci not working on aarch64 +Description of problem: +Once the VM is loaded I run lsusb from the cli and I get no devices listed. +Steps to reproduce: +1. Build qemu from source with libusb support +2. Launch vm using the above configuration +3. Run lsusb from the command line in the VM instance +Additional information: + diff --git a/results/classifier/118/virtual/1850000 b/results/classifier/118/virtual/1850000 new file mode 100644 index 00000000..e6437746 --- /dev/null +++ b/results/classifier/118/virtual/1850000 @@ -0,0 +1,173 @@ +virtual: 0.889 +debug: 0.884 +assembly: 0.865 +risc-v: 0.865 +device: 0.859 +semantic: 0.855 +arm: 0.847 +architecture: 0.842 +PID: 0.836 +register: 0.825 +TCG: 0.818 +user-level: 0.814 +permissions: 0.802 +mistranslation: 0.796 +vnc: 0.796 +performance: 0.793 +hypervisor: 0.790 +graphic: 0.788 +KVM: 0.788 +boot: 0.783 +peripherals: 0.778 +files: 0.773 +ppc: 0.748 +kernel: 0.742 +VMM: 0.737 +network: 0.628 +socket: 0.560 +x86: 0.546 +i386: 0.423 + +4.1.0 bogus QCOW2 corruption reported after compress + +Creating a compressed image then running `qemu-img check <..>.qcow2' on said image seems to report bogus corruption in some (but not all) cases: + +Step 1. + +# qemu-img info win7-base.qcow2 +image: win7-base.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 12.2 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: false + +# qemu-img check win7-base.qcow2 +No errors were found on the image. +327680/327680 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters +Image end offset: 21478375424 + +Step 2. + +# qemu-img convert -f qcow2 -O qcow2 -c win7-base.qcow2 test1-z.qcow2 + +Step 3. + +# qemu-img info test1-z.qcow2 +image: test1-z.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 5.78 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# qemu-img check test1-z.qcow2 +ERROR cluster 1191 refcount=1 reference=2 +ERROR cluster 1194 refcount=1 reference=4 +ERROR cluster 1195 refcount=1 reference=7 +ERROR cluster 1196 refcount=1 reference=7 +ERROR cluster 1197 refcount=1 reference=6 +ERROR cluster 1198 refcount=1 reference=4 +ERROR cluster 1199 refcount=1 reference=4 +ERROR cluster 1200 refcount=1 reference=5 +ERROR cluster 1201 refcount=1 reference=3 +<...> snip many errors +Leaked cluster 94847 refcount=3 reference=0 +Leaked cluster 94848 refcount=3 reference=0 +Leaked cluster 94849 refcount=11 reference=0 +Leaked cluster 94850 refcount=14 reference=0 + +20503 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +20503 leaked clusters were found on the image. +This means waste of disk space, but no harm to data. +197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters +Image end offset: 6216220672 + + +The resultant image seems to work fine in a VM when used as a backing file. + +Interestingly, if I substitute a qemu-img binary from qemu-4.0 then no errors are reported. + +# /tmp/qemu-img check test1-z.qcow2 +No errors were found on the image. +197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters +Image end offset: 6216220672 + +Is the image corrupted or not? I'm guessing not. + +Just in case it matters, this is ext4 fs on rotational disk. Latest Arch Linux but self compiled 4.1.0 with recent QCOW2 corruption fixes added. + +I haven't tried latest trunk but might do so if time permits. + +Current trunk still displays the problem. + +A git bisection between 4.0.0 and 4.1.0 revealed: + +b6c246942b14d3e0dec46a6c5868ed84e7dbea19 is the first bad commit +commit b6c246942b14d3e0dec46a6c5868ed84e7dbea19 +Author: Alberto Garcia <email address hidden> +Date: Fri May 10 19:22:54 2019 +0300 + + qcow2: Define and use QCOW2_COMPRESSED_SECTOR_SIZE + + When an L2 table entry points to a compressed cluster the space used + by the data is specified in 512-byte sectors. This size is independent + from BDRV_SECTOR_SIZE and is specific to the qcow2 file format. + + The QCOW2_COMPRESSED_SECTOR_SIZE constant defined in this patch makes + this explicit. + + Signed-off-by: Alberto Garcia <email address hidden> + Signed-off-by: Kevin Wolf <email address hidden> + + block/qcow2-cluster.c | 5 +++-- + block/qcow2-refcount.c | 25 ++++++++++++++----------- + block/qcow2.c | 3 ++- + block/qcow2.h | 4 ++++ + 4 files changed, 23 insertions(+), 14 deletions(-) + + + + + +There is definitely a bug in that patch, and that is that QCOW2_COMPRESSED_SECTOR_MASK is an unsigned int instead of a uint64_t (so the mask is too small). + +It looks like the bug has existed in some places before that patch (because they use ~511 as a mask), but not in others. + +This would explain why the bug is visible only for some images, namely for those with a compressed size of more than 4 GB, I presume. + + +And indeed, fixing QCOW2_COMPRESSED_SECTOR_MASK to be an unsigned long long fixes the bug. I’ll send a patch (but I’ll have to write a more simple and quicker test case first). + +Max + +Forgot to say that I sent a patch: + +https://lists.nongnu.org/archive/html/qemu-block/2019-10/msg01764.html + + +Thanks for reporting! + +Max + +Thank you Max. + +Can confirm your patch fixes my issue (qemu-img check ...) + +Not sure about those other code paths. I don't use internal snapshots and I'm not sure under which circumstances qcow2_free_any_clusters() gets exercised. + +Just for good measure, with patch applied I created another >4GB compressed image then booted it a few times and all seems fine. + +Fix has been included in QEMU v4.2: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=24552feb6ae2f615b76c2 + diff --git a/results/classifier/118/virtual/1853042 b/results/classifier/118/virtual/1853042 new file mode 100644 index 00000000..736e7e5e --- /dev/null +++ b/results/classifier/118/virtual/1853042 @@ -0,0 +1,367 @@ +virtual: 0.894 +debug: 0.883 +graphic: 0.868 +semantic: 0.866 +performance: 0.860 +user-level: 0.856 +risc-v: 0.854 +architecture: 0.851 +device: 0.839 +register: 0.832 +kernel: 0.831 +arm: 0.823 +permissions: 0.816 +vnc: 0.816 +ppc: 0.815 +mistranslation: 0.812 +socket: 0.807 +peripherals: 0.799 +PID: 0.797 +assembly: 0.796 +files: 0.780 +network: 0.778 +KVM: 0.777 +boot: 0.752 +VMM: 0.750 +hypervisor: 0.747 +TCG: 0.694 +x86: 0.571 +i386: 0.504 + +Ubuntu 18.04 - vm disk i/o performance issue when using file system passthrough + +== Comment: #0 - I-HSIN CHUNG <email address hidden> - 2019-11-15 12:35:05 == +---Problem Description--- +Ubuntu 18.04 - vm disk i/o performance issue when using file system passthrough + +Contact Information = <email address hidden> + +---uname output--- +Linux css-host-22 4.15.0-1039-ibm-gt #41-Ubuntu SMP Wed Oct 2 10:52:25 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux (host) Linux ubuntu 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:08:54 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux (vm) + +Machine Type = p9/ac922 + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + 1. Env: Ubuntu 18.04.3 LTS?Genesis kernel linux-ibm-gt - 4.15.0-1039.41?qemu 1:2.11+dfsg-1ubuntu7.18 ibmcloud0.3 or 1:2.11+dfsg-1ubuntu7.19 ibm-cloud1?fio-3.15-4-g029b + +2. execute run.sh to run fio benchmark: + +2.1) run.sh: +#!/bin/bash + +for bs in 4k 16m +do + +for rwmixread in 0 25 50 75 100 +do + +for numjobs in 1 4 16 64 +do +echo ./fio j1.txt --bs=$bs --rwmixread=$rwmixread --numjobs=$numjobs +./fio j1.txt --bs=$bs --rwmixread=$rwmixread --numjobs=$numjobs + +done +done +done + +2.2) j1.txt: + +[global] +direct=1 +rw=randrw +refill_buffers +norandommap +randrepeat=0 +ioengine=libaio +iodepth=64 +runtime=60 + +allow_mounted_write=1 + +[job2] +new_group +filename=/dev/vdb +filesize=1000g +cpus_allowed=0-63 +numa_cpu_nodes=0 +numa_mem_policy=bind:0 + +3. performance profile: +device passthrough performance for the nvme: +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm/20191011-112156/html/#/measurement/vm/ubuntu (I/O bandwidth achieved inside VM in GB/s range) + +file system passthrough +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm/20191106-123613/html/#/measurement/vm/ubuntu (I/o bandwidth achieved inside the VM is very low) + +desired performance when using file system passthrough should be similar to the device passthrough + +Userspace tool common name: fio + +The userspace tool has the following bit modes: should be 64 bit + +Userspace rpm: ? + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. + +Hi, +Let me provide my expectations (which are different): +You said "desired performance when using file system passthrough should be similar to the device passthrough" +IMHO that isn’t right - it might be "desired" but unrealistic to "be expected" + +Usually you have a hierarchy: +1. device passthrough +2. using block devices +3. using images on Host Filesystem +4. using images on semi-remote cluster filesystems +(and a few special cases in between) + +Those usually from 1->4 are decreasing performance but increasing flexibility and manageability. + +So I wanted to give a heads up based on the initial report that eventually this might end up as "please adjust expectations" + +--- + +That said, let’s focus on what your setup actually looks like and if there are obvious improvements or hidden bugs. +Unfortunately "file system passthrough" isn't a clearly defined thing. +Could you: +1) outline which disk storage you attached to the host +2) which filesystem is on that storage +3) how you are passing files and/or images to the guest + +Please explain the questions above and attach libvirts guest xml of both of your test cases. + +P.S. nvme passthrough will soon become even faster on ppc64el due to the fix for bug LP 1847948 + +------- Comment From <email address hidden> 2019-11-19 10:40 EDT------- +1) nvme installed inside p9/ac992 +2) File system pass through +# cd /nvme0 +# qemu-img create -f qcow2 nvme1.img 3GFormatting ?nvme1.img?, fmt=qcow2 size=3221225472 cluster_size=65536 lazy_refcounts=off refcount_bits=16 +# virsh attach-disk test_vm /nvme0/nvme1.img vdb --driver qemu --subdriver qcow2 --targetbus virtio --persistentDisk attached successfully + +# virsh detach-disk test_vm /nvme0/nvme1.imgDisk detached successfully + +Thanks for confirming the setup that I already have assumed. + +This will naturally be slower for having: +a) overhead by the host filesystem +b) overhead by qcow metadata handling +c) exits to the host for the I/O (biggest single element of these) +d) less concurrency as the defaults for queue count and depths +e) with the PT case you do real direct I/O write, while the other probably caches in the host which most of the time is bad. + +I can help you to optimize the tunables for the image that you attach if you want that. +That will make it slightly better than it is, but clearly it will never reach the performance of the nvme-passthrough. + +Let me know if you want some general tuning guidance on those or not. + +Hi, Christian. + +It would be great if you could share your knowledge on this. + +Thank you! + +Murilo + +Hi, +a little personal disclaimer. +This might not be perfect as I don't know your case in detail enough. +And also in general there is always "one more tuning" that you can tune :-) + +An example of an alternative might be to partition the nvme and pass the partitions as block devices => less flexible for live cycle management, but usually much faster - it is up to your needs entirely. +All these things will come at a tradeoff like overhead / features / affecting different workload patterns differently. + +For now my suggestion here tries to stick to the qcow2 image on FS option that you have chosen and just tune that one. + +Lets summarize the benefits of NVME passthrough to images on host FS +- lower latency +- more and deeper queues +- no host caching adding overhead +- features +- less overhead +- ... + +Lets take care about a few of those ... +A disk by default will start like: + + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/yourdisk.qcow'/> + <target dev='vdb' bus='virtio'/> + </disk> + +Your's will most likely look very similar. +Note I prefer an XML compared to the command line options as there are more features and it is more easy to document and audit later on (even if generated). + + +#1 Queues +By default a virtio block device has only one queue which is enough in many cases. +But on huge systems with massively parallel work the might not be. +Add something like - queues='8' - to your driver section. + +example: +<driver name='qemu' type='qcow2' queues='8'/> + +#2 Caching +Not always, but often for high speed I/O host caching is a drawback. +You can disable that via - cache='none' - in your driver section. + +example: +<driver name='qemu' type='qcow2' queues='8' cache='none'/> + +#3 Features +NVME disks after all are flash and you'd want to make sure that it learns about freed space (discard) in the long run. virtio-blk won't transfer those, but virtio-scsi will. + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> + </controller> + +Combining that with the above needs to adapt slightly as with virtio-scsi the controller has the queues, so queues='x' moves here. +E.g. read https://mpolednik.github.io/2017/01/23/virtio-blk-vs-virtio-scsi/ and links from there. + + +#4 IOThreads +By default your VM might have not enough I/O threads. +If you have multiple high performing elements you might want to assign them an individual one. +You'll need to allocate more and then assign more to your disk(controller). +Again this depends on your setup, and here I only outline how to unblock multiple disks from each others iothread. +1. in the domain section the threads + <iothreads>4</iothreads> +2. if you use virtio-scsi as above you assign iothreads at the controller level and might therefore want one controller per disk (in other cases you might assign the disk) + +(assign separate threads to each controller and have each disk have its own controller) + + + +--- + +Overall modified from the initial example: + + <domain> + ... + <iothreads>4</iothreads> + <devices> + ... + <controller type='scsi' index='0' model='virtio-scsi'> + <driver queues='8' iothread='3'/> + </controller> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/var/lib/uvtool/libvirt/images/yourdisk.qcow'/> + <target dev='sda' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + +--- + +Some choices of the setup e.g. using qcow files - will limit some of the benefits above. +At least in the past emulation limited the concurrency of actions here as well as passthrough of discard might be less effective. +Raw files and even more so partitions will be much faster - but as I said all is up to your specific needs. + +You might need to evaluate all the alternatives between qcow files and NVME-passthrough (which are like polar opposite) and rethink what you need in terms of features/performance and then pick YOUR tradeoff. + + +You'll find generic documentation about what I used above at: +https://libvirt.org/formatdomain.html#elementsDisks +https://libvirt.org/formatdomain.html#elementsIOThreadsAllocation + +As you see this is only the tip of the iceberg :-) + +------- Comment From <email address hidden> 2019-11-20 10:28 EDT------- +Hello, + +Thanks very much for the advice. I will try those settings as suggested. + +Our high-level goal is to provide a solution to enable NVMe as the local storage in the cloud node shared by multiple VMs. This would require 1) allocated storage space for different VMs with (security) isolation 2) I/O bandwidth performance with QoS. + +For high overhead of file system passthrough, is it possible to profile the performance overhead? + +Thanks again. + +I-Hsin + +As I said, you have to make your own tradeoff choices. +I still don't know enough of your needs, but from the bit I heard you can run e.g. an LVM on the NVME in the host and provision "disks" from the volume group on it (on many) which will be less flexible (but hey, still even has snapshots) but faster than images-on-FS while at the same time being more flexible than "just" partitions. + +Disk PT <-> partitions <-> LVM <-> images on FS +Speed <-> Features +(many suboptions in between) + +Sorry, but from here those are decisions you have to make :-/ + +About profiling, that is possible, but not helpful and in the worst case will add additional latency. Your initial decision which block architecture to use will make 95% of the perf/feature tradeoff. Later tuning profiling can usually only gain the remaining 5%, so I'd recommend to not focus on that part. + +P.S. This bug turns into consulting which I sometimes like (performance :-) ) but looking at my todo list I have other important things to do - sorry. I hope my guidance helped you to make better choices! + +Closing based on the assumption that Christian's response in comment #7 answered the relevant questions. + +------- Comment From <email address hidden> 2019-12-16 15:02 EDT------- +some summary we have so far + +css-host-22 is p9/ac922 and css-host-130 is x86/hgx1 + +1. Device pass through + +P9/x86 similar performance +Bare metal / VM similar performance +0.5GB/s to 1 GB/s for writes +Up to 4-5 GB/s for reads +Millions of int/csw per seconds for 4k page size and much smaller for 16 MB page size + +profiles + +Bare Metal +http://css-host-22.watson.ibm.com/rundir/nvme_bm_perf_on_bm/20191004-103224/html/#/measurement/nvme_bm_perf_bm/css-host-22 +http://css-host-130.watson.ibm.com/rundir/nvme_bm_perf_on_bm/20191210-132738/html/#/measurement/nvme_bm_perf_bm/css-host-130 +Virtual Machine +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm/20191011-112156/html/#/measurement/vm/ubuntu +http://css-host-130.watson.ibm.com/rundir/nvme_vm_perf_vm/20191210-223913/html/#/measurement/vm/ubuntu + +2. file system pass through + +P9/x86 similar performance +I/O bw achieved with 16MB page size, but very low I/O bw achieved with 4k page size +CPU utilization is much lower on P9/AC922 +On x86, CPU is waiting for some process to get to it (50% for qcow2 and 35% for raw) +Int/csw +Higher on x86 +Higher with 4k page size +Higher with raw + +profiles + +qcow2 +http://css-host-130.watson.ibm.com/rundir/nvme_vm_perf_vm_qcow2/20191211-232233/html/#/measurement/vm/ubuntu +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm_qcow2/20191211-233729/html/#/measurement/vm/ubuntu +raw +http://css-host-130.watson.ibm.com/rundir/nvme_vm_perf_vm_raw/20191212-082717/html/#/measurement/vm/ubuntu +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm_raw/20191212-082810/html/#/measurement/vm/ubuntu + +3. questions + +a. what is the diff between qcow2 and raw? how is that contributing to the cpu utilization? + +b. I have trouble configure scsci controller when I try to following the instructions: + +<controller type='scsi' index='0' model='virtio-scsi'> +<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> +</controller> + +it gave me the argument is not available error + +c. for file system pass through, How to get better 4k performance? + +@IBM + +this bug report is closed as invalid in Launchpad, as it is a discussion / perf tuning, rather than a bug report. And we have provided extension consultation about it. + +Can you please turn off bugproxy comment syncing, if you wish to continue commenting on this LTC ticket internally? + +Please note in Launchpad this bug report, and comments are open and public. + diff --git a/results/classifier/118/virtual/1857269 b/results/classifier/118/virtual/1857269 new file mode 100644 index 00000000..328eb32c --- /dev/null +++ b/results/classifier/118/virtual/1857269 @@ -0,0 +1,62 @@ +virtual: 0.887 +VMM: 0.811 +hypervisor: 0.694 +device: 0.657 +performance: 0.643 +graphic: 0.642 +semantic: 0.606 +KVM: 0.598 +mistranslation: 0.580 +risc-v: 0.520 +PID: 0.514 +user-level: 0.494 +socket: 0.471 +register: 0.468 +arm: 0.442 +boot: 0.441 +permissions: 0.425 +debug: 0.394 +architecture: 0.394 +vnc: 0.378 +TCG: 0.364 +files: 0.343 +peripherals: 0.337 +ppc: 0.319 +i386: 0.300 +x86: 0.292 +assembly: 0.264 +network: 0.262 +kernel: 0.213 + +Keyboard not fully working on Windows version + +Hello, + +I am working with windows qemu version: + +qemu-w64-setup-20190815 + +I have installed a msdos virtual machine on qemu with sp keyboard layout (Spain at Europe). I have found that some keys do not work in the way they should. I believe that the problem is that es qemu spanish keyboard layout is the latin one, la in msdos sysytem. + +I ask you to create the Spain layout. + + + +Thanks in advance. + +Hello, + +I thought that the not fully working problem on my laptop was originated by the es keymap file, but it is not. I have edited that file and I receive the same error. I believe that windows version of qemu has a problem, at least, with laptops. A few months ago I get this error with an asus laptop and nowdays I am even worse with a hp. I can not test the windows version with a desktop computer. + +I will download every new version and I shall comment if it works. + +Thanks for your attention. + + + +This bug is solved in last version of qemu for windows. + +Great work. + +Best regards. + diff --git a/results/classifier/118/virtual/1862619 b/results/classifier/118/virtual/1862619 new file mode 100644 index 00000000..0060b252 --- /dev/null +++ b/results/classifier/118/virtual/1862619 @@ -0,0 +1,111 @@ +virtual: 0.883 +permissions: 0.818 +boot: 0.800 +device: 0.768 +graphic: 0.766 +semantic: 0.752 +register: 0.752 +PID: 0.748 +architecture: 0.729 +debug: 0.728 +performance: 0.722 +network: 0.708 +TCG: 0.704 +vnc: 0.698 +assembly: 0.677 +peripherals: 0.673 +risc-v: 0.670 +arm: 0.667 +ppc: 0.628 +VMM: 0.623 +files: 0.572 +user-level: 0.543 +kernel: 0.541 +socket: 0.534 +KVM: 0.469 +hypervisor: 0.421 +x86: 0.402 +mistranslation: 0.380 +i386: 0.359 + +"-serial telnet::xxxx,server" causes "Device 'serial0' is in use" + +I start qemu version 4.2.50 in a first terminal : + +$ sudo ./qemu-system-hppa -boot d -serial telnet::4441,server -drive if=scsi,bus=0,index=6,file=./hpux.img,format=raw -serial mon:stdio -D /tmp/foo -nographic -m 512 -d nochain -cdrom ./HPUX_9.05_Installation_Disc_S700.iso -D /tmp/foo -net nic,model=tulip -net tap + +qemu-system-hppa: -serial telnet::4441,server: info: QEMU waiting for connection on: disconnected:telnet:0.0.0.0:4441,server + +In another terminal, I launch "telnet localhost 4441" + +And in the qemu window I have the following error: + +Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:220: +qemu-system-hppa: Device 'serial0' is in use + +Try top put "-serial mon:stdio" before "-serial telnet::4441,server" + + +Effectively, no more error ! +Now, my hppa machine is booted on its installation support for HP-UX 10.20, et I am connected with telnet in an other terminal. I don't know what I must enter now (on a real machine, the installation starts automatically, if I remember well what I did in 1990 !) + +If I use an installation support HP-UX 11.00, the installation starts automatically. Then, it finds no disk for installation, but I will work on the drive option of qemu to resolve this trouble. +Thanks a lot for your help ! + +I would observe that it would be much better if the order of the -serial arguments did not matter so much. I know gcc has the same sort of madness (for instance), but it sure isn't intuitive. + +But in my case, when you do the -serial things out of order, you end up with a segfault. +That can't be the intended behavior. + +Yes, a segfault is definitely a bug. Can you give instructions to reproduce that (full command line, any necessary images) ? The example originally reported in this bug doesn't seem to be a segfault. + +I'm now using qemu-system-hppa version 5.2.50, and I can put "-serial mon: stdio" before or after "-serial telnet :: 4441, server" without a problem. + +#qemu-system-hppa --version +QEMU emulator version 5.2.50 (v5.2.0-1300-g0e32462630) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +For me, no more bug. + +Ok, since you said that there is no more bug, I'm closing this issue now. + +Reporting again. Compiled QEMU from the latest stable Git: + +QEMU emulator version 6.2.50 (v6.2.0-529-gfb084237a3) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +Exactly as original post, if I place -serial telnet::4441,server ahead of -serial mon,stdio on the command line, it dumps core and aborts. + +if I flip them, it runs... BUT! The vm console output appears in the terminal where I launched qemu, I get no output in the telnet session. That's backwards. I have no access to the qemu console and can't issue commands to do things like change the CDROM. + +full command startup script (this one works but output doesn't happen where I expect) + +#!/bin/sh +CDROM="-cdrom HP-UX-OE-1.iso" +QEMU=/home/ascott/Documents/hpux/qemu/qemu/build/qemu-system-hppa +IMAGE=/home/ascott/Documents/hpux/hpux.img +$QEMU -boot d -serial mon:stdio -serial telnet::4441,server -drive if=scsi,bus=0,index=6,file=$IMAGE,format=raw -nographic -m 512 -d nochain $CDROM -net nic,model=tulip -net user + +This one dumps core with the serial0 error from the originla post: + +#!/bin/sh +CDROM="-cdrom HP-UX-OE-1.iso" +QEMU=/home/ascott/Documents/hpux/qemu/qemu/build/qemu-system-hppa +IMAGE=/home/ascott/Documents/hpux/hpux.img +$QEMU -boot d -serial telnet::4441,server -serial mon:stdio -drive if=scsi,bus=0,index=6,file=$IMAGE,format=raw -nographic -m 512 -d nochain $CDROM -net nic,model=tulip -net user + +ascott@vmhost01:~/Documents/hpux$ sh ./install-hpux.sh +qemu-system-hppa: -serial telnet::4441,server: info: QEMU waiting for connection on: disconnected:telnet:0.0.0.0:4441,server=on +Unexpected error in qemu_chr_fe_init() at ../chardev/char-fe.c:220: +qemu-system-hppa: Device 'serial0' is in use +Aborted (core dumped) + + + + + + + + +Hi Andrew! The QEMU project does not use this bug tracker anymore - could you please open a new issue here: https://gitlab.com/qemu-project/qemu/-/issues - Thanks! + diff --git a/results/classifier/118/virtual/1869073 b/results/classifier/118/virtual/1869073 new file mode 100644 index 00000000..ae74a1df --- /dev/null +++ b/results/classifier/118/virtual/1869073 @@ -0,0 +1,49 @@ +virtual: 0.966 +graphic: 0.938 +architecture: 0.873 +performance: 0.867 +user-level: 0.858 +device: 0.815 +debug: 0.801 +semantic: 0.764 +arm: 0.725 +PID: 0.711 +hypervisor: 0.698 +mistranslation: 0.667 +register: 0.613 +vnc: 0.609 +permissions: 0.607 +VMM: 0.568 +files: 0.529 +ppc: 0.513 +risc-v: 0.499 +network: 0.483 +boot: 0.470 +socket: 0.457 +TCG: 0.446 +assembly: 0.379 +peripherals: 0.365 +kernel: 0.364 +KVM: 0.317 +i386: 0.231 +x86: 0.228 + +qemu-arm-static crashes "segmentation fault" when running "git clone -s" + +I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc". + +The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault". + +I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage. + +What is the version of QEMU you are using? + +Actually this one magically went good. I'm testing in Virtual Box as my ARM64 host. Maybe something went wrong there. After rebooting the whole machine today "git" works well. + +Will reopen if it happens again... + +"git crashes" was a known issue with some older versions of QEMU (we had race conditions and git happens to go multi-threaded for some operations including I think 'clone'), but they should all now be fixed. If it does happen again I would recommend trying the most recent QEMU release. + + +Let's assume that this is fixed. Please open a new bug if it happens again. + diff --git a/results/classifier/118/virtual/1877384 b/results/classifier/118/virtual/1877384 new file mode 100644 index 00000000..e4838389 --- /dev/null +++ b/results/classifier/118/virtual/1877384 @@ -0,0 +1,315 @@ +virtual: 0.920 +user-level: 0.899 +graphic: 0.898 +network: 0.887 +peripherals: 0.886 +semantic: 0.883 +KVM: 0.881 +TCG: 0.879 +performance: 0.878 +permissions: 0.877 +device: 0.873 +architecture: 0.869 +mistranslation: 0.854 +arm: 0.851 +kernel: 0.850 +risc-v: 0.849 +register: 0.843 +debug: 0.843 +hypervisor: 0.840 +vnc: 0.836 +socket: 0.833 +x86: 0.815 +VMM: 0.802 +ppc: 0.801 +PID: 0.795 +files: 0.775 +assembly: 0.771 +boot: 0.699 +i386: 0.635 + +9pfs file create with mapped-xattr can fail on overlayfs + +QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do the same in master. +qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic "user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fs,mount_tag=fs -drive "file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" -append "$append" + + +I'm using CI that runs in a Docker container and runs a qemu VM with code and results shared via virtio 9p. +The 9p fsdev is configured with security_model=mapped-xattr +When the test code attempts to create a log file in an existing directory, open with O_CREAT fails with -ENOENT. + +The relevant strace excerpt is: + +28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20 +28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 21 +28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0 +28791 close(20) = 0 +28791 openat(21, "client.log", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20 +28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0 +28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 4, 0) = -1 ENOENT (No such file or directory) + +My hypothesis for what's going wrong is since the Docker container's overlayfs copies-up on writes, when it opens the file it's created a new version of the `src` directory containing a `client.log`, but this new src directory isn't accessible by file descriptor 20 and the lsetxattr call is instead attempting to set attributes on the path in the old `src` directory. + +Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and change `local_open2` to instead of calling `local_set_xattrat` to set the xattrs by directory file descriptor and file name, to have a version of local_set_xattrat` which uses `fsetxattr` to set the virtfs attributes instead of the `fsetxattrat_nofollow` helper. + +This reliably happened for me in CI, but I don't have access to the CI host or the time to strip the test down to make a minimal test case, and had difficulty reproducing the error on other machines. + +Since the report is about overlayfs being involved, could you please try if +the following patch makes a difference? + +https://github.com/gkurz/qemu/commit/f7f5a1b01307af1c7b6c94672f2ce75c36f10565 + +It's not yet on master, but will be soon. + +I've tested it (eventually, hit +https://github.com/torvalds/linux/commit/467d12f5c7842896d2de3ced74e4147ee29e97c8 +while trying to build it), +it doesn't help, since my program wasn't failing from attempting to +use O_NOATIME. + +The following patch fixed the -ENOENT on file create for me. I also +applied the fix to symlink. Potentially it could happen to mknod and +other calls that create a new directory entry, which couldn't be +simply fixed by altering the open file, but I've not encountered +issues there. + +On Sat, 9 May 2020 at 15:05, Christian Schoenebeck +<email address hidden> wrote: +> +> Since the report is about overlayfs being involved, could you please try if +> the following patch makes a difference? +> +> https://github.com/gkurz/qemu/commit/f7f5a1b01307af1c7b6c94672f2ce75c36f10565 +> +> It's not yet on master, but will be soon. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1877384 +> +> Title: +> 9pfs file create with mapped-xattr can fail on overlayfs +> +> Status in QEMU: +> New +> +> Bug description: +> QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do the same in master. +> qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic "user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fs,mount_tag=fs -drive "file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" -append "$append" +> +> +> I'm using CI that runs in a Docker container and runs a qemu VM with code and results shared via virtio 9p. +> The 9p fsdev is configured with security_model=mapped-xattr +> When the test code attempts to create a log file in an existing directory, open with O_CREAT fails with -ENOENT. +> +> The relevant strace excerpt is: +> +> 28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20 +> 28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 21 +> 28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0 +> 28791 close(20) = 0 +> 28791 openat(21, "client.log", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20 +> 28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0 +> 28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 4, 0) = -1 ENOENT (No such file or directory) +> +> My hypothesis for what's going wrong is since the Docker container's +> overlayfs copies-up on writes, when it opens the file it's created a +> new version of the `src` directory containing a `client.log`, but this +> new src directory isn't accessible by file descriptor 20 and the +> lsetxattr call is instead attempting to set attributes on the path in +> the old `src` directory. +> +> Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and +> change `local_open2` to instead of calling `local_set_xattrat` to set +> the xattrs by directory file descriptor and file name, to have a +> version of local_set_xattrat` which uses `fsetxattr` to set the virtfs +> attributes instead of the `fsetxattrat_nofollow` helper. +> +> This reliably happened for me in CI, but I don't have access to the CI +> host or the time to strip the test down to make a minimal test case, +> and had difficulty reproducing the error on other machines. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1877384/+subscriptions + + +Yes, that compile error with QEMU + recent kernel headers is a bit annoying, and AFAICS it is not fixed in Debian yet. + +Would you mind writing a test case for this bug that you fixed, to prevent this accidentally being broken in future again? + +Please note that 9pfs is currently only been taken care of by 2 people, and both only on a side channel. The 9pfs code base is complex and error prone to edge cases like this one, so active assistance would be very much appreciated! + +If you might consider writing a test case, I would give you quick, easy and short instructions how to compile the 9pfs test cases, and which source files to touch. There is no guest OS installation required for the test cases. + +Thanks! + +Swamped with other work at the moment, but this hasn't been forgotten. +I might be able to take a look at it next week. + +On Sat, 16 May 2020 at 12:55, Christian Schoenebeck +<email address hidden> wrote: +> +> Yes, that compile error with QEMU + recent kernel headers is a bit +> annoying, and AFAICS it is not fixed in Debian yet. +> +> Would you mind writing a test case for this bug that you fixed, to +> prevent this accidentally being broken in future again? +> +> Please note that 9pfs is currently only been taken care of by 2 people, +> and both only on a side channel. The 9pfs code base is complex and error +> prone to edge cases like this one, so active assistance would be very +> much appreciated! +> +> If you might consider writing a test case, I would give you quick, easy +> and short instructions how to compile the 9pfs test cases, and which +> source files to touch. There is no guest OS installation required for +> the test cases. +> +> Thanks! +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1877384 +> +> Title: +> 9pfs file create with mapped-xattr can fail on overlayfs +> +> Status in QEMU: +> New +> +> Bug description: +> QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do the same in master. +> qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic "user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fs,mount_tag=fs -drive "file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" -append "$append" +> +> +> I'm using CI that runs in a Docker container and runs a qemu VM with code and results shared via virtio 9p. +> The 9p fsdev is configured with security_model=mapped-xattr +> When the test code attempts to create a log file in an existing directory, open with O_CREAT fails with -ENOENT. +> +> The relevant strace excerpt is: +> +> 28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20 +> 28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 21 +> 28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0 +> 28791 close(20) = 0 +> 28791 openat(21, "client.log", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20 +> 28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0 +> 28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 4, 0) = -1 ENOENT (No such file or directory) +> +> My hypothesis for what's going wrong is since the Docker container's +> overlayfs copies-up on writes, when it opens the file it's created a +> new version of the `src` directory containing a `client.log`, but this +> new src directory isn't accessible by file descriptor 20 and the +> lsetxattr call is instead attempting to set attributes on the path in +> the old `src` directory. +> +> Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and +> change `local_open2` to instead of calling `local_set_xattrat` to set +> the xattrs by directory file descriptor and file name, to have a +> version of local_set_xattrat` which uses `fsetxattr` to set the virtfs +> attributes instead of the `fsetxattrat_nofollow` helper. +> +> This reliably happened for me in CI, but I don't have access to the CI +> host or the time to strip the test down to make a minimal test case, +> and had difficulty reproducing the error on other machines. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1877384/+subscriptions + + +Good! Then just for the case ... + +Compiling the 9pfs test cases: + +cd build +make tests/qtest/qos-test + +Running the test cases: + +export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 +tests/qtest/qos-test + +All 9pfs test cases are in: +tests/qtest/virtio-9p-test.c + +The 9pfs test cases are using a simulated filesystem driver called 'synth' driver: +hw/9pfs/9p-synth.c +That 'synth' driver is exclusively used for the 9pfs test cases, it is not used for anything else, so you can add there whatever you need to simulate any file system behaviour required for your test case. + +Fixed in commit d76f4f97eb2772bf85fe286097183d0c7db19ae8 + +Closed by accident, Christian just told me that this is not fixed yet. Sorry for the inconvenience. + +It might be, I revisited a month back and could no longer trigger the +bug, so it's possible unrelated changes or kernel changes have fixed +the overlayfs copy-up semantics in cases where it would cause issues +with QEMU. If I ever see it again I can resubmit evidence, so it may +be better off closed. + +On Thu, 10 Dec 2020 at 12:01, Thomas Huth <email address hidden> wrote: +> +> Closed by accident, Christian just told me that this is not fixed yet. +> Sorry for the inconvenience. +> +> ** Changed in: qemu +> Status: Fix Released => Confirmed +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1877384 +> +> Title: +> 9pfs file create with mapped-xattr can fail on overlayfs +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do the same in master. +> qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic "user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fs,mount_tag=fs -drive "file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" -append "$append" +> +> +> I'm using CI that runs in a Docker container and runs a qemu VM with code and results shared via virtio 9p. +> The 9p fsdev is configured with security_model=mapped-xattr +> When the test code attempts to create a log file in an existing directory, open with O_CREAT fails with -ENOENT. +> +> The relevant strace excerpt is: +> +> 28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20 +> 28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 21 +> 28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0 +> 28791 close(20) = 0 +> 28791 openat(21, "client.log", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20 +> 28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0 +> 28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 4, 0) = -1 ENOENT (No such file or directory) +> +> My hypothesis for what's going wrong is since the Docker container's +> overlayfs copies-up on writes, when it opens the file it's created a +> new version of the `src` directory containing a `client.log`, but this +> new src directory isn't accessible by file descriptor 20 and the +> lsetxattr call is instead attempting to set attributes on the path in +> the old `src` directory. +> +> Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and +> change `local_open2` to instead of calling `local_set_xattrat` to set +> the xattrs by directory file descriptor and file name, to have a +> version of local_set_xattrat` which uses `fsetxattr` to set the virtfs +> attributes instead of the `fsetxattrat_nofollow` helper. +> +> This reliably happened for me in CI, but I don't have access to the CI +> host or the time to strip the test down to make a minimal test case, +> and had difficulty reproducing the error on other machines. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1877384/+subscriptions + + +Good to know. Then it makes sense to close this report for now. Feel free to reopen it if necessary. + +Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/188 b/results/classifier/118/virtual/188 new file mode 100644 index 00000000..4620a08c --- /dev/null +++ b/results/classifier/118/virtual/188 @@ -0,0 +1,31 @@ +virtual: 0.814 +register: 0.801 +architecture: 0.771 +performance: 0.770 +device: 0.739 +mistranslation: 0.723 +network: 0.521 +arm: 0.505 +semantic: 0.488 +graphic: 0.430 +VMM: 0.426 +peripherals: 0.409 +risc-v: 0.349 +debug: 0.336 +i386: 0.323 +x86: 0.317 +permissions: 0.310 +hypervisor: 0.302 +TCG: 0.263 +PID: 0.251 +vnc: 0.242 +ppc: 0.219 +boot: 0.193 +kernel: 0.182 +files: 0.172 +assembly: 0.133 +user-level: 0.106 +KVM: 0.103 +socket: 0.023 + +savevm with hax saves wrong register state diff --git a/results/classifier/118/virtual/1881645 b/results/classifier/118/virtual/1881645 new file mode 100644 index 00000000..fa4b180a --- /dev/null +++ b/results/classifier/118/virtual/1881645 @@ -0,0 +1,39 @@ +virtual: 0.954 +kernel: 0.945 +x86: 0.915 +device: 0.808 +graphic: 0.775 +mistranslation: 0.709 +architecture: 0.657 +VMM: 0.622 +user-level: 0.592 +arm: 0.560 +i386: 0.518 +semantic: 0.502 +network: 0.491 +performance: 0.434 +ppc: 0.327 +debug: 0.302 +boot: 0.289 +register: 0.199 +risc-v: 0.198 +KVM: 0.173 +PID: 0.171 +vnc: 0.164 +hypervisor: 0.150 +socket: 0.144 +TCG: 0.108 +files: 0.087 +assembly: 0.075 +peripherals: 0.074 +permissions: 0.057 + +qemu-system-x86_64 --help (or --version) gives no output + +I have Arch Linux with qemu 5.0.0-6 (seen with pacman). Running VMs work just fine, but when I run qemu-system-x86_64 --version or qemu-system-x86_64 --help, there is no feedback on the screen. This behavior messes up other applications (GNS3 in my case that cannot recognize qemu as correctly installed because there is no feedback. +My kernel is 5.6.11. + +Can you reproduce this problem with the latest upstream version of QEMU, too (currently v6.0)? Otherwise it might be a bug in the version from your distribution, in that case please report it in the bug tracker of your distro instead. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1886208 b/results/classifier/118/virtual/1886208 new file mode 100644 index 00000000..9fa425ee --- /dev/null +++ b/results/classifier/118/virtual/1886208 @@ -0,0 +1,50 @@ +virtual: 0.895 +graphic: 0.869 +architecture: 0.862 +device: 0.816 +i386: 0.789 +semantic: 0.710 +network: 0.680 +mistranslation: 0.619 +PID: 0.601 +boot: 0.584 +files: 0.575 +vnc: 0.539 +performance: 0.522 +permissions: 0.512 +register: 0.506 +hypervisor: 0.503 +socket: 0.500 +VMM: 0.498 +arm: 0.496 +TCG: 0.392 +ppc: 0.390 +kernel: 0.304 +user-level: 0.291 +x86: 0.287 +risc-v: 0.239 +debug: 0.215 +peripherals: 0.208 +assembly: 0.102 +KVM: 0.018 + +[Feature request] Haiku VM image + +We already have handy VMs to build QEMU within: + +$ git grep -l basevm.BaseVM +tests/vm/centos +tests/vm/fedora +tests/vm/freebsd +tests/vm/netbsd +tests/vm/openbsd +tests/vm/ubuntu.i386 + +With David Carlier recent work, we can build QEMU on Haiku OS: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01241.html + +To avoid bitrots it would be useful to have a Haiku VM. + +Haiku image has been included now: +https://gitlab.com/qemu-project/qemu/-/commit/9fc33bf4e1d6942 + diff --git a/results/classifier/118/virtual/1888417 b/results/classifier/118/virtual/1888417 new file mode 100644 index 00000000..f88e2c32 --- /dev/null +++ b/results/classifier/118/virtual/1888417 @@ -0,0 +1,67 @@ +virtual: 0.949 +boot: 0.863 +ppc: 0.859 +vnc: 0.850 +VMM: 0.784 +device: 0.780 +graphic: 0.773 +architecture: 0.771 +user-level: 0.733 +hypervisor: 0.725 +performance: 0.706 +files: 0.700 +PID: 0.686 +semantic: 0.676 +register: 0.668 +peripherals: 0.663 +permissions: 0.632 +risc-v: 0.596 +mistranslation: 0.594 +socket: 0.590 +TCG: 0.577 +arm: 0.574 +network: 0.543 +kernel: 0.528 +debug: 0.521 +x86: 0.445 +i386: 0.425 +KVM: 0.405 +assembly: 0.340 + +Latest QEMU git build on Arch linux causes PCI Passthrough host to hang on guest reboot. + +Current Arch linux release, up-to-date as of 7/21/2020. + +Running a windows 7 virtual machine (also happens with windows 10, possibly more OSes), with an nvidia GTX 1060 passthrough, if the VM is attempted to be restarted, either through the guest interface, or by libvirt's gui interface "Virtual Machine Manager", it hangs in a "paused" state once the VM shutsdown, and just before the reboot can take place. A force-stop of the VM allows the VM to be properly booted without any disk error checks, alluding to a clean shutdown, but failed reboot. The VM can be properly shutdown using the guests shutdown function, or the libvirt manager shutdown, without any hangs. Reverting to Arch stable build QEMU 5.0.0-7 fixes the issue. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1891 b/results/classifier/118/virtual/1891 new file mode 100644 index 00000000..b3b3bf4f --- /dev/null +++ b/results/classifier/118/virtual/1891 @@ -0,0 +1,78 @@ +virtual: 0.954 +graphic: 0.917 +kernel: 0.849 +peripherals: 0.825 +architecture: 0.799 +device: 0.768 +hypervisor: 0.768 +debug: 0.731 +boot: 0.669 +performance: 0.658 +PID: 0.624 +x86: 0.618 +arm: 0.561 +KVM: 0.548 +VMM: 0.505 +ppc: 0.499 +user-level: 0.492 +semantic: 0.482 +register: 0.467 +TCG: 0.428 +permissions: 0.409 +risc-v: 0.393 +vnc: 0.381 +socket: 0.373 +mistranslation: 0.364 +i386: 0.333 +assembly: 0.307 +network: 0.306 +files: 0.270 + +qemu 8.1.0 breaks gvt-g + qemu-ui-gtk w gl=on (black screen, qemu: eglCreateImageKHR failed) +Description of problem: +As of 8.1.0, qemu-ui-gtk renders a black window with the error `qemu: eglCreateImageKHR failed` repeatedly appearing in the command line. + + +# +Steps to reproduce: +1. enable kernel modules, set parameters etc. +2. create vgpu + `echo "$GVT_GUID" > "/sys/devices/pci0000:00/0000:00:02.0/mdev_supported_types/i915-GVTg_V4_2/create"` +3. launch VM +4. wait + +Instructions (a small part of which I wrote by trial and error) for the setup are on the [Arch Wiki](https://wiki.archlinux.org/title/Intel_GVT-g). + +# +Additional information: +Windows is installed directly to a second SSD, I dual-boot it. +I've been using this exact VM, from libvirt, for almost two years. +relevant sections: +``` + <hostdev mode="subsystem" type="mdev" managed="no" model="vfio-pci" display="off"> + <source> + <address uuid="$GVT_GUID"/> + </source> + </hostdev> + </devices> + <qemu:commandline> + <qemu:arg value="-display"/> + <qemu:arg value="gtk,gl=on,zoom-to-fit=off"/> + <qemu:env name="DISPLAY" value=":0.0"/> + </qemu:commandline> + <qemu:override> + <qemu:device alias="hostdev0"> + <qemu:frontend> + <qemu:property name="x-igd-opregion" type="bool" value="true"/> + <qemu:property name="driver" type="string" value="vfio-pci-nohotplug"/> + <qemu:property name="ramfb" type="bool" value="true"/> + <qemu:property name="display" type="string" value="on"/> + <qemu:property name="romfile" type="string" value="/home/user/VM/vbios_gvt_uefi.rom"/> + </qemu:frontend> + </qemu:device> + </qemu:override> +``` + +The patched vBIOS necessary to use DMA-BUF with OVMF is linked there too, but its [successors](https://github.com/patmagauran/i915ovmfPkg) doesn't work either. + +# diff --git a/results/classifier/118/virtual/1894836 b/results/classifier/118/virtual/1894836 new file mode 100644 index 00000000..07a6bb66 --- /dev/null +++ b/results/classifier/118/virtual/1894836 @@ -0,0 +1,85 @@ +virtual: 0.956 +graphic: 0.952 +kernel: 0.951 +boot: 0.918 +performance: 0.916 +files: 0.904 +device: 0.903 +architecture: 0.902 +arm: 0.876 +ppc: 0.873 +vnc: 0.871 +peripherals: 0.853 +PID: 0.847 +network: 0.832 +VMM: 0.829 +x86: 0.814 +TCG: 0.805 +risc-v: 0.782 +permissions: 0.772 +user-level: 0.765 +semantic: 0.752 +socket: 0.734 +hypervisor: 0.728 +assembly: 0.694 +register: 0.684 +mistranslation: 0.673 +KVM: 0.645 +debug: 0.581 +i386: 0.422 + +kernel panic using hvf with CPU passthrough + +Host Details +QEMU 5.1 (Homebrew) +macOS 10.15.6 Catalina +Late 2014 model +i5-4690 @ 3.5 GHz +8 GB RAM + +Guest Details +Ubuntu Desktop 20.04.1 Installer ISO + +Problem +Whenever I boot with "-accel hvf -cpu host", the Ubuntu desktop installer will immediately crash with a kernel panic after the initial splash screen. +See the attached picture of the kernel panic for more details. + +Steps to recreate +From https://www.jwillikers.com/posts/virtualize_ubuntu_desktop_on_macos_with_qemu/ + +1. Install QEMU with Homebrew. +$ brew install qemu + +2. Create a qcow2 disk image to which to install. +$ qemu-img create -f qcow2 ubuntu2004.qcow2 60G + +3. Download the ISO. +$ curl -L -o ubuntu-20.04.1-desktop-amd64.iso https://releases.ubuntu.com/20.04/ubuntu-20.04.1-desktop-amd64.iso + +4. Run the installer in QEMU. +$ qemu-system-x86_64 \ + -accel hvf \ + -cpu host \ + -smp 2 \ + -m 4G \ + -usb \ + -device usb-tablet \ + -vga virtio \ + -display default,show-cursor=on \ + -device virtio-net,netdev=vmnic -netdev user,id=vmnic \ + -audiodev coreaudio,id=snd0 \ + -device ich9-intel-hda -device hda-output,audiodev=snd0 \ + -cdrom ubuntu-20.04.1-desktop-amd64.iso \ + -drive file=ubuntu2004.qcow2,if=virtio + +Workaround +Emulating the CPU with "-cpu qemu64" does not result in a kernel panic. + + + +0f 01 f9 is RDTSCP; use -cpu host,-rdtscp to mask out the feature. KVM couldn't pass the feature through for a while, and HVF currently can't, though HVF should be modified to automatically hide the feature until it can emulate it. + +Thanks for the response Jessica! The option you provided fixes the problem and everything works flawlessly now. Thank you!! + +Fixed in commit 65baabca22366e5246955474228908d6a8354881 + diff --git a/results/classifier/118/virtual/1897568 b/results/classifier/118/virtual/1897568 new file mode 100644 index 00000000..3a7d4b32 --- /dev/null +++ b/results/classifier/118/virtual/1897568 @@ -0,0 +1,103 @@ +virtual: 0.957 +graphic: 0.863 +user-level: 0.849 +mistranslation: 0.800 +semantic: 0.698 +socket: 0.690 +debug: 0.651 +device: 0.609 +architecture: 0.578 +x86: 0.566 +PID: 0.529 +arm: 0.517 +performance: 0.511 +assembly: 0.510 +vnc: 0.508 +hypervisor: 0.467 +register: 0.454 +boot: 0.448 +ppc: 0.443 +permissions: 0.419 +VMM: 0.397 +risc-v: 0.383 +kernel: 0.375 +peripherals: 0.348 +network: 0.316 +i386: 0.311 +TCG: 0.285 +KVM: 0.239 +files: 0.224 + +Strange keyboard behaviour in Vim editor + + +I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a problem with the keyboard in the Vim editor. The arrow keys jump over a line, as if you had typed the key twice. PgUp and PgDn are likewise affected. Other applications are not affected, unless you shell out from Vim. + +The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've tried without it and it doesn't make a difference. + +I don't get this keyboard behaviour in the exact same VM under VMware Player or Bochs. + +-Albert. + +Possible fix: +https://<email address hidden>/msg804823.html + +The patch mentioned by Philippe has now been merged to the QEMU master branch (commit d1e45668d2128b064). Albert, could you maybe check the current git version to see whether this problem has been fixed now (using "-global i8042.kbd-throttle=on" to enable this new feature)? + +Hi, + +thanks for letting me know. + +I do plan to test this and report back, but that may take some time, as I +would first have to compile and install a new version of QEMU. + +-aw + +On Thu, 27 May 2021 at 05:10, Thomas Huth <email address hidden> +wrote: + +> The patch mentioned by Philippe has now been merged to the QEMU master +> branch (commit d1e45668d2128b064). Albert, could you maybe check the +> current git version to see whether this problem has been fixed now +> (using "-global i8042.kbd-throttle=on" to enable this new feature)? +> +> ** Changed in: qemu +> Status: In Progress => Fix Committed +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1897568 +> +> Title: +> Strange keyboard behaviour in Vim editor +> +> Status in QEMU: +> Fix Committed +> +> Bug description: +> +> I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a +> problem with the keyboard in the Vim editor. The arrow keys jump over a +> line, as if you had typed the key twice. PgUp and PgDn are likewise +> affected. Other applications are not affected, unless you shell out from +> Vim. +> +> The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've +> tried without it and it doesn't make a difference. +> +> I don't get this keyboard behaviour in the exact same VM under VMware +> Player or Bochs. +> +> -Albert. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1897568/+subscriptions +> + + +Can someone explain why the patch keeps the incorrect behaviour as the default? It’s silly. + +Felix, if you want to discuss the default behaviour, please get in touch with the author of the patch, since he might not read this bug tracker here. +Anyway, the patch has been released with QEMU 6.1, so I'm closing this ticket here now. + diff --git a/results/classifier/118/virtual/1900352 b/results/classifier/118/virtual/1900352 new file mode 100644 index 00000000..4ae4f4f4 --- /dev/null +++ b/results/classifier/118/virtual/1900352 @@ -0,0 +1,46 @@ +virtual: 0.954 +graphic: 0.915 +hypervisor: 0.880 +device: 0.878 +vnc: 0.872 +debug: 0.860 +performance: 0.840 +network: 0.795 +peripherals: 0.774 +semantic: 0.761 +ppc: 0.705 +architecture: 0.704 +PID: 0.694 +assembly: 0.655 +x86: 0.652 +risc-v: 0.632 +register: 0.629 +VMM: 0.592 +mistranslation: 0.554 +socket: 0.537 +i386: 0.501 +files: 0.493 +TCG: 0.484 +user-level: 0.478 +permissions: 0.468 +KVM: 0.424 +arm: 0.356 +kernel: 0.339 +boot: 0.338 + +no sound in spice when VNC enabled + +Running Fedora32 with virt-manager → libvirt → qemu I noticed that I got no sound in my spice client. The VM is configured with a SPICE-server and a QXL display, and in addition a VNC display. + +Apparently when I remove the VNC display, then the sound is routed just fine to the spice client: I can hear it, and `G_MESSAGES_DEBUG=all remote-viewer --spice-debug spice://localhost:5900` mentions SpicePlaybackChannel and SpiceRecordChannel. With the VNC server configured, such messages are missing, and I cannot hear the sound (which is sent by the guest OS to the virtual hardware). + +What is in the libvirt logs (/var/log/libvirt/qemu/${guest}.log) ? + +If VNC is enabled, then libvirt sets QEMU_AUDIO_DRV=none unless /etc/libvirt/qemu.conf is set to allow output to host audio. + +Clearly this doesn't do the right thing when SPICE is present at the same time as VNC, but that's libvirt's fault rather than QEMU. + +So if this is libvirt's fault, can we close this ticket here? Has anybody already reported this to in the libvirt bug tracker? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1906295 b/results/classifier/118/virtual/1906295 new file mode 100644 index 00000000..9efb1a2e --- /dev/null +++ b/results/classifier/118/virtual/1906295 @@ -0,0 +1,54 @@ +virtual: 0.920 +architecture: 0.885 +device: 0.861 +arm: 0.830 +user-level: 0.724 +performance: 0.703 +semantic: 0.675 +mistranslation: 0.648 +graphic: 0.646 +debug: 0.624 +ppc: 0.594 +network: 0.587 +kernel: 0.584 +assembly: 0.581 +permissions: 0.581 +PID: 0.565 +hypervisor: 0.546 +risc-v: 0.543 +vnc: 0.538 +files: 0.534 +VMM: 0.533 +x86: 0.528 +register: 0.526 +peripherals: 0.519 +socket: 0.516 +TCG: 0.475 +KVM: 0.440 +i386: 0.427 +boot: 0.402 + +Implementation of exclusive monitor in ARM + +Hi + +I refer to the implementation of exclusive monitor in ARM32. For instruction like STREX Rx,Ry,[Rz], we need to check whether the address [Rz] is in exclusive state. If not, we set the value Rx as 1 without doing the store operation. However, I noticed that QEMU will not check whether the address that Rz points to is a legal address or not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU will set Rx as 1 and continue to execute the following instructions. + +However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. +Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks + +Regards +Muhui + +QEMU's load/store exclusive implementation is known to not be architecturally compliant. Most notably, it works on virtual addresses and the architecture specifies that exclusives are supposed to work on physical addresses. We provide a "good enough for what real code (not weird test cases) needs" implementation. + +However, in this specific case, we're within the architectural requirements. In the ARMv8A Arm ARM (DDI0487F.c) the pseudocode AArch32.ExclusiveMonitorsPass() function has this comment: + +// It is IMPLEMENTATION DEFINED whether the detection of memory aborts happens +// before or after the check on the local Exclusives monitor. As a result a failure +// of the local monitor can occur on some implementations even if the memory +// access would give a memory about. + +In other words, it's up to the implementation whether it detects and reports the invalid address first. QEMU's implementation chooses not to. + + diff --git a/results/classifier/118/virtual/1907776 b/results/classifier/118/virtual/1907776 new file mode 100644 index 00000000..6192bb6e --- /dev/null +++ b/results/classifier/118/virtual/1907776 @@ -0,0 +1,88 @@ +virtual: 0.946 +graphic: 0.878 +architecture: 0.818 +boot: 0.772 +x86: 0.754 +vnc: 0.740 +files: 0.728 +user-level: 0.718 +device: 0.687 +KVM: 0.658 +permissions: 0.643 +PID: 0.638 +hypervisor: 0.626 +semantic: 0.624 +VMM: 0.623 +kernel: 0.614 +network: 0.613 +mistranslation: 0.613 +performance: 0.592 +ppc: 0.580 +register: 0.564 +assembly: 0.561 +risc-v: 0.549 +TCG: 0.523 +socket: 0.521 +peripherals: 0.519 +arm: 0.515 +debug: 0.491 +i386: 0.464 + +Mounting VFat drive yields error messages. + +Mounting a virtual Fat drive results in error messages (see attached image). + +* https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images + +The "drive" is however mounted, and as a test, saving a text file to the drive is successfully stored in the directory `/tmp`, which can be read after shutdown of Qemu. + + Archlinux 5.9.11-arch2-1 (64-bit) + qemu-headless 5.1.0-3 + + qemu-system-x86_64 -boot order=d -name test \ + -enable-kvm -m 2G -cpu host -k sv \ + -daemonize \ + -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ + -drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \ + -drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \ + -vnc :1 \ + -cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \ + -drive format=raw,index=0,media=disk,file=~/vm/qemu.raw + + + +I have just noticed that the error does not appear when mounting the VFat drive in the installed instance of Arch Linux. The reported error messages occurred when using the "LiveUSB". + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1910603 b/results/classifier/118/virtual/1910603 new file mode 100644 index 00000000..7de3c039 --- /dev/null +++ b/results/classifier/118/virtual/1910603 @@ -0,0 +1,251 @@ +virtual: 0.921 +permissions: 0.917 +hypervisor: 0.894 +i386: 0.889 +semantic: 0.887 +register: 0.883 +peripherals: 0.874 +assembly: 0.873 +device: 0.868 +KVM: 0.863 +vnc: 0.863 +risc-v: 0.861 +TCG: 0.859 +debug: 0.857 +user-level: 0.855 +graphic: 0.850 +arm: 0.849 +architecture: 0.840 +VMM: 0.833 +PID: 0.832 +ppc: 0.828 +performance: 0.818 +boot: 0.806 +mistranslation: 0.771 +kernel: 0.732 +x86: 0.731 +files: 0.662 +network: 0.623 +socket: 0.595 + +[OSS-Fuzz] Issue 29174 sb16: Abrt in audio_bug + +=== Reproducer === +cat << EOF | ../build-system/qemu-system-i386 \ +-machine q35 -device sb16,audiodev=snd0 \ +-audiodev none,id=snd0 -nographic -nodefaults \ +-qtest stdio +outw 0x22c 0x41 +outb 0x22c 0x0 +outw 0x22c 0x1004 +outw 0x22c 0x1c +EOF + +=== Stack Trace === +A bug was just triggered in audio_calloc +Save all your work and restart without audio +I am sorry +Context: +Aborted + +#0 raise +#1 abort +#2 audio_bug /src/qemu/audio/audio.c:119:9 +#3 audio_calloc /src/qemu/audio/audio.c:154:9 +#4 audio_pcm_sw_alloc_resources_out /src/qemu/audio/audio_template.h:116:15 +#5 audio_pcm_sw_init_out /src/qemu/audio/audio_template.h:175:11 +#6 audio_pcm_create_voice_pair_out /src/qemu/audio/audio_template.h:410:9 +#7 AUD_open_out /src/qemu/audio/audio_template.h:503:14 +#8 continue_dma8 /src/qemu/hw/audio/sb16.c:216:20 +#9 dma_cmd8 /src/qemu/hw/audio/sb16.c:276:5 +#10 command /src/qemu/hw/audio/sb16.c:0 +#11 dsp_write /src/qemu/hw/audio/sb16.c:949:13 +#12 portio_write /src/qemu/softmmu/ioport.c:205:13 +#13 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#14 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#15 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#16 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#17 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#18 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#19 cpu_outw /src/qemu/softmmu/ioport.c:70:5 + + +OSS-Fuzz Report: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29174 + +This is still reproducible with the current version of QEMU. Marking this as "Confirmed" + +While the SB16 seems to work up to 48000 Hz, the "Sound Blaster Series +Hardware Programming Guide" limit the sampling range from 4000 Hz to +44100 Hz (Section 3-9, 3-10: Digitized Sound I/O Programming, tables +3-2 and 3-3). + +Later, section 6-15 (DSP Commands) is more specific regarding the 41h / +42h registers (Set digitized sound output sampling rate): + + Valid sampling rates range from 5000 to 45000 Hz inclusive. + +There is no comment regarding error handling if the register is filled +with an out-of-range value. (See also section 3-28 "8-bit or 16-bit +Auto-initialize Transfer"). Assume limits are enforced in hardware. + +This fixes triggering an assertion in audio_calloc(): + + #1 abort + #2 audio_bug audio/audio.c:119:9 + #3 audio_calloc audio/audio.c:154:9 + #4 audio_pcm_sw_alloc_resources_out audio/audio_template.h:116:15 + #5 audio_pcm_sw_init_out audio/audio_template.h:175:11 + #6 audio_pcm_create_voice_pair_out audio/audio_template.h:410:9 + #7 AUD_open_out audio/audio_template.h:503:14 + #8 continue_dma8 hw/audio/sb16.c:216:20 + #9 dma_cmd8 hw/audio/sb16.c:276:5 + #10 command hw/audio/sb16.c:0 + #11 dsp_write hw/audio/sb16.c:949:13 + #12 portio_write softmmu/ioport.c:205:13 + #13 memory_region_write_accessor softmmu/memory.c:491:5 + #14 access_with_adjusted_size softmmu/memory.c:552:18 + #15 memory_region_dispatch_write softmmu/memory.c:0:13 + #16 flatview_write_continue softmmu/physmem.c:2759:23 + #17 flatview_write softmmu/physmem.c:2799:14 + #18 address_space_write softmmu/physmem.c:2891:18 + #19 cpu_outw softmmu/ioport.c:70:5 + +[*] http://www.baudline.com/solutions/full_duplex/sb16_pci/index.html + +Fixes: 85571bc7415 ("audio merge (malc)") +Buglink: https://bugs.launchpad.net/bugs/1910603 +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29174 +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- + hw/audio/sb16.c | 14 ++++++++++ + tests/qtest/fuzz-sb16-test.c | 52 ++++++++++++++++++++++++++++++++++++ + MAINTAINERS | 1 + + tests/qtest/meson.build | 1 + + 4 files changed, 68 insertions(+) + create mode 100644 tests/qtest/fuzz-sb16-test.c + +diff --git a/hw/audio/sb16.c b/hw/audio/sb16.c +index 8b207004102..5cf121fe363 100644 +--- a/hw/audio/sb16.c ++++ b/hw/audio/sb16.c +@@ -115,6 +115,9 @@ struct SB16State { + PortioList portio_list; + }; + ++#define SAMPLE_RATE_MIN 5000 ++#define SAMPLE_RATE_MAX 45000 ++ + static void SB_audio_callback (void *opaque, int free); + + static int magic_of_irq (int irq) +@@ -241,6 +244,17 @@ static void dma_cmd8 (SB16State *s, int mask, int dma_len) + int tmp = (256 - s->time_const); + s->freq = (1000000 + (tmp / 2)) / tmp; + } ++ if (s->freq < SAMPLE_RATE_MIN) { ++ qemu_log_mask(LOG_GUEST_ERROR, ++ "sampling range too low: %d, increasing to %u\n", ++ s->freq, SAMPLE_RATE_MIN); ++ s->freq = SAMPLE_RATE_MIN; ++ } else if (s->freq > SAMPLE_RATE_MAX) { ++ qemu_log_mask(LOG_GUEST_ERROR, ++ "sampling range too high: %d, decreasing to %u\n", ++ s->freq, SAMPLE_RATE_MAX); ++ s->freq = SAMPLE_RATE_MAX; ++ } + + if (dma_len != -1) { + s->block_size = dma_len << s->fmt_stereo; +diff --git a/tests/qtest/fuzz-sb16-test.c b/tests/qtest/fuzz-sb16-test.c +new file mode 100644 +index 00000000000..51030cd7dc4 +--- /dev/null ++++ b/tests/qtest/fuzz-sb16-test.c +@@ -0,0 +1,52 @@ ++/* ++ * QTest fuzzer-generated testcase for sb16 audio device ++ * ++ * Copyright (c) 2021 Philippe Mathieu-Daudé <email address hidden> ++ * ++ * SPDX-License-Identifier: GPL-2.0-or-later ++ */ ++ ++#include "qemu/osdep.h" ++#include "libqos/libqtest.h" ++ ++/* ++ * This used to trigger the assert in audio_calloc ++ * https://bugs.launchpad.net/qemu/+bug/1910603 ++ */ ++static void test_fuzz_sb16_0x1c(void) ++{ ++ QTestState *s = qtest_init("-M q35 -display none " ++ "-device sb16,audiodev=snd0 " ++ "-audiodev none,id=snd0"); ++ qtest_outw(s, 0x22c, 0x41); ++ qtest_outb(s, 0x22c, 0x00); ++ qtest_outw(s, 0x22c, 0x1004); ++ qtest_outw(s, 0x22c, 0x001c); ++ qtest_quit(s); ++} ++ ++static void test_fuzz_sb16_0x91(void) ++{ ++ QTestState *s = qtest_init("-M pc -display none " ++ "-device sb16,audiodev=none " ++ "-audiodev id=none,driver=none"); ++ qtest_outw(s, 0x22c, 0xf141); ++ qtest_outb(s, 0x22c, 0x00); ++ qtest_outb(s, 0x22c, 0x24); ++ qtest_outb(s, 0x22c, 0x91); ++ qtest_quit(s); ++} ++ ++int main(int argc, char **argv) ++{ ++ const char *arch = qtest_get_arch(); ++ ++ g_test_init(&argc, &argv, NULL); ++ ++ if (strcmp(arch, "i386") == 0) { ++ qtest_add_func("fuzz/test_fuzz_sb16/1c", test_fuzz_sb16_0x1c); ++ qtest_add_func("fuzz/test_fuzz_sb16/91", test_fuzz_sb16_0x91); ++ } ++ ++ return g_test_run(); ++} +diff --git a/MAINTAINERS b/MAINTAINERS +index 5f55404f2fa..7edb26d2293 100644 +--- a/MAINTAINERS ++++ b/MAINTAINERS +@@ -2213,6 +2213,7 @@ F: qapi/audio.json + F: tests/qtest/ac97-test.c + F: tests/qtest/es1370-test.c + F: tests/qtest/intel-hda-test.c ++F: tests/qtest/fuzz-sb16-test.c + + Block layer core + M: Kevin Wolf <email address hidden> +diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build +index c3a223a83d6..b03e8541700 100644 +--- a/tests/qtest/meson.build ++++ b/tests/qtest/meson.build +@@ -20,6 +20,7 @@ + qtests_generic = \ + (config_all_devices.has_key('CONFIG_MEGASAS_SCSI_PCI') ? ['fuzz-megasas-test'] : []) + \ + (config_all_devices.has_key('CONFIG_VIRTIO_SCSI') ? ['fuzz-virtio-scsi-test'] : []) + \ ++ (config_all_devices.has_key('CONFIG_SB16') ? ['fuzz-sb16-test'] : []) + \ + [ + 'cdrom-test', + 'device-introspect-test', +-- +2.26.3 + + + +OSS-Fuzz confirms this is fixed: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30574#c4 + +Fixed by: +https://gitlab.com/qemu-project/qemu/-/commit/a2cd86a94a881b38a7d8bb67c619 + diff --git a/results/classifier/118/virtual/1911351 b/results/classifier/118/virtual/1911351 new file mode 100644 index 00000000..0a71b552 --- /dev/null +++ b/results/classifier/118/virtual/1911351 @@ -0,0 +1,137 @@ +virtual: 0.856 +permissions: 0.842 +graphic: 0.839 +semantic: 0.838 +architecture: 0.838 +kernel: 0.820 +debug: 0.816 +arm: 0.814 +device: 0.811 +register: 0.808 +performance: 0.802 +assembly: 0.802 +risc-v: 0.789 +PID: 0.782 +x86: 0.779 +network: 0.775 +mistranslation: 0.764 +VMM: 0.754 +TCG: 0.752 +user-level: 0.749 +vnc: 0.742 +files: 0.736 +boot: 0.735 +socket: 0.735 +ppc: 0.721 +peripherals: 0.713 +KVM: 0.709 +hypervisor: 0.621 +i386: 0.590 + +x86-64 MTTCG Does not update page table entries atomically + +It seems like the qemu tcg code for x86-64 doesn't write the access and dirty flags of the page table entries atomically. Instead, they first read the entry, see if they need to set the page table entry, and then overwrite the entry. So if you have two threads running at the same time, one accessing the virtual address over and over again, and the other modifying the page table entry, it is possible that after the second thread modifies the page table entry, qemu overwrites the value with the old page table entry value, with the access/dirty flags set. + +Here's a unit test that reproduces this behavior: + +https://github.com/mvanotti/kvm-unit-tests/commit/09f9722807271226a714b04f25174776454b19cd + +You can run it with: + +``` +/usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \ +-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \ +-vnc none -serial stdio -device pci-testdev \ +-smp 4 -machine q35 --accel tcg,thread=multi \ +-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf +``` + +Expected output (failure): + +``` +kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf +enabling apic +enabling apic +enabling apic +enabling apic +paging enabled +cr0 = 80010011 +cr3 = 627000 +cr4 = 20 +found 4 cpus +PASS: Need more than 1 CPU +Detected overwritten PTE: + want: 0x000000000062e007 + got: 0x000000000062d027 +FAIL: PTE not overwritten +PASS: All Reads were zero +SUMMARY: 3 tests, 1 unexpected failures +``` + +This bug has allows user-to-root privilege escalation inside the guest VM: if the user is able overwrite an entry that belongs to a second-to-last level page table, and is able to allocate the referenced page, then the user would be in control of a last-level page table, being able to map any memory they want. This is not uncommon in situations where memory is being decomitted. + +Yeah, it's a long standing API deficiency inside QEMU that we don't have a way to do atomic modifications in things like page-table-walk code: mostly you don't notice unless you go looking for it, but we really ought to fix this. Thanks for the unit test. + + +Not strictly i386 specific -- any arch that wants to do read-modify-update to its page tables runs into this. There are some not-yet-implemented Arm architecture extensions that require this, and likely other archs too. + + +We only tested it on x86-64 and aarch64, but we couldn't repro on arm. It is possible that this affects other platforms as well, but note that this is specifically mentioned in the qemu wiki as one of the cases that should be covered when porting mttcg to a new platform: https://wiki.qemu.org/Features/tcg-multithread + +BTW, the RISC-V MMU code _does_ get this right and the model could be followed by the x86 version - - something like https://github.com/vsrinivas/qemu/commit/1efa7dc689c4572d8fe0880ddbe44ec22f8f4348, (but with more compiling + working) might solve this problem and more closely model h/w. + +On Tue, 2 Feb 2021 at 05:07, Venkatesh Srinivas +<email address hidden> wrote: +> BTW, the RISC-V MMU code _does_ get this right and the model could be +> followed by the x86 version - - something like +> https://github.com/vsrinivas/qemu/commit/1efa7dc689c4572d8fe0880ddbe44ec22f8f4348, +> (but with more compiling + working) might solve this problem and more +> closely model h/w + +target/i386 is the wrong place to put the fix, though: +the abstraction layers for working with AddressSpaces need to +provide atomic operations and then under the hood do the right +thing to implement them. target-specific code shouldn't need +to manually do the translation, fish out a MemoryRegion, +check whether it's really host RAM, and so on. + +thanks +-- PMM + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +This issue has been migrated to gitlab issue #279. See https://gitlab.com/qemu-project/qemu/-/issues/279 + +Closing issue as it has been migrated to https://gitlab.com/qemu-project/qemu/-/issues/279 + +Closing issue as it has been migrated to https://gitlab.com/qemu-project/qemu/-/issues/279 + diff --git a/results/classifier/118/virtual/1911797 b/results/classifier/118/virtual/1911797 new file mode 100644 index 00000000..e1bf6aca --- /dev/null +++ b/results/classifier/118/virtual/1911797 @@ -0,0 +1,57 @@ +mistranslation: 0.996 +virtual: 0.987 +device: 0.921 +network: 0.877 +graphic: 0.873 +performance: 0.856 +semantic: 0.801 +peripherals: 0.729 +arm: 0.691 +assembly: 0.684 +ppc: 0.649 +hypervisor: 0.647 +VMM: 0.640 +socket: 0.602 +vnc: 0.542 +architecture: 0.538 +debug: 0.519 +PID: 0.511 +KVM: 0.506 +risc-v: 0.466 +kernel: 0.451 +i386: 0.405 +user-level: 0.374 +TCG: 0.362 +x86: 0.333 +register: 0.309 +files: 0.285 +permissions: 0.283 +boot: 0.281 + +hmp command `hostfwd_remove` does not work on running vm + +On a running VM, I ran the following two hmp commands: + +"hostfwd_add tcp::43210-:43210" --> WORKS +'hostfwd_remove tcp::43210-:43210" --> DOES NOT WORK. returns 'invalid format' + +QEMU version 5.1 + +Looks like intended behavior: + +(qemu) help hostfwd_add +hostfwd_add [netdev_id] [tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport -- redirect TCP or UDP connections from host to guest (requires -net user) +(qemu) help hostfwd_remove +hostfwd_remove [netdev_id] [tcp|udp]:[hostaddr]:hostport -- remove host-to-guest TCP or UDP redirection + + +Not sure I understand. The intended behavior is to remove the ports. It doesn't do that. And it returns 'invalid format'. + +(qemu) hostfwd_add tcp::43210-:43210 +(qemu) hostfwd_remove tcp::43210-:43210 +invalid format + +My bad. The correct command is this: +(qemu) hostfwd_remove tcp::43210 +This bug can be closed. + diff --git a/results/classifier/118/virtual/1916506 b/results/classifier/118/virtual/1916506 new file mode 100644 index 00000000..4219c6f2 --- /dev/null +++ b/results/classifier/118/virtual/1916506 @@ -0,0 +1,79 @@ +virtual: 0.865 +graphic: 0.856 +files: 0.774 +semantic: 0.763 +hypervisor: 0.744 +mistranslation: 0.724 +user-level: 0.708 +device: 0.700 +PID: 0.691 +performance: 0.681 +architecture: 0.678 +register: 0.676 +vnc: 0.628 +permissions: 0.627 +network: 0.610 +debug: 0.573 +risc-v: 0.556 +x86: 0.541 +ppc: 0.541 +i386: 0.540 +TCG: 0.539 +peripherals: 0.537 +kernel: 0.533 +VMM: 0.519 +assembly: 0.491 +KVM: 0.477 +socket: 0.474 +arm: 0.465 +boot: 0.377 + +make check-venv may leave stale and incomplete tests/venv directory directory + +As reported by "Philippe Mathieu-Daudé" <email address hidden>, a "make check-venv" can be run and fail to properly create a suitable virtual environment, leaving the tests/venv directory which is the target for "make check-venv" itself. + +This means that on a subsequent run: + +> $ make check-venv +> GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3 +> tests/fp/berkeley-softfloat-3 dtc capstone slirp +> make: Nothing to be done for 'check-venv'. + +And the venv will still be incomplete. The causes of such failures to create a suitable virtual environment are too many (in the reported case it was because of missing *required* Python packages). Some more evolved virtual environments + Python packaging systems exist that could probably be used here (Pipenv) but would add further core requirements. + +The current mitigation is to run "make check-clean" when the venv appears to be incomplete. + +The goal of this bug is to attempt to make the venv setup atomic and more reliable. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/1929 b/results/classifier/118/virtual/1929 new file mode 100644 index 00000000..0b15cac1 --- /dev/null +++ b/results/classifier/118/virtual/1929 @@ -0,0 +1,51 @@ +virtual: 0.973 +register: 0.936 +device: 0.900 +semantic: 0.875 +graphic: 0.850 +debug: 0.813 +hypervisor: 0.795 +performance: 0.650 +vnc: 0.639 +user-level: 0.611 +architecture: 0.601 +ppc: 0.599 +arm: 0.547 +PID: 0.527 +network: 0.457 +boot: 0.453 +kernel: 0.449 +socket: 0.448 +risc-v: 0.444 +TCG: 0.412 +mistranslation: 0.383 +VMM: 0.381 +files: 0.343 +permissions: 0.316 +i386: 0.248 +peripherals: 0.208 +x86: 0.205 +assembly: 0.203 +KVM: 0.088 + +regression: 7.0.0 breaks registering process subreaper on Apple silicon +Description of problem: +When running any container on the QEMU virtual guest that is using a utility like `tini` which is trying to register itself as a process subreaper I get an error message like this: + +``` +[FATAL tini (1)] PR_SET_CHILD_SUBREAPER is unavailable on this platform. Are you using Linux >= 3.4? +``` + +The issue has been observed by multiple people on Apple silicon Macs, e.g. in these issues: +https://github.com/docker/for-mac/issues/6620#issuecomment-1694380189 +https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/issues/1735 +Steps to reproduce: +1. Install QEMU 7.0.0+ on an Apple silicon MAC +2. Run a virtual guest +3. Try to register a process subreaper, e.g. like `tini -s` does +Additional information: +the issue was introduced in QEMU 7.0.0 with this commit: +https://gitlab.com/qemu-project/qemu/-/commit/220717a6f46a99031a5b1af964bbf4dec1310440 + +tini readme talking about process subreaping: +https://github.com/krallin/tini#subreaping diff --git a/results/classifier/118/virtual/1945540 b/results/classifier/118/virtual/1945540 new file mode 100644 index 00000000..fc5e9879 --- /dev/null +++ b/results/classifier/118/virtual/1945540 @@ -0,0 +1,205 @@ +register: 0.952 +virtual: 0.933 +device: 0.928 +architecture: 0.926 +semantic: 0.925 +files: 0.923 +debug: 0.919 +graphic: 0.917 +PID: 0.910 +assembly: 0.906 +user-level: 0.899 +network: 0.895 +permissions: 0.890 +mistranslation: 0.887 +peripherals: 0.885 +x86: 0.878 +arm: 0.863 +risc-v: 0.847 +socket: 0.846 +KVM: 0.833 +kernel: 0.833 +performance: 0.827 +ppc: 0.823 +vnc: 0.798 +TCG: 0.785 +hypervisor: 0.737 +VMM: 0.667 +boot: 0.621 +i386: 0.467 + +Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8' + +Host environment + +- Operating system: Ubuntu 20.04.3 LTS Desktop +- OS/kernel version: Linux tower 5.11.0-37-generic #41~20.04.2-Ubuntu + SMP Fri Sep 24 09:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux +- Architecture: amd64 +- QEMU flavor: qemu-system-s390x +- QEMU version: QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.17) +- QEMU command line: See attached file 'command-line.txt' + +Emulated/Virtualized environment + +- Operating system: Ubuntu 20.04.3 LTS Server +- OS/kernel version: Linux s390x-focal 5.4.0-88-generic #99-Ubuntu + SMP Thu Sep 23 17:27:44 UTC 2021 s390x s390x s390x GNU/Linux +- Architecture: s390x + +Description of problem + +Java crashes as shown below: + +$ java --version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x000003ff9f5fe6f4, pid=6789, tid=6818 +# +# JRE version: (17.0+35) (build ) +# Java VM: OpenJDK 64-Bit Server VM (17+35-snap, mixed mode, sharing, +# tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) +# Problematic frame: +# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 +# +# Core dump will be written. Default location: core.6789 (may not +# exist) +# +# An error report file with more information is saved as: +# /home/ubuntu/src/hs_err_pid6789.log +# +# +Aborted (core dumped) + +Steps to reproduce + +Run any Java program to reproduce the problem. + +Because the 'openjdk' packages in Ubuntu run the 'java' command during installation, they hit the same error and fail to install. As an alternative, you can install the OpenJDK Snap package for the 's390x' architecture as follows: + + $ sudo snap install openjdk + +The OpenJDK Snap package has been tested to work on a real IBM/S390 8561 system, namely the IBM LinuxONE III LT1 at Marist College: + + Marist College Installs World’s First IBM LinuxONE III™ + https://www.marist.edu/-/marist-first-linuxone-iii + +Additional information + +See the following attached files: + +command-line.txt - the command-line used to start the virtual machine +hs_err_pid6789.log - the log file resulting from 'java --version' + + + + + +I just tried the same s390x virtual machine under QEMU version 6.0.0 in the Ubuntu 21.10 Beta release, and the error still occurs. My system information is shown below: + +$ qemu-system-s390x --version +QEMU emulator version 6.0.0 (Debian 1:6.0+dfsg-2expubuntu1) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +$ cat /etc/lsb-release +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=21.10 +DISTRIB_CODENAME=impish +DISTRIB_DESCRIPTION="Ubuntu Impish Indri (development branch)" + +$ uname -a +Linux ubuntu 5.13.0-16-generic #16-Ubuntu SMP Fri Sep 3 14:53:27 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux + + +There were some fixes in QEMU v6.1. Please try that one to see whether it solves your problem, too. + +The error still occurs on the same s390x virtual machine with QEMU version 6.1. + +After building QEMU 6.1, I started the virtual machine as follows: + + $ ../qemu-6.1.0/build/s390x-softmmu/qemu-system-s390x \ + -m 2048 -drive if=virtio,file=s390x-focal.qcow2,cache=none + +The QEMU 6.1.0 monitor shows: + + (qemu) info version + 6.1.0 + +On the guest, I installed the new 'openjdk-17-jre-headless' OpenJDK 17 package in Ubuntu 20.04. Although the installation fails because of this bug, the 'java' command is available after the attempt to install the package. + + $ sudo apt-get install openjdk-17-jre-headless + +The error in this bug report still occurs: + + $ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version + # + # A fatal error has been detected by the Java Runtime Environment: + # + # SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884 + # + # JRE version: (17.0+35) (build ) + # Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed + # mode, sharing, tiered, compressed oops, compressed class ptrs, + # serial gc, linux-s390x) + # Problematic frame: + # C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 + # + # Core dump will be written. Default location: Core dumps may + # be processed with "/usr/share/apport/apport %p %s %c %d %P %E" + # (or dumping to /home/ubuntu/core.2883) + # + # An error report file with more information is saved as: + # /home/ubuntu/hs_err_pid2883.log + # + # + Aborted (core dumped) + +I'll also attach the corresponding log file. + +For reference, the guest shows the following CPU information under QEMU 6.1. + + $ lscpu + Architecture: s390x + CPU op-mode(s): 32-bit, 64-bit + Byte Order: Big Endian + CPU(s): 1 + On-line CPU(s) list: 0 + Thread(s) per core: 1 + Core(s) per socket: 1 + Socket(s) per book: 1 + Book(s) per drawer: 1 + Drawer(s): 1 + NUMA node(s): 1 + Vendor ID: IBM/S390 + Machine type: 3906 + BogoMIPS: 13370.00 + Hypervisor: KVM/Linux + Hypervisor vendor: KVM + Virtualization type: full + Dispatching mode: horizontal + NUMA node0 CPU(s): 0 + ... + + + + +Now that I can reproduce the problem on the latest QEMU 6.1, I created the following issue with the upstream project: + +Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8' +https://gitlab.com/qemu-project/qemu/-/issues/655 + + +Thank you John, +emulation on s390x is imperfect at times - the JVM might just use a non emulated instruction or something like that. I've linked your upstream report (thanks) here to that the bug automatically gets updates from there. + +Do we already happen to know at which (maybe always the same) instruction sequence this crashes? + +For more history on this issue, please see the following Debian bug report created in June 2021: + +openjdk-11-jre-headless: running java in qemu s390 gives a SIGILL at C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990417 + +That report links to a simple C program that can reproduce the error. + + diff --git a/results/classifier/118/virtual/2025586 b/results/classifier/118/virtual/2025586 new file mode 100644 index 00000000..ebccc768 --- /dev/null +++ b/results/classifier/118/virtual/2025586 @@ -0,0 +1,74 @@ +virtual: 0.942 +x86: 0.918 +device: 0.909 +performance: 0.848 +kernel: 0.791 +mistranslation: 0.776 +architecture: 0.766 +PID: 0.762 +hypervisor: 0.751 +files: 0.750 +graphic: 0.749 +KVM: 0.740 +semantic: 0.693 +VMM: 0.691 +network: 0.663 +socket: 0.650 +permissions: 0.640 +ppc: 0.609 +register: 0.609 +peripherals: 0.598 +vnc: 0.593 +debug: 0.551 +user-level: 0.549 +risc-v: 0.548 +TCG: 0.454 +arm: 0.429 +boot: 0.399 +i386: 0.377 +assembly: 0.250 + +Align the iov length to the logical block size + +[Impact] +When the logical block size of the virtual block device is smaller than the block device it is backed by on the host, +qemu encounters a situation where it needs to bounce unaligned buffers during the use of direct IO. +In the past, the logical block size happened to align with the memory page offset, leading qemu to mistakenly use the memory offset as the block size. +However, a kernel commit b1a000d3b8ec resolved this issue by separating memory alignment from the logical block size. +As a result, qemu now has an incorrect understanding of the minimum vector size. + +[Fix] +Upstream commit 25474d90aa50 fixed this issue. +========== +Author: Keith Busch <email address hidden> +CommitDate: Fri Sep 30 18:43:44 2022 +0200 + + block: use the request length for iov alignment + + An iov length needs to be aligned to the logical block size, which may + be larger than the memory alignment. + + Tested-by: Jens Axboe <email address hidden> + Signed-off-by: Keith Busch <email address hidden> + Message-Id: <email address hidden> + Reviewed-by: Kevin Wolf <email address hidden> + Signed-off-by: Kevin Wolf <email address hidden> +========== + +[Test Plan] +1. Get a ubuntu image and convert it to RAW format +wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img +qemu-img convert jammy-server-cloudimg-amd64-disk-kvm.img jammy-server-cloudimg-amd64-disk-kvm.raw +2. Set up a loop device with RAW image +losetup -b 4096 -f jammy-server-cloudimg-amd64-disk-kvm.raw +3. Get loop device number by `losetup -a` command +4. Start the virtual machine +qemu-system-x86_64 -enable-kvm -drive file=/dev/loopX,format=raw,cache=none --nographic + +[Where problems could occur] +The patch addressed the issue of misusing the memory offset as the block size. +This problem only occurred when the cache option was set to "none" and the Linux kernel being used had the commit b1a000d3b8ec. +However, it is worth noting that the patch also worked effectively with older kernels. + +[Other Info] + diff --git a/results/classifier/118/virtual/2045 b/results/classifier/118/virtual/2045 new file mode 100644 index 00000000..62d7349d --- /dev/null +++ b/results/classifier/118/virtual/2045 @@ -0,0 +1,31 @@ +virtual: 0.966 +device: 0.757 +architecture: 0.589 +semantic: 0.558 +performance: 0.539 +mistranslation: 0.397 +graphic: 0.386 +TCG: 0.382 +ppc: 0.366 +debug: 0.364 +boot: 0.332 +peripherals: 0.331 +register: 0.299 +i386: 0.255 +x86: 0.231 +VMM: 0.210 +vnc: 0.188 +arm: 0.170 +assembly: 0.141 +PID: 0.131 +permissions: 0.121 +network: 0.099 +kernel: 0.070 +files: 0.060 +KVM: 0.046 +user-level: 0.036 +socket: 0.024 +risc-v: 0.009 +hypervisor: 0.006 + +virtio-gpu-*-pci Support reset of virtual GPU from /sys/bus/pci/devices/$NUMBER/reset diff --git a/results/classifier/118/virtual/2051 b/results/classifier/118/virtual/2051 new file mode 100644 index 00000000..3716c776 --- /dev/null +++ b/results/classifier/118/virtual/2051 @@ -0,0 +1,31 @@ +virtual: 0.942 +device: 0.898 +performance: 0.800 +network: 0.692 +debug: 0.619 +graphic: 0.523 +hypervisor: 0.379 +boot: 0.352 +risc-v: 0.340 +vnc: 0.283 +VMM: 0.222 +semantic: 0.203 +ppc: 0.189 +TCG: 0.178 +architecture: 0.152 +user-level: 0.130 +PID: 0.129 +mistranslation: 0.123 +arm: 0.115 +register: 0.094 +peripherals: 0.079 +i386: 0.059 +kernel: 0.041 +KVM: 0.035 +files: 0.022 +permissions: 0.019 +x86: 0.018 +socket: 0.017 +assembly: 0.014 + +virtio-gpu redraw issue diff --git a/results/classifier/118/virtual/2072 b/results/classifier/118/virtual/2072 new file mode 100644 index 00000000..e5a78e56 --- /dev/null +++ b/results/classifier/118/virtual/2072 @@ -0,0 +1,31 @@ +virtual: 0.930 +hypervisor: 0.833 +architecture: 0.815 +device: 0.810 +performance: 0.707 +arm: 0.613 +network: 0.604 +VMM: 0.532 +risc-v: 0.532 +vnc: 0.446 +graphic: 0.417 +register: 0.333 +kernel: 0.315 +boot: 0.281 +debug: 0.273 +semantic: 0.256 +TCG: 0.227 +files: 0.194 +socket: 0.193 +ppc: 0.193 +PID: 0.181 +peripherals: 0.174 +permissions: 0.085 +KVM: 0.067 +mistranslation: 0.058 +assembly: 0.053 +user-level: 0.036 +x86: 0.011 +i386: 0.006 + +Regression in 8.2: Synchronous Exception when running a VM on AArch64 diff --git a/results/classifier/118/virtual/2118 b/results/classifier/118/virtual/2118 new file mode 100644 index 00000000..ec1c92ca --- /dev/null +++ b/results/classifier/118/virtual/2118 @@ -0,0 +1,31 @@ +virtual: 0.912 +device: 0.836 +architecture: 0.819 +VMM: 0.813 +network: 0.764 +PID: 0.588 +performance: 0.464 +arm: 0.428 +x86: 0.421 +boot: 0.399 +semantic: 0.391 +i386: 0.391 +mistranslation: 0.383 +permissions: 0.377 +vnc: 0.331 +graphic: 0.329 +socket: 0.328 +files: 0.321 +peripherals: 0.298 +register: 0.268 +user-level: 0.244 +debug: 0.237 +ppc: 0.206 +assembly: 0.195 +TCG: 0.165 +hypervisor: 0.079 +risc-v: 0.014 +kernel: 0.012 +KVM: 0.004 + +make vm-build-openbsd reinstalls OpenBSD every time diff --git a/results/classifier/118/virtual/2189 b/results/classifier/118/virtual/2189 new file mode 100644 index 00000000..022e0252 --- /dev/null +++ b/results/classifier/118/virtual/2189 @@ -0,0 +1,44 @@ +virtual: 0.953 +network: 0.903 +x86: 0.886 +graphic: 0.869 +performance: 0.862 +VMM: 0.844 +device: 0.841 +vnc: 0.807 +mistranslation: 0.791 +files: 0.727 +PID: 0.699 +hypervisor: 0.665 +socket: 0.648 +semantic: 0.607 +register: 0.597 +architecture: 0.584 +risc-v: 0.575 +kernel: 0.538 +boot: 0.527 +peripherals: 0.523 +arm: 0.473 +debug: 0.459 +ppc: 0.455 +permissions: 0.451 +i386: 0.436 +KVM: 0.430 +user-level: 0.364 +TCG: 0.347 +assembly: 0.272 + +vhost_user:When configure queues of vhost-user NIC exceeds max_queues, the virtual machine is always paused +Description of problem: +When the virtual machine uses the vhost-user network card and sets the queue number of the network card to exceed the maximum number of supported queues, the virtual machine fails to start and stays in the paused state. +And the virtual machine log file kept print "qemu - system - x86_64: -netdev host-user,chardev=charnet0,queues=5,id=hostnet0:you are asking more queues than supported:4” +Steps to reproduce: +1.Configure vhost-user network cards for VMS and use multiple queues. +2.The number of NIC queues configured in the VM xml file is greater than the maximum number of queues supported by the VM, that is, the number of Vcpus on the VM. +3.Execute "virsh create VM_xml_file" cmd to start VM. +Additional information: +According to normal logic, if the number of configured vhost-user NIC queues exceeds max-queues, the qemu process should be stopped, rather than paused the virtual machine. +I am confused about this patch:https://github.com/qemu/qemu/commit/c89804d674e4e3804bd3ac1fe79650896044b4e8 +The process will remain in the do...while loop, when vhost_user_start is called in net_vhost_user_event, if queues > max_queues in vhost_user_start. +/label ~"kind::Bug" +``` diff --git a/results/classifier/118/virtual/2196 b/results/classifier/118/virtual/2196 new file mode 100644 index 00000000..96cbfe19 --- /dev/null +++ b/results/classifier/118/virtual/2196 @@ -0,0 +1,31 @@ +virtual: 0.906 +performance: 0.826 +device: 0.683 +graphic: 0.552 +arm: 0.296 +semantic: 0.257 +hypervisor: 0.223 +mistranslation: 0.201 +i386: 0.165 +permissions: 0.155 +debug: 0.142 +boot: 0.108 +x86: 0.092 +vnc: 0.089 +VMM: 0.085 +architecture: 0.085 +PID: 0.081 +network: 0.078 +TCG: 0.075 +user-level: 0.065 +ppc: 0.064 +register: 0.041 +risc-v: 0.036 +socket: 0.028 +assembly: 0.021 +files: 0.021 +peripherals: 0.008 +KVM: 0.005 +kernel: 0.002 + +Missing support for video hardware accelerate support in virgl (virtio-gpu) diff --git a/results/classifier/118/virtual/2206 b/results/classifier/118/virtual/2206 new file mode 100644 index 00000000..a62a849d --- /dev/null +++ b/results/classifier/118/virtual/2206 @@ -0,0 +1,40 @@ +virtual: 0.960 +graphic: 0.948 +device: 0.842 +vnc: 0.756 +ppc: 0.703 +debug: 0.685 +performance: 0.648 +VMM: 0.648 +semantic: 0.641 +KVM: 0.627 +PID: 0.595 +architecture: 0.592 +mistranslation: 0.589 +network: 0.565 +risc-v: 0.548 +boot: 0.545 +hypervisor: 0.538 +arm: 0.518 +kernel: 0.484 +socket: 0.484 +user-level: 0.458 +TCG: 0.437 +register: 0.387 +files: 0.370 +peripherals: 0.243 +assembly: 0.241 +i386: 0.123 +permissions: 0.113 +x86: 0.046 + +PAGE_FAULT_IN_NONPAGED_AREA in Windows 7 x64. +Description of problem: +When trying to install Windows 7, it always crashes with PAGE_FAULT_IN_NONPAGED_AREA. This also impacts Windows 8.1, but crashes when it tries to start up the installation disc. +Steps to reproduce: +1. Create A VM with the Windows 7 installation disc inside the cdrom. +2. Go through the installation +3. At some point, it will pull a blue screen with a PAGE_FAULT_IN_NONPAGED_AREA. (around expanding windows files or completing installation) +Additional information: +It looks like this bsod is relating to some non-canonical (illegal) virtual address being referenced. (It's just my guess based on the stop code) + diff --git a/results/classifier/118/virtual/22219210 b/results/classifier/118/virtual/22219210 new file mode 100644 index 00000000..fc4faf9e --- /dev/null +++ b/results/classifier/118/virtual/22219210 @@ -0,0 +1,68 @@ +virtual: 0.877 +x86: 0.860 +architecture: 0.818 +graphic: 0.701 +performance: 0.498 +hypervisor: 0.491 +device: 0.489 +mistranslation: 0.472 +semantic: 0.387 +VMM: 0.364 +network: 0.323 +ppc: 0.297 +TCG: 0.285 +user-level: 0.273 +socket: 0.244 +debug: 0.225 +PID: 0.214 +vnc: 0.204 +files: 0.202 +peripherals: 0.201 +kernel: 0.166 +register: 0.150 +permissions: 0.141 +risc-v: 0.123 +i386: 0.120 +KVM: 0.099 +arm: 0.093 +assembly: 0.078 +boot: 0.070 + +[BUG][CPU hot-plug]CPU hot-plugs cause the qemu process to coredump + +Hello,Recently, when I was developing CPU hot-plugs under the loongarch +architecture, +I found that there was a problem with qemu cpu hot-plugs under x86 +architecture, +which caused the qemu process coredump when repeatedly inserting and +unplugging +the CPU when the TCG was accelerated. + + +The specific operation process is as follows: + +1.Use the following command to start the virtual machine + +qemu-system-x86_64 \ +-machine q35 \ +-cpu Broadwell-IBRS \ +-smp 1,maxcpus=4,sockets=4,cores=1,threads=1 \ +-m 4G \ +-drive file=~/anolis-8.8.qcow2 \ +-serial stdio  \ +-monitor telnet:localhost:4498,server,nowait + + +2.Enter QEMU Monitor via telnet for repeated CPU insertion and unplugging + +telnet 127.0.0.1 4498 +(qemu) device_add +Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread-id=0,id=cpu1 +(qemu) device_del cpu1 +(qemu) device_add +Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread-id=0,id=cpu1 +3.You will notice that the QEMU process has a coredump + +# malloc(): unsorted double linked list corrupted +Aborted (core dumped) + diff --git a/results/classifier/118/virtual/2272 b/results/classifier/118/virtual/2272 new file mode 100644 index 00000000..1291328a --- /dev/null +++ b/results/classifier/118/virtual/2272 @@ -0,0 +1,51 @@ +virtual: 0.967 +device: 0.927 +ppc: 0.785 +x86: 0.722 +semantic: 0.676 +debug: 0.668 +graphic: 0.653 +kernel: 0.633 +PID: 0.622 +architecture: 0.609 +boot: 0.553 +VMM: 0.544 +vnc: 0.544 +risc-v: 0.542 +i386: 0.512 +TCG: 0.475 +permissions: 0.440 +register: 0.395 +user-level: 0.395 +socket: 0.344 +performance: 0.343 +files: 0.305 +peripherals: 0.265 +network: 0.225 +arm: 0.209 +hypervisor: 0.199 +mistranslation: 0.174 +assembly: 0.121 +KVM: 0.095 + +Memory leak in the virtual device applesmc +Description of problem: +In the function _qdev_applesmc_isa_reset_, the device mallocs the _AppleSMCData_ but does not free them, causing a memory leak. + +The following log reveals it: + +``` +==1029295==ERROR: LeakSanitizer: detected memory leaksDirect leak of 80 byte(s) in 2 object(s) allocated from: +#0 0x5574dc600a82 in __interceptor_calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 +#1 0x7f4919b22c50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) +#2 0x5574dcdb0dfe in qdev_applesmc_isa_reset qemu/hw/misc/applesmc.c:285:5 +#3 0x5574de30e099 in resettable_phase_hold qemu/hw/core/resettable.c +#4 0x5574de2ef753 in bus_reset_child_foreach qemu/hw/core/bus.c:97:13 +#5 0x5574de30dcfe in resettable_child_foreach qemu/hw/core/resettable.c:96:9 +#6 0x5574de30dcfe in resettable_phase_hold qemu/hw/core/resettable.c:173:5 +#7 0x5574de3059b3 in device_reset_child_foreach qemu/hw/core/qdev.c:276:9 +``` +Steps to reproduce: +1. Build qemu with the sanitizer +2. Boot the Linux kernel with the above command line. +3. Stop the qemu process diff --git a/results/classifier/118/virtual/2277 b/results/classifier/118/virtual/2277 new file mode 100644 index 00000000..0a30a6e1 --- /dev/null +++ b/results/classifier/118/virtual/2277 @@ -0,0 +1,31 @@ +virtual: 0.976 +performance: 0.834 +VMM: 0.814 +device: 0.713 +hypervisor: 0.705 +network: 0.695 +architecture: 0.645 +vnc: 0.559 +risc-v: 0.539 +graphic: 0.525 +KVM: 0.401 +register: 0.375 +boot: 0.370 +TCG: 0.331 +debug: 0.287 +ppc: 0.239 +arm: 0.197 +x86: 0.168 +semantic: 0.165 +i386: 0.133 +PID: 0.109 +kernel: 0.067 +mistranslation: 0.052 +permissions: 0.043 +files: 0.042 +socket: 0.023 +assembly: 0.012 +peripherals: 0.011 +user-level: 0.007 + +COarse-grained LOck-stepping Virtual Machines for Non-stop Service Encountered Assertion Error diff --git a/results/classifier/118/virtual/2294 b/results/classifier/118/virtual/2294 new file mode 100644 index 00000000..bfa5270c --- /dev/null +++ b/results/classifier/118/virtual/2294 @@ -0,0 +1,31 @@ +architecture: 0.996 +x86: 0.996 +virtual: 0.981 +device: 0.969 +performance: 0.813 +boot: 0.598 +graphic: 0.506 +risc-v: 0.469 +TCG: 0.439 +mistranslation: 0.429 +debug: 0.348 +semantic: 0.341 +permissions: 0.339 +i386: 0.336 +VMM: 0.249 +PID: 0.239 +register: 0.218 +hypervisor: 0.180 +files: 0.147 +arm: 0.146 +assembly: 0.107 +network: 0.105 +socket: 0.096 +peripherals: 0.091 +vnc: 0.083 +kernel: 0.081 +ppc: 0.057 +user-level: 0.021 +KVM: 0.011 + +x86 microvm machine stuck under Xen accelerator diff --git a/results/classifier/118/virtual/2310 b/results/classifier/118/virtual/2310 new file mode 100644 index 00000000..ab6abc39 --- /dev/null +++ b/results/classifier/118/virtual/2310 @@ -0,0 +1,31 @@ +virtual: 0.895 +device: 0.846 +performance: 0.700 +peripherals: 0.635 +debug: 0.520 +risc-v: 0.517 +graphic: 0.478 +hypervisor: 0.454 +register: 0.397 +vnc: 0.392 +network: 0.380 +VMM: 0.343 +arm: 0.332 +PID: 0.297 +permissions: 0.217 +TCG: 0.216 +socket: 0.210 +i386: 0.188 +user-level: 0.185 +architecture: 0.183 +mistranslation: 0.183 +semantic: 0.137 +boot: 0.124 +KVM: 0.114 +x86: 0.110 +ppc: 0.108 +assembly: 0.065 +kernel: 0.046 +files: 0.032 + +Virtio devices not working diff --git a/results/classifier/118/virtual/2339 b/results/classifier/118/virtual/2339 new file mode 100644 index 00000000..a1a9c79c --- /dev/null +++ b/results/classifier/118/virtual/2339 @@ -0,0 +1,31 @@ +virtual: 0.972 +device: 0.858 +graphic: 0.807 +VMM: 0.749 +debug: 0.682 +architecture: 0.673 +risc-v: 0.660 +performance: 0.629 +network: 0.500 +files: 0.454 +PID: 0.454 +vnc: 0.453 +register: 0.448 +TCG: 0.411 +boot: 0.407 +ppc: 0.345 +arm: 0.309 +permissions: 0.283 +x86: 0.253 +i386: 0.247 +socket: 0.243 +hypervisor: 0.181 +semantic: 0.171 +mistranslation: 0.161 +peripherals: 0.144 +KVM: 0.089 +kernel: 0.089 +assembly: 0.066 +user-level: 0.055 + +VM Crash is observed while deploying an ubuntu VM with OS version 18.04 on host with ubuntu version 24.04 diff --git a/results/classifier/118/virtual/2347 b/results/classifier/118/virtual/2347 new file mode 100644 index 00000000..8903757f --- /dev/null +++ b/results/classifier/118/virtual/2347 @@ -0,0 +1,39 @@ +virtual: 0.878 +device: 0.846 +mistranslation: 0.813 +graphic: 0.802 +performance: 0.637 +architecture: 0.571 +semantic: 0.569 +permissions: 0.517 +debug: 0.480 +arm: 0.356 +assembly: 0.355 +TCG: 0.269 +vnc: 0.240 +risc-v: 0.231 +peripherals: 0.229 +ppc: 0.211 +hypervisor: 0.193 +register: 0.177 +PID: 0.170 +socket: 0.125 +kernel: 0.123 +boot: 0.122 +user-level: 0.120 +network: 0.119 +i386: 0.119 +files: 0.117 +VMM: 0.116 +x86: 0.066 +KVM: 0.045 + +Grab Input not working only for Windows key +Description of problem: +When Input Grabbing is enabled (as seen in the menu and the Qemu window title itself), a press on the Windows key will also send that press to the host system (Arch / KDE). + +I expected all inputs to be grabbed and stay within the VM. +Steps to reproduce: +1. Open a QEMU instance in a Arch / KDE host (not fullscreen) +2. Focus the instance and enable Input Grabbing (Ctrl + Alt + G) +3. Press the Windows key diff --git a/results/classifier/118/virtual/2352 b/results/classifier/118/virtual/2352 new file mode 100644 index 00000000..d5d83145 --- /dev/null +++ b/results/classifier/118/virtual/2352 @@ -0,0 +1,31 @@ +virtual: 0.971 +peripherals: 0.948 +mistranslation: 0.921 +performance: 0.918 +device: 0.910 +hypervisor: 0.839 +network: 0.821 +vnc: 0.795 +assembly: 0.702 +graphic: 0.671 +risc-v: 0.670 +permissions: 0.609 +VMM: 0.552 +semantic: 0.518 +socket: 0.479 +architecture: 0.428 +ppc: 0.418 +KVM: 0.398 +register: 0.389 +arm: 0.357 +boot: 0.309 +user-level: 0.294 +debug: 0.289 +files: 0.242 +PID: 0.168 +TCG: 0.106 +kernel: 0.092 +i386: 0.064 +x86: 0.028 + +spapr-vlan hotplug diff --git a/results/classifier/118/virtual/2393 b/results/classifier/118/virtual/2393 new file mode 100644 index 00000000..a1d2bfa7 --- /dev/null +++ b/results/classifier/118/virtual/2393 @@ -0,0 +1,50 @@ +virtual: 0.991 +performance: 0.932 +semantic: 0.874 +boot: 0.872 +x86: 0.855 +graphic: 0.849 +architecture: 0.849 +kernel: 0.829 +device: 0.771 +ppc: 0.730 +hypervisor: 0.729 +vnc: 0.700 +user-level: 0.699 +PID: 0.654 +VMM: 0.568 +socket: 0.543 +KVM: 0.535 +register: 0.532 +network: 0.512 +permissions: 0.500 +peripherals: 0.479 +mistranslation: 0.461 +assembly: 0.460 +files: 0.442 +risc-v: 0.433 +arm: 0.412 +TCG: 0.407 +i386: 0.382 +debug: 0.320 + +qemu: seabios hangs for 10~15 sec at boot with `-machine q35` +Description of problem: +Whenever i'm starting a virtual machine i'm having the issue that seabios (or at least that's what i see) hangs for about 10~15 seconds. In that time on of the cpu cores runs at 100%. +This issue isn't new actually. I'm having this already for quite some time and a i think for at least the last 2 major versions. I haven't looked into it since it isn't a big issue, just annoying. +Today i've looked into it and as far as i can see, this issue is always present with the flag `-machine q35`, which is the default for my vm's. If i set it to `-machine pc`, booting works as expected. However i also found a "workaround" where the vm's starting immediately (with `-machine q35` enabled), which is by simply adding a iso image to the command line (via -cdrom) - even though it's not used. + +This means: +- 15 sec delay: qemu-system-x86_64 -machine q35 +- works immediately: qemu-system-x86_64 -machine q35 -cdrom /mnt/data/vm/isos/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230303-Media.iso + +Please note that most of my vm's usually start booting from a kernel image directly (-kernel /mnt/data/vm/kernel/gentoo-latest -initrd /mnt/data/vm/kernel/initrd-v5.cpio.gz) - but even in that case settings a cdrom (image) would fix the issue. +Also, the image needs to be a valid one, if i set an empty file or /dev/null the issue would remain. +Further more, i have the same issue on a second computer. This also runs on Gentoo Linux and is also a AMD Ryzen. (in case this is relevant) +Steps to reproduce: +1. qemu-system-x86_64 -machine q35 +2. wait about 10-15sec before boot continues +Additional information: +I was thinking to add an Screenshot of the hanging boot process, but the only text written there is: +SeaBIOS (version 1.16.0-20220807_005459-localhost) +with a blinking cursor below diff --git a/results/classifier/118/virtual/242 b/results/classifier/118/virtual/242 new file mode 100644 index 00000000..ec6fa366 --- /dev/null +++ b/results/classifier/118/virtual/242 @@ -0,0 +1,31 @@ +virtual: 0.960 +device: 0.815 +architecture: 0.735 +assembly: 0.541 +risc-v: 0.477 +graphic: 0.414 +TCG: 0.334 +boot: 0.316 +performance: 0.279 +i386: 0.248 +files: 0.225 +KVM: 0.215 +vnc: 0.215 +ppc: 0.214 +VMM: 0.207 +x86: 0.187 +semantic: 0.165 +debug: 0.147 +network: 0.095 +arm: 0.091 +mistranslation: 0.089 +user-level: 0.084 +register: 0.066 +kernel: 0.054 +PID: 0.051 +hypervisor: 0.032 +permissions: 0.027 +socket: 0.022 +peripherals: 0.022 + +Implementation of Virtual Battery for Battery Status diff --git a/results/classifier/118/virtual/2436 b/results/classifier/118/virtual/2436 new file mode 100644 index 00000000..08a07f27 --- /dev/null +++ b/results/classifier/118/virtual/2436 @@ -0,0 +1,31 @@ +virtual: 0.991 +KVM: 0.968 +device: 0.947 +network: 0.914 +hypervisor: 0.910 +architecture: 0.888 +performance: 0.862 +peripherals: 0.559 +mistranslation: 0.504 +kernel: 0.386 +semantic: 0.350 +graphic: 0.302 +arm: 0.270 +x86: 0.242 +risc-v: 0.231 +VMM: 0.197 +vnc: 0.184 +boot: 0.176 +register: 0.160 +TCG: 0.156 +i386: 0.142 +assembly: 0.138 +debug: 0.129 +user-level: 0.077 +ppc: 0.069 +permissions: 0.065 +PID: 0.033 +files: 0.030 +socket: 0.011 + +virtio kvm iofd sigfault bypass diff --git a/results/classifier/118/virtual/253 b/results/classifier/118/virtual/253 new file mode 100644 index 00000000..faca5d80 --- /dev/null +++ b/results/classifier/118/virtual/253 @@ -0,0 +1,31 @@ +virtual: 0.936 +device: 0.902 +KVM: 0.895 +architecture: 0.810 +performance: 0.684 +hypervisor: 0.501 +arm: 0.431 +graphic: 0.292 +semantic: 0.226 +register: 0.214 +debug: 0.178 +PID: 0.176 +risc-v: 0.168 +peripherals: 0.162 +permissions: 0.160 +mistranslation: 0.130 +vnc: 0.121 +TCG: 0.119 +boot: 0.098 +ppc: 0.092 +user-level: 0.086 +socket: 0.079 +VMM: 0.039 +kernel: 0.019 +network: 0.019 +files: 0.016 +assembly: 0.009 +i386: 0.001 +x86: 0.001 + +Qemu Win98 VM with KVM videocard passthrough DOS mode video is not working for most of games.. diff --git a/results/classifier/118/virtual/2530 b/results/classifier/118/virtual/2530 new file mode 100644 index 00000000..ea5c0d8f --- /dev/null +++ b/results/classifier/118/virtual/2530 @@ -0,0 +1,47 @@ +virtual: 0.957 +i386: 0.879 +device: 0.873 +graphic: 0.844 +vnc: 0.827 +peripherals: 0.757 +files: 0.727 +ppc: 0.707 +PID: 0.610 +semantic: 0.568 +socket: 0.566 +architecture: 0.564 +risc-v: 0.552 +network: 0.537 +register: 0.518 +mistranslation: 0.512 +VMM: 0.455 +permissions: 0.442 +debug: 0.431 +boot: 0.402 +kernel: 0.399 +hypervisor: 0.385 +arm: 0.328 +x86: 0.325 +performance: 0.317 +TCG: 0.306 +KVM: 0.192 +assembly: 0.138 +user-level: 0.105 + +Duplicate ACPI _SUN +Description of problem: +ACPI _SUN is `the slot-unique ID number for a slot`, but qemu uses `PCI_SLOT()` which is definitely not unique +https://gitlab.com/qemu-project/qemu/-/blob/407f9a4b121eb65166375c410e14d7b704bc1106/hw/i386/acpi-build.c#L524 +Steps to reproduce: +1. Create a linux VM with 2 virtio NICs +2. Look at the ACPI _SUN of the virtio-pci devices (firmware_node/sun) + +Both virtio-pci devices have _SUN == 0 +``` +# +Additional information: +In systemd we recently introduced code to use firmware_node/sun information for NIC naming +https://github.com/systemd/systemd/commit/0a4ecc54cb9f2d3418b970c51bfadb69c34ae9eb + +but having duplicate _SUN is of course problematic +https://github.com/systemd/systemd/issues/34082 diff --git a/results/classifier/118/virtual/2541 b/results/classifier/118/virtual/2541 new file mode 100644 index 00000000..e95fd87a --- /dev/null +++ b/results/classifier/118/virtual/2541 @@ -0,0 +1,31 @@ +virtual: 0.980 +device: 0.872 +performance: 0.786 +network: 0.651 +graphic: 0.558 +hypervisor: 0.466 +architecture: 0.442 +permissions: 0.415 +boot: 0.383 +semantic: 0.363 +register: 0.300 +PID: 0.278 +mistranslation: 0.274 +files: 0.227 +vnc: 0.196 +arm: 0.184 +socket: 0.163 +peripherals: 0.080 +ppc: 0.075 +risc-v: 0.074 +user-level: 0.068 +VMM: 0.056 +debug: 0.042 +TCG: 0.032 +kernel: 0.023 +i386: 0.011 +x86: 0.011 +assembly: 0.009 +KVM: 0.002 + +virtio-9p qos-test failure: v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) FAIL diff --git a/results/classifier/118/virtual/2576 b/results/classifier/118/virtual/2576 new file mode 100644 index 00000000..d2426ce6 --- /dev/null +++ b/results/classifier/118/virtual/2576 @@ -0,0 +1,31 @@ +virtual: 0.988 +mistranslation: 0.971 +graphic: 0.934 +device: 0.719 +performance: 0.665 +semantic: 0.659 +vnc: 0.593 +VMM: 0.363 +user-level: 0.297 +hypervisor: 0.290 +risc-v: 0.280 +debug: 0.252 +boot: 0.197 +peripherals: 0.194 +TCG: 0.182 +PID: 0.167 +register: 0.163 +ppc: 0.137 +network: 0.125 +assembly: 0.113 +arm: 0.097 +permissions: 0.082 +KVM: 0.062 +i386: 0.036 +x86: 0.024 +architecture: 0.014 +files: 0.010 +kernel: 0.004 +socket: 0.004 + +virtio-balloon: Assertion `mrs.mr' failed. diff --git a/results/classifier/118/virtual/258 b/results/classifier/118/virtual/258 new file mode 100644 index 00000000..383a2856 --- /dev/null +++ b/results/classifier/118/virtual/258 @@ -0,0 +1,31 @@ +virtual: 0.981 +graphic: 0.894 +hypervisor: 0.799 +device: 0.621 +performance: 0.394 +VMM: 0.308 +mistranslation: 0.276 +vnc: 0.255 +assembly: 0.238 +permissions: 0.207 +semantic: 0.179 +architecture: 0.165 +boot: 0.124 +ppc: 0.102 +i386: 0.080 +arm: 0.077 +x86: 0.076 +user-level: 0.075 +peripherals: 0.067 +network: 0.060 +debug: 0.050 +register: 0.048 +files: 0.034 +PID: 0.022 +risc-v: 0.021 +socket: 0.017 +TCG: 0.007 +kernel: 0.003 +KVM: 0.002 + +Add Illumnos VM image diff --git a/results/classifier/118/virtual/2594 b/results/classifier/118/virtual/2594 new file mode 100644 index 00000000..d4a14165 --- /dev/null +++ b/results/classifier/118/virtual/2594 @@ -0,0 +1,65 @@ +virtual: 0.884 +peripherals: 0.882 +graphic: 0.831 +performance: 0.794 +hypervisor: 0.762 +x86: 0.756 +VMM: 0.742 +i386: 0.699 +architecture: 0.694 +vnc: 0.676 +debug: 0.669 +socket: 0.662 +device: 0.637 +PID: 0.628 +user-level: 0.568 +kernel: 0.501 +ppc: 0.497 +KVM: 0.473 +semantic: 0.468 +mistranslation: 0.431 +boot: 0.430 +network: 0.405 +risc-v: 0.381 +files: 0.379 +TCG: 0.348 +register: 0.333 +permissions: 0.298 +arm: 0.250 +assembly: 0.233 + +Migration fails with 'get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0' after hotplugging a CPU +Description of problem: +After hotplugging a CPU and finishing a migration from node 1 to node 2, the instance on node 2 crashes when virtio block devices are used: +``` +qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x9a read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0 +qemu-system-x86_64: Failed to load PCIDevice:config +qemu-system-x86_64: Failed to load virtio-blk:virtio +qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/virtio-blk' +qemu-system-x86_64: load of migration failed: Invalid argument +``` + +I found the problem also exhibits when using `scsi-hd` in combination with `virtio-scsi`, but not when using IDE hard disks or SCSI disks with an LSI controller. VMs with network cards aren't affected either, as are VMs without virtio disks. + + +Interestingly, the latest QEMU version shipped with Ubuntu 20.04 (4.2.1-Debian 1:4.2-3ubuntu6.29) is able to migrate this VM just fine. +Steps to reproduce: +1. Start a VM using the first command line +2. Start another VM using the second command line +3. Hotplug a CPU in QMP: + ``` + {"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"}} + ``` +4. Start a migration by executing the following QMP command (again substituting `<ip:port>` with the IP:port combination of node 2 + ``` + {"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"}} + ``` + +(For steps 3 and 4 I used this): +``` +echo '{"execute":"qmp_capabilities"} +{"execute":"device_add","arguments":{"node-id":0,"socket-id":0,"core-id":2,"thread-id":0,"id":{},"driver":"qemu64-x86_64-cpu"},"id":1} +{"execute":"migrate","arguments":{"uri":"tcp:127.0.0.1:1234"},"id":2}' | nc -U /tmp/vm1.sock +``` +Additional information: + diff --git a/results/classifier/118/virtual/2626 b/results/classifier/118/virtual/2626 new file mode 100644 index 00000000..45b42ea7 --- /dev/null +++ b/results/classifier/118/virtual/2626 @@ -0,0 +1,38 @@ +virtual: 0.923 +device: 0.867 +performance: 0.863 +graphic: 0.845 +network: 0.793 +vnc: 0.710 +architecture: 0.670 +hypervisor: 0.607 +debug: 0.575 +TCG: 0.566 +socket: 0.543 +risc-v: 0.529 +semantic: 0.449 +VMM: 0.417 +ppc: 0.404 +PID: 0.357 +permissions: 0.341 +kernel: 0.337 +files: 0.325 +boot: 0.312 +i386: 0.304 +register: 0.302 +x86: 0.301 +KVM: 0.250 +peripherals: 0.248 +mistranslation: 0.201 +arm: 0.200 +user-level: 0.096 +assembly: 0.065 + +QEMU crashes after host time moves backwards +Description of problem: +QEMU process crashes after time synchronized and moved backwards on the host. +Steps to reproduce: +As detailed in the [thread](https://bugzilla.redhat.com/show_bug.cgi?id=2228406) + +1. create a virtual machine and change tick period in the guest +2. executing `while [ 1 ];do hwclock --systohc; hwclock --hctosys;done` on the host diff --git a/results/classifier/118/virtual/270 b/results/classifier/118/virtual/270 new file mode 100644 index 00000000..7228ca98 --- /dev/null +++ b/results/classifier/118/virtual/270 @@ -0,0 +1,31 @@ +virtual: 0.951 +architecture: 0.871 +device: 0.847 +performance: 0.782 +graphic: 0.698 +network: 0.577 +risc-v: 0.461 +peripherals: 0.440 +ppc: 0.422 +hypervisor: 0.419 +permissions: 0.416 +PID: 0.404 +semantic: 0.323 +TCG: 0.323 +assembly: 0.320 +i386: 0.283 +vnc: 0.227 +arm: 0.211 +VMM: 0.191 +register: 0.190 +mistranslation: 0.189 +debug: 0.173 +boot: 0.155 +user-level: 0.155 +files: 0.125 +x86: 0.103 +KVM: 0.089 +kernel: 0.067 +socket: 0.024 + +virtio only support packed ring size power of 2 diff --git a/results/classifier/118/virtual/2713 b/results/classifier/118/virtual/2713 new file mode 100644 index 00000000..53e39df7 --- /dev/null +++ b/results/classifier/118/virtual/2713 @@ -0,0 +1,43 @@ +virtual: 0.914 +device: 0.908 +graphic: 0.851 +architecture: 0.844 +hypervisor: 0.703 +semantic: 0.686 +arm: 0.676 +performance: 0.619 +VMM: 0.583 +PID: 0.515 +register: 0.457 +boot: 0.440 +risc-v: 0.397 +mistranslation: 0.348 +network: 0.343 +debug: 0.332 +files: 0.329 +vnc: 0.306 +socket: 0.292 +user-level: 0.291 +kernel: 0.271 +TCG: 0.263 +x86: 0.242 +permissions: 0.242 +KVM: 0.227 +assembly: 0.203 +ppc: 0.203 +peripherals: 0.136 +i386: 0.119 + +Addressing Limitations with 64GB RAM on virt-9.2 Machine Type in QEMU 9.1.93 +Description of problem: +When attempting to run a VM with 64GB of RAM using the `virt-9.2` machine type, QEMU encounters an error related to addressing limitations. It appears that the memory configuration exceeds the 32-bit addressing limit. + +Error output: +**qemu-system-aarch64: Addressing limited to 32 bits, but memory exceeds it by 65498251264 bytes** +Steps to reproduce: +1. Build QEMU from source on macOS (M2 MacBook, arm64). +2. Run the command with the `virt-9.2` machine type and 64GB of RAM. +Additional information: +- Changes in [UTM app](https://github.com/utmapp/UTM/releases) for release v4.6.2 - (macOS) Support > 32GiB RAM configurations in QEMU ([#5537](https://github.com/utmapp/UTM/issues/5537)) +- Although the site advertises release of qemu-9.2.0-rc3, the brew install doesn't install the latest version yet. +- The QEMU build environment includes dependencies installed via Homebrew: libffi, gettext, glib, pkg-config, pixman, ninja, meson, sdl2, gtk+3, gnu-tar. diff --git a/results/classifier/118/virtual/2747 b/results/classifier/118/virtual/2747 new file mode 100644 index 00000000..b0468198 --- /dev/null +++ b/results/classifier/118/virtual/2747 @@ -0,0 +1,39 @@ +virtual: 0.904 +permissions: 0.875 +device: 0.784 +network: 0.734 +graphic: 0.706 +VMM: 0.647 +architecture: 0.567 +files: 0.537 +semantic: 0.458 +performance: 0.445 +vnc: 0.444 +PID: 0.426 +debug: 0.424 +register: 0.422 +mistranslation: 0.410 +hypervisor: 0.374 +kernel: 0.356 +boot: 0.311 +user-level: 0.301 +TCG: 0.298 +ppc: 0.287 +risc-v: 0.274 +socket: 0.254 +i386: 0.241 +x86: 0.218 +peripherals: 0.168 +KVM: 0.158 +arm: 0.133 +assembly: 0.115 + +External snapshots are created world-readable when connecting via qemu+ssh://root +Description of problem: +External snapshots are created with world-readable permissions when connecting via `qemu+ssh://root`. +Steps to reproduce: +1. Create a VM over `qemu+ssh://root@$SERVER/system` +2. Create an external snapshot via virt-manager or with `virsh snapshot-create-as --domain testvm --name test --disk-only --diskspec vda,file=/var/lib/libvirt/images/test.qcow2 --atomic` +3. `ls -l /var/lib/libvirt/images/test.qcow2` +Additional information: +Issue doesn't seem to go away by adding `umask 077` in `$HOME/.profile` diff --git a/results/classifier/118/virtual/2755 b/results/classifier/118/virtual/2755 new file mode 100644 index 00000000..96a37f09 --- /dev/null +++ b/results/classifier/118/virtual/2755 @@ -0,0 +1,41 @@ +virtual: 0.920 +device: 0.839 +graphic: 0.676 +architecture: 0.609 +vnc: 0.599 +risc-v: 0.534 +VMM: 0.498 +PID: 0.491 +permissions: 0.474 +peripherals: 0.452 +network: 0.413 +semantic: 0.409 +hypervisor: 0.397 +kernel: 0.396 +boot: 0.357 +debug: 0.339 +performance: 0.324 +register: 0.300 +arm: 0.280 +socket: 0.260 +files: 0.247 +ppc: 0.168 +TCG: 0.166 +mistranslation: 0.121 +user-level: 0.118 +x86: 0.074 +KVM: 0.070 +i386: 0.060 +assembly: 0.050 + +shrink attached rbd size is not allowed by default +Description of problem: + +Steps to reproduce: +1. attach a disk with size 100GiB to a running vm +2. writing some data to the attached disk +3. executing block_resize command and shrink the size to 1GiB + +the result is virtual disk is resized successfully and causing data lost. +Additional information: +Tested QEMU version is 4.2 diff --git a/results/classifier/118/virtual/2820 b/results/classifier/118/virtual/2820 new file mode 100644 index 00000000..d0b2c2bd --- /dev/null +++ b/results/classifier/118/virtual/2820 @@ -0,0 +1,57 @@ +architecture: 0.931 +virtual: 0.920 +performance: 0.912 +permissions: 0.902 +hypervisor: 0.895 +semantic: 0.882 +peripherals: 0.870 +register: 0.855 +graphic: 0.848 +mistranslation: 0.827 +debug: 0.822 +risc-v: 0.817 +vnc: 0.800 +kernel: 0.793 +network: 0.773 +ppc: 0.771 +device: 0.745 +x86: 0.743 +files: 0.697 +VMM: 0.679 +i386: 0.667 +user-level: 0.666 +PID: 0.645 +socket: 0.645 +arm: 0.612 +assembly: 0.588 +KVM: 0.569 +boot: 0.509 +TCG: 0.482 + +STOPI CSR Incorrect Value for Virtual Supervisor External Interrupt in QEMU (AIA Extension) +Description of problem: +We are developing a RISC-V core and have implemented tests for the AIA extension. One of these tests reveals a bug when running in QEMU in a bare-metal environment. The issue relates to the value of the STOPI CSR. Although the CSR behaves correctly in most cases, when a virtual supervisor external interrupt is generated using the IMSIC (i.e., both hip.vseip and hie.vseip are set to 1) while executing in supervisor mode with hideleg.vseip set to 0, the STOPI CSR always returns the value 0. However, according to the specifications, it should return 10, which is the major identity number for the virtual supervisor external interrupt. + +According to the RISC-V specs: + +> The value of stopi is zero unless: (a) there is an interrupt that is both pending in sip and enabled in +sie, or, if the hypervisor extension is implemented, both pending in hip and enabled in hie; and (b) +the interrupt is not delegated to a lower privilege level (by hideleg, if the hypervisor extension is +implemented). When there is a pending-and-enabled major interrupt for supervisor level, field IID is +the major identity number of the highest-priority interrupt, and field IPRIO indicates its priority. + +Upon reviewing the QEMU AIA code, I found the following snippet in `qemu/target/riscv/cpu_helper.c` that might be causing the problem: +``` +int riscv_cpu_sirq_pending(CPURISCVState *env) +{ + uint64_t irqs = riscv_cpu_all_pending(env) & env->mideleg & + ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP); + uint64_t irqs_f = env->mvip & env->mvien & ~env->mideleg & env->sie; + + return riscv_cpu_pending_to_irq(env, IRQ_S_EXT, IPRIO_DEFAULT_S, + irqs | irqs_f, env->siprio); +} +``` +It appears that virtual supervisor (VS) interrupts are being masked (via the `~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP)` operation) when they likely should not be, which could explain why the STOPI CSR does not reflect the correct value. + +Thank you for your time, and please let me know if any details require further clarification or if my interpretation is incorrect. diff --git a/results/classifier/118/virtual/2880 b/results/classifier/118/virtual/2880 new file mode 100644 index 00000000..bf3ceea5 --- /dev/null +++ b/results/classifier/118/virtual/2880 @@ -0,0 +1,33 @@ +virtual: 0.895 +device: 0.870 +VMM: 0.492 +mistranslation: 0.419 +boot: 0.363 +architecture: 0.345 +graphic: 0.335 +arm: 0.301 +TCG: 0.275 +KVM: 0.245 +debug: 0.225 +semantic: 0.223 +ppc: 0.208 +i386: 0.205 +vnc: 0.188 +files: 0.182 +PID: 0.179 +risc-v: 0.170 +user-level: 0.164 +register: 0.158 +x86: 0.150 +hypervisor: 0.071 +performance: 0.059 +permissions: 0.029 +socket: 0.018 +network: 0.015 +kernel: 0.010 +assembly: 0.009 +peripherals: 0.006 + +how to migrate storage live for the vm with vhostuser disk +Additional information: + diff --git a/results/classifier/118/virtual/2894 b/results/classifier/118/virtual/2894 new file mode 100644 index 00000000..b1e3ca04 --- /dev/null +++ b/results/classifier/118/virtual/2894 @@ -0,0 +1,55 @@ +virtual: 0.917 +permissions: 0.906 +device: 0.895 +network: 0.870 +files: 0.865 +graphic: 0.856 +semantic: 0.851 +boot: 0.850 +peripherals: 0.845 +performance: 0.839 +x86: 0.831 +arm: 0.818 +KVM: 0.814 +socket: 0.809 +kernel: 0.809 +debug: 0.808 +user-level: 0.805 +hypervisor: 0.801 +PID: 0.796 +risc-v: 0.777 +VMM: 0.776 +mistranslation: 0.774 +assembly: 0.767 +architecture: 0.761 +register: 0.760 +TCG: 0.748 +ppc: 0.746 +vnc: 0.737 +i386: 0.695 + +There is a bug in versions 2025-02-10 and later that causes virtual machines to be created with incorrect SMP settings with warnings about TCG features when setting more than 2 cores with the smp option in the default TCG acceleration (see main text). +Description of problem: +When using qemu-system-x86_64 in versions 9.2.50 and later, if you create a virtual machine with 2 or more cores using the smp option, + +``` +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1] +``` +The log will be displayed as many as the number of cores you have enabled, and the created virtual machine will be displayed as having a 1-core CPU with the number of cores you have enabled. +* I have not tested whether the same symptom occurs on versions 9.2.50 and later for other environments (Linux and the WoA version released on March 26th). +Steps to reproduce: +1. Create a virtual machine with more than two cores using TCG acceleration, which is the default acceleration, by using options such as 'qemu-system-x86_64 -smp 2' or 'qemu-system-x86_64 -smp sockets=1,cores=2,threads=1'. +2. 'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]' and +'qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1]' +The log is generated as many as the number of cores set and the virtual machine is created. +3. When checking the CPU information of the booted virtual machine, it does not show that there is one CPU with the specified number of cores, but rather that there is a single core CPU with the specified number of cores. +Additional information: +``` +>qemu-system-x86_64 -M q35 -smp 2 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime +``` + +``` +>qemu-system-x86_64 -M q35 -smp 4 -m 4g -display sdl -usb -device usb-tablet -drive file=MasterOS.vdi,id=disk,if=none -drive file="C:\Program Files\qemu\share\edk2-x86_64-code.fd",id=efi,readonly=on,format=raw,if=pflash -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.1 -rtc base=localtime +``` + diff --git a/results/classifier/118/virtual/2913 b/results/classifier/118/virtual/2913 new file mode 100644 index 00000000..a11a314c --- /dev/null +++ b/results/classifier/118/virtual/2913 @@ -0,0 +1,31 @@ +virtual: 0.943 +device: 0.921 +performance: 0.824 +architecture: 0.823 +VMM: 0.784 +graphic: 0.768 +arm: 0.759 +files: 0.591 +hypervisor: 0.545 +register: 0.545 +mistranslation: 0.488 +permissions: 0.464 +network: 0.462 +risc-v: 0.439 +debug: 0.425 +peripherals: 0.397 +user-level: 0.368 +semantic: 0.353 +boot: 0.333 +PID: 0.315 +kernel: 0.275 +TCG: 0.209 +socket: 0.205 +ppc: 0.169 +vnc: 0.168 +assembly: 0.113 +i386: 0.037 +KVM: 0.033 +x86: 0.015 + +vmapple machine unusable with macOS 15.4 diff --git a/results/classifier/118/virtual/365 b/results/classifier/118/virtual/365 new file mode 100644 index 00000000..3cb2cdc0 --- /dev/null +++ b/results/classifier/118/virtual/365 @@ -0,0 +1,31 @@ +virtual: 0.973 +PID: 0.912 +device: 0.802 +architecture: 0.631 +network: 0.502 +graphic: 0.415 +hypervisor: 0.413 +arm: 0.325 +performance: 0.219 +ppc: 0.196 +files: 0.196 +x86: 0.191 +i386: 0.179 +debug: 0.146 +TCG: 0.140 +semantic: 0.138 +vnc: 0.105 +risc-v: 0.101 +boot: 0.094 +peripherals: 0.092 +register: 0.085 +permissions: 0.084 +mistranslation: 0.072 +kernel: 0.065 +VMM: 0.052 +KVM: 0.037 +user-level: 0.028 +socket: 0.026 +assembly: 0.020 + +virtiofsd: Directory for PID file hardcoded diff --git a/results/classifier/118/virtual/366 b/results/classifier/118/virtual/366 new file mode 100644 index 00000000..2bc3ee92 --- /dev/null +++ b/results/classifier/118/virtual/366 @@ -0,0 +1,31 @@ +virtual: 0.941 +device: 0.714 +assembly: 0.562 +hypervisor: 0.541 +performance: 0.437 +semantic: 0.428 +mistranslation: 0.361 +network: 0.348 +architecture: 0.336 +graphic: 0.331 +user-level: 0.281 +risc-v: 0.213 +permissions: 0.202 +register: 0.163 +boot: 0.145 +vnc: 0.141 +files: 0.137 +arm: 0.135 +VMM: 0.118 +i386: 0.082 +x86: 0.059 +debug: 0.048 +socket: 0.047 +peripherals: 0.040 +kernel: 0.028 +ppc: 0.017 +PID: 0.014 +TCG: 0.008 +KVM: 0.008 + +How to make OVMF diff --git a/results/classifier/118/virtual/368 b/results/classifier/118/virtual/368 new file mode 100644 index 00000000..69001ec5 --- /dev/null +++ b/results/classifier/118/virtual/368 @@ -0,0 +1,31 @@ +virtual: 0.936 +permissions: 0.910 +device: 0.855 +architecture: 0.799 +network: 0.770 +files: 0.584 +performance: 0.546 +register: 0.452 +user-level: 0.436 +hypervisor: 0.426 +semantic: 0.397 +PID: 0.353 +mistranslation: 0.303 +peripherals: 0.297 +debug: 0.296 +arm: 0.257 +graphic: 0.250 +ppc: 0.237 +i386: 0.222 +TCG: 0.186 +x86: 0.149 +risc-v: 0.125 +vnc: 0.105 +boot: 0.093 +VMM: 0.054 +assembly: 0.051 +socket: 0.034 +kernel: 0.008 +KVM: 0.006 + +virtiofsd: doesn't garant write access at users allowed by group permission diff --git a/results/classifier/118/virtual/465 b/results/classifier/118/virtual/465 new file mode 100644 index 00000000..a398bbb6 --- /dev/null +++ b/results/classifier/118/virtual/465 @@ -0,0 +1,37 @@ +virtual: 0.990 +network: 0.980 +kernel: 0.827 +device: 0.806 +vnc: 0.759 +mistranslation: 0.683 +graphic: 0.649 +semantic: 0.562 +VMM: 0.552 +ppc: 0.538 +socket: 0.502 +risc-v: 0.431 +arm: 0.415 +permissions: 0.373 +files: 0.370 +register: 0.363 +PID: 0.337 +boot: 0.305 +performance: 0.303 +architecture: 0.282 +user-level: 0.281 +x86: 0.232 +TCG: 0.225 +i386: 0.209 +hypervisor: 0.187 +KVM: 0.138 +peripherals: 0.078 +assembly: 0.074 +debug: 0.064 + +Support network virtualization for Macos Big Sur+ +Additional information: +The following implementation are already submitted as a patch and they seem to work well on my mbp 2019 Big Sur. The only prob is that the qemu-system command should be run as root. + +[https://patchwork.kernel.org/project/qemu-devel/list/?series=502533](https://patchwork.kernel.org/project/qemu-devel/list/?series=502533) + +[https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/](https://patchwork.kernel.org/project/qemu-devel/patch/20210708054451.9374-1-akihiko.odaki@gmail.com/) diff --git a/results/classifier/118/virtual/466 b/results/classifier/118/virtual/466 new file mode 100644 index 00000000..ea47a0ff --- /dev/null +++ b/results/classifier/118/virtual/466 @@ -0,0 +1,31 @@ +virtual: 0.961 +performance: 0.907 +VMM: 0.847 +graphic: 0.768 +architecture: 0.732 +device: 0.587 +risc-v: 0.511 +vnc: 0.503 +arm: 0.492 +TCG: 0.459 +ppc: 0.432 +hypervisor: 0.422 +PID: 0.419 +KVM: 0.374 +x86: 0.344 +i386: 0.286 +semantic: 0.251 +register: 0.221 +mistranslation: 0.215 +debug: 0.191 +kernel: 0.153 +permissions: 0.126 +boot: 0.069 +files: 0.040 +socket: 0.038 +assembly: 0.024 +network: 0.023 +user-level: 0.022 +peripherals: 0.004 + +3x 100% host CPU core usage while virtual machine is in idle diff --git a/results/classifier/118/virtual/477 b/results/classifier/118/virtual/477 new file mode 100644 index 00000000..bde62dc0 --- /dev/null +++ b/results/classifier/118/virtual/477 @@ -0,0 +1,42 @@ +architecture: 0.976 +virtual: 0.966 +device: 0.924 +graphic: 0.897 +boot: 0.893 +debug: 0.888 +KVM: 0.853 +performance: 0.701 +register: 0.691 +arm: 0.647 +semantic: 0.643 +peripherals: 0.598 +PID: 0.587 +vnc: 0.486 +mistranslation: 0.445 +risc-v: 0.398 +ppc: 0.393 +permissions: 0.393 +kernel: 0.369 +network: 0.365 +hypervisor: 0.311 +TCG: 0.296 +user-level: 0.291 +files: 0.269 +VMM: 0.206 +assembly: 0.196 +socket: 0.120 +x86: 0.113 +i386: 0.088 + +Nested kvm-svm does not work since f5cc5a5c16 +Description of problem: +Nested SVM virtualization seems to not work. I bisected this to f5cc5a5c16. +Steps to reproduce: +1. Boot up a Linux guest such as the Debian Live CD with -accel kvm -cpu host +2. ```dmesg | grep kvm; ls /dev/kvm```; # Shows that KVM is disabled within the guest +Additional information: +Details about my AMD host: +``` +model name : AMD Ryzen 5 2600 Six-Core Processor +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca +``` diff --git a/results/classifier/118/virtual/498421 b/results/classifier/118/virtual/498421 new file mode 100644 index 00000000..ed3d5c9b --- /dev/null +++ b/results/classifier/118/virtual/498421 @@ -0,0 +1,40 @@ +virtual: 0.981 +graphic: 0.955 +device: 0.749 +mistranslation: 0.738 +user-level: 0.720 +semantic: 0.609 +performance: 0.567 +risc-v: 0.542 +VMM: 0.501 +architecture: 0.495 +vnc: 0.494 +boot: 0.486 +register: 0.465 +PID: 0.443 +socket: 0.404 +ppc: 0.378 +TCG: 0.369 +network: 0.363 +permissions: 0.330 +debug: 0.324 +kernel: 0.315 +arm: 0.295 +files: 0.282 +hypervisor: 0.273 +i386: 0.269 +peripherals: 0.217 +x86: 0.212 +KVM: 0.209 +assembly: 0.158 + +Emulated monitor EDID reports too few available graphics resolutions + +In a Windows guest, not very many resolution modes are available. The available modes are restricted by what the virtual "monitor" EDID reports via DDC. And apparently, your fake monitor has a short list of modes. Please add some more modes like 1152x864, at least. But what would be REALLY nice is much finer granularity so that users can set the guest res to be just enough smaller than the host display so that window decorations and such fit. + +If you use -vga std of -vga vmware, you'll have a much larger choice of resolutions. + +For -vga vmware, it's actually possible to add custom resolutions but we don't have the tooling to make that user friendly today. I'll mark this bug as a wish list to track adding that feature. + +As mentioned in comment #1, -vga std is the way to go, so marking this ticket now as "Won't fix". + diff --git a/results/classifier/118/virtual/523 b/results/classifier/118/virtual/523 new file mode 100644 index 00000000..14abb27b --- /dev/null +++ b/results/classifier/118/virtual/523 @@ -0,0 +1,156 @@ +virtual: 0.887 +mistranslation: 0.882 +hypervisor: 0.880 +peripherals: 0.880 +user-level: 0.875 +register: 0.875 +x86: 0.867 +permissions: 0.863 +performance: 0.860 +architecture: 0.852 +ppc: 0.848 +VMM: 0.841 +risc-v: 0.840 +vnc: 0.838 +graphic: 0.838 +semantic: 0.836 +device: 0.832 +network: 0.829 +debug: 0.827 +KVM: 0.827 +arm: 0.820 +assembly: 0.790 +socket: 0.787 +TCG: 0.782 +files: 0.755 +boot: 0.749 +kernel: 0.742 +PID: 0.699 +i386: 0.528 + +Some iotests failing with --enable-block-drv-whitelist-in-tools +Description of problem: +Building latest RC with Fedora, some of the iotests now report fail. We could track it down to the --enable-block-drv-whitelist-in-tools option. +Steps to reproduce: +1. ```configure --enable-block-drv-whitelist-in-tools``` +2. ```make``` +3. ```make check``` +Additional information: +``` +... + TEST iotest-qcow2: 049 [fail] +QEMU -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 +IMGPROTO -- file +PLATFORM -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64 +TEST_DIR -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmpr6u1m61s +SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper +--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/049.out ++++ 049.out.bad +@@ -199,6 +199,8 @@ + qemu-img create -f qcow2 --object secret,id=sec0,data=123456 -o encryption=on,encrypt.key-secret=sec0 TEST_DIR/t.qcow2 64M + Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 encryption=on encrypt.key-secret=sec0 cluster_size=65536 extended_l2=off compression_type=zlib size=67108864 lazy_refcounts=off refcount_bits=16 ++qemu-img: TEST_DIR/t.qcow2: Use of AES-CBC encrypted qcow2 images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted qcow2, or raw with the LUKS format instead. + == Check lazy_refcounts option (only with v3) == +... + TEST iotest-qcow2: 134 [fail] +QEMU -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 +IMGPROTO -- file +PLATFORM -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64 +TEST_DIR -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmpr6u1m61s +SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper +--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/134.out ++++ 134.out.bad +@@ -1,30 +1,24 @@ + QA output created by 134 + Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on ++qemu-img: TEST_DIR/t.IMGFMT: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead. + == reading whole image == +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == rewriting cluster part == +-wrote 512/512 bytes at offset 512 +-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 512/512 bytes at offset 0 +-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +-read 512/512 bytes at offset 512 +-512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == rewriting whole image == +-wrote 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern failure with wrong password == +-Pattern verification failed at offset 0, 134217728 bytes +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + *** done +... + TEST iotest-qcow2: 158 [fail] +QEMU -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-system-x86_64" -nodefaults -display none -accel qtest +QEMU_IMG -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-img" +QEMU_IO -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 +QEMU_NBD -- "/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/../../qemu-nbd" +IMGFMT -- qcow2 +IMGPROTO -- file +PLATFORM -- Linux/x86_64 buildvm-x86-11.iad2.fedoraproject.org 5.12.13-300.fc34.x86_64 +TEST_DIR -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch +SOCK_DIR -- /tmp/tmpr6u1m61s +SOCKET_SCM_HELPER -- /builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/socket_scm_helper +--- /builddir/build/BUILD/qemu-6.1.0-rc3/tests/qemu-iotests/158.out ++++ 158.out.bad +@@ -1,26 +1,25 @@ + QA output created by 158 + == create base == + Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728 encryption=on ++qemu-img: TEST_DIR/t.IMGFMT.base: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead. + == writing whole image == +-wrote 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2.base': No such file or directory + == verify pattern == +-read 134217728/134217728 bytes at offset 0 +-128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2.base': No such file or directory + == create overlay == + Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT encryption=on ++qemu-img: TEST_DIR/t.IMGFMT: Use of AES-CBC encrypted IMGFMT images is no longer supported in system emulators ++You can use 'qemu-img convert' to convert your image to an alternative supported format, such as unencrypted IMGFMT, or raw with the LUKS format instead. + == writing part of a cluster == +-wrote 1024/1024 bytes at offset 0 +-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 1024/1024 bytes at offset 0 +-1 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + == verify pattern == +-read 64512/64512 bytes at offset 1024 +-63 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++qemu-io: can't open: Could not open '/builddir/build/BUILD/qemu-6.1.0-rc3/qemu_kvm_build/tests/qemu-iotests/scratch/t.qcow2': No such file or directory + *** done +... +Failures: 049 134 158 +Failed 3 of 122 iotests +``` diff --git a/results/classifier/118/virtual/543 b/results/classifier/118/virtual/543 new file mode 100644 index 00000000..43bdec13 --- /dev/null +++ b/results/classifier/118/virtual/543 @@ -0,0 +1,31 @@ +virtual: 0.991 +device: 0.828 +network: 0.750 +performance: 0.707 +semantic: 0.705 +graphic: 0.595 +mistranslation: 0.574 +hypervisor: 0.565 +debug: 0.485 +architecture: 0.446 +boot: 0.401 +arm: 0.360 +vnc: 0.314 +TCG: 0.294 +PID: 0.274 +permissions: 0.251 +peripherals: 0.208 +i386: 0.207 +ppc: 0.194 +register: 0.189 +x86: 0.154 +assembly: 0.141 +files: 0.141 +user-level: 0.111 +VMM: 0.065 +risc-v: 0.054 +socket: 0.040 +KVM: 0.009 +kernel: 0.008 + +virtio-blk: ASSERT: !s->dataplane_started diff --git a/results/classifier/118/virtual/563 b/results/classifier/118/virtual/563 new file mode 100644 index 00000000..4ded3d9e --- /dev/null +++ b/results/classifier/118/virtual/563 @@ -0,0 +1,31 @@ +virtual: 0.999 +KVM: 0.998 +architecture: 0.995 +hypervisor: 0.988 +device: 0.974 +performance: 0.813 +boot: 0.597 +graphic: 0.404 +mistranslation: 0.392 +semantic: 0.316 +register: 0.314 +permissions: 0.300 +arm: 0.270 +socket: 0.262 +vnc: 0.239 +risc-v: 0.213 +network: 0.203 +PID: 0.166 +files: 0.138 +VMM: 0.079 +assembly: 0.079 +ppc: 0.064 +debug: 0.046 +user-level: 0.044 +x86: 0.035 +peripherals: 0.026 +TCG: 0.020 +kernel: 0.007 +i386: 0.002 + +KVM ubuntu 20 VPS on Ryzen 9 5950X diff --git a/results/classifier/118/virtual/584146 b/results/classifier/118/virtual/584146 new file mode 100644 index 00000000..5feea33d --- /dev/null +++ b/results/classifier/118/virtual/584146 @@ -0,0 +1,42 @@ +virtual: 0.939 +files: 0.816 +device: 0.731 +vnc: 0.536 +architecture: 0.507 +network: 0.491 +socket: 0.424 +graphic: 0.403 +semantic: 0.403 +register: 0.392 +VMM: 0.371 +ppc: 0.329 +risc-v: 0.321 +debug: 0.311 +performance: 0.306 +boot: 0.296 +mistranslation: 0.258 +arm: 0.250 +PID: 0.215 +i386: 0.199 +TCG: 0.197 +kernel: 0.182 +user-level: 0.173 +permissions: 0.169 +x86: 0.165 +assembly: 0.119 +peripherals: 0.086 +hypervisor: 0.069 +KVM: 0.048 + +Virtual fat breaks with -snapshot + +When using fat emulation together with snapshot, qemu fails to find the directory for the fat "filesystem". + +See Debian bug#504049, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504049 and discussion on qemu-devel with Kevin Wolf, http://marc.info/?t=126850802800001 for details. + +There's a workaround for this bug: when using full path for fat:/dir/name it works. + +Can you still reproduce this issue with the latest version of QEMU? If so, could you please provide a proper command line that triggers this problem? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/587 b/results/classifier/118/virtual/587 new file mode 100644 index 00000000..c831a333 --- /dev/null +++ b/results/classifier/118/virtual/587 @@ -0,0 +1,31 @@ +virtual: 0.989 +boot: 0.915 +device: 0.817 +VMM: 0.785 +graphic: 0.674 +architecture: 0.610 +hypervisor: 0.577 +risc-v: 0.557 +arm: 0.547 +vnc: 0.512 +performance: 0.502 +files: 0.420 +network: 0.418 +debug: 0.408 +TCG: 0.401 +semantic: 0.384 +PID: 0.363 +KVM: 0.330 +ppc: 0.295 +register: 0.265 +x86: 0.261 +i386: 0.211 +peripherals: 0.196 +socket: 0.195 +mistranslation: 0.164 +kernel: 0.134 +permissions: 0.116 +user-level: 0.063 +assembly: 0.004 + +qemu show no error but the virtual machine stuck in boot (GPU passthrough) diff --git a/results/classifier/118/virtual/589 b/results/classifier/118/virtual/589 new file mode 100644 index 00000000..043d176d --- /dev/null +++ b/results/classifier/118/virtual/589 @@ -0,0 +1,31 @@ +virtual: 0.991 +VMM: 0.870 +device: 0.810 +graphic: 0.792 +debug: 0.654 +architecture: 0.641 +performance: 0.506 +arm: 0.480 +files: 0.417 +mistranslation: 0.283 +semantic: 0.262 +boot: 0.260 +risc-v: 0.172 +hypervisor: 0.141 +peripherals: 0.138 +permissions: 0.133 +KVM: 0.118 +network: 0.102 +i386: 0.076 +user-level: 0.075 +ppc: 0.074 +register: 0.055 +vnc: 0.055 +PID: 0.030 +assembly: 0.023 +socket: 0.018 +TCG: 0.006 +x86: 0.003 +kernel: 0.001 + +Error installing QGA file under virtual machine of windows system diff --git a/results/classifier/118/virtual/613529 b/results/classifier/118/virtual/613529 new file mode 100644 index 00000000..ef058152 --- /dev/null +++ b/results/classifier/118/virtual/613529 @@ -0,0 +1,56 @@ +virtual: 0.937 +device: 0.786 +user-level: 0.714 +boot: 0.712 +mistranslation: 0.706 +architecture: 0.681 +performance: 0.666 +semantic: 0.661 +graphic: 0.647 +files: 0.646 +PID: 0.640 +register: 0.631 +socket: 0.585 +permissions: 0.562 +vnc: 0.557 +kernel: 0.536 +risc-v: 0.516 +ppc: 0.513 +VMM: 0.471 +network: 0.460 +i386: 0.424 +x86: 0.402 +hypervisor: 0.394 +peripherals: 0.328 +TCG: 0.326 +arm: 0.322 +assembly: 0.311 +KVM: 0.307 +debug: 0.141 + +qemu does not accept regular disk geometry + +Hi, + +I am currently hunting a strange bug in qemu/kvm: + +I am using an lvm logical volume as a virtual hard disk for a virtual machine. + +I use fdisk or parted to create a partition table and partitions, kpartx to generate the device entries for the partitions, then install linux on ext3/ext4 with grub or msdos filesystem with syslinux. + +But then, in most cases even the boot process fails or behaves strangely, sometimes even mounting the file system in the virtual machine fails. It seems as if there is a problem with the virtual disk geometry. The problem does not seem to occur if I reboot the host system after creating the partition table on the logical volume. I guess the linux kernel needs to learn the disk geometry by reboot. A blkdev --rereadpt does not work on lvm volumes. + +The first approach to test/fix the problem would be to pass the disk geometry to qemu/lvm with the -drive option. Unfortunately, qemu/kvm does not accept the default geometry with 255 heads and 63 sectors. Seems to limit the number of heads to 16, thus limiting the disk size. + +Seems to be the same issue as in +http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=5218 + +has been (orally) confirmed by other users. + +It is effectively impossible to reliably install a system on an lvm logical device and run it under kvm/qemu + + +Which version of QEMU have you been using for your tests? Can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/628 b/results/classifier/118/virtual/628 new file mode 100644 index 00000000..1864d04d --- /dev/null +++ b/results/classifier/118/virtual/628 @@ -0,0 +1,38 @@ +x86: 0.968 +virtual: 0.957 +architecture: 0.896 +device: 0.853 +network: 0.823 +ppc: 0.769 +graphic: 0.729 +files: 0.695 +mistranslation: 0.678 +VMM: 0.663 +socket: 0.639 +performance: 0.634 +boot: 0.626 +vnc: 0.592 +semantic: 0.591 +arm: 0.570 +register: 0.529 +permissions: 0.524 +kernel: 0.517 +hypervisor: 0.507 +debug: 0.471 +TCG: 0.464 +PID: 0.459 +user-level: 0.439 +risc-v: 0.362 +peripherals: 0.258 +i386: 0.232 +assembly: 0.147 +KVM: 0.075 + +nested virtualization on whpx +Additional information: +Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression. +``` +PS J:\> E:\scoopg\shims\qemu-system-x86_64.exe --version +QEMU emulator version 6.1.0 (v6.1.0-11882-g7deea770bf-dirty) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +``` diff --git a/results/classifier/118/virtual/643430 b/results/classifier/118/virtual/643430 new file mode 100644 index 00000000..30cb050c --- /dev/null +++ b/results/classifier/118/virtual/643430 @@ -0,0 +1,67 @@ +virtual: 0.930 +graphic: 0.910 +i386: 0.890 +architecture: 0.875 +x86: 0.863 +performance: 0.848 +ppc: 0.844 +socket: 0.843 +device: 0.832 +register: 0.829 +user-level: 0.827 +PID: 0.822 +boot: 0.819 +mistranslation: 0.817 +TCG: 0.816 +semantic: 0.809 +network: 0.808 +debug: 0.806 +VMM: 0.805 +files: 0.794 +kernel: 0.791 +permissions: 0.772 +hypervisor: 0.768 +vnc: 0.761 +arm: 0.726 +KVM: 0.724 +risc-v: 0.723 +assembly: 0.619 +peripherals: 0.619 + +system_powerdown NOT working in qemu-kvm with KVM enabled for FreeBSD guests + +system_powerdown stops working in qemu-kvm for FreeBSD guests if KVM is enabled. + +How to reproduce: + +1. qemu -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso +2. Enter system_powerdown in the qemu console +3. Nothing happens. + +Adding --no-kvm option makes system_powerdown work: + +1. qemu --no-kvm -cdrom ~/.VirtualBox/libvirt/FreeBSD-8.1-RELEASE-i386-bootonly.iso +2. system_powerdown +3. FreeBSD installer shows the shutdown dialog as expected + +Tested on FreeBSD 6.4, 7.2, and 8.0 with qemu-kvm 0.12.5 and older versions. + +The subject should be: system_powerdown is NOT working - can someone correct this please? + +I have the same issue with FreeBSD 8.1-RELEASE (i386 and x86_64) on qemu-kvm 0.12.5 (Fedora 13) + +system_powerdown works properly for Linux and Windows 2008 guests, but not for FreeBSD The ACPI power button event is not received by the FreeBSD guest. + +I found this (unconfirmed) status report: +http://www.spinics.net/lists/kvm/msg40064.html + +So it seems to be a regression... + + + +This is fixed upstream (in seabios actually) by commit 6d5a2172f2b76900572107868ec080400c4f615d -- see http://git.linuxtogo.org/?p=kevin/seabios.git;a=commit;h=6d5a2172f2b76900572107868ec080400c4f615d . I added this patch to Debian releases of qemu-kvm, both for squeeze and experimental. + +The updated bios.bin works fine for me, thanks. + +Marking this now as "Fix released" according to comment #3 + diff --git a/results/classifier/118/virtual/669 b/results/classifier/118/virtual/669 new file mode 100644 index 00000000..7107cb94 --- /dev/null +++ b/results/classifier/118/virtual/669 @@ -0,0 +1,53 @@ +virtual: 0.970 +boot: 0.961 +files: 0.944 +kernel: 0.934 +device: 0.925 +graphic: 0.904 +PID: 0.849 +architecture: 0.829 +x86: 0.824 +peripherals: 0.810 +performance: 0.802 +hypervisor: 0.802 +debug: 0.785 +user-level: 0.784 +network: 0.779 +register: 0.765 +socket: 0.754 +vnc: 0.751 +risc-v: 0.741 +VMM: 0.741 +permissions: 0.739 +KVM: 0.733 +assembly: 0.729 +TCG: 0.671 +ppc: 0.646 +mistranslation: 0.627 +semantic: 0.614 +arm: 0.606 +i386: 0.589 + +QEMU Segmentation fault - UnRaid 9.3.2 when passing nvidia k620 GPU inserted into Lenovo x3550 M5 server +Description of problem: +When I pass the following GPU to any Virtual Machine: +IOMMU group 33:[10de:13bb] 81:00.0 VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K620] (rev a2) +I receive this error as soon as i try to boot the VM (any OS). + +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: enabling device (0140 -> 0141) +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258 +Oct 13 03:06:12 MyUnraid-1U kernel: vfio-pci 0000:81:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +**Oct 13 03:06:12 MyUnraid-1U kernel: qemu-system-x86[6080]: segfault at a8 ip 00005618620c812a sp 00007ffc610531b0 error 4 in qemu-system-x86_64[561861fbb000+51d000] +Oct 13 03:06:12 MyUnraid-1U kernel: Code: ef ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 e8 4e de ff ff 48 89 df e8 16 e9 ff ff <48> 8b 85 a8 00 00 00 48 85 c0 74 52 8b 93 a0 00 00 00 eb 0e 66 90** +Oct 13 03:06:13 MyUnraid-1U avahi-daemon[3536]: Interface vnet0.IPv6 no longer relevant for mDNS. + +This is one example of W10 VM: +In attach my VM template + +[VM_example.txt](/uploads/428ca5a10ef3338d5d408583fc552b25/VM_example.txt) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/virtual/681 b/results/classifier/118/virtual/681 new file mode 100644 index 00000000..49eed90c --- /dev/null +++ b/results/classifier/118/virtual/681 @@ -0,0 +1,55 @@ +virtual: 0.935 +device: 0.920 +graphic: 0.897 +VMM: 0.869 +vnc: 0.831 +PID: 0.818 +architecture: 0.775 +performance: 0.723 +socket: 0.686 +ppc: 0.678 +debug: 0.673 +kernel: 0.651 +arm: 0.607 +hypervisor: 0.594 +risc-v: 0.574 +permissions: 0.573 +files: 0.553 +mistranslation: 0.524 +register: 0.505 +network: 0.501 +TCG: 0.489 +semantic: 0.481 +i386: 0.416 +x86: 0.415 +boot: 0.407 +KVM: 0.376 +user-level: 0.257 +peripherals: 0.248 +assembly: 0.217 + +Error saving memory to disk +Description of problem: +When trying to save the state of the machine using virt-manager (3.2.0) it fails with this error: + +Error saving domain: operation failed: domain save job: unexpectedly failed +```bash +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/vmmenu.py", line 182, in cb + vm.save(meter=asyncjob.get_meter()) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1377, in save + self._backend.managedSave(0) + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1780, in managedSave + raise libvirtError('virDomainManagedSave() failed') +libvirt.libvirtError: operation failed: domain save job: unexpectedly failed +``` +Steps to reproduce: +1. setup a virtual machine +2. setup a linux distro +3. try to save the memory to disk +Additional information: +Will be provided when needed diff --git a/results/classifier/118/virtual/70 b/results/classifier/118/virtual/70 new file mode 100644 index 00000000..505f7409 --- /dev/null +++ b/results/classifier/118/virtual/70 @@ -0,0 +1,31 @@ +virtual: 0.976 +vnc: 0.870 +network: 0.819 +device: 0.778 +mistranslation: 0.767 +files: 0.609 +debug: 0.515 +risc-v: 0.371 +register: 0.324 +graphic: 0.256 +user-level: 0.226 +peripherals: 0.177 +boot: 0.160 +VMM: 0.157 +permissions: 0.145 +performance: 0.144 +arm: 0.121 +PID: 0.098 +TCG: 0.096 +hypervisor: 0.090 +semantic: 0.089 +kernel: 0.088 +ppc: 0.076 +socket: 0.068 +i386: 0.062 +x86: 0.031 +architecture: 0.028 +assembly: 0.014 +KVM: 0.009 + +hda sound capture broken with VNC diff --git a/results/classifier/118/virtual/722 b/results/classifier/118/virtual/722 new file mode 100644 index 00000000..fff32237 --- /dev/null +++ b/results/classifier/118/virtual/722 @@ -0,0 +1,42 @@ +virtual: 0.939 +device: 0.844 +network: 0.781 +performance: 0.720 +graphic: 0.712 +PID: 0.684 +vnc: 0.674 +debug: 0.587 +VMM: 0.576 +socket: 0.539 +semantic: 0.514 +permissions: 0.504 +risc-v: 0.503 +architecture: 0.480 +boot: 0.438 +files: 0.428 +peripherals: 0.389 +i386: 0.383 +register: 0.368 +hypervisor: 0.368 +KVM: 0.358 +arm: 0.337 +x86: 0.323 +mistranslation: 0.308 +ppc: 0.308 +user-level: 0.269 +TCG: 0.227 +assembly: 0.192 +kernel: 0.184 + +Qemu slirp connectivity lost when host enters vpn(openvpn or wireguard) +Description of problem: +No connectivity after host enters a vpn, tested with valid openvpn +and wireguard. +Steps to reproduce: +1. Open the vpn. +2. Open a virtual machine using slirp +3. Ping 8.8.8.8(if you can...) +Additional information: +The bug is independent on the order of execution, if you start the vm +to see it works, and run the vpn script, the connectivity in the vm +will drop, and come back when the tunneled connection is over. diff --git a/results/classifier/118/virtual/766 b/results/classifier/118/virtual/766 new file mode 100644 index 00000000..1d304b21 --- /dev/null +++ b/results/classifier/118/virtual/766 @@ -0,0 +1,57 @@ +virtual: 0.975 +x86: 0.957 +TCG: 0.920 +graphic: 0.824 +performance: 0.772 +semantic: 0.761 +architecture: 0.707 +device: 0.691 +mistranslation: 0.673 +vnc: 0.625 +ppc: 0.577 +PID: 0.534 +kernel: 0.515 +debug: 0.515 +socket: 0.502 +i386: 0.495 +network: 0.485 +files: 0.468 +peripherals: 0.468 +permissions: 0.456 +VMM: 0.449 +hypervisor: 0.432 +register: 0.403 +user-level: 0.399 +risc-v: 0.385 +boot: 0.380 +arm: 0.343 +assembly: 0.167 +KVM: 0.121 + +qemu-system-x86_64: Reboot loop after Machine->Reset +Description of problem: +When using tcg, the virtual machine goes into a reboot loop after the VM +is rebooted through UI->Machine->Reboot menu, or through outb(0xcf9, 0xf). +There might be other reboot mechanisms that result in the same loop. + +The loop doesn't occur when using kvm: +qemu-system-x86_64 -M q35 -enable-kvm +Steps to reproduce: +1. Run the command. (The one without -enable-kvm.) +2. From the UI, click on Machine->Reset. +3. See that the VM locks up, instead of resetting. +Additional information: +The reboot loop occurs because a variable defined by Seabios cannot be updated, possibly because the memory is read-only. + +The variable in question is [HaveRunPost](https://github.com/coreboot/seabios/blob/2dd4b9b3f84019668719344b40dba79d681be41c/src/fw/shadow.c#L194). If HaveRunPost is non-zero, the BIOS follows the resume path. When the reset is clicked, the BIOS does indeed gain control and follow the resume path because HaveRunPost is 2. The control ends up at qemu_reboot, which should reset HaveRunPost to 0 and trigger another reset, so that this second time around, the BIOS sees HaveRunPost as 0, and follows the initialization path instead. + +But, even though the instruction to update HaveRunPost seems to run, the value remains non-zero (2 to be exact). + +``` + // HaveRunPost has value 2 here. + barrier(); + HaveRunPost = 0; + barrier(); + // If a dprintf(1, "%x\n", HaveRunPost); is placed here, the value printed is 2 and not 0! + // With kvm-enabled, this dprintf prints 0. +``` diff --git a/results/classifier/118/virtual/775604 b/results/classifier/118/virtual/775604 new file mode 100644 index 00000000..6cfe6bc0 --- /dev/null +++ b/results/classifier/118/virtual/775604 @@ -0,0 +1,46 @@ +x86: 0.972 +virtual: 0.923 +architecture: 0.911 +graphic: 0.888 +device: 0.862 +VMM: 0.854 +performance: 0.799 +vnc: 0.695 +semantic: 0.691 +mistranslation: 0.659 +debug: 0.588 +hypervisor: 0.564 +permissions: 0.562 +PID: 0.517 +socket: 0.484 +user-level: 0.468 +risc-v: 0.447 +files: 0.414 +network: 0.408 +register: 0.374 +ppc: 0.371 +boot: 0.361 +kernel: 0.333 +KVM: 0.329 +TCG: 0.239 +arm: 0.215 +peripherals: 0.211 +i386: 0.173 +assembly: 0.146 + +Could not open SDL display when running XP as guest + +When running XP as guest on Linux 2.6.38 x86_64 (Arch Linux) in full screen qemu will crash. Dropping to 1400x900 or below does not have a problem nor does windowed mode. + +1. Running: +qemu-system-x86_64 -vga std -full-screen Virtual_Machines/Windows_XP/Windows_XP.img + +Produces error: +Could not open SDL display (1920x1200x0): No video mode large enough for 1920x1200 + +qemu-kvm version 0.14.0-1 + +Triaging old bug tickets... QEMU 0.14 is completely outdated nowadays. Can you still reproduce this behavior with the latest version of QEMU? + + Thanks for following up. I am no longer using QEMU. + diff --git a/results/classifier/118/virtual/787 b/results/classifier/118/virtual/787 new file mode 100644 index 00000000..37c29ac2 --- /dev/null +++ b/results/classifier/118/virtual/787 @@ -0,0 +1,42 @@ +virtual: 0.955 +device: 0.900 +graphic: 0.864 +x86: 0.798 +performance: 0.767 +vnc: 0.759 +VMM: 0.753 +architecture: 0.727 +socket: 0.710 +PID: 0.686 +permissions: 0.662 +risc-v: 0.632 +debug: 0.596 +hypervisor: 0.568 +TCG: 0.562 +files: 0.557 +register: 0.546 +kernel: 0.546 +network: 0.540 +boot: 0.536 +i386: 0.527 +ppc: 0.510 +KVM: 0.457 +semantic: 0.452 +arm: 0.410 +mistranslation: 0.409 +peripherals: 0.321 +user-level: 0.200 +assembly: 0.147 + +6.2.0 Regression with Intel GVT-g +Description of problem: +Until version 6.1.0 the Intel GVT-g graphics passtrought was working flawless. But, since the version 6.2.0 the machine with the exact same configuration is not working anymore, presenting an error that the graphics device was not found. + +``` +qemu-system-x86_64: -set device.hostdev0.x-igd-opregion=on: there is no device "hostdev0" defined +``` + +Downgrade to 6.1.0 fixes the problem. +Steps to reproduce: +1. Create a virtual machine with GVT-g +2. Try to run the machine. diff --git a/results/classifier/118/virtual/800 b/results/classifier/118/virtual/800 new file mode 100644 index 00000000..2dfb8793 --- /dev/null +++ b/results/classifier/118/virtual/800 @@ -0,0 +1,55 @@ +virtual: 0.964 +device: 0.952 +graphic: 0.916 +kernel: 0.883 +architecture: 0.803 +peripherals: 0.771 +PID: 0.740 +semantic: 0.683 +x86: 0.681 +VMM: 0.681 +performance: 0.679 +debug: 0.652 +ppc: 0.643 +vnc: 0.630 +files: 0.622 +mistranslation: 0.556 +hypervisor: 0.482 +risc-v: 0.482 +permissions: 0.481 +boot: 0.464 +register: 0.429 +socket: 0.418 +network: 0.381 +arm: 0.377 +user-level: 0.371 +TCG: 0.298 +i386: 0.223 +assembly: 0.184 +KVM: 0.134 + +Cannot write to MTP Devices in Qemu 6.0.0+ +Description of problem: +QEMU versions above 6.0.0 are no longer able to write to MTP devices, the kernel prints a warning which is unique to versions above 6.0.0: +``` +usb-mtp: file monitoring init failed: File monitoring not available on this platform is just warning +``` +Steps to reproduce: +1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0 +2. Mount the MTP device using something: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + touch mtpDevice/test + ``` +4. Observe that you will get an input/output error when trying to write to the device, like this: + ``` + vm-test-run-mtp> client: must succeed: /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh >&2 + vm-test-run-mtp> client # Device 0 (VID=46f4 and PID=0004) is a QEMU Virtual MTP. + vm-test-run-mtp> client # qemu-system-x86_64: usb-mtp: file monitoring init failed: File monitoring not available on this platform + vm-test-run-mtp> client # /nix/store/xmib7222ybr72iyycra4w386s8p1k4av-jmtpfsTest.sh: line 4: phone/tmp/testFile: Input/output error + ``` +Additional information: + diff --git a/results/classifier/118/virtual/809912 b/results/classifier/118/virtual/809912 new file mode 100644 index 00000000..945b6828 --- /dev/null +++ b/results/classifier/118/virtual/809912 @@ -0,0 +1,50 @@ +x86: 0.986 +virtual: 0.981 +graphic: 0.957 +architecture: 0.953 +hypervisor: 0.916 +device: 0.905 +performance: 0.891 +kernel: 0.859 +KVM: 0.837 +ppc: 0.777 +semantic: 0.732 +VMM: 0.697 +user-level: 0.692 +PID: 0.665 +vnc: 0.621 +arm: 0.590 +boot: 0.540 +debug: 0.538 +network: 0.529 +register: 0.442 +peripherals: 0.438 +permissions: 0.410 +socket: 0.406 +risc-v: 0.389 +mistranslation: 0.385 +TCG: 0.355 +files: 0.325 +assembly: 0.172 +i386: 0.158 + +qemu-kvm -m bigger 4096 aborts with 'Bad ram offset' + +When I try to start a virtual machine (x86_64 guest on a x86_64 host that has 32GB memory, using kvm_amd module, both host and guest running linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp 2 -m 4096 ...", shortly after the guest kernel starts, qemu aborts with a message "Bad ram offset 11811c000". + +With e.g. "-m 3500" (or lower), the virtual machine runs fine. + +I experience this both using qemu-kvm 0.14.1 and a recent version from git +commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021 +Merge: d589310 75ef849 +Author: Avi Kivity <email address hidden> +Date: Mon Jul 4 13:36:06 2011 +0300 + +After updating from the QEMU that came with Ubuntu 11.04 to 070411-1ubuntu2 version, I am seeing the bad ram offset error, also. If I drop the memory for the guest (which is Windows 7 Pro 64-bit) from 4 GB to 3300MB, the error goes away. + +Host machine has an AMD Opteron 6128 with 32GB RAM and is running the 64 bit version of Ubuntu 11.04 updated to current versions as of November + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/816860 b/results/classifier/118/virtual/816860 new file mode 100644 index 00000000..79de178a --- /dev/null +++ b/results/classifier/118/virtual/816860 @@ -0,0 +1,61 @@ +virtual: 0.914 +KVM: 0.909 +performance: 0.878 +device: 0.772 +network: 0.741 +graphic: 0.713 +hypervisor: 0.696 +semantic: 0.651 +register: 0.601 +PID: 0.591 +vnc: 0.546 +permissions: 0.539 +architecture: 0.538 +ppc: 0.522 +kernel: 0.521 +socket: 0.508 +mistranslation: 0.483 +VMM: 0.476 +boot: 0.476 +peripherals: 0.459 +risc-v: 0.440 +files: 0.436 +x86: 0.363 +assembly: 0.357 +i386: 0.335 +user-level: 0.310 +arm: 0.296 +debug: 0.231 +TCG: 0.187 + +Guest machine freezes when NFS mount goes offline + +I have a virtual KVM machine that has 2 CDROM units with ISOs mounted from a NFS mount point. When NFS server goes offline the virtual machine blocks completely instead of throwing read errors for the CDROM device. + +Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +Guest: Windows 7 professional SP 1 + +On Wed, Jul 27, 2011 at 10:09 AM, Igor Blanco <email address hidden> wrote: +> Public bug reported: +> +> I have a virtual KVM machine that has 2 CDROM units with ISOs mounted +> from a NFS mount point. When NFS server goes offline the virtual machine +> blocks completely instead of throwing read errors for the CDROM device. +> +> Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0) +> KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel) +> Guest: Windows 7 professional SP 1 + +Thanks for reporting this. There are instances where QEMU performs +blocking operations in a thread that will prevent the guest from +running. I suspect you are hitting this case and refactoring work +needs to be done to ensure that QEMU threads never block. + +Stefan + + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/virtual/81775929 b/results/classifier/118/virtual/81775929 new file mode 100644 index 00000000..28280490 --- /dev/null +++ b/results/classifier/118/virtual/81775929 @@ -0,0 +1,260 @@ +virtual: 0.864 +assembly: 0.849 +permissions: 0.849 +PID: 0.847 +performance: 0.831 +vnc: 0.825 +semantic: 0.825 +architecture: 0.823 +arm: 0.819 +graphic: 0.818 +register: 0.817 +KVM: 0.815 +ppc: 0.815 +user-level: 0.813 +mistranslation: 0.811 +socket: 0.810 +hypervisor: 0.802 +debug: 0.799 +x86: 0.793 +files: 0.788 +VMM: 0.781 +device: 0.777 +risc-v: 0.774 +network: 0.759 +peripherals: 0.757 +boot: 0.742 +TCG: 0.742 +kernel: 0.740 +i386: 0.613 + +[Qemu-devel] [BUG] Monitor QMP is broken ? + +Hello! + + I have updated my qemu to the recent version and it seems to have lost +compatibility with +libvirt. The error message is: +--- cut --- +internal error: unable to execute QEMU command 'qmp_capabilities': QMP input +object member +'id' is unexpected +--- cut --- + What does it mean? Is it intentional or not? + +Kind regards, +Pavel Fedin +Expert Engineer +Samsung Electronics Research center Russia + +Hello! + +> +I have updated my qemu to the recent version and it seems to have lost +> +compatibility +with +> +libvirt. The error message is: +> +--- cut --- +> +internal error: unable to execute QEMU command 'qmp_capabilities': QMP input +> +object +> +member +> +'id' is unexpected +> +--- cut --- +> +What does it mean? Is it intentional or not? +I have found the problem. It is caused by commit +65207c59d99f2260c5f1d3b9c491146616a522aa. libvirt does not seem to use the +removed +asynchronous interface but it still feeds in JSONs with 'id' field set to +something. So i +think the related fragment in qmp_check_input_obj() function should be brought +back + +Kind regards, +Pavel Fedin +Expert Engineer +Samsung Electronics Research center Russia + +On Fri, Jun 05, 2015 at 04:58:46PM +0300, Pavel Fedin wrote: +> +Hello! +> +> +> I have updated my qemu to the recent version and it seems to have lost +> +> compatibility +> +with +> +> libvirt. The error message is: +> +> --- cut --- +> +> internal error: unable to execute QEMU command 'qmp_capabilities': QMP +> +> input object +> +> member +> +> 'id' is unexpected +> +> --- cut --- +> +> What does it mean? Is it intentional or not? +> +> +I have found the problem. It is caused by commit +> +65207c59d99f2260c5f1d3b9c491146616a522aa. libvirt does not seem to use the +> +removed +> +asynchronous interface but it still feeds in JSONs with 'id' field set to +> +something. So i +> +think the related fragment in qmp_check_input_obj() function should be +> +brought back +If QMP is rejecting the 'id' parameter that is a regression bug. + +[quote] +The QMP spec says + +2.3 Issuing Commands +-------------------- + +The format for command execution is: + +{ "execute": json-string, "arguments": json-object, "id": json-value } + + Where, + +- The "execute" member identifies the command to be executed by the Server +- The "arguments" member is used to pass any arguments required for the + execution of the command, it is optional when no arguments are + required. Each command documents what contents will be considered + valid when handling the json-argument +- The "id" member is a transaction identification associated with the + command execution, it is optional and will be part of the response if + provided. The "id" member can be any json-value, although most + clients merely use a json-number incremented for each successive + command + + +2.4 Commands Responses +---------------------- + +There are two possible responses which the Server will issue as the result +of a command execution: success or error. + +2.4.1 success +------------- + +The format of a success response is: + +{ "return": json-value, "id": json-value } + + Where, + +- The "return" member contains the data returned by the command, which + is defined on a per-command basis (usually a json-object or + json-array of json-objects, but sometimes a json-number, json-string, + or json-array of json-strings); it is an empty json-object if the + command does not return data +- The "id" member contains the transaction identification associated + with the command execution if issued by the Client + +[/quote] + +And as such, libvirt chose to /always/ send an 'id' parameter in all +commands it issues. + +We don't however validate the id in the reply, though arguably we +should have done so. + +Regards, +Daniel +-- +|: +http://berrange.com +-o- +http://www.flickr.com/photos/dberrange/ +:| +|: +http://libvirt.org +-o- +http://virt-manager.org +:| +|: +http://autobuild.org +-o- +http://search.cpan.org/~danberr/ +:| +|: +http://entangle-photo.org +-o- +http://live.gnome.org/gtk-vnc +:| + +"Daniel P. Berrange" <address@hidden> writes: + +> +On Fri, Jun 05, 2015 at 04:58:46PM +0300, Pavel Fedin wrote: +> +> Hello! +> +> +> +> > I have updated my qemu to the recent version and it seems to have +> +> > lost compatibility +> +> with +> +> > libvirt. The error message is: +> +> > --- cut --- +> +> > internal error: unable to execute QEMU command 'qmp_capabilities': +> +> > QMP input object +> +> > member +> +> > 'id' is unexpected +> +> > --- cut --- +> +> > What does it mean? Is it intentional or not? +> +> +> +> I have found the problem. It is caused by commit +> +> 65207c59d99f2260c5f1d3b9c491146616a522aa. libvirt does not seem to +> +> use the removed +> +> asynchronous interface but it still feeds in JSONs with 'id' field +> +> set to something. So i +> +> think the related fragment in qmp_check_input_obj() function should +> +> be brought back +> +> +If QMP is rejecting the 'id' parameter that is a regression bug. +It is definitely a regression, my fault, and I'll get it fixed a.s.a.p. + +[...] + diff --git a/results/classifier/118/virtual/884 b/results/classifier/118/virtual/884 new file mode 100644 index 00000000..d2996f72 --- /dev/null +++ b/results/classifier/118/virtual/884 @@ -0,0 +1,38 @@ +virtual: 0.974 +device: 0.888 +graphic: 0.878 +peripherals: 0.781 +performance: 0.711 +hypervisor: 0.383 +network: 0.347 +architecture: 0.299 +semantic: 0.275 +permissions: 0.275 +debug: 0.257 +TCG: 0.213 +VMM: 0.211 +boot: 0.197 +files: 0.189 +risc-v: 0.165 +vnc: 0.156 +arm: 0.154 +PID: 0.143 +kernel: 0.140 +i386: 0.135 +mistranslation: 0.130 +KVM: 0.119 +register: 0.111 +ppc: 0.108 +x86: 0.085 +socket: 0.060 +user-level: 0.054 +assembly: 0.051 + +Stuck when using virtio driver to rotate the screen +Description of problem: +Configure the virtual machine's graphics card as Virtio, and use `xrandr -o left` to rotate the screen and it will get stuck. + +Configure the graphics card as VGA, and use `xrandr -o left` to rotate the screen normally. +Steps to reproduce: +1. Configure the virtual machine's graphics card as Virtio +2. use `xrandr -o left` to rotate the screen diff --git a/results/classifier/118/virtual/90 b/results/classifier/118/virtual/90 new file mode 100644 index 00000000..52599c9d --- /dev/null +++ b/results/classifier/118/virtual/90 @@ -0,0 +1,31 @@ +virtual: 0.963 +device: 0.801 +performance: 0.626 +semantic: 0.606 +files: 0.522 +graphic: 0.476 +mistranslation: 0.405 +user-level: 0.388 +arm: 0.345 +register: 0.304 +peripherals: 0.247 +permissions: 0.244 +boot: 0.217 +socket: 0.179 +network: 0.165 +risc-v: 0.152 +debug: 0.147 +PID: 0.119 +TCG: 0.118 +architecture: 0.116 +i386: 0.115 +assembly: 0.084 +ppc: 0.072 +vnc: 0.054 +kernel: 0.054 +VMM: 0.024 +x86: 0.022 +KVM: 0.018 +hypervisor: 0.015 + +vga/std lacks few wide screen modes. diff --git a/results/classifier/118/virtual/901 b/results/classifier/118/virtual/901 new file mode 100644 index 00000000..ad25eb46 --- /dev/null +++ b/results/classifier/118/virtual/901 @@ -0,0 +1,40 @@ +virtual: 0.966 +device: 0.940 +KVM: 0.888 +graphic: 0.884 +architecture: 0.736 +mistranslation: 0.624 +PID: 0.560 +arm: 0.557 +vnc: 0.516 +register: 0.493 +debug: 0.492 +risc-v: 0.489 +performance: 0.431 +semantic: 0.407 +VMM: 0.378 +ppc: 0.361 +permissions: 0.337 +boot: 0.325 +files: 0.285 +TCG: 0.260 +i386: 0.258 +hypervisor: 0.226 +socket: 0.221 +user-level: 0.173 +kernel: 0.169 +x86: 0.148 +assembly: 0.148 +network: 0.078 +peripherals: 0.044 + +Bad screen behavior with adaptive sync +Description of problem: +KDE Wayland has freesync automatically enabled for full screen applications[[1]](https://wiki.archlinux.org/title/Variable_refresh_rate#Wayland_configuration). When using a VM in full screen mode, the screen starts having a strange behavior, like "blinking". I've tried windows 10, Linux Mint, MX Linux and Ubuntu 21.10. +The problem disappears if using Xorg or disabling freesync trough KDE settings. +Steps to reproduce: +1. On KDE Wayland, check if freesync is activated in settings> screen> adaptive synchronization +2. Launch any vm in fuul screen mode +3. Observe the screen +Additional information: + diff --git a/results/classifier/118/virtual/932490 b/results/classifier/118/virtual/932490 new file mode 100644 index 00000000..d90c1815 --- /dev/null +++ b/results/classifier/118/virtual/932490 @@ -0,0 +1,55 @@ +virtual: 0.919 +performance: 0.865 +user-level: 0.850 +x86: 0.848 +semantic: 0.834 +mistranslation: 0.821 +architecture: 0.780 +device: 0.733 +graphic: 0.659 +permissions: 0.653 +peripherals: 0.650 +ppc: 0.650 +PID: 0.640 +debug: 0.637 +network: 0.613 +register: 0.604 +kernel: 0.585 +assembly: 0.557 +socket: 0.547 +hypervisor: 0.543 +i386: 0.540 +vnc: 0.520 +KVM: 0.501 +boot: 0.474 +risc-v: 0.471 +VMM: 0.459 +files: 0.434 +arm: 0.394 +TCG: 0.340 + +Qemu fails on -fda /dev/fd0 when no medium is present + +# qemu-system-x86_64 --version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +# qemu-system-x86_64 -fda /dev/fd0 +qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No such device or address + +Starting with a medium (floppy disk) inserted, then removing or changing the medium works fine. + +Is this still an issue with the latest version of QEMU (currently v2.10), or could we close this ticket nowadays? + +Sorry, it has been more than five years and I don't have a system with a floppy disk to test anymore. + +Best, +Herbert + +Likely the bug as reported still exists, because this attempts to use the disk image, not the floppy drive as a whole. If there's no floppy inserted, there's no disk image to use. Later versions of QEMU even explicitly remove support for pass-through floppy disks. + +Basically, what you want to do is to create a normal emulated floppy drive in QEMU, and then use the block device add commands to use the /dev/fd0 as a media which can then be virtually inserted into the virtual floppy device. + +QEMU does not have support for doing pass-through of the floppy controller / drive itself presently. (Uh, unless you have a PCI floppy controller or something, but... you probably don't!) + +We can close this bug as WONTFIX, essentially. + diff --git a/results/classifier/118/virtual/943 b/results/classifier/118/virtual/943 new file mode 100644 index 00000000..5c5d22d7 --- /dev/null +++ b/results/classifier/118/virtual/943 @@ -0,0 +1,31 @@ +virtual: 0.996 +architecture: 0.654 +device: 0.645 +mistranslation: 0.581 +VMM: 0.495 +semantic: 0.404 +hypervisor: 0.349 +network: 0.302 +performance: 0.285 +files: 0.279 +risc-v: 0.278 +vnc: 0.267 +boot: 0.223 +KVM: 0.207 +graphic: 0.201 +user-level: 0.197 +PID: 0.192 +arm: 0.191 +ppc: 0.180 +register: 0.164 +i386: 0.133 +debug: 0.130 +x86: 0.121 +permissions: 0.100 +TCG: 0.078 +socket: 0.068 +kernel: 0.039 +peripherals: 0.025 +assembly: 0.024 + +Calling get-fsinfo on a virtual machine does not include ZFS (zfsonlinux, debian guest tested) volumes diff --git a/results/classifier/118/virtual/959852 b/results/classifier/118/virtual/959852 new file mode 100644 index 00000000..5d77a40f --- /dev/null +++ b/results/classifier/118/virtual/959852 @@ -0,0 +1,63 @@ +virtual: 0.880 +kernel: 0.784 +device: 0.741 +mistranslation: 0.729 +debug: 0.725 +graphic: 0.695 +semantic: 0.678 +architecture: 0.639 +files: 0.621 +user-level: 0.619 +peripherals: 0.567 +boot: 0.479 +PID: 0.474 +assembly: 0.449 +ppc: 0.434 +permissions: 0.427 +performance: 0.424 +risc-v: 0.416 +arm: 0.397 +VMM: 0.386 +register: 0.371 +vnc: 0.343 +x86: 0.340 +KVM: 0.329 +TCG: 0.328 +network: 0.265 +hypervisor: 0.264 +i386: 0.235 +socket: 0.230 + +Build fails: osx 10.7, deprecated CoreAudio APIs + +Virtual audio driver for darwin is using deprecated APIs. + +○ → ./configure --cc=/usr/bin/gcc --disable-darwin-user --disable-bsd-user --disable-guest-agent + + +○ → make +. +. +. + CC audio/noaudio.o + CC audio/wavaudio.o + CC audio/mixeng.o + CC audio/coreaudio.o +audio/coreaudio.c: In function ‘isPlaying’: +audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c: In function ‘coreaudio_init_out’: +audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270) +audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) +audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) +audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) +audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419) +audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) +audio/coreaudio.c: In function ‘coreaudio_fini_out’: +audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) + CC audio/wavcapture.o + +This was fixed at the tail end of 2015 and has now been released in QEMU 2.6. + + |