diff options
Diffstat (limited to 'results/classifier/118/review')
646 files changed, 87630 insertions, 0 deletions
diff --git a/results/classifier/118/review/100 b/results/classifier/118/review/100 new file mode 100644 index 000000000..98c804bfe --- /dev/null +++ b/results/classifier/118/review/100 @@ -0,0 +1,61 @@ +mistranslation: 0.966 +device: 0.853 +performance: 0.694 +graphic: 0.663 +semantic: 0.640 +arm: 0.609 +architecture: 0.596 +network: 0.541 +risc-v: 0.472 +debug: 0.429 +ppc: 0.358 +register: 0.278 +i386: 0.255 +vnc: 0.251 +permissions: 0.216 +x86: 0.214 +kernel: 0.200 +virtual: 0.159 +peripherals: 0.157 +VMM: 0.123 +hypervisor: 0.119 +socket: 0.115 +user-level: 0.115 +KVM: 0.110 +boot: 0.083 +PID: 0.081 +TCG: 0.073 +files: 0.069 +assembly: 0.041 +-------------------- +debug: 0.987 +performance: 0.049 +virtual: 0.048 +user-level: 0.026 +kernel: 0.022 +semantic: 0.016 +x86: 0.016 +TCG: 0.015 +files: 0.014 +assembly: 0.011 +PID: 0.010 +hypervisor: 0.009 +device: 0.008 +ppc: 0.008 +boot: 0.007 +arm: 0.006 +risc-v: 0.005 +register: 0.003 +i386: 0.003 +peripherals: 0.002 +VMM: 0.002 +graphic: 0.002 +architecture: 0.002 +socket: 0.001 +network: 0.001 +KVM: 0.001 +permissions: 0.000 +mistranslation: 0.000 +vnc: 0.000 + +GDB context is inconsistent after "monitor system_reset" diff --git a/results/classifier/118/review/1006655 b/results/classifier/118/review/1006655 new file mode 100644 index 000000000..a60ced16b --- /dev/null +++ b/results/classifier/118/review/1006655 @@ -0,0 +1,200 @@ +user-level: 0.817 +graphic: 0.799 +register: 0.791 +virtual: 0.782 +debug: 0.773 +permissions: 0.759 +semantic: 0.752 +TCG: 0.737 +hypervisor: 0.737 +risc-v: 0.737 +PID: 0.733 +VMM: 0.730 +mistranslation: 0.724 +vnc: 0.714 +device: 0.713 +ppc: 0.691 +performance: 0.688 +arm: 0.687 +architecture: 0.684 +peripherals: 0.645 +network: 0.623 +boot: 0.616 +assembly: 0.582 +KVM: 0.579 +files: 0.575 +socket: 0.571 +kernel: 0.513 +x86: 0.446 +i386: 0.270 +-------------------- +hypervisor: 0.705 +KVM: 0.630 +virtual: 0.503 +files: 0.082 +register: 0.022 +user-level: 0.020 +debug: 0.012 +architecture: 0.007 +semantic: 0.007 +device: 0.006 +kernel: 0.006 +network: 0.004 +PID: 0.003 +socket: 0.003 +risc-v: 0.003 +performance: 0.002 +TCG: 0.002 +assembly: 0.001 +ppc: 0.001 +VMM: 0.001 +graphic: 0.001 +x86: 0.001 +boot: 0.001 +permissions: 0.001 +vnc: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +Can't convert to vmdk with the streamOptimized subformat + +Hi all, +I'm trying to convert a qcow2 image file to the vmdk (on Ubuntu Server 12.04): + +# qemu-img convert -f qcow2 -O vmdk -o Stream spv-2912.qcow2 spv-2912-3.vmdk -o subformat=streamOptimized +VMDK: can't write to allocated cluster for streamOptimized +qemu-img: error while writing sector 65: Input/output error + +Same result with any input format. Others subformats work but the StreamOptimized it is by far the most important one. The only workaround I found is to migrate to raw and then to use VBoxManage (VirtualBox). + +Thanks for reporting this bug. While the error looks different, I assume it is related to the same general lack of support as bug 905095 (and https://bugzilla.redhat.com/show_bug.cgi?id=548723) + +Actually, using the same options as you do I do not get a failure. + +Can you show the result of + +qemu-img info spv-2912.qcow2 + +Hi Serge, +the bug was confirmed by Stefan Hajnoczi[1] and still in QEMU 1.1: + +"Unfortunately there has not been a fix. The cause of the bug is known +and described in the email thread you linked. If someone has time to +write a fix and test it, it could be merged. It won't be possible for +QEMU 1.1 since the release is imminent." + +[1] http://<email address hidden>/msg114031.html + +Thanks, Sebastien. + +root@ulisse:/mnt# qemu-img convert -pO vmdk -o subformat=streamOptimized /dev/sdd optimized.vmdk +qemu-img: Could not write to allocated cluster for streamOptimized +qemu-img: error while writing sector 10: Input/output error + +root@ulisse:/mnt# dpkg-query -s qemu-kvm +Package: qemu-kvm +Status: install ok installed +Priority: optional +Section: otherosfs +Installed-Size: 97 +Maintainer: Ubuntu Developers <email address hidden> +Architecture: amd64 +Multi-Arch: foreign +Source: qemu +Version: 2.0.0+dfsg-2ubuntu1.10 +Replaces: qemu-kvm-spice, qemu-system-x86 (<< 1.7.0+dfsg-2~) +Provides: kvm, qemu-kvm-spice +Depends: qemu-system-x86 (>= 1.7.0+dfsg-2~) +Breaks: qemu-system-x86 (<< 1.7.0+dfsg-2~) +Conflicts: kvm, qemu-kvm-spice +Description: QEMU Full virtualization on x86 hardware (transitional package) + QEMU is a fast processor emulator. This package provides just a wrapper + script /usr/bin/kvm which run qemu-system-x86 in kvm mode. + . + Please note that old qemu-kvm configuration files (in /etc/kvm/) are + no longer used. +Homepage: http://www.qemu.org/ +Original-Maintainer: Debian QEMU Team <email address hidden> + +root@ulisse:/mnt# cat /etc/lsb-release +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=14.04 +DISTRIB_CODENAME=trusty +DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS" + + +With the latest codebase there is no error message but the converted streamOptimized image is incorrect. I have a patch for this and will submit it for review soon. + +My patch has landed: https://github.com/qemu/qemu/commit/3efffc3292d94271a15b1606b4a56adf6c6f04ed + +I think we can resolve this bug as fixed. Just one note for those how are trying to use streamOptimized images with VMware: you need to patch the VMDK version because VMware products accept only version 3 for streamOptimized: + +# Set VMDK version 3 for foo.vmdk +$ printf '\x03' | dd conv=notrunc of=foo.vmdk bs=1 seek=$((0x4)) + + + +This bug was fixed in the package qemu - 1:2.3+dfsg-5ubuntu6 + +--------------- +qemu (1:2.3+dfsg-5ubuntu6) wily; urgency=medium + + * Make qemu-system-common and qemu-utils depend on qemu-block-extra + to fix errors with missing block backends. (LP: #1495895) + * Cherry pick fixes for vmdk stream-optimized subformat (LP: #1006655) + * Apply fix for memory corruption during live-migration in tcg mode + (LP: #1493049) + * Apply tracing patch to remove use of custom vtable in newer glibc + (LP: #1491972) + + -- Ryan Harper <email address hidden> Tue, 15 Sep 2015 09:37:23 -0500 + +I'm confused- this is marked as affecting qemu-kvm in precise, but the +preceding patch (c6ac36e) which introduced the bug is not there either. +So I'm going to mark this as not affecting precise unless someone speaks +up to say that we in fact need the whole dependent series. + + +I have tried, many times, to use qemu-img to create StreamOptimized for VMWare ESXi 6.0 OVAs. + +It does NOT work. + +After days of research, I replaced qemu-img, by vboxmanage, then, it worked! + +Now, I'm using something this: + +-- +vboxmanage convertfromraw packer/output-vm.raw packer/output-vm-disk1.vmdk --format vmdk --variant Stream +-- + +I also had to edit the headers, with dd: + +--- +dd if=output-vm-disk1.vmdk of=output-vm-disk1.descriptor bs=1 skip=512 count=1024 +sed -i -e 's/ide/lsilogic/g' output-vm-disk1.descriptor +dd conv=notrunc,nocreat if=output-vm-disk1.descriptor of=output-disk1.vmdk bs=1 seek=512 count=1024 +--- + +This is the only way to build StreamOptimized VMDKs, for inclusion inside of OVA, that works on VMWare 6.0. + +The qemu-img can not be used. + +Here is my full solution to this problem (if the same problem): + +https://github.com/tmartinx/svauto/blob/dev/image-factory.sh#L510 + +I'm just not entirely sure if we're talking about the same problem here... + +Cheers! +Thiago + +It looks like my problem is different, since I'm not seeing this: + +qemu-img: error while writing sector 65: Input/output error + +But maybe, it is a light in the end of the tunnel... + +Patch 3efffc3292d9427 had been released with QEMU 2.5 + diff --git a/results/classifier/118/review/1007 b/results/classifier/118/review/1007 new file mode 100644 index 000000000..6c9d47703 --- /dev/null +++ b/results/classifier/118/review/1007 @@ -0,0 +1,61 @@ +user-level: 0.901 +permissions: 0.769 +device: 0.712 +architecture: 0.558 +network: 0.541 +arm: 0.441 +socket: 0.394 +performance: 0.357 +i386: 0.321 +VMM: 0.319 +x86: 0.318 +semantic: 0.267 +hypervisor: 0.262 +graphic: 0.256 +PID: 0.233 +virtual: 0.205 +ppc: 0.205 +peripherals: 0.198 +assembly: 0.198 +vnc: 0.188 +boot: 0.166 +TCG: 0.160 +files: 0.147 +mistranslation: 0.115 +register: 0.113 +debug: 0.084 +kernel: 0.082 +risc-v: 0.039 +KVM: 0.018 +-------------------- +virtual: 0.966 +hypervisor: 0.928 +x86: 0.755 +user-level: 0.734 +assembly: 0.146 +i386: 0.036 +KVM: 0.020 +debug: 0.018 +semantic: 0.016 +TCG: 0.016 +files: 0.014 +kernel: 0.011 +VMM: 0.007 +ppc: 0.007 +architecture: 0.003 +arm: 0.003 +boot: 0.002 +graphic: 0.002 +register: 0.002 +permissions: 0.002 +PID: 0.001 +device: 0.001 +performance: 0.000 +risc-v: 0.000 +mistranslation: 0.000 +network: 0.000 +vnc: 0.000 +peripherals: 0.000 +socket: 0.000 + +qemu-user: add execveat syscall support diff --git a/results/classifier/118/review/1012023 b/results/classifier/118/review/1012023 new file mode 100644 index 000000000..840294abe --- /dev/null +++ b/results/classifier/118/review/1012023 @@ -0,0 +1,158 @@ +user-level: 0.897 +peripherals: 0.883 +permissions: 0.840 +register: 0.831 +graphic: 0.825 +mistranslation: 0.820 +ppc: 0.812 +hypervisor: 0.806 +risc-v: 0.805 +assembly: 0.792 +vnc: 0.775 +performance: 0.757 +debug: 0.752 +device: 0.739 +PID: 0.733 +files: 0.731 +architecture: 0.727 +semantic: 0.724 +VMM: 0.723 +KVM: 0.716 +arm: 0.714 +boot: 0.704 +kernel: 0.689 +i386: 0.680 +TCG: 0.680 +network: 0.674 +x86: 0.668 +virtual: 0.631 +socket: 0.579 +-------------------- +x86: 0.966 +hypervisor: 0.237 +debug: 0.143 +PID: 0.113 +boot: 0.097 +performance: 0.063 +virtual: 0.060 +files: 0.046 +user-level: 0.041 +device: 0.038 +register: 0.035 +peripherals: 0.034 +kernel: 0.029 +KVM: 0.016 +graphic: 0.015 +TCG: 0.011 +socket: 0.010 +semantic: 0.007 +risc-v: 0.005 +architecture: 0.005 +ppc: 0.004 +VMM: 0.004 +network: 0.004 +assembly: 0.003 +permissions: 0.002 +i386: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +Windows 7 bluescreen STOP: 00000005D + +Hello, with installed windows, or with install cd I have a blue screen (crash) after the first windows logo, see the screenshot. + +Thanks to fix it. + + + +This is a wonderful bugreport. With no information whatsoever. + +Can we close it with "works for me" resolution already? ;) + +Seriously, please provide at least version of qemu and kernel you're using, together with complete qemu command line. + +https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/956374 - the same STOP code, fwiw. + +Last version of QEMU (1.0.1 -> I have try other minor version, 1.0), I have try with multiple kernel (3.4, 3.5), no dmesg info. + +Hardware info: + +Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz + +00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11) +00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 1 (rev 11) +00:05.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 3 (rev 11) +00:08.0 System peripheral: Intel Corporation Core Processor System Management Registers (rev 11) +00:08.1 System peripheral: Intel Corporation Core Processor Semaphore and Scratchpad Registers (rev 11) +00:08.2 System peripheral: Intel Corporation Core Processor System Control and Status Registers (rev 11) +00:08.3 System peripheral: Intel Corporation Core Processor Miscellaneous Registers (rev 11) +00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11) +00:10.1 System peripheral: Intel Corporation Core Processor QPI Routing and Protocol Registers (rev 11) +00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1a.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1a.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1a.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) +00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05) +00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 05) +00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 05) +00:1c.6 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 7 (rev 05) +00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1d.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1d.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1d.3 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05) +00:1d.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) +00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5) +00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 05) +00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05) +00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05) +01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450] +01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio [Radeon HD 5400/6300 Series] +02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9128 PCIe SATA 6 Gb/s RAID controller (rev 11) +04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) +05:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) +06:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03) +06:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03) +3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-Core Registers (rev 04) +3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 04) +3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 04) +3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 04) +3f:03.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller (rev 04) +3f:03.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Target Address Decoder (rev 04) +3f:03.4 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Test Registers (rev 04) +3f:04.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Control Registers (rev 04) +3f:04.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Address Registers (rev 04) +3f:04.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Rank Registers (rev 04) +3f:04.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Thermal Control Registers (rev 04) +3f:05.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Control Registers (rev 04) +3f:05.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Address Registers (rev 04) +3f:05.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Rank Registers (rev 04) +3f:05.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Thermal Control Registers (rev 04) +Bus 004 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter +Bus 009 Device 002: ID 1bcf:0007 Sunplus Innovation Technology Inc. Optical Mouse +Bus 009 Device 003: ID 0a81:0101 Chesen Electronics Corp. Keyboard +Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub +Bus 011 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + + +Can we close this with "works for me" already? + +Can you FINALLY provide the command line? + +Thanks. + +/usr/bin/qemu-system-x86_64 -drive file=hdd.img,if=virtio,cache=unsafe -k fr -alt-grab -m 1024 -vga vmware -net nic,vlan=0,model=virtio -net user + +But bug will ALL cli and options. + +Looks like this is a duplicate of https://bugs.launchpad.net/qemu/+bug/921208 ... so closing this ticket here. + diff --git a/results/classifier/118/review/1013714 b/results/classifier/118/review/1013714 new file mode 100644 index 000000000..55696c312 --- /dev/null +++ b/results/classifier/118/review/1013714 @@ -0,0 +1,113 @@ +semantic: 0.859 +virtual: 0.843 +permissions: 0.835 +peripherals: 0.834 +debug: 0.826 +graphic: 0.817 +architecture: 0.816 +device: 0.801 +vnc: 0.793 +KVM: 0.790 +register: 0.779 +VMM: 0.773 +assembly: 0.765 +hypervisor: 0.764 +performance: 0.762 +PID: 0.759 +kernel: 0.752 +network: 0.748 +boot: 0.741 +user-level: 0.740 +files: 0.723 +arm: 0.711 +ppc: 0.703 +risc-v: 0.678 +mistranslation: 0.658 +TCG: 0.540 +socket: 0.538 +x86: 0.434 +i386: 0.329 +-------------------- +KVM: 0.976 +debug: 0.959 +virtual: 0.958 +hypervisor: 0.759 +kernel: 0.586 +TCG: 0.045 +register: 0.020 +performance: 0.016 +PID: 0.016 +x86: 0.010 +device: 0.008 +VMM: 0.006 +semantic: 0.005 +user-level: 0.005 +socket: 0.005 +network: 0.005 +files: 0.005 +risc-v: 0.004 +i386: 0.004 +vnc: 0.004 +architecture: 0.003 +boot: 0.003 +assembly: 0.003 +peripherals: 0.002 +arm: 0.001 +graphic: 0.001 +ppc: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +Data corruption after block migration (LV->LV) + +We quite frequently use the live block migration feature to move VM's between nodes without downtime. These sometimes result in data corruption on the receiving end. It only happens if the VM is actually doing I/O (doesn't have to be all that much to trigger the issue). + +We use logical volumes and each VM has two disks. We use cache=none for all VM disks. + +All guests use virtio (a mix of various Linux distro's and Windows 2008R2). + +We currently have two stacks in use and have seen the issue on both of them: + +Fedora - qemu-kvm 0.13 +Scientific Linux 6.2 (RHEL derived) - qemu-kvm package 0.12.1.2 + +Even though we don't run the most recent versions of KVM I highly suspect this issue is still unreported and that filing a bug is therefore appropriate. (There doesn't seem to be any similar bug report in launchpad or RedHat's bugzilla and nothing related in change logs, release notes and git commit logs.) + +I have no idea where to look or where to start debugging this issue, but if there is any way I can provide useful debug information please let me know. + +Hi, I suggest that you try a newer version. There were several fixes that I think went only in 0.14, in particular commit 62155e2b51e3c282ddc30adbb6d7b8d3bb7c386e, commit 62155e2b51e3c282ddc30adbb6d7b8d3bb7c386e, commit 62155e2b51e3c282ddc30adbb6d7b8d3bb7c386e. RHEL6.2 doesn't have them. With the fixes, it's quite less likely that live block migration will eat your data. + +However, we were also thinking of deprecating block migration, so we are interesting of hearing about your setup. The replacement would be more powerful (it would allow migrating storage separately from the VM), more efficient (storage and RAM streams would run in parallel on different TCP ports), and easier for us to test and maintain. + +However, it would be more complicated to set the new mechanism up for migration without shared storage. This is what live block migration does, and it sounds like your usecase requires migration without shared storage. Likely, a true replacement of live block migration would not be ready in time for the next release (1.2), hence its removal would also be delayed. + +Hello Paolo, + +Thank you for your quick response! + +Did you intend to mention 3 different commits or did you accidentally paste the same commit thrice? ;) I came across that commit but somehow thought it was already included in 0.13. Thanks! + +We're of course in no position to ask, but I'll do it anyway: Would you be in a position to add patches for these commits to the qemu-kvm package for RHEL6 (assuming they apply at all)? Or perhaps ask one of the RH package maintainers to do so? We'd be very grateful! + +A little bit of background (our use case for using live block migration): We are an ISP and provide virtual private servers on KVM. + +The way we see it traditional centralized shared storage introduces one big, expensive and complicated SPOF into a VM platform. + +We actually have no problems dealing with the limitations of local storage. For example, we have automated (offline) VM migrations to other hosts when customers need to upgrade and the current host doesn't have enough resources. It would be great if live block migration would be stable enough to do this online to reduce downtime for customers. + +We sometimes use live block migration to reduce the server load by migrating off a busy VM. It doesn't really matter if the migration takes a while to complete. We also use it to migrate all VM's off a host in case the hardware is being retired or we need to reinstall. + +Live block migration is just not very useful for generic system maintenance, like a reboot for a kernel or firmware update. In that case we simply reboot the host (and most customers don't mind that once in a while). + +We would appreciate it if live block migration would not be removed until its superior replacement is ready. We don't mind if it's more complex to work with, as long as it's well documented ;) + +Hello Paolo, + +We backported most of the block migration fixes from upstream to the RHEL6 qemu-kvm package ourselves and are now unable to reproduce the disk corruption problem anymore. So I guess the issues are (mostly) fixed upstream. + +You can close this bug, but I would still appreciate it if you could fix this in the RHEL6 package (other RH customers might appreciate that as well ;). We could even provide the patches if you like. + + + +Closing according to comment #3 + diff --git a/results/classifier/118/review/1027525 b/results/classifier/118/review/1027525 new file mode 100644 index 000000000..f3074c47f --- /dev/null +++ b/results/classifier/118/review/1027525 @@ -0,0 +1,111 @@ +mistranslation: 0.882 +x86: 0.857 +files: 0.787 +semantic: 0.781 +PID: 0.732 +vnc: 0.702 +device: 0.699 +graphic: 0.626 +i386: 0.620 +performance: 0.581 +ppc: 0.487 +register: 0.483 +socket: 0.481 +kernel: 0.469 +user-level: 0.445 +risc-v: 0.422 +KVM: 0.407 +VMM: 0.392 +architecture: 0.389 +permissions: 0.388 +network: 0.388 +hypervisor: 0.380 +TCG: 0.346 +debug: 0.321 +boot: 0.312 +arm: 0.306 +virtual: 0.305 +assembly: 0.289 +peripherals: 0.223 +-------------------- +KVM: 0.981 +hypervisor: 0.769 +x86: 0.726 +virtual: 0.705 +debug: 0.466 +kernel: 0.330 +vnc: 0.195 +files: 0.129 +PID: 0.095 +TCG: 0.045 +permissions: 0.026 +socket: 0.023 +register: 0.017 +semantic: 0.009 +network: 0.009 +device: 0.007 +user-level: 0.006 +performance: 0.004 +VMM: 0.004 +boot: 0.003 +risc-v: 0.002 +architecture: 0.002 +i386: 0.002 +ppc: 0.002 +assembly: 0.001 +graphic: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +arm: 0.000 + +Unable to insert cd media located on ro nfs mount + +When issuing a "change" command via the monitor, qemu is unable to open the iso file if it is mounted on a read-only nfs share. If I mount read-write (and make sure the file is writable by the qemu process), then the change command succeeds. Note that this doesn't affect media specified on the command line when starting qemu, only when changing via the monitor. + +To reproduce, mount cd images directory read only, e.g. + +[root@kvmhost0 ~]# grep iso /etc/fstab +10.48.50.20:/iso /srv/kvm/iso nfs4 defaults,ro 0 0 + +Start qemu with minimal options, just need access to the monitor: + +[root@kvmhost0 ~]# kvm -vnc 127.0.0.1:0 -S + +Connect to the monitor and issue a change command: + +(qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso +Could not open '/srv/kvm/iso/ubuntu-12.04-server-amd64.iso + +Re-mount the iso directory read-write and notice that the command succeeds: + +[root@kvmhost0 ~]# mount -o remount,rw /srv/kvm/iso + +(qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso +(qemu) + +[root@kvmhost0 ~]# kvm --version +QEMU emulator version 1.1.1 (qemu-kvm-1.1.1), Copyright (c) 2003-2008 Fabrice Bellard +[root@kvmhost0 ~]# uname -a +Linux kvmhost0 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux + +I ran strace while running the test and I see few times: + +open("/srv/kvm/iso/ubuntu-12.04-server-amd64.iso", O_RDONLY|O_NONBLOCK) = 12 +fstat(12, {st_mode=S_IFREG|0666, st_size=717533184, ...}) = 0 +close(12) + +But the final open looks like this: + +open("/srv/kvm/iso/ubuntu-12.04-server-amd64.iso", O_RDWR|O_DSYNC|O_CLOEXEC) = -1 EROFS (Read-only file system) + +For some reason, the O_RDRW flag was requested. + + +Looks like the read_only flag in the block device state never gets set. This needs to be set otherwise qmp_change_blockdev tries to open the device read only. This patch works for me. + +Of course, I mean "qmp_change_blockdev tries to open the device read-write". + +Can you still reproduce this problem with the latest version of QEMU? If so, could you please refresh your patch and send it to the qemu-devel mailing list? (we do not accept patches from the bug tracker) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1029 b/results/classifier/118/review/1029 new file mode 100644 index 000000000..b4e9facf9 --- /dev/null +++ b/results/classifier/118/review/1029 @@ -0,0 +1,113 @@ +user-level: 0.937 +risc-v: 0.932 +TCG: 0.920 +hypervisor: 0.915 +debug: 0.905 +virtual: 0.900 +ppc: 0.899 +mistranslation: 0.898 +register: 0.897 +peripherals: 0.891 +device: 0.887 +vnc: 0.880 +permissions: 0.872 +semantic: 0.871 +performance: 0.866 +graphic: 0.860 +arm: 0.857 +KVM: 0.856 +architecture: 0.854 +PID: 0.850 +assembly: 0.850 +kernel: 0.843 +socket: 0.841 +VMM: 0.828 +network: 0.818 +files: 0.817 +boot: 0.816 +i386: 0.776 +x86: 0.737 +-------------------- +hypervisor: 0.873 +TCG: 0.365 +files: 0.211 +debug: 0.087 +virtual: 0.066 +user-level: 0.064 +arm: 0.056 +kernel: 0.039 +semantic: 0.027 +register: 0.025 +architecture: 0.019 +PID: 0.016 +device: 0.006 +boot: 0.006 +permissions: 0.005 +performance: 0.004 +network: 0.004 +ppc: 0.004 +assembly: 0.003 +graphic: 0.003 +x86: 0.003 +socket: 0.002 +i386: 0.002 +VMM: 0.002 +risc-v: 0.002 +peripherals: 0.001 +KVM: 0.001 +mistranslation: 0.001 +vnc: 0.001 + +Unable to build qemu on macOS Monterey, M1 Pro +Description of problem: +qemu doesn't build, producing the following error: +``` +$ make +# snip +FAILED: libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o +cc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/opt/homebrew/Cellar/pixman/0.40.0/include/pixman-1 -I/opt/homebrew/Cellar/glib/2.72.1/include -I/opt/homebrew/Cellar/glib/2.72.1/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.72.1/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre/8.45/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /Users/duncanbayne/code/qemu -iquote /Users/duncanbayne/code/qemu/include -iquote /Users/duncanbayne/code/qemu/disas/libvixl -iquote /Users/duncanbayne/code/qemu/tcg/aarch64 -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o -MF libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o.d -o libqemu-aarch64-softmmu.fa.p/target_arm_hvf_hvf.c.o -c ../target/arm/hvf/hvf.c +../target/arm/hvf/hvf.c:586:15: error: unknown type name 'ARMCPRegInfo'; did you mean 'ARMCPUInfo'? + const ARMCPRegInfo *ri; + ^~~~~~~~~~~~ + ARMCPUInfo +../target/arm/cpu-qom.h:38:3: note: 'ARMCPUInfo' declared here +} ARMCPUInfo; + ^ +../target/arm/hvf/hvf.c:589:14: error: implicit declaration of function 'get_arm_cp_reginfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key); + ^ +../target/arm/hvf/hvf.c:589:12: warning: incompatible integer to pointer conversion assigning to 'const ARMCPUInfo *' (aka 'const struct ARMCPUInfo *') from 'int' [-Wint-conversion] + ri = get_arm_cp_reginfo(arm_cpu->cp_regs, key); + ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../target/arm/hvf/hvf.c:591:26: error: no member named 'type' in 'struct ARMCPUInfo' + assert(!(ri->type & ARM_CP_NO_RAW)); + ~~ ^ +/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/assert.h:99:25: note: expanded from macro 'assert' + (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __ASSERT_FILE_NAME, __LINE__, #e) : (void)0) + ^ +../target/arm/hvf/hvf.c:591:33: error: use of undeclared identifier 'ARM_CP_NO_RAW' + assert(!(ri->type & ARM_CP_NO_RAW)); + ^ +1 warning and 4 errors generated. +ninja: build stopped: subcommand failed. +make[1]: *** [run-ninja] Error 1 +make: *** [all] Error 2 +``` +Steps to reproduce: +``` +git clone https://gitlab.com/qemu-project/qemu.git +cd qemu +./configure +make +``` +Additional information: +``` +$ cc --version +Apple clang version 13.1.6 (clang-1316.0.21.2.5) +Target: arm64-apple-darwin21.4.0 +Thread model: posix +InstalledDir: /Library/Developer/CommandLineTools/usr/bin + +$ ninja --version +1.10.2.git.kitware.jobserver-1 +``` diff --git a/results/classifier/118/review/1034 b/results/classifier/118/review/1034 new file mode 100644 index 000000000..1e239595e --- /dev/null +++ b/results/classifier/118/review/1034 @@ -0,0 +1,77 @@ +architecture: 0.884 +semantic: 0.805 +performance: 0.737 +graphic: 0.658 +user-level: 0.601 +ppc: 0.571 +device: 0.564 +arm: 0.497 +permissions: 0.479 +mistranslation: 0.410 +register: 0.408 +PID: 0.357 +network: 0.323 +boot: 0.322 +socket: 0.317 +debug: 0.295 +peripherals: 0.289 +risc-v: 0.289 +vnc: 0.235 +assembly: 0.214 +files: 0.205 +hypervisor: 0.160 +KVM: 0.157 +kernel: 0.153 +TCG: 0.145 +VMM: 0.133 +x86: 0.131 +virtual: 0.099 +i386: 0.092 +-------------------- +virtual: 0.735 +debug: 0.579 +user-level: 0.119 +architecture: 0.041 +hypervisor: 0.038 +semantic: 0.028 +performance: 0.020 +kernel: 0.018 +files: 0.009 +permissions: 0.007 +PID: 0.006 +TCG: 0.005 +network: 0.005 +register: 0.004 +arm: 0.003 +ppc: 0.002 +assembly: 0.002 +device: 0.002 +risc-v: 0.001 +socket: 0.001 +boot: 0.001 +peripherals: 0.001 +vnc: 0.001 +mistranslation: 0.001 +VMM: 0.001 +x86: 0.000 +graphic: 0.000 +i386: 0.000 +KVM: 0.000 + +Erlang/OTP 25 JIT on AArch64 fails in user mode emulation +Description of problem: +Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: + +> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: +> +> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. +> +> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. +> +> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. +> +> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. +> +> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. + +There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/118/review/1035042 b/results/classifier/118/review/1035042 new file mode 100644 index 000000000..6f363c9ce --- /dev/null +++ b/results/classifier/118/review/1035042 @@ -0,0 +1,77 @@ +mistranslation: 0.898 +graphic: 0.683 +semantic: 0.548 +device: 0.488 +ppc: 0.469 +files: 0.430 +socket: 0.394 +network: 0.362 +vnc: 0.227 +performance: 0.208 +arm: 0.197 +i386: 0.184 +boot: 0.167 +user-level: 0.155 +kernel: 0.152 +architecture: 0.149 +hypervisor: 0.145 +risc-v: 0.144 +x86: 0.128 +VMM: 0.101 +peripherals: 0.092 +PID: 0.090 +TCG: 0.087 +permissions: 0.085 +register: 0.085 +virtual: 0.067 +debug: 0.063 +KVM: 0.061 +assembly: 0.025 +-------------------- +files: 0.710 +hypervisor: 0.354 +debug: 0.162 +TCG: 0.088 +register: 0.080 +virtual: 0.022 +user-level: 0.022 +x86: 0.018 +network: 0.017 +VMM: 0.015 +ppc: 0.014 +KVM: 0.013 +kernel: 0.013 +device: 0.011 +i386: 0.010 +risc-v: 0.009 +arm: 0.008 +semantic: 0.007 +PID: 0.005 +socket: 0.005 +assembly: 0.004 +boot: 0.003 +architecture: 0.003 +vnc: 0.002 +graphic: 0.001 +peripherals: 0.001 +performance: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +Inconsistency in x509-dh-key-file parameter + +Hello, + +At source it is x509-dh-file, at config[2] it is x509-dh-key-file, at man[3] it is also x509-dh-key-file. + +I guess that [1] is not correct? + +Thanks! + +[1] http://git.qemu.org/?p=qemu.git;a=blob;f=ui/spice-core.c;h=4fc48f89026944fa91c4be349436041e97fc8654;hb=HEAD#l615 +[2] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-config.c;h=5c3296b8c6f0ec85201579f9a5f4e085adc33314;hb=HEAD#l498 +[3] http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;h=5e7d0dc035978945e692efe3ef063b6a69e73b29;hb=HEAD#l888 + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9995c0b706a2270a49c + diff --git a/results/classifier/118/review/1037606 b/results/classifier/118/review/1037606 new file mode 100644 index 000000000..54889b017 --- /dev/null +++ b/results/classifier/118/review/1037606 @@ -0,0 +1,191 @@ +user-level: 0.909 +permissions: 0.890 +VMM: 0.882 +virtual: 0.881 +architecture: 0.874 +risc-v: 0.863 +debug: 0.858 +device: 0.857 +register: 0.845 +KVM: 0.843 +peripherals: 0.839 +kernel: 0.835 +hypervisor: 0.824 +vnc: 0.820 +assembly: 0.819 +mistranslation: 0.813 +graphic: 0.812 +semantic: 0.805 +arm: 0.801 +PID: 0.793 +ppc: 0.763 +network: 0.756 +performance: 0.755 +boot: 0.754 +TCG: 0.737 +socket: 0.720 +files: 0.684 +x86: 0.673 +i386: 0.565 +-------------------- +kernel: 0.960 +debug: 0.937 +KVM: 0.881 +hypervisor: 0.823 +virtual: 0.578 +x86: 0.131 +TCG: 0.058 +graphic: 0.029 +files: 0.025 +boot: 0.022 +VMM: 0.021 +PID: 0.020 +register: 0.019 +user-level: 0.014 +ppc: 0.014 +semantic: 0.011 +socket: 0.011 +device: 0.010 +i386: 0.009 +network: 0.008 +performance: 0.008 +arm: 0.006 +architecture: 0.005 +permissions: 0.004 +assembly: 0.003 +risc-v: 0.003 +vnc: 0.003 +peripherals: 0.002 +mistranslation: 0.001 + +vmwgfx does not work with kvm vmware vga + +vmwgfx driver fails to initialize inside kvm. + +tried: kvm -m 2048 -vga vmware -cdrom RebeccaBlackLinux.iso (Ubuntu based, any Ubuntu live CD would do) + + + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1037606 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +There is screenshot of the error message. + +The message reads + +*ERROR* Hardware has no pichlock + + +This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run: + +apport-collect 1037606 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +Since the error prevents graphical environment from starting and apport-collect requires a graphical browser to post the data it collects it is not useful to run. + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.6 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages. + +Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. + +If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. + +If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. + +If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. +Once testing of the upstream kernel is complete, please mark this bug as "Confirmed". + + +Thanks in advance. + +[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/ + +This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug. + +If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report. + +[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel + +i am also having this problem on amd64 debian sid, using: + + qemu 1.7.0+dfsg-5 + +on the guest system, i'm also running sid: + + linux-image-amd64 3.13+56 + xserver-xorg-video-vmware 1:13.0.1-3+b1 + +i added vmwgfx to /etc/modules, trying to follow the directions here (aside from using VMware Play, etc.): + + http://www.x.org/wiki/vmware/vmware3D/ + +however, that only gives me the bug sooner than Michael. + +[ 1.590515] [drm] Initialized drm 1.1.0 20060810 +[ 1.598096] [drm] DMA map mode: Using physical TTM page addresses. +[ 1.598131] [drm] Capabilities: +[ 1.598132] [drm] Rect copy. +[ 1.598133] [drm] Cursor. +[ 1.598133] [drm] Cursor bypass. +[ 1.598134] [drm] Cursor bypass 2. +[ 1.598135] [drm] VRAM at 0xfd000000 size is 16384 kiB +[ 1.598136] [drm] MMIO at 0xfe000000 size is 64 kiB +[ 1.598138] [drm] global init. +[ 1.601643] [TTM] Zone kernel: Available graphics memory: 512610 kiB +[ 1.601646] [TTM] Initializing pool allocator +[ 1.601649] [TTM] Initializing DMA pool allocator +[ 1.601657] [drm] No GMR memory available. Graphics memory resources are very limited. +[ 1.601718] [drm:vmw_driver_load] *ERROR* Hardware has no pitchlock +[ 1.601971] [TTM] Finalizing pool allocator +[ 1.601975] [TTM] Finalizing DMA pool allocator +[ 1.602006] [TTM] Zone kernel: Used memory at exit: 0 kiB +[ 1.602724] vmwgfx: probe of 0000:00:02.0 failed with error -38 + + +the bug on the kernel bug tracker is marked as "resolved obsolete", not "confirmed". + +https://bugzilla.kernel.org/show_bug.cgi?id=46711 is marked as WILLNOTFIX, so I'm closing the QEMU bug here, too. + +The kernel bugzilla response is: + +The vmwgfx kernel module does not support devices without the pitchlock capability. Sorry. In that case you need to use the xf86-video-vmware driver standalone without kernel modesetting. + +So presumably this is some capability to be added to the qemu device + +Also http://airlied.livejournal.com/69291.html + +OK, got your point ... but AFAIK the vmware display device in QEMU is pretty much unmaintened anyway, so unless someone steps up and takes care of this device, I think the WONT-FIX status is appropriate for this bug. + diff --git a/results/classifier/118/review/1043 b/results/classifier/118/review/1043 new file mode 100644 index 000000000..3d7b87033 --- /dev/null +++ b/results/classifier/118/review/1043 @@ -0,0 +1,70 @@ +architecture: 0.937 +x86: 0.922 +device: 0.913 +hypervisor: 0.881 +graphic: 0.833 +performance: 0.831 +boot: 0.718 +debug: 0.702 +semantic: 0.669 +register: 0.642 +files: 0.595 +PID: 0.573 +permissions: 0.534 +mistranslation: 0.521 +network: 0.477 +vnc: 0.398 +virtual: 0.352 +VMM: 0.352 +ppc: 0.337 +risc-v: 0.298 +socket: 0.253 +TCG: 0.233 +user-level: 0.212 +arm: 0.205 +kernel: 0.204 +assembly: 0.138 +peripherals: 0.044 +i386: 0.028 +KVM: 0.027 +-------------------- +virtual: 0.974 +x86: 0.762 +hypervisor: 0.739 +debug: 0.420 +boot: 0.236 +user-level: 0.044 +PID: 0.042 +kernel: 0.022 +performance: 0.019 +register: 0.019 +files: 0.018 +TCG: 0.015 +device: 0.013 +semantic: 0.010 +socket: 0.008 +assembly: 0.007 +risc-v: 0.006 +peripherals: 0.005 +architecture: 0.004 +VMM: 0.003 +permissions: 0.002 +network: 0.001 +graphic: 0.001 +ppc: 0.001 +vnc: 0.001 +KVM: 0.000 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx +Description of problem: +- System does not boot. +- WHPX: setting APIC emulation mode in the hypervisor +- Windows Hypervisor Platform accelerator is operational +- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005) +- qemu: WHPX: Unexpected VP exit code 4 +Steps to reproduce: +1. Windows 11 / Ryzen +2. qemu-system-x86_64.exe --accel whpx --cpu max diff --git a/results/classifier/118/review/1047576 b/results/classifier/118/review/1047576 new file mode 100644 index 000000000..b6554ba4c --- /dev/null +++ b/results/classifier/118/review/1047576 @@ -0,0 +1,129 @@ +risc-v: 0.923 +user-level: 0.881 +vnc: 0.880 +TCG: 0.874 +register: 0.869 +ppc: 0.864 +hypervisor: 0.860 +KVM: 0.853 +VMM: 0.853 +graphic: 0.844 +virtual: 0.840 +peripherals: 0.827 +mistranslation: 0.822 +device: 0.820 +semantic: 0.811 +PID: 0.793 +x86: 0.792 +i386: 0.787 +arm: 0.787 +debug: 0.786 +performance: 0.785 +permissions: 0.783 +boot: 0.782 +architecture: 0.774 +kernel: 0.765 +assembly: 0.756 +socket: 0.751 +network: 0.728 +files: 0.676 +-------------------- +virtual: 0.680 +debug: 0.412 +PID: 0.380 +KVM: 0.290 +x86: 0.186 +kernel: 0.128 +hypervisor: 0.105 +performance: 0.066 +socket: 0.062 +register: 0.042 +TCG: 0.040 +ppc: 0.037 +files: 0.036 +i386: 0.035 +semantic: 0.025 +user-level: 0.023 +network: 0.019 +vnc: 0.018 +device: 0.016 +VMM: 0.016 +arm: 0.015 +assembly: 0.012 +permissions: 0.006 +architecture: 0.004 +boot: 0.003 +graphic: 0.003 +peripherals: 0.003 +risc-v: 0.003 +mistranslation: 0.001 + +qemu unittest emulator failure on latest git master + +Running the emulator unittest, using the cmdline: + +16:01:30 INFO | Running emulator +16:01:30 INFO | Running qemu command (reformatted): +16:01:30 INFO | /home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/qemu +16:01:30 INFO | -S +16:01:30 INFO | -name 'unittest_vm' +16:01:30 INFO | -nodefaults +16:01:30 INFO | -chardev socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120907-155940-WomlFZY3,server,nowait +16:01:30 INFO | -mon chardev=hmp_id_humanmonitor1,mode=readline +16:01:30 INFO | -chardev socket,id=serial_id_20120907-155940-WomlFZY3,path=/tmp/serial-20120907-155940-WomlFZY3,server,nowait +16:01:30 INFO | -device isa-serial,chardev=serial_id_20120907-155940-WomlFZY3 +16:01:30 INFO | -chardev socket,id=seabioslog_id_20120907-155940-WomlFZY3,path=/tmp/seabios-20120907-155940-WomlFZY3,server,nowait +16:01:30 INFO | -device isa-debugcon,chardev=seabioslog_id_20120907-155940-WomlFZY3,iobase=0x402 +16:01:30 INFO | -m 512 +16:01:30 INFO | -smp 2,cores=1,threads=1,sockets=2 +16:01:30 INFO | -kernel '/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/unittests/emulator.flat' +16:01:30 INFO | -vnc :0 +16:01:30 INFO | -chardev file,id=testlog,path=/tmp/testlog-20120907-155940-WomlFZY3 +16:01:30 INFO | -device testdev,chardev=testlog +16:01:30 INFO | -rtc base=utc,clock=host,driftfix=none +16:01:30 INFO | -boot order=cdn,once=c,menu=off +16:01:30 INFO | -S +16:01:30 INFO | -enable-kvm + +We get + +16:01:32 INFO | Waiting for unittest emulator to complete, timeout 600, output in /tmp/testlog-20120907-155940-WomlFZY3 +16:01:32 INFO | [qemu output] KVM internal error. Suberror: 1 +16:01:32 INFO | [qemu output] emulation failure +16:01:32 INFO | [qemu output] RAX=ffffffffffffeff8 RBX=ffffffffffffe000 RCX=fffffffffffff000 RDX=000000000044d2b0 +16:01:32 INFO | [qemu output] RSI=000000000044c9fa RDI=000000000044e370 RBP=ffffffffffffeff8 RSP=000000000044d2b0 +16:01:32 INFO | [qemu output] R8 =000000000000000a R9 =00000000000003f8 R10=0000000000000000 R11=0000000000000000 +16:01:32 INFO | [qemu output] R12=ffffffffffffe000 R13=000000001fff6000 R14=000000001fff5000 R15=0000000000000000 +16:01:32 INFO | [qemu output] RIP=0000000000400a89 RFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +16:01:32 INFO | [qemu output] ES =0010 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +16:01:32 INFO | [qemu output] CS =0008 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +16:01:32 INFO | [qemu output] SS =0000 0000000000000000 ffffffff 00000000 +16:01:32 INFO | [qemu output] DS =0010 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +16:01:32 INFO | [qemu output] FS =0010 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +16:01:32 INFO | [qemu output] GS =0010 000000000044c370 ffffffff 00c09300 DPL=0 DS [-WA] +16:01:32 INFO | [qemu output] LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +16:01:32 INFO | [qemu output] TR =0048 000000000040a452 0000ffff 00008b00 DPL=0 TSS64-busy +16:01:32 INFO | [qemu output] GDT= 000000000040a00a 00000447 +16:01:32 INFO | [qemu output] IDT= 0000000000000000 00000fff +16:01:32 INFO | [qemu output] CR0=80010011 CR2=0000000000000000 CR3=000000001ffff000 CR4=00000020 +16:01:32 INFO | [qemu output] DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +16:01:32 INFO | [qemu output] DR6=00000000ffff0ff0 DR7=0000000000000400 +16:01:32 INFO | [qemu output] EFER=0000000000000500 +16:01:32 INFO | [qemu output] Code=88 77 00 49 8d 84 24 f8 0f 00 00 48 89 e2 48 89 e9 48 89 c5 <c9> 48 87 e2 48 87 e9 48 81 f9 99 88 77 00 0f 94 c0 48 39 d5 40 0f 94 c6 40 0f b6 f6 21 c6 + +More logs will be attached to this bug report. + + + +Adding relevant qemu and unittest versions + +software_version_qemu_kvm=git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git:master:4c3e02beed9878a5f760eeceb6cd42c475cf0127 +software_version_kvm_unit_tests=git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git:master:09b657b6d3a80d0424b8b370462a77d284117926 + + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU? + +This doesn't reproduce with the latest version of QEMU, you may close it. + +Thanks for checking again! + diff --git a/results/classifier/118/review/1048 b/results/classifier/118/review/1048 new file mode 100644 index 000000000..713a46692 --- /dev/null +++ b/results/classifier/118/review/1048 @@ -0,0 +1,66 @@ +register: 0.905 +mistranslation: 0.834 +device: 0.825 +graphic: 0.725 +network: 0.527 +files: 0.518 +socket: 0.518 +vnc: 0.502 +architecture: 0.452 +peripherals: 0.427 +arm: 0.420 +performance: 0.376 +TCG: 0.370 +ppc: 0.350 +semantic: 0.338 +boot: 0.301 +PID: 0.288 +risc-v: 0.252 +VMM: 0.239 +i386: 0.232 +debug: 0.187 +x86: 0.164 +permissions: 0.155 +kernel: 0.097 +hypervisor: 0.081 +virtual: 0.065 +user-level: 0.056 +KVM: 0.045 +assembly: 0.040 +-------------------- +register: 0.770 +peripherals: 0.741 +virtual: 0.335 +hypervisor: 0.166 +debug: 0.159 +assembly: 0.138 +files: 0.123 +TCG: 0.062 +device: 0.062 +x86: 0.055 +arm: 0.047 +kernel: 0.025 +performance: 0.020 +i386: 0.012 +semantic: 0.009 +PID: 0.009 +architecture: 0.009 +boot: 0.006 +KVM: 0.004 +socket: 0.004 +ppc: 0.003 +user-level: 0.003 +network: 0.002 +VMM: 0.002 +risc-v: 0.001 +permissions: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +usb/ohci does not reset HccaPad1 after frame number update. +Description of problem: +When the OHCI controller's framenumber is incremented, HccaPad1 register should be set to zero. Ref OHCI Spec 4.4.1. +Relevant code section: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/hcd-ohci.c#L1201 + +ReactOS uses hccaPad1 to determine if the OHCI hardware is running, consequently it fails this check in current qemu master. diff --git a/results/classifier/118/review/1050 b/results/classifier/118/review/1050 new file mode 100644 index 000000000..a442c58e8 --- /dev/null +++ b/results/classifier/118/review/1050 @@ -0,0 +1,132 @@ +user-level: 0.881 +graphic: 0.857 +performance: 0.839 +register: 0.831 +mistranslation: 0.829 +virtual: 0.811 +device: 0.805 +architecture: 0.788 +debug: 0.787 +peripherals: 0.781 +TCG: 0.779 +semantic: 0.770 +permissions: 0.767 +arm: 0.766 +assembly: 0.746 +network: 0.736 +hypervisor: 0.735 +PID: 0.734 +ppc: 0.726 +KVM: 0.707 +files: 0.702 +socket: 0.701 +x86: 0.696 +risc-v: 0.694 +kernel: 0.669 +vnc: 0.669 +boot: 0.651 +VMM: 0.646 +i386: 0.555 +-------------------- +kernel: 0.956 +user-level: 0.847 +debug: 0.671 +hypervisor: 0.613 +virtual: 0.191 +files: 0.092 +TCG: 0.061 +VMM: 0.048 +PID: 0.044 +risc-v: 0.025 +x86: 0.022 +device: 0.021 +KVM: 0.019 +architecture: 0.017 +assembly: 0.017 +register: 0.012 +ppc: 0.011 +semantic: 0.009 +arm: 0.008 +boot: 0.006 +vnc: 0.005 +peripherals: 0.005 +performance: 0.005 +socket: 0.004 +network: 0.002 +graphic: 0.002 +permissions: 0.001 +i386: 0.001 +mistranslation: 0.001 + +[BUG] heap-buffer-overflow in sifive_plic_create +Description of problem: +I run check-qtest-riscv64 in ubuntu20.04, and got a heap-buffer-overflow report with address sanitizer +HEAD: 7077fcb9b68f058809c9dd9fd1dacae1881e886c +Steps to reproduce: +run +`G_TEST_DBUS_DAEMON=/root/o/sources/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=58 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_BINARY=./qemu-system-riscv64 /root/o/sources/qemu/build/tests/qtest/test-hmp --tap -k` +Additional information: +I think is because on some conditions when after `j++(hw/intc/sifive_plic.c:458)`, it accesses `plic->addr_config[j](hw/intc/sifive_plic.c:463)` and results in heap-overflow. +I tried to modify `hw/intc/sifive_plic.c:463` to else-if, then the report gone. +Could you please have a check. +``` +==63425==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000031624 at pc 0x561afe157d54 bp 0x7ffcd8aef510 sp 0x7ffcd8aef500 +READ of size 4 at 0x602000031624 thread T0 + #0 0x561afe157d53 in sifive_plic_create ../hw/intc/sifive_plic.c:463 + #1 0x561afdc0ac7f in sifive_e_soc_realize ../hw/riscv/sifive_e.c:207 + #2 0x561afe6698fb in device_set_realized ../hw/core/qdev.c:531 + #3 0x561afe679b90 in property_set_bool ../qom/object.c:2273 + #4 0x561afe681c7f in object_property_set ../qom/object.c:1408 + #5 0x561afe68b763 in object_property_set_qobject ../qom/qom-qobject.c:28 + #6 0x561afe682535 in object_property_set_bool ../qom/object.c:1477 + #7 0x561afdc0a601 in sifive_e_machine_init ../hw/riscv/sifive_e.c:91 + #8 0x561afd34d608 in machine_run_board_init ../hw/core/machine.c:1427 + #9 0x561afda49697 in qemu_init_board ../softmmu/vl.c:2610 + #10 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2706 + #11 0x561afda49697 in qmp_x_exit_preconfig ../softmmu/vl.c:2699 + #12 0x561afda504ee in qemu_init ../softmmu/vl.c:3737 + #13 0x561afd1cf4ae in qemu_main ../softmmu/main.c:35 + #14 0x561afd1cf4ae in main ../softmmu/main.c:45 + #15 0x7f9d13bf3082 in __libc_start_main ../csu/libc-start.c:308 + #16 0x561afd1de78d in _start (/root/o/sources/qemu/build/qemu-system-riscv64+0x271378d) + +0x602000031624 is located 8 bytes to the right of 12-byte region [0x602000031610,0x60200003161c) +allocated by thread T0 here: + #0 0x7f9d15026808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 + #1 0x7f9d14a84e98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + +SUMMARY: AddressSanitizer: heap-buffer-overflow ../hw/intc/sifive_plic.c:463 in sifive_plic_create +Shadow bytes around the buggy address: + 0x0c047fffe270: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa + 0x0c047fffe280: fa fa 05 fa fa fa 07 fa fa fa fd fa fa fa 02 fa + 0x0c047fffe290: fa fa 00 01 fa fa fd fd fa fa fd fa fa fa fd fd + 0x0c047fffe2a0: fa fa 00 02 fa fa 00 02 fa fa 05 fa fa fa 07 fa + 0x0c047fffe2b0: fa fa 00 01 fa fa 07 fa fa fa 05 fa fa fa 07 fa +=>0x0c047fffe2c0: fa fa 00 04[fa]fa 04 fa fa fa 00 00 fa fa 00 00 + 0x0c047fffe2d0: fa fa 00 00 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe2e0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe2f0: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fd + 0x0c047fffe300: fa fa 00 03 fa fa fd fd fa fa 00 03 fa fa fd fa + 0x0c047fffe310: fa fa fd fd fa fa 00 03 fa fa fd fd fa fa 00 03 +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==63425==ABORTING +``` diff --git a/results/classifier/118/review/1052857 b/results/classifier/118/review/1052857 new file mode 100644 index 000000000..ab2f4dd82 --- /dev/null +++ b/results/classifier/118/review/1052857 @@ -0,0 +1,108 @@ +architecture: 0.874 +TCG: 0.802 +device: 0.801 +peripherals: 0.794 +PID: 0.789 +permissions: 0.780 +socket: 0.765 +ppc: 0.761 +files: 0.753 +performance: 0.752 +debug: 0.742 +graphic: 0.735 +arm: 0.697 +mistranslation: 0.696 +semantic: 0.695 +virtual: 0.695 +network: 0.690 +boot: 0.679 +user-level: 0.663 +vnc: 0.650 +assembly: 0.649 +register: 0.644 +VMM: 0.587 +hypervisor: 0.574 +kernel: 0.537 +x86: 0.511 +risc-v: 0.506 +KVM: 0.432 +i386: 0.403 +-------------------- +ppc: 0.975 +hypervisor: 0.598 +virtual: 0.227 +debug: 0.175 +files: 0.048 +TCG: 0.036 +user-level: 0.026 +PID: 0.018 +architecture: 0.013 +kernel: 0.012 +semantic: 0.009 +register: 0.009 +boot: 0.007 +performance: 0.004 +VMM: 0.004 +socket: 0.004 +device: 0.003 +KVM: 0.003 +assembly: 0.003 +vnc: 0.002 +network: 0.002 +graphic: 0.001 +permissions: 0.001 +peripherals: 0.001 +x86: 0.001 +mistranslation: 0.000 +risc-v: 0.000 +arm: 0.000 +i386: 0.000 + +qemu-user compiled static for ppc fails on 64bit hosts + +On debian I used debootstrap to set up a powerpc chroot. If I then copy in a statically linked qemu-user ppc binary it will work for some commands in the chroot and fail for others. Steps to reproduce: + +host$ mkdir powerpc +host$ sudo debootstrap --arch=powerpc --foreign wheezy powerpc http://ftp.debian.org/debian +host$ sudo cp /usr/bin/qemu-ppc-static powerpc/usr/bin/ +host$ LANG=C sudo chroot powerpc /usr/bin/qemu-ppc-static /bin/bash +I have no name!@guest:/# pwd +/ +I have no name!@guest:/# cd home/ +I have no name!@guest:/home# ls +qemu-ppc-static: /tmp/buildd/qemu-1.1.2+dfsg/linux-user/signal.c:4341: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed. + +I have also built this from the git HEAD sources (hash 6b80f7db8a7f84d21e46d01e30c8497733bb23a0) and I get the same result. + +I ran into this issue also and did a bit of investigating. This is only an issue when ran on a 64bit host. The actual problem line is + +err |= __put_user(h2g(ka->_sa_handler), &sc->handler); + +inside of linux_user/signal.c. What I am unsure of is when the h2g() macro, the cause of the assert, is valid to be used. In this case, under 64bit, GUEST_BASE has a value (32bit it is 0) but ka->_sa_handler has a low value. Assuming that the low value is a direct result of being a guest address and not a host address then the h2g() shouldn't be called. + +I removed the macro from that line which kept the assert from appearing but qemu still died after running 'ls'. I am attempting to fix this bug but I have limited understanding of qemu itself so no promises of me doing a fix, let alone a proper fix. + +On 1 January 2013 06:56, Samuel Seay <email address hidden> wrote: +> I ran into this issue also and did a bit of investigating. This is only +> an issue when ran on a 64bit host. The actual problem line is +> +> err |= __put_user(h2g(ka->_sa_handler), &sc->handler); +> +> inside of linux_user/signal.c. What I am unsure of is when the h2g() +> macro, the cause of the assert, is valid to be used. + +Strongly suspect that (PPC-specific) code is just busted -- no other guest +architecture's signal handling code does an h2g on ka->_sa_handler, +because it's a guest address already. + +cc'ing our PPC maintainer :-) + +-- PMM + + +I just submitted a patch to the dev mailing list. Just in case there is an issue with the submitted patch, or if Erik wants it sooner, I attached the patch I submitted. + +As far as I can see, the fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=beb526b12134a6b674 +... so closing this ticket now. + diff --git a/results/classifier/118/review/1061 b/results/classifier/118/review/1061 new file mode 100644 index 000000000..359dc31f7 --- /dev/null +++ b/results/classifier/118/review/1061 @@ -0,0 +1,306 @@ +user-level: 0.845 +risc-v: 0.844 +virtual: 0.829 +graphic: 0.805 +mistranslation: 0.787 +assembly: 0.782 +architecture: 0.769 +debug: 0.766 +semantic: 0.757 +register: 0.749 +vnc: 0.740 +peripherals: 0.732 +socket: 0.731 +ppc: 0.727 +VMM: 0.726 +hypervisor: 0.719 +PID: 0.718 +TCG: 0.716 +boot: 0.715 +device: 0.711 +performance: 0.686 +permissions: 0.678 +files: 0.643 +network: 0.635 +arm: 0.627 +kernel: 0.617 +KVM: 0.602 +x86: 0.452 +i386: 0.381 +-------------------- +hypervisor: 0.916 +virtual: 0.872 +x86: 0.587 +debug: 0.459 +device: 0.116 +boot: 0.081 +files: 0.076 +TCG: 0.040 +PID: 0.029 +register: 0.022 +semantic: 0.019 +kernel: 0.018 +socket: 0.014 +architecture: 0.009 +performance: 0.008 +risc-v: 0.007 +user-level: 0.006 +assembly: 0.005 +peripherals: 0.005 +graphic: 0.005 +network: 0.005 +permissions: 0.003 +vnc: 0.003 +VMM: 0.002 +i386: 0.002 +ppc: 0.001 +KVM: 0.001 +mistranslation: 0.001 +arm: 0.000 + +xen/pt: Incorrect register mask for PCI passthrough prevents Linux guest from completing boot process +Description of problem: +In brief, the problem is that PCI/GPU passthrough functions normally with Xen/Qemu if the Xen HVM guest is Windows, but if the guest is Linux, the guest will not complete the booting process and it never reaches the systemd targets that allow the GUI environment to start and login to the desktop environment. The problem is that a bug in the way Qemu initializes the PCI status register of the passed through devices causes the PCI capabilities list bit of the PCI status register to be disabled instead of enabled. This in turn disables the MSI-x interrupt handling capability of the passed through PCI devices. I think the reason only Linux guests are affected is that Linux guests use a different method of delivering interrupts from the passed through PCI devices to the guest from the method used by Windows guests, and the method used by Windows does not require the MSI-x capability of the PCI devices but the method used by Linux does need the MSI-x capability of the passed through devices. I will explain this further in the additional information section with logs and other relevant information. +Steps to reproduce: +1. It might only be reproducible on specific hardware. It is very reproducible on my system, an ASRock B85M-Pro4 with BIOS version P2.50 and a Haswell core i5-4590S CPU. +2. Configure the system to pass through the Intel integrated graphics device (IGD), the on-board USB 3 controller, and the onboard PCI audio device to a Windows Xen HVM guest with Qemu running as the device model for the Windows guest in Dom0 using the Xen xl toolstack, and verify that the Windows guest boots and functions properly. This is not trivial and can probably only be done by persons familiar with Xen and its PCI and VGA/GPU passthrough feature. Here is the xl domain configuration file that the Xen xl toolstack used to create and boot the working Windows HVM domain with passthrough of three PCI devices on my hardware: +``` +builder = 'hvm' +bios = 'seabios' +memory = '3072' +vcpus = '4' +device_model_version = 'qemu-xen' +disk = ['/dev/systems/windows,,xvda,w'] +name = 'bullseye' +vif = [ 'model=e1000,script=vif-route,ip=<redacted>' ] +on_poweroff = 'destroy' +on_reboot = 'restart' +on_crash = 'destroy' +boot = 'c' +acpi = '1' +apic = '1' +viridian = '1' +xen_platform_pci = '1' +serial = 'pty' +vga = 'none' +sdl = '0' +vnc = '0' +gfx_passthru = '1' +pci = [ '00:1b.0', '00:14.0,rdm_policy=relaxed', '00:02.0' ] +``` +3. Shut down the working Windows Xen HVM and replace it with a Linux Xen HVM disk image and try to boot that in place of Windows, keeping all other configuration options the same as with the working Windows guest. To create and boot the non-working Linux HVM domain, I used the same xl domain configuration as for Windows with the exception that the disk line was replaced with: +``` +disk = ['/dev/systems/linux,,xvda,w'] +``` +which obviously points to a virtual disk that boots Linux instead of Windows. A Linux guest, such as Debian bullseye or Debian buster or Debian sid will not boot properly and instead exhibit the problem handling IRQs from the passed through PCI devices, as discussed above. +Additional information: +This problem is known by QubesOS and they have been using a patch to fix it since 2017, but they give very few details about the problem in their commit messages: + +https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3/commits/ab2b4c2ad02827a73c52ba561e9a921cc4bb227c + +That same patch to hw/xen/xen_pt_config_init.c also fixes the problem on my system. + +Some logs: + +Without the QubesOS patch, I get error messages indicating problems handling IRQs like this in the Dom0: + +May 10 08:50:03 bullseye kernel: [79077.644346] pciback 0000:00:1b.0: xen_pciback: vpci: assign to virtual slot 0 +May 10 08:50:03 bullseye kernel: [79077.644478] pciback 0000:00:1b.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.644732] pciback 0000:00:14.0: xen_pciback: vpci: assign to virtual slot 1 +May 10 08:50:03 bullseye kernel: [79077.644874] pciback 0000:00:14.0: registering for 16 +May 10 08:50:03 bullseye kernel: [79077.645024] pciback 0000:00:02.0: xen_pciback: vpci: assign to virtual slot 2 +May 10 08:50:03 bullseye kernel: [79077.645107] pciback 0000:00:02.0: registering for 16 +May 10 08:50:30 bullseye kernel: [79105.273876] vif vif-16-0 vif16.0: Guest Rx ready +May 10 08:50:30 bullseye kernel: [79105.273893] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready +May 10 08:50:30 bullseye kernel: [79105.278023] xen-blkback: backend/vbd/16/51712: using 4 queues, protocol 1 (x86_64-abi) persistent grants +May 10 08:50:44 bullseye kernel: [79119.104937] irq 16: nobody cared (try booting with the "irqpoll" option) +May 10 08:50:44 bullseye kernel: [79119.104973] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-6-amd64 #1 Debian 5.10.28-1 +May 10 08:50:44 bullseye kernel: [79119.104976] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B85M Pro4, BIOS P2.50 12/11/2015 +May 10 08:50:44 bullseye kernel: [79119.104979] Call Trace: +May 10 08:50:44 bullseye kernel: [79119.104984] <IRQ> +May 10 08:50:44 bullseye kernel: [79119.104998] dump_stack+0x6b/0x83 +May 10 08:50:44 bullseye kernel: [79119.105008] __report_bad_irq+0x35/0xa7 +May 10 08:50:44 bullseye kernel: [79119.105014] note_interrupt.cold+0xb/0x61 +May 10 08:50:44 bullseye kernel: [79119.105024] handle_irq_event+0xa8/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105030] handle_fasteoi_irq+0x78/0x1c0 +May 10 08:50:44 bullseye kernel: [79119.105037] generic_handle_irq+0x47/0x50 +May 10 08:50:44 bullseye kernel: [79119.105044] __evtchn_fifo_handle_events+0x175/0x190 +May 10 08:50:44 bullseye kernel: [79119.105054] __xen_evtchn_do_upcall+0x66/0xb0 +May 10 08:50:44 bullseye kernel: [79119.105063] __xen_pv_evtchn_do_upcall+0x11/0x20 +May 10 08:50:44 bullseye kernel: [79119.105069] asm_call_irq_on_stack+0x12/0x20 +May 10 08:50:44 bullseye kernel: [79119.105072] </IRQ> +May 10 08:50:44 bullseye kernel: [79119.105079] xen_pv_evtchn_do_upcall+0xa2/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105084] exc_xen_hypervisor_callback+0x8/0x10 +May 10 08:50:44 bullseye kernel: [79119.105091] RIP: e030:xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105097] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc +May 10 08:50:44 bullseye kernel: [79119.105100] RSP: e02b:ffffffff82603de8 EFLAGS: 00000246 +May 10 08:50:44 bullseye kernel: [79119.105106] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff810023aa +May 10 08:50:44 bullseye kernel: [79119.105108] RDX: 0000000009d62df2 RSI: 0000000000000000 RDI: 0000000000000001 +May 10 08:50:44 bullseye kernel: [79119.105111] RBP: ffffffff82613940 R08: 00000066a1715350 R09: 000047f57b235dc9 +May 10 08:50:44 bullseye kernel: [79119.105114] R10: 0000000000007ff0 R11: 0000000000000246 R12: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105117] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +May 10 08:50:44 bullseye kernel: [79119.105124] ? xen_hypercall_sched_op+0xa/0x20 +May 10 08:50:44 bullseye kernel: [79119.105133] ? xen_safe_halt+0xc/0x20 +May 10 08:50:44 bullseye kernel: [79119.105140] ? default_idle+0xa/0x10 +May 10 08:50:44 bullseye kernel: [79119.105145] ? default_idle_call+0x38/0xc0 +May 10 08:50:44 bullseye kernel: [79119.105152] ? do_idle+0x208/0x2b0 +May 10 08:50:44 bullseye kernel: [79119.105158] ? cpu_startup_entry+0x19/0x20 +May 10 08:50:44 bullseye kernel: [79119.105164] ? start_kernel+0x587/0x5a8 +May 10 08:50:44 bullseye kernel: [79119.105170] ? xen_start_kernel+0x625/0x631 +May 10 08:50:44 bullseye kernel: [79119.105180] ? startup_xen+0x3e/0x3e +May 10 08:50:44 bullseye kernel: [79119.105184] handlers: +May 10 08:50:44 bullseye kernel: [79119.105222] [<000000005d228d5f>] usb_hcd_irq [usbcore] +May 10 08:50:44 bullseye kernel: [79119.105245] [<00000000e534b010>] ath_isr [ath9k] +May 10 08:50:44 bullseye kernel: [79119.105257] Disabling IRQ #16 + +Also, without the patch, I get error messages about failure to handle IRQs in the Linux Xen HVM guest: + +Oct 23 18:50:32 domU kernel: irq 36: nobody cared (try booting with the "irqpoll" option) +Oct 23 18:50:32 domU kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-9-amd64 #1 Debian 5.10.70-1 +Oct 23 18:50:32 domU kernel: Hardware name: Xen HVM domU, BIOS 4.14.3 10/22/2021 +Oct 23 18:50:32 domU kernel: Call Trace: +Oct 23 18:50:32 domU kernel: <IRQ> +Oct 23 18:50:32 domU kernel: dump_stack+0x6b/0x83 +Oct 23 18:50:32 domU kernel: __report_bad_irq+0x35/0xa7 +Oct 23 18:50:32 domU kernel: note_interrupt.cold+0xb/0x61 +Oct 23 18:50:32 domU kernel: handle_irq_event+0xa8/0xb0 +Oct 23 18:50:32 domU kernel: handle_fasteoi_irq+0x78/0x1c0 +Oct 23 18:50:32 domU kernel: generic_handle_irq+0x47/0x50 +Oct 23 18:50:32 domU kernel: __evtchn_fifo_handle_events+0x175/0x190 +Oct 23 18:50:32 domU kernel: __xen_evtchn_do_upcall+0x66/0xb0 +Oct 23 18:50:32 domU kernel: __sysvec_xen_hvm_callback+0x22/0x30 +Oct 23 18:50:32 domU kernel: asm_call_irq_on_stack+0x12/0x20 +Oct 23 18:50:32 domU kernel: </IRQ> +Oct 23 18:50:32 domU kernel: sysvec_xen_hvm_callback+0x72/0x80 +Oct 23 18:50:32 domU kernel: asm_sysvec_xen_hvm_callback+0x12/0x20 +Oct 23 18:50:32 domU kernel: RIP: 0010:native_safe_halt+0xe/0x10 +Oct 23 18:50:32 domU kernel: Code: 02 20 48 8b 00 a8 08 75 c4 e9 7b ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d a6 6f 54 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 96 6f 54 00 f4 c3 cc cc 0f 1f 44 00 +Oct 23 18:50:32 domU kernel: RSP: 0018:ffffffff89003e48 EFLAGS: 00000246 +Oct 23 18:50:32 domU kernel: RAX: 0000000000004000 RBX: 0000000000000001 RCX: ffff8dbb7cc2c9c0 +Oct 23 18:50:32 domU kernel: RDX: ffff8dbb7cc00000 RSI: ffff8dbaf55b1400 RDI: ffff8dbaf55b1464 +Oct 23 18:50:32 domU kernel: RBP: ffff8dbaf55b1464 R08: ffffffff891b9120 R09: 0000000000000008 +Oct 23 18:50:32 domU kernel: R10: 000000000000000e R11: 000000000000000d R12: 0000000000000001 +Oct 23 18:50:32 domU kernel: R13: ffffffff891b91a0 R14: 0000000000000001 R15: 0000000000000000 +Oct 23 18:50:32 domU kernel: ? xen_sched_clock+0x11/0x20 +Oct 23 18:50:32 domU kernel: acpi_idle_do_entry+0x46/0x50 +Oct 23 18:50:32 domU kernel: acpi_idle_enter+0x86/0xc0 +Oct 23 18:50:32 domU kernel: cpuidle_enter_state+0x89/0x350 +Oct 23 18:50:32 domU kernel: cpuidle_enter+0x29/0x40 +Oct 23 18:50:32 domU kernel: do_idle+0x1ef/0x2b0 +Oct 23 18:50:32 domU kernel: cpu_startup_entry+0x19/0x20 +Oct 23 18:50:32 domU kernel: start_kernel+0x587/0x5a8 +Oct 23 18:50:32 domU kernel: secondary_startup_64_no_verify+0xb0/0xbb +Oct 23 18:50:32 domU kernel: handlers: +Oct 23 18:50:32 domU kernel: [<000000007d3a0964>] usb_hcd_irq [usbcore] +Oct 23 18:50:32 domU kernel: Disabling IRQ #36 +Oct 23 18:50:32 domU kernel: PM: Image not found (code -22) +Oct 23 18:50:32 domU kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:45:pipe A] flip_done timed out + +To prove the cause of the bug, I compare some logs without the patch +and with the patch that fixes it. + +First, relevant logs generated by Qemu in Dom0, for existing Qemu without the patch. On Debian these logs are located in /var/log/xen in the Dom0: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0280. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0080. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +Next, the same logs, but now using a version of Qemu with the patch that fixes the bug: + +[00:06.0] xen_pt_realize: Assigning real physical device 00:14.0 to devfn 0x30 +[...] +[00:06.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0290, syncing to 0x0290. +[...] +[00:06.0] xen_pt_realize: Real physical device 00:14.0 registered successfully +[00:02.0] xen_pt_realize: Assigning real physical device 00:02.0 to devfn 0x10 +[...] +[00:02.0] xen_pt_config_reg_init: Offset 0x0006 mismatch! Emulated=0x0010, host=0x0090, syncing to 0x0090. +[...] +[00:02.0] xen_pt_realize: Real physical device 00:02.0 registered successfully + +To decipher what is happening here, one must refer to the definitions +in the pci/header.h file from PCI Utilities that in Debian is in the +libpci-dev package and is probably in similarly named packages on other +distros. + +The Offset of 0x0006 corresponds to the 16-bit PCI_STATUS register of +the passed through device, and the Emulated value of 0x0010 sets the desired +emulated value of the PCI_STATUS_CAP_LIST bit to 1 in the PCI_STATUS register. +The host values of 0x0290, 0x0090 correspond to the setting of the register in the +physical device for real device 00:14.0 and 00:02.0, respectively. +The syncing to value indicates the value of the register that Qemu +exposes to the guest. Notice that without the patch, the PCI_STATUS_CAP_LIST +bit is turned off for the two PCI devices (register value = 0x0280 and 0x0080 +for real device 00:14.0 and 00:02.0, respectively), but the bit is turned +on (0x0290 and 0x0090) for these devices with the patch. With the capabilities list enabled, the guest can use the MSI-x capability of the device, but with the capabilities +list disabled, the guest cannot use the MSI-x capability of the devices. +That explains why this patch is needed in Qemu to fix this problem and enable the Linux guest to use the MSI-x capability of the passed through PCI devices. + +This is the QubesOS patch thatfixes it: +``` +--- a/hw/xen/xen_pt_config_init.c ++++ b/hw/xen/xen_pt_config_init.c +@@ -1969,7 +1969,7 @@ + /* Mask out host (including past size). */ + new_val = val & host_mask; + /* Merge emulated ones (excluding the non-emulated ones). */ +- new_val |= data & host_mask; ++ new_val |= data & reg->emu_mask; + /* Leave intact host and emulated values past the size - even though + * we do not care as we write per reg->size granularity, but for the + * logging below lets have the proper value. */ +``` +The QubesOS patch that fixes it in Debian's Qemu 7.0.0 build is also attached as a file.[xen-fix-emu-mask.patch](/uploads/3bef189175549cd9854f8dc3d1affc88/xen-fix-emu-mask.patch) + +~~I will not officially submit it as a patch because I am not its author.~~ + +~~I do not know why QubesOS never officially requested that this fix +be committed to Qemu upstream, but I hope after review by the +maintainers of the code touched by this patch it will be recognized +as a necessary fix to a mistake that causes the desired merge of +the host and emulated values to be incorrect.~~ + +For reference, the commit that is fixed by the QubesOS patch is: + +Fixes: 2e87512eccf3c5e40f3142ff5a763f4f850839f4 (xen/pt: Sync up the dev.config and data values.) + +I think perhaps that commit and the patched file might need some other cleanup so I might try my hand at officially submitting a patch to Qemu that fixes this issue on my hardware without breaking something else, because it is possible that the simple QubesOS patch is not suitable as the correct fix. + +But before I do that, I wish to make one more comment. In my logs, the only other register than the PCI_STATUS register that is affected by the QubesOS patch is the PCI_HEADER_TYPE register. Without the patch, the register's value is always exposed to the guest as 0x80, and with the patch, the value is always exposed as 0x00 (PCI_HEADER_TYPE_NORMAL as defined in pci/header.h). That is because Qemu sets the initial emulated value of PCI_HEADER_TYPE register to 0x80, but Qemu also sets the emu_mask to 0x00, so after correcting the merging of the host and emulated values with the QubesOS patch, the value is synced to 0x00 instead of 0x80. What I don't understand is why the register is initialized with 0x80, but the emu_mask is 0x00. Shouldn't the emu_mask be 0x80, to pass through the initial emulated value of 0x80? ~~Also, I don't know why the initial emulated value of PCI_HEADER_TYPE is set to 0x80 but I will assume that is the correct emulated value that should be exposed to the guest.~~ Update: After doing some research, I discovered the bit that is set in the PCI_HEADER_TYPE register (0x80) because of this issue is the bit to define the device as a multifunction device. None of my devices are multifunction, and the fact that the multifunction bit is incorrectly set on my passed through devices because of this issue seems to have no effect on the operation of the device or the guest. Apparently the author of the code to initialize the PCI_HEADER_TYPE register planned to initialize every passed through device as a multifunction device, but is this needed? My testing indicates it is not needed on my system. + +I am referring to this code in hw/xen/xen_pt_config_init.c: + +``` +static int xen_pt_header_type_reg_init(XenPCIPassthroughState *s, + XenPTRegInfo *reg, uint32_t real_offset, + uint32_t *data) +{ + /* read PCI_HEADER_TYPE */ + *data = reg->init_val | 0x80; + return 0; +} + +[...] + + /* Header Type reg */ + { + .offset = PCI_HEADER_TYPE, + .size = 1, + .init_val = 0x00, + .ro_mask = 0xFF, + .emu_mask = 0x00, + .init = xen_pt_header_type_reg_init, + .u.b.read = xen_pt_byte_reg_read, + .u.b.write = xen_pt_byte_reg_write, + }, +``` +I would appreciate any guidance that experienced Qemu or Xen contributors can give me about this question. ~~If no one gives me any guidance here in a timely manner, I plan to propose my own fix officially to Qemu as the QubesOS patch plus changing the emu_mask value of the PCI_HEADER_TYPE register from 0x00 to 0x80. I verified that fixes the problem I am seeing in the PCI_STATUS register without also causing the change that the QubesOS patch makes to the PCI_HEADER_TYPE register.~~ + +I plan to submit a patch to fix this issue, noting the effect the patch has on the PCI_HEADER_TYPE register in the commit message. diff --git a/results/classifier/118/review/1064 b/results/classifier/118/review/1064 new file mode 100644 index 000000000..30d6e23bf --- /dev/null +++ b/results/classifier/118/review/1064 @@ -0,0 +1,103 @@ +architecture: 0.899 +x86: 0.870 +KVM: 0.866 +files: 0.787 +network: 0.771 +device: 0.759 +kernel: 0.745 +mistranslation: 0.720 +socket: 0.689 +user-level: 0.682 +permissions: 0.668 +arm: 0.658 +graphic: 0.647 +vnc: 0.626 +performance: 0.619 +PID: 0.599 +debug: 0.593 +hypervisor: 0.570 +semantic: 0.567 +VMM: 0.558 +i386: 0.549 +peripherals: 0.540 +risc-v: 0.534 +register: 0.515 +ppc: 0.494 +boot: 0.469 +TCG: 0.468 +assembly: 0.459 +virtual: 0.345 +-------------------- +KVM: 0.174 +kernel: 0.132 +hypervisor: 0.099 +TCG: 0.061 +files: 0.043 +PID: 0.032 +debug: 0.028 +virtual: 0.013 +architecture: 0.007 +semantic: 0.006 +register: 0.006 +device: 0.005 +user-level: 0.004 +network: 0.004 +arm: 0.003 +risc-v: 0.003 +ppc: 0.003 +VMM: 0.003 +performance: 0.003 +graphic: 0.002 +assembly: 0.002 +socket: 0.001 +boot: 0.001 +peripherals: 0.001 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.001 +permissions: 0.001 +i386: 0.000 + +aarch64:qemu6.2.0 compile error +Description of problem: + +Steps to reproduce: +1. download qemu source package +`wget http://mirrors.163.com/centos-vault/centos/8-stream/AppStream/Source/SPackages/qemu-kvm-6.2.0-12.module_el8.7.0%2b1140%2bff0772f9.src.rpm` +2. install qemu source package +`rpm -ivh qemu-*.rpm` +3. build qemu +` rpmbuild --define "_topdir /xxx/src_qemu6.2.0" -bb SPECS/qemu-kvm.spec` +4. error message: +``` +In function 'dump_receive_iov', + inlined from 'filter_dump_receive_iov' at ../net/dump.c:157:5: +../net/dump.c:89:9: error: 'writev' specified size 18446744073709551600 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] + 89 | if (writev(s->fd, dumpiov, cnt + 1) != sizeof(hdr) + caplen) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In file included from /home/xxx/src_qemu6.2.0/BUILD/qemu-kvm-6.2.0/include/qemu/osdep.h:108, + from ../net/dump.c:25: +../net/dump.c: In function 'filter_dump_receive_iov': +/usr/include/sys/uio.h:52:16: note: in a call to function 'writev' declared with attribute 'read_only (2, 3)' + 52 | extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count) + | ^~~~~~ +cc1: all warnings being treated as errors +``` +**gcc version** +``` +# gcc --version +gcc (GCC) 10.3.1 +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` +``` +[root]# meson -v +0.62.1 +[root]# ninja -v +ninja: error: loading 'build.ninja': No such file or directory +[root@vm77 src_qemu6.2.0]# ninja --version +1.8.2 +``` +Additional information: + diff --git a/results/classifier/118/review/1066909 b/results/classifier/118/review/1066909 new file mode 100644 index 000000000..06e1d0db0 --- /dev/null +++ b/results/classifier/118/review/1066909 @@ -0,0 +1,78 @@ +mistranslation: 0.809 +performance: 0.609 +semantic: 0.560 +device: 0.537 +network: 0.499 +vnc: 0.456 +graphic: 0.438 +ppc: 0.421 +files: 0.415 +architecture: 0.395 +socket: 0.376 +TCG: 0.355 +boot: 0.345 +PID: 0.335 +risc-v: 0.323 +kernel: 0.321 +permissions: 0.308 +VMM: 0.297 +register: 0.282 +i386: 0.260 +arm: 0.259 +user-level: 0.246 +virtual: 0.220 +x86: 0.202 +hypervisor: 0.200 +peripherals: 0.181 +assembly: 0.179 +KVM: 0.115 +debug: 0.039 +-------------------- +kernel: 0.577 +debug: 0.322 +arm: 0.288 +virtual: 0.127 +TCG: 0.080 +user-level: 0.056 +ppc: 0.033 +files: 0.025 +x86: 0.025 +register: 0.015 +i386: 0.014 +PID: 0.012 +hypervisor: 0.011 +semantic: 0.008 +performance: 0.005 +assembly: 0.004 +network: 0.003 +architecture: 0.003 +VMM: 0.003 +device: 0.002 +risc-v: 0.001 +graphic: 0.001 +boot: 0.001 +socket: 0.001 +mistranslation: 0.001 +KVM: 0.001 +permissions: 0.001 +peripherals: 0.000 +vnc: 0.000 + +App-level clone emulation for microblaze is broken + +When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. + +I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. + +I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines. + +Here is a minimal test case showing the problem. + + +I accidentally posted the patch, which is here, on the wrong bug report (1068900 instead of here). Apologies. For reference here is the patch; it was committed and fixes this issue: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + +Issue # 1068900, where I mistakenly posted the patch, is unrelated and not fixed; it should be reopened and this issue (1066909) should be marked fixed. + + diff --git a/results/classifier/118/review/1068900 b/results/classifier/118/review/1068900 new file mode 100644 index 000000000..0d09f2e53 --- /dev/null +++ b/results/classifier/118/review/1068900 @@ -0,0 +1,77 @@ +mistranslation: 0.977 +user-level: 0.813 +device: 0.738 +semantic: 0.612 +graphic: 0.588 +network: 0.588 +register: 0.522 +ppc: 0.518 +socket: 0.479 +vnc: 0.478 +architecture: 0.472 +files: 0.465 +performance: 0.442 +risc-v: 0.439 +permissions: 0.417 +kernel: 0.416 +arm: 0.392 +x86: 0.391 +boot: 0.368 +PID: 0.319 +peripherals: 0.316 +debug: 0.296 +TCG: 0.295 +virtual: 0.265 +VMM: 0.261 +hypervisor: 0.214 +KVM: 0.152 +i386: 0.137 +assembly: 0.120 +-------------------- +debug: 0.235 +virtual: 0.207 +TCG: 0.127 +hypervisor: 0.071 +user-level: 0.051 +kernel: 0.033 +files: 0.013 +PID: 0.013 +network: 0.011 +performance: 0.010 +x86: 0.008 +i386: 0.007 +semantic: 0.005 +architecture: 0.004 +arm: 0.004 +device: 0.003 +ppc: 0.003 +register: 0.003 +socket: 0.002 +peripherals: 0.002 +assembly: 0.001 +boot: 0.001 +permissions: 0.001 +risc-v: 0.001 +graphic: 0.001 +KVM: 0.000 +vnc: 0.000 +mistranslation: 0.000 +VMM: 0.000 + +Thread cancellation broken in app-level emulation + +Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash. + +The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host). + +Patch for the issue is available here: + +https://lists.eait.uq.edu.au/pipermail/microblaze-linux/2012-October/005760.html + + +Arg, somehow I added the above comment on the wrong bug. Thus bug is not fixed. The other bug report I recently filed was fixed. + +The URL from comment #1 is unfortunately not valid anymore. If this issue is still pending, could you please post your patch again to the qemu-devel mailing list to get it discussed and included? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1070762 b/results/classifier/118/review/1070762 new file mode 100644 index 000000000..d022c2da3 --- /dev/null +++ b/results/classifier/118/review/1070762 @@ -0,0 +1,106 @@ +user-level: 0.918 +device: 0.903 +mistranslation: 0.850 +semantic: 0.806 +graphic: 0.791 +hypervisor: 0.767 +PID: 0.766 +performance: 0.733 +architecture: 0.643 +files: 0.643 +ppc: 0.639 +virtual: 0.623 +peripherals: 0.616 +x86: 0.608 +permissions: 0.607 +kernel: 0.605 +socket: 0.579 +network: 0.562 +register: 0.548 +debug: 0.546 +vnc: 0.534 +i386: 0.530 +KVM: 0.480 +risc-v: 0.458 +VMM: 0.443 +arm: 0.412 +boot: 0.392 +assembly: 0.302 +TCG: 0.295 +-------------------- +debug: 0.824 +x86: 0.702 +user-level: 0.553 +virtual: 0.197 +hypervisor: 0.085 +device: 0.066 +i386: 0.051 +files: 0.049 +TCG: 0.017 +PID: 0.013 +kernel: 0.012 +network: 0.010 +arm: 0.007 +register: 0.007 +VMM: 0.005 +ppc: 0.004 +socket: 0.004 +semantic: 0.003 +performance: 0.003 +risc-v: 0.002 +architecture: 0.002 +boot: 0.002 +peripherals: 0.001 +vnc: 0.001 +assembly: 0.001 +permissions: 0.001 +graphic: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +savevm fails with inserted CD, "Device '%s' is writable but does not support snapshots." + +Hi, + +yesterday unfortunately a customer reported a failed snapshot of his VM. Going through the logfile I discovered: + +"Device 'ide1-cd0' is writable but does not support snapshots" + +this is with qemu-1.2.0 and 1.0.1 at least... + +Why writeable? +Even if I specify "-drive ...,readonly=on,snapshot=off" to qemu the monitor-command sees the CD-ROM-device as being writeable?! + +Somewhere I saw a "hint" for blockdev.c: +=== snip === + +--- /tmp/blockdev.c 2012-10-24 11:37:10.000000000 +0200 ++++ blockdev.c 2012-10-24 11:37:17.000000000 +0200 +@@ -551,6 +551,7 @@ + case IF_XEN: + case IF_NONE: + dinfo->media_cd = media == MEDIA_CDROM; ++ dinfo->bdrv->read_only = 1; + break; + case IF_SD: + case IF_FLOPPY: + +=== snap === + +after installing with this small patch applied it works, so insert CD, savevm <somename> succeeds. +This should be fixed at all correct places, and the tags "readonly=on,snapshot=off" should do it, too. Or even just work after specifying a drive being a CD-rom should do the trick ;-) + +Another "bad habit" is, that the ISO/DVD-file has to be writeable to be changed? + +Thnx for attention and regards, + +Oliver. + +Very old bug. If anyone sees this behavior, please re-file against a supported release (5.0 at time of writing, soon to be 5.1) and please paste a full command-line and steps to reproduce. + +(To my knowledge, this bug is not present in modern QEMU builds, but do not know when it would have changed.) + +--js + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1077708 b/results/classifier/118/review/1077708 new file mode 100644 index 000000000..fd6a80cca --- /dev/null +++ b/results/classifier/118/review/1077708 @@ -0,0 +1,108 @@ +user-level: 0.845 +mistranslation: 0.785 +risc-v: 0.779 +VMM: 0.771 +network: 0.754 +KVM: 0.734 +register: 0.731 +vnc: 0.724 +hypervisor: 0.721 +ppc: 0.719 +virtual: 0.719 +peripherals: 0.709 +TCG: 0.687 +permissions: 0.682 +arm: 0.675 +graphic: 0.673 +semantic: 0.668 +debug: 0.668 +boot: 0.650 +architecture: 0.647 +device: 0.647 +assembly: 0.644 +socket: 0.630 +performance: 0.630 +PID: 0.627 +files: 0.618 +kernel: 0.595 +x86: 0.566 +i386: 0.565 +-------------------- +virtual: 0.976 +hypervisor: 0.872 +graphic: 0.808 +x86: 0.805 +KVM: 0.794 +socket: 0.413 +debug: 0.305 +peripherals: 0.072 +PID: 0.064 +kernel: 0.038 +device: 0.036 +TCG: 0.032 +performance: 0.022 +files: 0.017 +user-level: 0.012 +register: 0.010 +network: 0.009 +VMM: 0.008 +i386: 0.007 +architecture: 0.005 +semantic: 0.004 +assembly: 0.003 +arm: 0.003 +permissions: 0.002 +vnc: 0.002 +boot: 0.002 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.000 + +Video capture from webcam with USB passthrough freezes + +QEMU version: 1.2.0 +Graphics: Spice +Guest: Windows 7 32-bit +Host: Ubuntu 12.10 amd64 (using distro package qemu-kvm-spice) + +I am using USB 2.0 passthrough of a Logitech C920 webcam. The guest is running the proprietary Logitech drivers. When video chatting with either Google+ Hangouts or Skype 3.8.0.115, video capture from the webcam is initially fine but eventually freezes. It remains frozen for up to several minutes and then resumes on its own. The process then repeats. Audio recorded from the webcam's mic works continuously. + +The problem also affects video recording in Logitech's bundled software. Strangely though, the live preview is _not_ affected. The freezing is only present in the recorded video file. + +I can tell that the problem is not introduced by Spice during playback, because the user on the other end of Hangouts/Skype sees the same problem, and the freezes in a recorded video file are seen at the same point every time the file is played. + +Command line: + +/usr/bin/kvm-spice -name Windows7 -S -M pc-1.0 -enable-kvm -m 2048 -smp 3,sockets=3,cores=1,threads=1 -uuid cfcc7e85-7873-1c32-0a00-d1c35f3eb073 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/data/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:7e:0b:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=2,hostaddr=8,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +The problem also occurs with the generic Microsoft webcam drivers. + +Note that, during webcam use, these messages are output from QEMU sporadically: + +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +USBDEVFS_DISCARDURB: Invalid argument +husb: leaking iso urbs because of discard failure + +However, the timing of the messages is completely uncorrelated with the video freezes, so I am uncertain as to whether they are related or not. + +Does not seem to repro when using the webcam natively in the host with Google+ Hangouts. + +Does not seem to repro when using the webcam natively on a Windows Vista 32-bit machine with Google+ Hangouts. + +I'd be happy to do some debugging. Are there extra log messages that I should enable? + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1078892 b/results/classifier/118/review/1078892 new file mode 100644 index 000000000..9acf3dec8 --- /dev/null +++ b/results/classifier/118/review/1078892 @@ -0,0 +1,71 @@ +architecture: 0.883 +device: 0.781 +virtual: 0.720 +boot: 0.714 +graphic: 0.701 +register: 0.653 +vnc: 0.544 +semantic: 0.510 +ppc: 0.506 +VMM: 0.497 +hypervisor: 0.471 +x86: 0.468 +risc-v: 0.456 +kernel: 0.440 +files: 0.395 +mistranslation: 0.376 +network: 0.376 +i386: 0.364 +socket: 0.350 +performance: 0.290 +TCG: 0.290 +permissions: 0.287 +peripherals: 0.258 +PID: 0.253 +arm: 0.246 +debug: 0.231 +user-level: 0.216 +KVM: 0.114 +assembly: 0.107 +-------------------- +x86: 0.917 +debug: 0.751 +virtual: 0.744 +user-level: 0.615 +i386: 0.571 +architecture: 0.294 +TCG: 0.222 +hypervisor: 0.219 +register: 0.152 +boot: 0.141 +PID: 0.047 +performance: 0.033 +kernel: 0.018 +files: 0.015 +ppc: 0.015 +device: 0.014 +assembly: 0.014 +network: 0.009 +risc-v: 0.009 +semantic: 0.007 +socket: 0.005 +peripherals: 0.002 +VMM: 0.002 +vnc: 0.002 +permissions: 0.001 +arm: 0.001 +graphic: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +qemu doesn't general protection fault if there are reserved bits set in page-directory-pointer table entries + +While working on implementing 32-bit PAE mode in a custom operating system, which I was testing in QEMU, I noticed that my OS worked correctly, but resulted in a general protection fault when booted on VMware, VirtualBox, or bochs. + +According to the Intel Architecture Manual, Volume 3A, Section 4.4.1 "PDPTE Registers", "If any of the PDPTEs sets both the P flag (bit 0) and any reserved bit, the MOV to CR instruction causes a general-protection exception (#GP(0)) and the PDPTEs are not loaded." QEMU does not emulate this behavior. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/108 b/results/classifier/118/review/108 new file mode 100644 index 000000000..c242080c9 --- /dev/null +++ b/results/classifier/118/review/108 @@ -0,0 +1,61 @@ +mistranslation: 0.993 +device: 0.908 +performance: 0.704 +graphic: 0.546 +semantic: 0.545 +peripherals: 0.473 +debug: 0.315 +user-level: 0.277 +boot: 0.250 +VMM: 0.171 +virtual: 0.150 +register: 0.144 +network: 0.144 +arm: 0.134 +risc-v: 0.110 +ppc: 0.099 +permissions: 0.084 +vnc: 0.081 +assembly: 0.064 +hypervisor: 0.062 +TCG: 0.058 +PID: 0.056 +i386: 0.047 +architecture: 0.025 +x86: 0.019 +socket: 0.013 +KVM: 0.005 +kernel: 0.004 +files: 0.003 +-------------------- +peripherals: 0.732 +virtual: 0.730 +device: 0.115 +semantic: 0.079 +VMM: 0.068 +hypervisor: 0.062 +user-level: 0.059 +PID: 0.050 +x86: 0.021 +debug: 0.010 +performance: 0.010 +graphic: 0.006 +register: 0.005 +mistranslation: 0.005 +KVM: 0.004 +i386: 0.003 +boot: 0.003 +files: 0.003 +arm: 0.002 +kernel: 0.002 +ppc: 0.001 +permissions: 0.001 +socket: 0.001 +risc-v: 0.001 +assembly: 0.001 +TCG: 0.000 +vnc: 0.000 +network: 0.000 +architecture: 0.000 + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 diff --git a/results/classifier/118/review/1084 b/results/classifier/118/review/1084 new file mode 100644 index 000000000..35911af77 --- /dev/null +++ b/results/classifier/118/review/1084 @@ -0,0 +1,61 @@ +mistranslation: 0.947 +virtual: 0.909 +device: 0.876 +hypervisor: 0.758 +graphic: 0.613 +semantic: 0.609 +architecture: 0.584 +performance: 0.574 +vnc: 0.521 +network: 0.195 +register: 0.126 +debug: 0.113 +permissions: 0.107 +files: 0.101 +user-level: 0.101 +ppc: 0.098 +risc-v: 0.075 +VMM: 0.065 +boot: 0.061 +arm: 0.039 +i386: 0.033 +x86: 0.033 +peripherals: 0.030 +PID: 0.022 +socket: 0.020 +assembly: 0.011 +TCG: 0.009 +kernel: 0.003 +KVM: 0.002 +-------------------- +virtual: 0.979 +hypervisor: 0.977 +user-level: 0.231 +VMM: 0.187 +KVM: 0.143 +PID: 0.123 +performance: 0.047 +debug: 0.044 +x86: 0.026 +semantic: 0.017 +device: 0.016 +assembly: 0.012 +kernel: 0.012 +files: 0.011 +architecture: 0.006 +socket: 0.005 +i386: 0.004 +TCG: 0.004 +graphic: 0.004 +risc-v: 0.004 +ppc: 0.003 +peripherals: 0.002 +arm: 0.002 +vnc: 0.001 +network: 0.001 +mistranslation: 0.000 +register: 0.000 +permissions: 0.000 +boot: 0.000 + +Qemu - VCPU shutdown request error diff --git a/results/classifier/118/review/1086782 b/results/classifier/118/review/1086782 new file mode 100644 index 000000000..19e3081d8 --- /dev/null +++ b/results/classifier/118/review/1086782 @@ -0,0 +1,160 @@ +user-level: 0.925 +permissions: 0.880 +register: 0.862 +KVM: 0.843 +ppc: 0.842 +performance: 0.838 +network: 0.838 +VMM: 0.831 +vnc: 0.829 +virtual: 0.827 +files: 0.825 +socket: 0.824 +risc-v: 0.823 +kernel: 0.818 +assembly: 0.812 +architecture: 0.804 +device: 0.804 +boot: 0.801 +peripherals: 0.796 +debug: 0.792 +semantic: 0.790 +TCG: 0.789 +graphic: 0.781 +x86: 0.777 +arm: 0.775 +hypervisor: 0.775 +PID: 0.774 +mistranslation: 0.680 +i386: 0.604 +-------------------- +x86: 0.986 +kernel: 0.916 +KVM: 0.915 +performance: 0.823 +virtual: 0.752 +debug: 0.713 +hypervisor: 0.563 +files: 0.033 +device: 0.025 +architecture: 0.023 +semantic: 0.009 +assembly: 0.005 +register: 0.004 +PID: 0.004 +user-level: 0.004 +VMM: 0.003 +boot: 0.002 +socket: 0.002 +graphic: 0.001 +peripherals: 0.001 +TCG: 0.001 +network: 0.001 +vnc: 0.001 +permissions: 0.000 +risc-v: 0.000 +ppc: 0.000 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +HPET time drift windows 7 64bits guest + +Using latest qemu-kvm (1.2.0), time drift (clock slow in guest) in Windows 7 64 bits guest when HPET is enabled (default). +Disabling HPET (-no-hpet) solves the time drift. + +UsePlatformClock enable/disable doesn't make a difference in the guest. +bcdedit /set useplatformclock true + +Using driftfix slew doesn't make a difference too. + + +# qemu-system-x86_64 --version +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +Kernel is 3.6.8: +# uname -a +Linux pulsar 3.6.8 #1 SMP Sat Dec 1 16:26:10 CET 2012 x86_64 x86_64 x86_64 GNU/Linux + +TSC is stable in the host: +=== +# cat /sys/devices/system/clocksource/clocksource0/current_clocksource +tsc + +Dmesg: +[ 0.000000] hpet clockevent registered +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2660.096 MHz processor +[ 0.001002] Calibrating delay loop (skipped), value calculated using timer frequency.. 5320.19 BogoMIPS (lpj=2660096) +[ 0.001138] pid_max: default: 32768 minimum: 301 +... +[ 1.492019] tsc: Refined TSC clocksource calibration: 2659.973 MHz +[ 1.492093] Switching to clocksource tsc + + +CPUinfo, constant_tsc: +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2667.000 +cache size : 2048 KB +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority +bogomips : 5320.19 + +# grep -i hpet .config +CONFIG_HPET_TIMER=y +CONFIG_HPET_EMULATE_RTC=y +CONFIG_HPET=y +# CONFIG_HPET_MMAP is not set +=== + +Qemu command line: +/usr/bin/qemu-system-x86_64 -drive file=/dev/vol0/KVMORION01,cache=none,aio=native,if=virtio \ + -drive file=/dev/vol0/KVMORION02,cache=none,aio=native,if=virtio \ + -cpu host \ + -m 2048 \ + -smp 4,maxcpus=4,cores=4,threads=1,sockets=1 \ + -rtc base=localtime,driftfix=slew \ + -vnc 10.124.241.211:0,password -k es \ + -monitor telnet:localhost:37200,server,nowait \ + -netdev tap,id=kvmorion,ifname=kvmorion,script=/etc/qemu-ifup-br0,downscript=/etc/qemu-ifdown-br0 \ + -device virtio-net-pci,netdev=kvmorion,id=virtio-nic0,mac=02:85:64:02:c2:aa \ + -device virtio-balloon-pci,id=balloon0 \ + -boot menu=on \ + -pidfile /var/run/kvmorion.pid \ + -daemonize + +Using 1 CPU doesn't make a difference. +Only workaround is disabling hpet (-no-hpet) + +Sample time drift in guest: +>ntpdate -q 10.124.241.211 + 5 Dec 13:36:06 ntpdate[3464]: Raised to realtime priority class +server 10.124.241.211, stratum 2, offset 3.694184, delay 0.02551 + 5 Dec 13:36:12 ntpdate[3464]: step time server 10.124.241.211 offset 3.694184 s +ec + +>ntpdate -q 10.124.241.211 + 5 Dec 13:52:02 ntpdate[1964]: Raised to realtime priority class +server 10.124.241.211, stratum 2, offset 4.719968, delay 0.02554 + 5 Dec 13:52:08 ntpdate[1964]: step time server 10.124.241.211 offset 4.719968 s +ec + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Testing now with qemu 2.10.1 +Will need 1 day to see drift or not + +Running from 6 days, here are my results. +There is still some time drift but not critical. +Windows 7 guest is behind around 30 seconds in 6 days. This can be corrected by using NTP. + + + +[Expired for QEMU because there has been no activity for 60 days.] + +I have this problem with Ubuntu 18.04 + diff --git a/results/classifier/118/review/1087 b/results/classifier/118/review/1087 new file mode 100644 index 000000000..652c42d44 --- /dev/null +++ b/results/classifier/118/review/1087 @@ -0,0 +1,61 @@ +architecture: 0.924 +device: 0.772 +ppc: 0.731 +performance: 0.546 +network: 0.503 +hypervisor: 0.470 +arm: 0.396 +permissions: 0.394 +register: 0.384 +graphic: 0.371 +files: 0.363 +peripherals: 0.334 +socket: 0.325 +semantic: 0.324 +mistranslation: 0.322 +debug: 0.287 +kernel: 0.269 +assembly: 0.253 +user-level: 0.222 +PID: 0.198 +risc-v: 0.196 +virtual: 0.188 +vnc: 0.169 +VMM: 0.127 +boot: 0.111 +TCG: 0.106 +i386: 0.014 +KVM: 0.006 +x86: 0.005 +-------------------- +ppc: 0.997 +virtual: 0.930 +hypervisor: 0.888 +architecture: 0.123 +user-level: 0.067 +files: 0.044 +register: 0.019 +device: 0.016 +assembly: 0.012 +kernel: 0.011 +PID: 0.008 +boot: 0.007 +debug: 0.006 +semantic: 0.006 +peripherals: 0.006 +performance: 0.004 +TCG: 0.003 +graphic: 0.002 +risc-v: 0.001 +socket: 0.001 +network: 0.001 +VMM: 0.000 +KVM: 0.000 +mistranslation: 0.000 +x86: 0.000 +arm: 0.000 +permissions: 0.000 +i386: 0.000 +vnc: 0.000 + +QEMU 7.0.0 fails to build on PowerPC diff --git a/results/classifier/118/review/1087411 b/results/classifier/118/review/1087411 new file mode 100644 index 000000000..9febdd9bb --- /dev/null +++ b/results/classifier/118/review/1087411 @@ -0,0 +1,83 @@ +x86: 0.955 +ppc: 0.915 +graphic: 0.907 +peripherals: 0.901 +architecture: 0.899 +device: 0.857 +network: 0.826 +performance: 0.807 +vnc: 0.799 +VMM: 0.790 +socket: 0.785 +PID: 0.780 +debug: 0.721 +semantic: 0.712 +mistranslation: 0.710 +permissions: 0.705 +files: 0.581 +virtual: 0.552 +user-level: 0.544 +register: 0.536 +i386: 0.492 +hypervisor: 0.341 +TCG: 0.315 +assembly: 0.315 +risc-v: 0.312 +boot: 0.286 +kernel: 0.200 +arm: 0.176 +KVM: 0.066 +-------------------- +ppc: 0.672 +debug: 0.303 +PID: 0.274 +virtual: 0.089 +x86: 0.087 +TCG: 0.076 +files: 0.022 +socket: 0.020 +hypervisor: 0.009 +user-level: 0.007 +semantic: 0.006 +register: 0.006 +device: 0.006 +network: 0.004 +vnc: 0.003 +VMM: 0.003 +kernel: 0.002 +performance: 0.002 +boot: 0.002 +graphic: 0.002 +architecture: 0.002 +assembly: 0.002 +risc-v: 0.001 +peripherals: 0.001 +permissions: 0.001 +KVM: 0.001 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +pseries machine breaks in instalation of SLES11_SP2 + +QEMU version: 1.0, 1.1, and 1.2 + +Host OS: +Intel(R) Core(TM) i5-2520M CPU @ 2.50GH + Linux tpad 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +SLES Media: +SLES-11-SP2-DVD-ppc64-GM-DVD1.iso: sha256 -> 2247dd6bb495eb50860668e46f7d6ba004eece9909f347c8ce487fd6a5f65ee1 + +Command line: +./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom +/exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server + +Error message (after starting instalation ~23%): +Installation of package ./suse/ppc64/vim-base-7.2-8.15.2.ppc64.rpm failed. +Subprocess failed. Error: RPM failed: error: %post(vim-base-7.2-8.15.2.ppc64.rpm) + +Triaging 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/review/1103868 b/results/classifier/118/review/1103868 new file mode 100644 index 000000000..0ac718292 --- /dev/null +++ b/results/classifier/118/review/1103868 @@ -0,0 +1,123 @@ +architecture: 0.908 +files: 0.900 +permissions: 0.887 +device: 0.877 +PID: 0.857 +socket: 0.820 +user-level: 0.806 +arm: 0.802 +x86: 0.802 +performance: 0.773 +mistranslation: 0.762 +debug: 0.761 +peripherals: 0.758 +kernel: 0.756 +register: 0.741 +vnc: 0.736 +ppc: 0.723 +semantic: 0.721 +risc-v: 0.717 +network: 0.713 +boot: 0.698 +graphic: 0.684 +virtual: 0.684 +assembly: 0.637 +TCG: 0.633 +hypervisor: 0.622 +VMM: 0.332 +KVM: 0.326 +i386: 0.225 +-------------------- +x86: 0.981 +virtual: 0.824 +hypervisor: 0.803 +vnc: 0.667 +debug: 0.367 +device: 0.050 +register: 0.027 +files: 0.025 +PID: 0.021 +TCG: 0.017 +user-level: 0.010 +kernel: 0.010 +assembly: 0.005 +VMM: 0.005 +ppc: 0.004 +network: 0.004 +boot: 0.004 +KVM: 0.003 +semantic: 0.003 +risc-v: 0.003 +socket: 0.003 +peripherals: 0.003 +performance: 0.002 +i386: 0.002 +graphic: 0.002 +permissions: 0.002 +architecture: 0.002 +arm: 0.001 +mistranslation: 0.001 + +drive_mirror crashes on full disk copy of a resized disk with a backing file + +This bug was discovered using libvirt on ubuntu with a build of qemu 1.3 but it is trivailly reproducible with the curent git version. + +Repro steps: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-img resize /home/vishvananda/disk 64M +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio +QEMU 1.3.0 monitor - type 'help' for more information +(qemu) drive_mirror -f vda test +Formatting 'test', fmt=qcow2 size=67108864 encryption=off cluster_size=65536 lazy_refcounts=off +qemu-system-x86_64: /build/buildd/qemu-1.3.0+dfsg/block/mirror.c:129: mirror_run: Assertion `n > 0' failed. +Aborted + +Note that the command works just fine if the front image is not resized: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio + +or if the backing file is resized as well: + +qemu-img create -f qcow2 base 32M +qemu-img create -f qcow2 -o backing_file=base disk +qemu-img resize /home/vishvananda/disk 64M +qemu-img resize /home/vishvananda/base 64M +qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio + +or if we don't use -f when creating the mirror: + +QEMU 1.3.0 monitor - type 'help' for more information +(qemu) drive_mirror vda test +Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off + +although in this final case the mirror is created the same size as the backing file which seems wrong: + +qemu-img info test +image: test +file format: qcow2 +virtual size: 32M (33554432 bytes) +disk size: 196K +cluster_size: 65536 +backing file: base +backing file format: qcow2 + +separated the final size issue into a separate bug here: + +https://bugs.launchpad.net/qemu/+bug/1103903 + +Haven't found a good workaround for this. Best I've come up with is to use the workaround described in the other bug and then coalesce the files afterwards via qemu-img convert + + + +Reformatted patch and submitted upstream: + +http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg04585.html + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=63ba17d39f1a8d262b31e +... so I think it's OK to close this bug now. + diff --git a/results/classifier/118/review/1105 b/results/classifier/118/review/1105 new file mode 100644 index 000000000..f4dee0b19 --- /dev/null +++ b/results/classifier/118/review/1105 @@ -0,0 +1,63 @@ +architecture: 0.920 +device: 0.886 +arm: 0.845 +debug: 0.772 +performance: 0.757 +network: 0.744 +permissions: 0.728 +graphic: 0.672 +socket: 0.658 +risc-v: 0.656 +register: 0.624 +peripherals: 0.585 +ppc: 0.578 +boot: 0.569 +files: 0.562 +semantic: 0.530 +kernel: 0.468 +vnc: 0.461 +mistranslation: 0.432 +TCG: 0.401 +VMM: 0.378 +PID: 0.324 +assembly: 0.231 +hypervisor: 0.221 +KVM: 0.178 +user-level: 0.099 +virtual: 0.096 +x86: 0.027 +i386: 0.013 +-------------------- +debug: 0.714 +virtual: 0.251 +files: 0.202 +user-level: 0.115 +architecture: 0.105 +arm: 0.035 +TCG: 0.013 +semantic: 0.011 +hypervisor: 0.011 +register: 0.010 +kernel: 0.004 +device: 0.003 +boot: 0.002 +risc-v: 0.001 +graphic: 0.001 +peripherals: 0.001 +network: 0.001 +assembly: 0.001 +socket: 0.001 +performance: 0.001 +ppc: 0.001 +VMM: 0.000 +PID: 0.000 +x86: 0.000 +permissions: 0.000 +vnc: 0.000 +mistranslation: 0.000 +i386: 0.000 +KVM: 0.000 + +QEMU gdbstub should support PAC for aarch64 +Additional information: +The fix should probably be in gdbstub.c diff --git a/results/classifier/118/review/1110 b/results/classifier/118/review/1110 new file mode 100644 index 000000000..da064d14a --- /dev/null +++ b/results/classifier/118/review/1110 @@ -0,0 +1,63 @@ +architecture: 0.865 +kernel: 0.778 +device: 0.766 +graphic: 0.681 +mistranslation: 0.551 +network: 0.543 +virtual: 0.505 +performance: 0.499 +register: 0.421 +TCG: 0.405 +VMM: 0.385 +boot: 0.352 +semantic: 0.342 +ppc: 0.333 +hypervisor: 0.309 +PID: 0.274 +peripherals: 0.258 +files: 0.222 +vnc: 0.190 +permissions: 0.187 +user-level: 0.181 +socket: 0.169 +arm: 0.143 +debug: 0.114 +risc-v: 0.113 +i386: 0.102 +x86: 0.092 +KVM: 0.061 +assembly: 0.038 +-------------------- +virtual: 0.912 +hypervisor: 0.849 +kernel: 0.677 +TCG: 0.063 +register: 0.061 +VMM: 0.055 +files: 0.028 +KVM: 0.027 +user-level: 0.013 +semantic: 0.013 +x86: 0.011 +architecture: 0.010 +device: 0.009 +arm: 0.008 +assembly: 0.007 +PID: 0.006 +graphic: 0.005 +socket: 0.005 +debug: 0.005 +boot: 0.004 +vnc: 0.003 +network: 0.003 +permissions: 0.002 +risc-v: 0.002 +peripherals: 0.001 +performance: 0.001 +i386: 0.001 +ppc: 0.000 +mistranslation: 0.000 + +Add vhost-user-gpu support for cross architecture emulation +Additional information: +host:Android 12 with Linux kernel 4.14.186+ diff --git a/results/classifier/118/review/1116 b/results/classifier/118/review/1116 new file mode 100644 index 000000000..8f5972e9f --- /dev/null +++ b/results/classifier/118/review/1116 @@ -0,0 +1,78 @@ +x86: 0.957 +device: 0.916 +user-level: 0.895 +PID: 0.862 +graphic: 0.851 +kernel: 0.829 +network: 0.800 +semantic: 0.784 +VMM: 0.784 +files: 0.784 +TCG: 0.728 +KVM: 0.712 +ppc: 0.694 +i386: 0.690 +vnc: 0.683 +performance: 0.647 +architecture: 0.621 +mistranslation: 0.596 +permissions: 0.576 +socket: 0.573 +risc-v: 0.572 +hypervisor: 0.569 +boot: 0.563 +debug: 0.531 +peripherals: 0.521 +register: 0.499 +arm: 0.447 +assembly: 0.427 +virtual: 0.229 +-------------------- +files: 0.907 +x86: 0.837 +hypervisor: 0.785 +debug: 0.771 +TCG: 0.724 +register: 0.638 +vnc: 0.486 +boot: 0.480 +PID: 0.474 +socket: 0.447 +device: 0.376 +risc-v: 0.367 +semantic: 0.269 +virtual: 0.241 +VMM: 0.204 +KVM: 0.096 +assembly: 0.090 +kernel: 0.067 +graphic: 0.054 +ppc: 0.023 +permissions: 0.022 +i386: 0.022 +network: 0.022 +peripherals: 0.010 +architecture: 0.007 +performance: 0.007 +user-level: 0.006 +mistranslation: 0.003 +arm: 0.001 + +qemu/build/qemu-bundle/var/local/run is linked to qemu/qga/run which doesn't exist after building qemu +Description of problem: +A file qemu/build/qemu-bundle/var/local/run is generated after building qemu and this file is linked to qemu/qga/run which doesn't exist. + +[root@b49691d8db1c local]# ls /home/lxy/qemu/build/qemu-bundle/var/local -hl +total 0 +lrwxrwxrwx. 1 root root 22 Jul 22 00:06 run -> /home/lxy/qemu/qga/run +[root@b49691d8db1c local]# ls -hl /home/lxy/qemu/qga/run +ls: cannot access '/home/lxy/qemu/qga/run': No such file or directory +Steps to reproduce: +1. git clone https://gitlab.com/qemu-project/qemu.git +2. cd qemu/ +3. ./configure --target-list=x86_64-softmmu --enable-kvm +4. make -j100 && make install +5. ls ./build/qemu-bundle/var/local -hl +6. ls -hl ./qga/run +Additional information: + diff --git a/results/classifier/118/review/1119 b/results/classifier/118/review/1119 new file mode 100644 index 000000000..76e02842a --- /dev/null +++ b/results/classifier/118/review/1119 @@ -0,0 +1,75 @@ +mistranslation: 0.998 +device: 0.916 +graphic: 0.892 +network: 0.839 +kernel: 0.838 +socket: 0.814 +vnc: 0.809 +semantic: 0.794 +PID: 0.790 +performance: 0.782 +ppc: 0.781 +register: 0.777 +arm: 0.750 +files: 0.741 +user-level: 0.736 +VMM: 0.726 +risc-v: 0.716 +TCG: 0.707 +KVM: 0.705 +debug: 0.692 +boot: 0.585 +x86: 0.548 +architecture: 0.486 +assembly: 0.482 +virtual: 0.482 +i386: 0.387 +peripherals: 0.336 +permissions: 0.280 +hypervisor: 0.133 +-------------------- +kernel: 0.759 +files: 0.544 +hypervisor: 0.265 +debug: 0.236 +user-level: 0.232 +x86: 0.084 +virtual: 0.078 +semantic: 0.076 +KVM: 0.053 +TCG: 0.050 +performance: 0.045 +register: 0.030 +architecture: 0.020 +i386: 0.017 +ppc: 0.014 +device: 0.013 +assembly: 0.011 +VMM: 0.010 +boot: 0.009 +peripherals: 0.009 +socket: 0.006 +network: 0.006 +arm: 0.006 +PID: 0.004 +vnc: 0.002 +permissions: 0.002 +risc-v: 0.002 +graphic: 0.001 +mistranslation: 0.001 + +end_code set incorrectly +Description of problem: +https://github.com/qemu/qemu/blob/c99e34e537f13a431a80e3e414e5904e9dd0a116/linux-user/flatload.c#L811 + +This line says: + +``` +info->end_code = libinfo[0].start_code = libinfo[0].text_len; +``` + +but should be + +``` +info->end_code = libinfo[0].start_code + libinfo[0].text_len; +``` diff --git a/results/classifier/118/review/1122492 b/results/classifier/118/review/1122492 new file mode 100644 index 000000000..80d6f2523 --- /dev/null +++ b/results/classifier/118/review/1122492 @@ -0,0 +1,111 @@ +ppc: 0.891 +x86: 0.887 +graphic: 0.866 +semantic: 0.841 +architecture: 0.829 +boot: 0.815 +performance: 0.773 +device: 0.745 +files: 0.739 +socket: 0.726 +user-level: 0.711 +VMM: 0.708 +peripherals: 0.698 +permissions: 0.664 +mistranslation: 0.656 +PID: 0.654 +kernel: 0.634 +hypervisor: 0.601 +debug: 0.576 +vnc: 0.576 +network: 0.546 +i386: 0.507 +register: 0.476 +risc-v: 0.473 +TCG: 0.471 +assembly: 0.462 +KVM: 0.365 +arm: 0.343 +virtual: 0.288 +-------------------- +x86: 0.975 +virtual: 0.605 +user-level: 0.226 +boot: 0.071 +hypervisor: 0.034 +files: 0.028 +debug: 0.027 +kernel: 0.010 +PID: 0.009 +register: 0.005 +TCG: 0.005 +device: 0.004 +socket: 0.004 +network: 0.004 +semantic: 0.003 +i386: 0.002 +VMM: 0.002 +graphic: 0.001 +performance: 0.001 +ppc: 0.001 +permissions: 0.001 +architecture: 0.001 +peripherals: 0.001 +KVM: 0.001 +assembly: 0.001 +vnc: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +arm: 0.000 + +qemu and grub2 rescue floppy don't get along + +With qemu.git as of Feb 11 2013: + +# grub2-mkrescue -o test.img +# ./x86_64-softmmu/qemu-system-x86_64 -fda test.img -curses + +SeaBIOS (version ?-20130206_051134-ccnode4) + +iPXE v1.0.0-591-g7aee315 +iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+07FC7EC0+07F87EC0 C900 + + +Booting from Hard Disk... +Boot failed: could not read the boot disk + +Booting from Floppy... +GRUB loading.... +Welcome to GRUB! + +error: attempt to read or write outside of disk `fd0'. +Entering rescue mode... +grub rescue> + + +Expected results: grub header and a normal usable grub prompt like 'grub>' + + +This was originally reported against qemu 0.15 in Fedora 16 at: + +https://bugzilla.redhat.com/show_bug.cgi?id=784537 + +Some more info from that bug: + +0) The images that grub2-mkrescue creates are odd mixtures of ISO images and disk images: + file -r -k test.img + test.img: # ISO 9660 CD-ROM filesystem data 'ISOIMAGE ' (bootable) + - x86 boot sector; partition 1: ID=0xcd, active, starthead 0, startsector 1, 4455 sectors, code offset 0x63 DOS executable (COM), boot code + +1) The test image I use has a 2281472 byte size. If I append that with zeroes to 2880 KB (2949120 bytes) then I get the expected results. So there's a workaround. But I don't think it's an obvious workaround. + +2) It's debatable whether this is a bug. If it's considered a bug, I'm not sure whether qemu and/or grub2 is to blame. Should qemu (silently) handle (floppy) disk image between 1440 KB and 2880 KB as if they actually were 2880 KB in size? Or should grub2, if possible, zero pad the images it creates to (in this case) a 2880 KB size? + +3) Please note that there seems to be little one can do to leave "grub rescue" mode. Ie, "insmod normal" will fail too: + grub rescue> insmod normal + error: attempt to read or write outside of disk `fd0'. + +Triaging 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/review/1125 b/results/classifier/118/review/1125 new file mode 100644 index 000000000..61b6a778a --- /dev/null +++ b/results/classifier/118/review/1125 @@ -0,0 +1,63 @@ +architecture: 0.970 +device: 0.849 +performance: 0.734 +mistranslation: 0.538 +network: 0.522 +arm: 0.515 +graphic: 0.466 +debug: 0.463 +register: 0.436 +assembly: 0.413 +semantic: 0.343 +files: 0.337 +hypervisor: 0.311 +peripherals: 0.305 +permissions: 0.301 +boot: 0.279 +PID: 0.278 +socket: 0.184 +vnc: 0.178 +ppc: 0.164 +kernel: 0.159 +VMM: 0.138 +virtual: 0.131 +user-level: 0.124 +TCG: 0.102 +KVM: 0.012 +risc-v: 0.012 +x86: 0.009 +i386: 0.003 +-------------------- +hypervisor: 0.975 +virtual: 0.959 +architecture: 0.192 +KVM: 0.117 +debug: 0.064 +PID: 0.047 +user-level: 0.042 +semantic: 0.040 +assembly: 0.028 +boot: 0.019 +TCG: 0.016 +arm: 0.014 +kernel: 0.013 +VMM: 0.013 +register: 0.010 +files: 0.010 +device: 0.006 +performance: 0.006 +socket: 0.004 +graphic: 0.002 +risc-v: 0.001 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.001 +network: 0.001 +ppc: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 + +error on run qemu-system-aarch64 -smp 2 +Additional information: + diff --git a/results/classifier/118/review/1126 b/results/classifier/118/review/1126 new file mode 100644 index 000000000..584410293 --- /dev/null +++ b/results/classifier/118/review/1126 @@ -0,0 +1,68 @@ +architecture: 0.918 +graphic: 0.885 +kernel: 0.787 +semantic: 0.629 +device: 0.620 +files: 0.591 +performance: 0.570 +mistranslation: 0.509 +TCG: 0.430 +PID: 0.389 +permissions: 0.348 +user-level: 0.284 +vnc: 0.266 +debug: 0.251 +network: 0.242 +register: 0.225 +ppc: 0.219 +socket: 0.170 +VMM: 0.156 +boot: 0.153 +virtual: 0.122 +risc-v: 0.045 +peripherals: 0.033 +assembly: 0.028 +arm: 0.018 +hypervisor: 0.014 +i386: 0.011 +x86: 0.005 +KVM: 0.004 +-------------------- +virtual: 0.973 +hypervisor: 0.638 +user-level: 0.410 +TCG: 0.153 +kernel: 0.123 +files: 0.075 +register: 0.061 +arm: 0.048 +PID: 0.040 +performance: 0.027 +debug: 0.026 +architecture: 0.025 +x86: 0.013 +device: 0.012 +semantic: 0.011 +i386: 0.007 +socket: 0.005 +network: 0.005 +boot: 0.004 +graphic: 0.003 +peripherals: 0.003 +risc-v: 0.003 +assembly: 0.003 +VMM: 0.001 +permissions: 0.001 +vnc: 0.001 +ppc: 0.001 +KVM: 0.001 +mistranslation: 0.000 + +qemu-system-mipsel freezes for nanoMIPS in the semihosting mode +Description of problem: +In the current git master branch (SHA: 7b17a1a8) there is a problem with qemu-system-mipsel when trying to execute a simple hello.elf program in the semihosting mode for the nanoMIPS architecture. I.e. after executing the following command the terminal freezes: + ``` + $ ./qemu-system-mipsel -cpu I7200 -semihosting -nographic -kernel hello.elf + ``` +hello.elf file is generated using the nanoMIPS GNU Toolchain (https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases). +The program regularly terminates with QEMU emulator version 6.0.1. diff --git a/results/classifier/118/review/1127 b/results/classifier/118/review/1127 new file mode 100644 index 000000000..410394a16 --- /dev/null +++ b/results/classifier/118/review/1127 @@ -0,0 +1,189 @@ +mistranslation: 0.922 +peripherals: 0.903 +graphic: 0.897 +TCG: 0.848 +hypervisor: 0.820 +risc-v: 0.819 +VMM: 0.819 +arm: 0.814 +permissions: 0.813 +user-level: 0.810 +device: 0.805 +ppc: 0.799 +semantic: 0.791 +vnc: 0.784 +register: 0.783 +debug: 0.759 +boot: 0.726 +network: 0.720 +PID: 0.693 +KVM: 0.686 +socket: 0.648 +virtual: 0.627 +architecture: 0.598 +assembly: 0.584 +performance: 0.583 +x86: 0.576 +files: 0.542 +kernel: 0.446 +i386: 0.284 +-------------------- +boot: 0.739 +debug: 0.637 +kernel: 0.421 +assembly: 0.208 +user-level: 0.147 +register: 0.054 +virtual: 0.043 +PID: 0.024 +TCG: 0.019 +device: 0.018 +files: 0.018 +x86: 0.011 +semantic: 0.006 +VMM: 0.006 +i386: 0.004 +hypervisor: 0.003 +performance: 0.003 +architecture: 0.002 +peripherals: 0.002 +network: 0.002 +ppc: 0.002 +risc-v: 0.002 +socket: 0.002 +KVM: 0.001 +graphic: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.001 +arm: 0.001 + +Various problems with running SunOS 4.1.4 +Description of problem: +Yes, I know, SunOS 4.1.4 is ancient, but I happened to find an original Solaris 1.1.2/SunOS 4.1.4 installation CD, and nostalgia got the better of me. + +It used to be possible to run SunOS 4.1.4 in QEMU 5.0.0, but starting with 6.0.0, whenever you try to boot, you see the following whenever SunOS tries to access a SCSI disk: + +``` +ok boot disk +Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: +root on /iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@3,0:a fstype 4.2 +Boot: vmunix +Size: 1548288+463688+225704 bytes +SuperSPARC: PAC ENABLED +SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994 +Copyright (c) 1983-1993, Sun Microsystems, Inc. +cpu = SUNW,SPARCstation-20 +mod0 = TI,TMS390Z50 (mid = 8) +mem = 523836K (0x1ff8f000) +avail mem = 510947328 +cpu0 at Mbus 0x8 0x240000 +entering uniprocessor mode +Ethernet address = 52:54:0:12:34:56 +espdma0 at SBus slot f 0x400000 +esp0 at SBus slot f 0x800000 pri 4 (onboard) +esp0: data transfer overrun + State=DATA Last State=DATA_DONE + Latched stat=0x11<XZERO,IO> intr=0x10<BUS> fifo 0x0 + last msg out: EXTENDED; last msg in: COMMAND COMPLETE + DMA csr=0xa4240030<FLSH,INTEN> + addr=fff00034 last=fff00010 last_count=24 + Cmd dump for Target 3 Lun 0: + cdb=[ 0x12 0x0 0x0 0x0 0x24 0x0 ] + pkt_state 0xf<XFER,CMD,SEL,ARB> pkt_flags 0x9 pkt_statistics 0x0 + cmd_flags=0x5 cmd_timeout 0 + Mapped Dma Space: + Base = 0x10 Count = 0x24 + Transfer History: + Base = 0x10 Count = 0x24 + current phase 0x26=DATAIN stat=0x11 0x24 + current phase 0x1=CMD_START stat=0x12 0x12 + current phase 0x60=SELECT_SNDMSG stat=0x7 0x3 0x0 + current phase 0x23=SYNCHOUT stat=0x7 0x19 0xf + current phase 0xb=CMD_CMPLT stat=0x7 0x0 + current phase 0x27=STATUS stat=0x7 0x0 + current phase 0xb=CMD_CMPLT stat=0x13 + current phase 0x80=SEL_NO_ATN stat=0x0 0x3 0x0 + current phase 0x1=CMD_START stat=0x0 0x0 0x80 + current phase 0x1c=RESET stat=0x0 0x1f +``` + +This causes SunOS to ignore the disk, and later it tries to boot via ethernet instead. + +After some digging, I *think* I tracked down the problem. + +This commit seems to be what did it: + +commit 799d90d818ba38997e9f5de2163bbfc96256ac0b +Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> +Date: Thu Mar 4 22:10:58 2021 +0000 + + esp: transition to message out phase after SATN and stop command + + The SCSI bus should remain in the message out phase after the SATN and stop + command rather than transitioning to the command phase. A new ESPState variable + cmdbuf_cdb_offset is added which stores the offset of the CDB from the start + of cmdbuf when accumulating extended message out phase data. + + Currently any extended message out data is discarded in do_cmd() before the CDB + is processed in do_busid_cmd(). + + Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> + Reviewed-by: Laurent Vivier <laurent@vivier.eu> + Message-Id: <20210304221103.6369-38-mark.cave-ayland@ilande.co.uk> + +I determined this by rummaging through the changes to the esp.c driver between 5.0.0 and 6.0.0 until I stumbled across this one. I can make the problem go away with this simple change: + +``` +--- esp.c.orig 2022-04-19 12:10:27.000000000 -0700 ++++ esp.c 2022-07-25 19:57:06.602665000 -0700 +@@ -433,7 +433,7 @@ + trace_esp_handle_satn_stop(fifo8_num_used(&s->cmdfifo)); + s->do_cmd = 1; + s->cmdfifo_cdb_offset = 1; +- s->rregs[ESP_RSTAT] = STAT_MO; ++ s->rregs[ESP_RSTAT] = STAT_TC | STAT_CD /*STAT_MO*/; + s->rregs[ESP_RINTR] |= INTR_BS | INTR_FC; + s->rregs[ESP_RSEQ] = SEQ_MO; + esp_raise_irq(s); +``` + +NOTE: I am not sure if this is a proper fix, as I don't know enough about SCSI or the esp controller. All I know is putting this back the way it was makes SunOS happy again. Unfortunately it may also break something else, so somebody more knowledgeable than I should investigate further. + +If you're worried that reproducing this will be difficult, don't be. I prepared detailed instructions, scripts and all the images you should need to create a virtual SunOS disk and install the OS on it. This includes the OpenProm images and installation ISO. + +You can find everything here (consult readme.txt for details): + +http://people.freebsd.org/~wpaul/sunos-qemu + +The quick install option is very simple. Once you finish writing the OS to the disk and try to boot off it the first time, you should encounter the error above. + +But wait, there's more. + +SunOS 4 has this quirk where it only works with CD-ROM drives that report a block size of 512 bytes, instead of the default of 2048. Now, I realize that just recently, there was a change committed that allows the guest to change the block size with the MODE SELECT command. However this doesn't seem to be good enough for SunOS (I tried it, it still hates the drive). Note that scsi-disk.c hard codes the block size for CD-ROMs to 2058 in scsi_cd_realize(). What would be really nice is if was possible to override this from the command line, and that addresses the problem quite nicely. + +At the same URL above, I also provided a small patch to scsi-disk.c which implements this feature. This allows the user to set the initial block size with logical_block_size=512 when specifying the device parameters. The qemu_sparc5.sh and qemu_sparc20.sh scripts show an example of this. + +One more thing: I wanted to simulate a SPARCstation 20, but I found that SunOS 4 would panic when I tried to boot it with this configuration, even if I used the correct SS20 OpenProm image. The problem here has to do with the SUNW,DBRIe device. QEMU doesn't simulate this device, but it creates dummy resources for it, including a PROM space. The problem is that this space is empty. This causes the OpenProm to create a node with an empty "name" property, which is a condition the SunOS kernel doesn't expect. The result is that the kernel tries to dereference a NULL pointer and panics. (The OpenProm code itself seems to let it slide.) + +To work around this, I patched the sun4m.c code to create the SUNW,DBRIe device such that its PROM space can actually be populated with an FCode image, and I created a simple one with a valid name property so that the kernel doesn't panic. SunOS complains later that it can't find the audio device because it's not actually implemented, but at least it doesn't crash. + +I don't know how this would actually be addressed in QEMU proper since the existing FCode images that QEMU uses come from OpenBios. + +Finally, one thing I haven't figured out is that using the -smp flag with SunOS 4 never seems to work. The OpenProms and the SunOS kernel only ever seem to detect one CPU. I am not that broken up about this though, because SunOS 4 never really did SMP very well to begin with. +Steps to reproduce: +Download all the files at: + +http://people.freebsd.org/~wpaul/sunos-qemu + +You can download just: + +http://people.freebsd.org/~wpaul/sunos-qemu/sunos-qemu.tar.gz + +if you want everything in one shot. + +Read the readme.txt file. This will walk you through trying to create a bootable SunOS system. You should apply the CD-ROM patch to scsi-disk.c and use the qemu_sparc5.sh script initially. This should allow you to install the miniroot from the CD image onto the virtual hard drive, but it will fail booting due to the esp controller problem. The qemu_sparc20.sh script will only boot successfully if you apply the sun4m.c patch and copy QEMU,dbri.bin to the QEMU firmware directory. +Additional information: +I'm not planning to provide a pull request for any of this. As I said, I'm not sure if my fixes are necessarily correct (especially the esp.c one). I'm satisfied that they work for me, but I want to leave it to the appropriate maintainers do decide how to best deal with these things. + +I would be happy to answer questions and test candidate fixes though. diff --git a/results/classifier/118/review/1127053 b/results/classifier/118/review/1127053 new file mode 100644 index 000000000..3aa0ea142 --- /dev/null +++ b/results/classifier/118/review/1127053 @@ -0,0 +1,147 @@ +register: 0.918 +debug: 0.912 +device: 0.911 +virtual: 0.908 +graphic: 0.904 +architecture: 0.900 +permissions: 0.897 +socket: 0.884 +peripherals: 0.878 +user-level: 0.876 +arm: 0.868 +semantic: 0.865 +assembly: 0.863 +mistranslation: 0.859 +risc-v: 0.855 +hypervisor: 0.853 +performance: 0.850 +x86: 0.848 +network: 0.847 +vnc: 0.842 +PID: 0.840 +kernel: 0.835 +files: 0.826 +boot: 0.813 +KVM: 0.788 +ppc: 0.777 +TCG: 0.761 +VMM: 0.748 +i386: 0.666 +-------------------- +virtual: 0.947 +hypervisor: 0.931 +KVM: 0.801 +user-level: 0.201 +debug: 0.059 +x86: 0.051 +vnc: 0.029 +files: 0.017 +register: 0.016 +TCG: 0.013 +kernel: 0.010 +PID: 0.010 +socket: 0.009 +VMM: 0.008 +performance: 0.006 +semantic: 0.004 +network: 0.004 +boot: 0.004 +device: 0.004 +architecture: 0.003 +risc-v: 0.002 +assembly: 0.002 +ppc: 0.001 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.001 +i386: 0.001 +arm: 0.001 +mistranslation: 0.000 + +assertion failed in exec.c while attempting to start a guest (latest commit) + +Hi team, + +I decided to try the latest commit on git (previously used version 1.3.0), and I got failed assertions while attempting to start my guests: + +eclipse ~ # qemu-kvm -enable-kvm -hda arch.img -m 4096 -smp sockets=1,cores=4 -vnc :0 -cpu host -vga std -net nic,model=e1000,macaddr=00:00:00:00:00:00 -net tap,ifname=vm0 -qmp tcp:0.0.0.0:4900,server,nowait +qemu-kvm: /var/tmp/portage/app-emulation/qemu-9999/work/qemu-9999/exec.c:982: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed. +Aborted + +The assertion seems valid, so whatever's causing it is probably to blame. I haven't dug around much to find out what calls the method (qemu_ram_set_idstr()), but that is probably the best place to start. + +The host contains a Xeon E3-1240 CPU, virtualising a bunch of guests one of which is Arch Linux 64-bit, if that helps. + +eclipse ~ # qemu-kvm -version +QEMU emulator version 1.4.50, Copyright (c) 2003-2008 Fabrice Bellard + +It looks like this assertion happens if you call the executable without any parameters as well: + +eclipse ~ # qemu-kvm +qemu-kvm: /var/tmp/portage/app-emulation/qemu-9999/work/qemu-9999/exec.c:982: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed. +Aborted + +Thanks. + +For what it's worth, I got the same problem in 1.4 - not sure what's going on there: + +eclipse ~ # qemu-kvm --version +QEMU emulator version 1.4.0, Copyright (c) 2003-2008 Fabrice Bellard + +eclipse ~ # qemu-kvm +qemu-kvm: /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/exec.c:982: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed. +Aborted + +Commenting out the assertion in question (which has been in the source code for the last year) seems to resolve the problem with no noticeable negative impacts, or at least this is what my tests have shown. + +I'm surprised nobody has commented on this. It's definitely a bug - at least on my distribution (Gentoo Linux). Here is a gdb backtrace with debugging symbols included: + +eclipse ~ # gdb qemu-system-x86_64 +GNU gdb (Gentoo 7.5.1 p2) 7.5.1 +Copyright (C) 2012 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-pc-linux-gnu". +For bug reporting instructions, please see: +<http://bugs.gentoo.org/>... +Reading symbols from /usr/bin/qemu-system-x86_64...done. +(gdb) run +Starting program: /usr/bin/qemu-system-x86_64 +warning: Could not load shared library symbols for linux-vdso.so.1. +Do you need "set solib-search-path" or "set sysroot"? +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +[New Thread 0x7ffff33db700 (LWP 22865)] +[New Thread 0x7fffea8d8700 (LWP 22866)] +qemu-system-x86_64: /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/exec.c:982: qemu_ram_set_idstr: Assertion `!new_block->idstr[0]' failed. + +Program received signal SIGABRT, Aborted. +0x00007ffff5a52b15 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff5a52b15 in raise () from /lib64/libc.so.6 +#1 0x00007ffff5a53f96 in abort () from /lib64/libc.so.6 +#2 0x00007ffff5a4bb3e in ?? () from /lib64/libc.so.6 +#3 0x00007ffff5a4bc00 in __assert_fail () from /lib64/libc.so.6 +#4 0x0000000000573595 in qemu_ram_set_idstr (addr=<optimized out>, name=0x1357130 "e1000.rom", dev=<optimized out>) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/exec.c:982 +#5 0x00000000004ba6ba in pci_add_option_rom (is_default_rom=<optimized out>, pdev=<optimized out>) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/pci/pci.c:1872 +#6 pci_qdev_init (qdev=0x7fffe9511010) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/pci/pci.c:1653 +#7 0x00000000004ccd14 in device_realize (dev=0x7fffe9511010, err=0x7fffffffda90) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/qdev.c:175 +#8 0x00000000004ce3ff in device_set_realized (obj=0x7fffe9511010, value=true, err=0x7fffffffdb90) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/qdev.c:673 +#9 0x00000000005391e6 in property_set_bool (obj=0x7fffe9511010, v=<optimized out>, opaque=0x131ff80, name=<optimized out>, errp=0x7fffffffdb90) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/qom/object.c:1222 +#10 0x000000000053bc05 in object_property_set_qobject (obj=0x7fffe9511010, value=<optimized out>, name=0x749005 "realized", errp=0x7fffffffdb90) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/qom/qom-qobject.c:24 +#11 0x000000000053aa7e in object_property_set_bool (obj=0x7fffe9511010, value=<optimized out>, name=0x749005 "realized", errp=0x7fffffffdb90) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/qom/object.c:765 +#12 0x00000000004cd498 in qdev_init (dev=0x7fffe9511010) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/qdev.c:161 +#13 0x00000000004bb11b in pci_nic_init (nd=0x126bb60 <nd_table>, default_model=<optimized out>, default_devaddr=<optimized out>) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/pci/pci.c:1524 +#14 0x00000000004bb1bc in pci_nic_init_nofail (nd=0x126bb60 <nd_table>, default_model=0x6a5fb1 "e1000", default_devaddr=0x0) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/pci/pci.c:1537 +#15 0x000000000059a903 in pc_nic_init (isa_bus=0x132f900, pci_bus=0x130a930) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/i386/../pc.c:1124 +#16 0x000000000059af20 in pc_init1 (system_memory=0x12e19a0, system_io=0x12e2710, ram_size=<optimized out>, boot_device=0x6cb48b "cad", kernel_filename=0x13122c0 "PE0\001", kernel_cmdline=<optimized out>, initrd_filename=0x0, + cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/i386/../pc_piix.c:174 +#17 0x000000000059b2d0 in pc_init_pci (args=<optimized out>) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/hw/i386/../pc_piix.c:229 +#18 0x000000000040cfa7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /var/tmp/portage/app-emulation/qemu-1.4.0/work/qemu-1.4.0/vl.c:4199 + +Triaging 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/review/113 b/results/classifier/118/review/113 new file mode 100644 index 000000000..1f3d5f525 --- /dev/null +++ b/results/classifier/118/review/113 @@ -0,0 +1,61 @@ +mistranslation: 0.840 +ppc: 0.358 +graphic: 0.331 +permissions: 0.274 +VMM: 0.274 +semantic: 0.237 +user-level: 0.204 +virtual: 0.200 +vnc: 0.190 +device: 0.175 +risc-v: 0.164 +TCG: 0.157 +debug: 0.153 +architecture: 0.140 +register: 0.117 +i386: 0.099 +PID: 0.075 +network: 0.067 +KVM: 0.050 +x86: 0.045 +performance: 0.043 +socket: 0.041 +boot: 0.027 +arm: 0.022 +assembly: 0.021 +files: 0.020 +hypervisor: 0.014 +peripherals: 0.010 +kernel: 0.008 +-------------------- +network: 0.959 +files: 0.522 +virtual: 0.291 +semantic: 0.114 +x86: 0.043 +i386: 0.037 +user-level: 0.018 +debug: 0.018 +peripherals: 0.014 +device: 0.007 +VMM: 0.006 +permissions: 0.006 +TCG: 0.004 +ppc: 0.003 +boot: 0.003 +performance: 0.003 +PID: 0.003 +architecture: 0.002 +kernel: 0.001 +assembly: 0.001 +KVM: 0.001 +graphic: 0.001 +vnc: 0.001 +arm: 0.001 +mistranslation: 0.001 +hypervisor: 0.001 +register: 0.000 +risc-v: 0.000 +socket: 0.000 + +missing manpage for bridge.conf diff --git a/results/classifier/118/review/1145 b/results/classifier/118/review/1145 new file mode 100644 index 000000000..d57f0309d --- /dev/null +++ b/results/classifier/118/review/1145 @@ -0,0 +1,87 @@ +register: 0.946 +architecture: 0.929 +i386: 0.858 +debug: 0.846 +graphic: 0.755 +semantic: 0.722 +device: 0.660 +arm: 0.558 +socket: 0.541 +x86: 0.536 +performance: 0.478 +network: 0.439 +files: 0.438 +peripherals: 0.436 +PID: 0.388 +ppc: 0.386 +vnc: 0.378 +kernel: 0.347 +mistranslation: 0.336 +TCG: 0.268 +boot: 0.261 +permissions: 0.237 +VMM: 0.231 +assembly: 0.199 +user-level: 0.176 +hypervisor: 0.156 +KVM: 0.088 +virtual: 0.086 +risc-v: 0.050 +-------------------- +ppc: 0.828 +debug: 0.692 +files: 0.540 +register: 0.383 +KVM: 0.329 +arm: 0.193 +VMM: 0.156 +TCG: 0.150 +i386: 0.145 +kernel: 0.114 +risc-v: 0.044 +semantic: 0.026 +virtual: 0.015 +architecture: 0.014 +assembly: 0.012 +PID: 0.007 +user-level: 0.006 +performance: 0.006 +device: 0.005 +hypervisor: 0.003 +x86: 0.003 +boot: 0.002 +graphic: 0.002 +network: 0.002 +vnc: 0.001 +peripherals: 0.001 +socket: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +Support register name resolution in debugger part of monitor for `x` commands for ARM platforms +Additional information: +From the looks of `get_monitor_def()` function from `monitor/misc.c` it seems to be cross-target but somehow still doesn't work for some targets anyway. + +Then grepping for the actual target implementation, it seems only i386, PPC, SPARC, and M68K support it, but nor ARM, MIPS, RISC V, etc: +``` +[i] ℤ rg monitor_defs +target/sparc/monitor.c +59:const MonitorDef monitor_defs[] = { +162:const MonitorDef *target_monitor_defs(void) +164: return monitor_defs; + +target/ppc/monitor.c +86:const MonitorDef monitor_defs[] = { +102:const MonitorDef *target_monitor_defs(void) +104: return monitor_defs; + +target/i386/monitor.c +611:const MonitorDef monitor_defs[] = { +647:const MonitorDef *target_monitor_defs(void) +649: return monitor_defs; + +target/m68k/monitor.c +25:static const MonitorDef monitor_defs[] = { +59:const MonitorDef *target_monitor_defs(void) +61: return monitor_defs; +``` diff --git a/results/classifier/118/review/1150 b/results/classifier/118/review/1150 new file mode 100644 index 000000000..107798825 --- /dev/null +++ b/results/classifier/118/review/1150 @@ -0,0 +1,144 @@ +risc-v: 0.876 +TCG: 0.865 +peripherals: 0.836 +permissions: 0.832 +vnc: 0.790 +mistranslation: 0.789 +KVM: 0.782 +user-level: 0.778 +semantic: 0.774 +register: 0.767 +ppc: 0.759 +graphic: 0.725 +hypervisor: 0.723 +i386: 0.708 +x86: 0.707 +VMM: 0.699 +debug: 0.686 +arm: 0.686 +PID: 0.666 +virtual: 0.637 +performance: 0.609 +device: 0.566 +boot: 0.554 +network: 0.516 +architecture: 0.512 +assembly: 0.510 +kernel: 0.477 +socket: 0.467 +files: 0.384 +-------------------- +kernel: 0.989 +virtual: 0.880 +KVM: 0.824 +hypervisor: 0.654 +debug: 0.402 +performance: 0.037 +register: 0.036 +TCG: 0.034 +x86: 0.027 +files: 0.021 +PID: 0.021 +boot: 0.016 +VMM: 0.016 +semantic: 0.013 +ppc: 0.007 +device: 0.007 +assembly: 0.003 +architecture: 0.003 +socket: 0.002 +network: 0.002 +graphic: 0.002 +user-level: 0.002 +risc-v: 0.002 +i386: 0.001 +peripherals: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 +arm: 0.000 + +guest Linux Kernel hangs and reports CPU lockup/stuck (Qemu >= 6.0.1 regression) +Description of problem: +Since at least [qemu-6.0.1](https://download.qemu.org/qemu-6.0.1.tar.xz) my VM guest is having CPU problems. It looks like [qemu-6.0.0](https://download.qemu.org/qemu-6.0.0.tar.xz) is fine, but I can't confirm this 100 %. + +Problem: The guest hangs for about 30 seconds and dmesg reports errors. + +<details> +<summary>dmesg</summary> + +``` +[ 310.791732] watchdog: BUG: soft lockup - CPU#1 stuck for 25s! [swapper/1:0] +[ 310.791753] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter af_packet iscsi_ibft iscsi_boot_sysfs rfkill dm_crypt essiv authenc pktcdvd intel_rapl_msr intel_rapl_common kvm_intel kvm cirrus drm_kms_helper irqbypass cec pcspkr joydev rc_core syscopyarea sysfillrect sysimgblt virtio_balloon fb_sys_fops i2c_piix4 button nls_iso8859_1 nls_cp437 vfat fat drm fuse configfs ip_tables x_tables ext4 crc16 mbcache jbd2 hid_generic usbhid sd_mod t10_pi virtio_scsi virtio_net net_failover virtio_blk failover sr_mod cdrom ata_generic crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci xhci_pci_renesas xhci_hcd cryptd serio_raw ehci_pci uhci_hcd ehci_hcd usbcore ata_piix ahci libahci virtio_pci virtio_pci_modern_dev libata floppy qemu_fw_cfg dm_mirror dm_region_hash dm_log dm_mod sg scsi_mod +[ 310.792102] Supported: Yes +[ 310.792108] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.21-150400.22-default #1 SLE15-SP4 0b6a6578ade2de5c4a0b916095dff44f76ef1704 +[ 310.792121] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 +[ 310.792127] RIP: 0010:__do_softirq+0x6e/0x2bc +[ 310.792146] Code: 8b 70 2c 81 60 2c ff f7 ff ff 89 74 24 14 c7 44 24 10 0a 00 00 00 48 c7 c0 c0 30 03 00 65 66 c7 00 00 00 fb 66 0f 1f 44 00 00 <bb> ff ff ff ff 41 0f bc de 83 c3 01 89 1c 24 0f 84 92 00 00 00 49 +[ 310.792154] RSP: 0018:ffffb9a8c00d0f98 EFLAGS: 00000206 +[ 310.792163] RAX: 00000000000330c0 RBX: ffffb9a8c0093e18 RCX: 0000000034b47837 +[ 310.792169] RDX: ffff9835c02dd100 RSI: 0000000004200042 RDI: 0000000000000040 +[ 310.792175] RBP: 0000000000000022 R08: ffffb9a8c0093e18 R09: 0000000000000001 +[ 310.792180] R10: 0000000000000002 R11: 0000000000000283 R12: 0000000000000001 +[ 310.792185] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 +[ 310.792191] FS: 0000000000000000(0000) GS:ffff9836f7d00000(0000) knlGS:0000000000000000 +[ 310.792197] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 310.792203] CR2: 000055ed8cffbaf8 CR3: 00000001025c0001 CR4: 0000000000170ee0 +[ 310.792216] Call Trace: +[ 310.792247] <IRQ> +[ 310.792284] irq_exit_rcu+0x9c/0xc0 +[ 310.792305] common_interrupt+0x5d/0xa0 +[ 310.792331] </IRQ> +[ 310.792335] <TASK> +[ 310.792339] asm_common_interrupt+0x1e/0x40 +[ 310.792358] RIP: 0010:native_safe_halt+0xb/0x10 +[ 310.792368] Code: f0 80 48 02 20 48 8b 00 a8 08 74 82 eb c1 cc eb 07 0f 00 2d 89 f3 5f 00 f4 c3 0f 1f 44 00 00 eb 07 0f 00 2d 79 f3 5f 00 fb f4 <c3> cc cc cc cc 0f 1f 44 00 00 65 8b 15 14 ee 60 69 0f 1f 44 00 00 +[ 310.792375] RSP: 0018:ffffb9a8c0093ec8 EFLAGS: 00000212 +[ 310.792382] RAX: ffffffff96a0ca50 RBX: 0000000000000001 RCX: ffff9835c49c3700 +[ 310.792387] RDX: 00000000001df31e RSI: 0000000000000000 RDI: ffff9835c02a8000 +[ 310.792392] RBP: ffffffff97d47120 R08: 00000000001df31e R09: 0000000000029800 +[ 310.792397] R10: ffffb9a8c164bbe0 R11: 0000000000000198 R12: 0000000000000000 +[ 310.792402] R13: 0000000000000000 R14: ffffffffffffffff R15: ffff9835c02a8000 +[ 310.792409] ? __sched_text_end+0x5/0x5 +[ 310.792425] default_idle+0xa/0x10 +[ 310.792434] default_idle_call+0x2d/0xe0 +[ 310.792441] do_idle+0x1ec/0x2d0 +[ 310.792452] cpu_startup_entry+0x19/0x20 +[ 310.792460] start_secondary+0x11c/0x160 +[ 310.792475] secondary_startup_64_no_verify+0xc2/0xcb +[ 310.792501] </TASK> +``` + +``` +[ 435.511342] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 30s! +[ 435.511374] Showing busy workqueues and worker pools: +[ 435.511377] workqueue events: flags=0x0 +[ 435.511380] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 435.511385] pending: vmstat_shepherd +[ 435.511395] workqueue events_power_efficient: flags=0x80 +[ 435.511398] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256 refcnt=3 +[ 435.511402] pending: neigh_periodic_work, neigh_periodic_work +[ 435.511411] workqueue events_freezable_power_: flags=0x84 +[ 435.511414] pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 435.511417] in-flight: 4783:disk_events_workfn +[ 435.511425] workqueue mm_percpu_wq: flags=0x8 +[ 435.511428] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 435.511431] pending: vmstat_update +[ 435.511440] workqueue writeback: flags=0x4a +[ 435.511443] pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256 refcnt=3 +[ 435.511447] pending: wb_workfn +[ 435.511453] workqueue kblockd: flags=0x18 +[ 435.511455] pwq 3: cpus=1 node=0 flags=0x0 nice=-20 active=3/256 refcnt=4 +[ 435.511459] pending: blk_mq_timeout_work, blk_mq_timeout_work, blk_mq_timeout_work +[ 435.511475] workqueue ata_sff: flags=0x8 +[ 435.511479] pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/512 refcnt=2 +[ 435.511482] pending: ata_sff_pio_task [libata] +[ 435.511538] pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=30s workers=3 idle: 349 51 +``` + +</details> + +It looks like the problem mostly appears if SSH is being used over a "user" network connection. A typical situation is when editing a file in Vim (compiled with X support) via SSH and using the X clipboard (`"+y"`). But the problem also happens in other situations with SSH, e. g. when using SSHFS. +The type of NIC doesn't seem to make a difference (tested `virtio` and `e1000`). But "tap" network connections don't show a problem. + + diff --git a/results/classifier/118/review/1152 b/results/classifier/118/review/1152 new file mode 100644 index 000000000..e6fbb4751 --- /dev/null +++ b/results/classifier/118/review/1152 @@ -0,0 +1,88 @@ +semantic: 0.913 +architecture: 0.776 +KVM: 0.763 +graphic: 0.740 +debug: 0.727 +device: 0.624 +performance: 0.622 +register: 0.615 +x86: 0.611 +boot: 0.565 +PID: 0.536 +ppc: 0.479 +i386: 0.453 +permissions: 0.444 +risc-v: 0.434 +vnc: 0.421 +kernel: 0.404 +VMM: 0.385 +socket: 0.384 +mistranslation: 0.380 +files: 0.327 +network: 0.323 +peripherals: 0.265 +TCG: 0.252 +arm: 0.224 +hypervisor: 0.167 +virtual: 0.159 +assembly: 0.150 +user-level: 0.070 +-------------------- +debug: 0.954 +virtual: 0.950 +kernel: 0.904 +TCG: 0.375 +x86: 0.270 +hypervisor: 0.101 +performance: 0.075 +PID: 0.031 +files: 0.023 +VMM: 0.019 +socket: 0.018 +register: 0.015 +user-level: 0.011 +i386: 0.010 +architecture: 0.008 +device: 0.008 +assembly: 0.007 +boot: 0.005 +semantic: 0.005 +network: 0.002 +permissions: 0.002 +graphic: 0.002 +risc-v: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +KVM: 0.000 +vnc: 0.000 +ppc: 0.000 +arm: 0.000 + +Windows crashes on resuming from sleep if hv-tlbflush is enabled +Description of problem: +The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case). +Steps to reproduce: +1. Boot Windows +2. Tell Windows to go to sleep (observe that qemu's state switches to suspended) +3. Cause windows to wake up (e.g. using the `system_wakeup` HMP command) +Additional information: +Looking at the crash dumps always shows the "ATTEMPTED WRITE TO READONLY MEMORY" error, and always with this stack trace: + +``` +nt!KeBugCheckEx +nt!MiRaisedIrqlFault+0x1413a6 +nt!MmAccessFault+0x4ef +nt!KiPageFault+0x35e +nt!MiIncreaseUsedPtesCount+0x12 +nt!MiBuildForkPte+0xc6 +nt!MiCloneVads+0x4ab +nt!MiCloneProcessAddressSpace+0x261 +nt!MmInitializeProcessAddressSpace+0x1cb631 +nt!PspAllocateProcess+0x1d13 +nt!PspCreateProcess+0x242 +nt!NtCreateProcessEx+0x85 +nt!KiSystemServiceCopyEnd+0x25 +ntdll!NtCreateProcessEx+0x14 +``` + +However, the process that is being created here is always `WerFault.exe`, i.e. the crash reporter. The crashing process is seemingly random. Removing `hv-tlbflush` from the command line resolves the problem. Hence, my hypothesis is that due to improper TLB flushing during wakeup, a random application on the core will crash, which spawns `WerFault.exe` which then immediately crashes again inside the kernel (also because of bad/stale TLB contents) and causes the BSOD. Perhaps one core wakes up first, requests a TLB flush, which is then *not* propagated to sleeping cores due to hv-tlbflush. Then one of those cores wakes up without the TLB flush? diff --git a/results/classifier/118/review/1162644 b/results/classifier/118/review/1162644 new file mode 100644 index 000000000..74faf36ac --- /dev/null +++ b/results/classifier/118/review/1162644 @@ -0,0 +1,191 @@ +user-level: 0.912 +vnc: 0.888 +register: 0.859 +permissions: 0.856 +peripherals: 0.854 +risc-v: 0.851 +KVM: 0.850 +x86: 0.845 +hypervisor: 0.845 +performance: 0.841 +device: 0.840 +VMM: 0.834 +boot: 0.823 +architecture: 0.821 +virtual: 0.810 +assembly: 0.805 +debug: 0.800 +arm: 0.794 +graphic: 0.792 +files: 0.787 +kernel: 0.787 +socket: 0.787 +semantic: 0.782 +network: 0.777 +ppc: 0.765 +TCG: 0.765 +PID: 0.738 +mistranslation: 0.730 +i386: 0.678 +-------------------- +x86: 0.991 +hypervisor: 0.882 +debug: 0.747 +virtual: 0.620 +boot: 0.492 +PID: 0.198 +KVM: 0.063 +TCG: 0.052 +socket: 0.045 +files: 0.034 +ppc: 0.032 +register: 0.025 +kernel: 0.018 +user-level: 0.011 +semantic: 0.009 +performance: 0.008 +VMM: 0.008 +device: 0.008 +network: 0.008 +peripherals: 0.005 +assembly: 0.004 +architecture: 0.002 +graphic: 0.002 +permissions: 0.001 +vnc: 0.001 +risc-v: 0.001 +arm: 0.001 +i386: 0.000 +mistranslation: 0.000 + +qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base() + +Description: +When QEMU tries to boot with a usb 3.0 tablet (xhci) on a Raring ringtail box (QEMU package1.4.0+dfsg-1expubuntu4) it will crash soon afterwards: + +qemu-system-x86_64: /build/buildd/qemu-1.4.0+dfsg/hw/usb/core.c:552: usb_packet_setup: Assertion `p->iov.iov != ((void *)0)' failed. + +Component: +qemu-system -> 1.4.0+dfsg-1expubuntu4 + +Ubuntu Version: + +Description: Ubuntu Raring Ringtail (development branch) +Release: 13.04 + +Steps to reproduce it: + +I met this bug while running the virt-test suite + +https://github.com/autotest/virt-test + +Instructions to install and run it can be seen on the README file + +https://github.com/autotest/virt-test#readme + +After the suite is set, it can be reproduced on a raring (13.04) simply by running: + +./run -t qemu --tests usb.usb_reboot.usb_tablet.xhci + +Command line: + +23:52:42 INFO | Running qemu command (reformatted): +/usr/bin/kvm \ + -S \ + -name 'virt-tests-vm1' \ + -nodefaults \ + -chardev socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130331-233911-ndvUEvrV,server,nowait \ + -mon chardev=hmp_id_hmp1,mode=readline \ + -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-serial,chardev=serial_id_serial1 \ + -chardev socket,id=seabioslog_id_20130331-233911-ndvUEvrV,path=/tmp/seabios-20130331-233911-ndvUEvrV,server,nowait \ + -device isa-debugcon,chardev=seabioslog_id_20130331-233911-ndvUEvrV,iobase=0x402 \ + -device ich9-usb-uhci1,id=usb1 \ + -device nec-usb-xhci,id=usbtest \ + -drive file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0 \ + -device virtio-blk-pci,drive=virtio0,bootindex=1 \ + -device virtio-net-pci,netdev=idumV1TE,mac='9a:c0:c1:c2:c3:c4',id='idmN7iHv' \ + -netdev user,id=idumV1TE,hostfwd=tcp::5000-:22 \ + -m 1024 \ + -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \ + -cpu 'SandyBridge' \ + -M pc \ + -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ + -device usb-tablet,id=usb-testdev,bus=usbtest.0,port=1 \ + -vnc :0 \ + -vga std \ + -rtc base=utc,clock=host,driftfix=none \ + -boot order=cdn,once=c,menu=off \ + -enable-kvm + +ProblemType: Crash +DistroRelease: Ubuntu 13.04 +Package: qemu-system-x86 1.4.0+dfsg-1expubuntu4 +ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 +Uname: Linux 3.8.0-15-generic x86_64 +ApportVersion: 2.9.2-0ubuntu5 +Architecture: amd64 +Date: Sun Mar 31 23:52:46 2013 +EcryptfsInUse: Yes +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-03-31 (0 days ago) +InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) +MarkForUpload: True +ProcEnviron: + TERM=dumb + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +Signal: 6 +SourcePackage: qemu +StacktraceTop: + raise () from /lib/x86_64-linux-gnu/libc.so.6 + abort () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () from /lib/x86_64-linux-gnu/libc.so.6 + __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 + ?? () +Title: qemu-system-x86_64 crashed with SIGABRT in raise() +UpgradeStatus: Upgraded to raring on 2013-03-31 (0 days ago) +UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo + + + + + + + + + + + + + +Thanks for reporting this bug, I will try to reproduce it, and check whether upstream git head has the same bug. + +I can't reproduce this on a clean raring system, which has the same qemu version as your quantal system. + +Is it possible for you to test on a clean raring system? + +What is your libvirt package version? + +It doesn't get any cleaner than this. I've installed the box with 12.10, immediately followed by upgrade to 13.04. What seems to be going on is that the issue is not 100% reproducible (I tried today with the same setup and could not reproduce it). + +Moreover, what really matters here is the qemu/kernel version, and nothing else. + +Libvirt version is 1.0.2-0ubuntu10. I did compile the latest git master and so far I could not reproduce it either. + +I could just reproduce it on Fedora 19 qemu-kvm version (which is 1.4.0) and qemu.git master. So the issue is not 100% reproducible, but it can be seen on qemu.git master and therefore, downstream packages such as the ones found on Ubuntu and Fedora, for example. + +Ok, thanks - i did run it 3 or 4 times. How often would you say it fails for you? + +I will mark this as affecting the upstream qemu project based on comment #10. + +On my F19 box, it's failing about 2/3 of the attempts. What is funny is that on the Ubuntu 13.04 box, I can't get the problem reproduced anymore, for some reason beyond me. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Sure, please close it. + diff --git a/results/classifier/118/review/1172613 b/results/classifier/118/review/1172613 new file mode 100644 index 000000000..137b23a3e --- /dev/null +++ b/results/classifier/118/review/1172613 @@ -0,0 +1,130 @@ +user-level: 0.876 +hypervisor: 0.874 +graphic: 0.867 +ppc: 0.864 +TCG: 0.858 +register: 0.844 +peripherals: 0.838 +architecture: 0.834 +performance: 0.830 +virtual: 0.812 +assembly: 0.811 +mistranslation: 0.807 +PID: 0.806 +permissions: 0.806 +KVM: 0.804 +device: 0.795 +semantic: 0.790 +risc-v: 0.785 +VMM: 0.774 +boot: 0.771 +files: 0.770 +vnc: 0.759 +arm: 0.754 +network: 0.747 +kernel: 0.735 +debug: 0.735 +socket: 0.701 +x86: 0.655 +i386: 0.614 +-------------------- +arm: 0.848 +register: 0.661 +assembly: 0.582 +virtual: 0.532 +debug: 0.327 +architecture: 0.191 +hypervisor: 0.177 +ppc: 0.165 +kernel: 0.115 +TCG: 0.076 +files: 0.032 +PID: 0.030 +device: 0.019 +boot: 0.015 +user-level: 0.011 +VMM: 0.011 +semantic: 0.010 +socket: 0.006 +KVM: 0.005 +graphic: 0.004 +performance: 0.003 +peripherals: 0.002 +x86: 0.002 +risc-v: 0.002 +permissions: 0.001 +network: 0.001 +mistranslation: 0.001 +vnc: 0.001 +i386: 0.000 + +[qemu 1.4.1] inconsistent behavior on different architecture + +Running with qemu 1.4.1 and eglibc 2.17 on Debian Linux 7.0 for amd64 + +---------------- armhf ---------------- +$ arm-linux-gnueabihf-gcc hello.c +$ qemu-arm ./a.out +/lib/ld-linux-armhf.so.3: No such file or directory + +$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so ./a.out +./a.out: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory + +$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so --library-path arm-linux-gnueabihf/lib ./a.out +Hello, world ! + +---------------- powerpc64 ---------------- +$ powerpc64-linux-gcc hello.c + +$ qemu-ppc64 ./a.out +/lib64/ld64.so.1: No such file or directory + +[BAD BEHAVIOR !!!] +$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so ./a.out +Invalid data memory access: 0x00000041988fd008 +NIP 000000400001cb2c LR 000000400001cc30 CTR 0000000000000000 XER 0000000000000000 +MSR 8000000002006000 HID0 0000000060000000 HF 8000000002006000 idx 0 +TB 00000000 00000000 +GPR00 0000000000000000 000000400083a220 0000004000041230 00000043309bd010 +GPR04 0000004000026f12 000000000000000b 000000000000002e 000000000000002e +GPR08 0000000000000030 000000008803fffc 00000041988fcff4 0000000000000037 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 000000400003a4d8 000000400083a6d0 000000400083a6d8 +GPR20 000000400003a898 000000000000000a 0000000000000000 00000043309bd010 +GPR24 0000004000037b60 00000000cfe8ced7 000000400003a430 0000000010000261 +GPR28 00000001980bfff4 0000000000000000 000000004401ffff 000000002200ffff +CR 22242224 [ E E E G E E E G ] RES ffffffffffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 0000000000000000 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so --library-path powerpc64-linux/lib64 ./a.out +Hello, world ! + +---------------- sparc64 ---------------- +$ sparc64-linux-gcc hello.c + +$ qemu-sparc64 ./a.out +/lib64/ld-linux.so.2: No such file or directory + +[BAD BEHAVIOR !!!] +$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so ./a.out +Segmentation fault + +$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so --library-path sparc64-linux/lib64 ./a.out +Hello, world ! + +This is going to be the same "glibc crashes if it sees a wrong-endianness /etc/ld.so.cache" situation also seen in lp:1701798. Personally I think it's a glibc bug, not really a QEMU bug. + + +In particular, the only crashes here are the ones where --library-path isn't specified, so it isn't even a case of "QEMU should somehow support whiteouts in --library-path so you can tell it to ignore the host ld.so.cache". So I'm going to close this bug report (with 'invalid' as the closest sensible resolution). + + diff --git a/results/classifier/118/review/1177774 b/results/classifier/118/review/1177774 new file mode 100644 index 000000000..aeeff2663 --- /dev/null +++ b/results/classifier/118/review/1177774 @@ -0,0 +1,129 @@ +risc-v: 0.888 +user-level: 0.862 +permissions: 0.751 +peripherals: 0.741 +mistranslation: 0.732 +performance: 0.721 +semantic: 0.718 +register: 0.714 +virtual: 0.713 +graphic: 0.710 +hypervisor: 0.695 +assembly: 0.688 +vnc: 0.675 +kernel: 0.674 +TCG: 0.673 +socket: 0.666 +ppc: 0.662 +device: 0.661 +i386: 0.658 +PID: 0.657 +architecture: 0.649 +arm: 0.648 +network: 0.646 +debug: 0.645 +files: 0.637 +KVM: 0.610 +boot: 0.604 +x86: 0.603 +VMM: 0.582 +-------------------- +i386: 0.883 +TCG: 0.787 +x86: 0.736 +files: 0.607 +PID: 0.109 +register: 0.092 +user-level: 0.070 +virtual: 0.062 +debug: 0.060 +semantic: 0.042 +permissions: 0.037 +ppc: 0.035 +boot: 0.026 +hypervisor: 0.022 +graphic: 0.018 +performance: 0.016 +device: 0.014 +network: 0.011 +architecture: 0.010 +socket: 0.009 +risc-v: 0.009 +VMM: 0.008 +assembly: 0.008 +arm: 0.008 +KVM: 0.007 +mistranslation: 0.004 +peripherals: 0.004 +kernel: 0.004 +vnc: 0.004 + +Gtk+ frontend fails to build + +The QEMU Gtk+ frontend fails to build.. + +cc -I/home/ports/pobj/qemu-1.5.0-rc0/qemu-1.5.0-rc0/tcg -I/home/ports/pobj/qemu-1.5.0-rc0/qemu-1.5.0-rc0/tcg/i386 -I. -I/home/ports/pobj/qemu-1.5.0-rc0/qemu-1.5.0-rc0 -I/home/ports/pobj/qemu-1.5.0-rc0/qemu-1.5.0-rc0/include -Iui -Iui -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -DTIME_MAX=INT_MAX -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/include -I/usr/X11R6/include/pixman-1 -I/home/ports/pobj/qemu-1.5.0-rc0/qemu-1.5.0-rc0/dtc/libfdt -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/home/ports/pobj/qemu-1.5.0-rc0/qemu-1.5.0-rc0/tests -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/X11R6/include -I/usr/local/include/cairo -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/pixman-1 -I/usr/local/include/libpng -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/harfbuzz -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/local/include/vte-0.0 -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/X11R6/include -I/usr/local/include/atk-1.0 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/harfbuzz -I/usr/local/include/gio-unix-2.0/ -pthread -I/usr/local/include/cairo -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng -MMD -MP -MT ui/gtk.o -MF ui/gtk.d -O2 -pipe -c -o ui/gtk.o ui/gtk.c +In file included from /usr/local/include/gtk-2.0/gtk/gtk.h:234, + from ui/gtk.c:44: +/usr/local/include/gtk-2.0/gtk/gtkitemfactory.h:47: warning: function declaration isn't a prototype +ui/gtk.c:58:17: warning: pty.h: No such file or directory +ui/gtk.c: In function 'gd_vc_init': +ui/gtk.c:1142: error: storage size of 'tty' isn't known +ui/gtk.c:1162: warning: implicit declaration of function 'openpty' +ui/gtk.c:1162: warning: nested extern declaration of 'openpty' +ui/gtk.c:1166: warning: implicit declaration of function 'tcgetattr' +ui/gtk.c:1166: warning: nested extern declaration of 'tcgetattr' +ui/gtk.c:1167: warning: implicit declaration of function 'cfmakeraw' +ui/gtk.c:1167: warning: nested extern declaration of 'cfmakeraw' +ui/gtk.c:1168: warning: implicit declaration of function 'tcsetattr' +ui/gtk.c:1168: warning: nested extern declaration of 'tcsetattr' +ui/gtk.c:1168: error: 'TCSAFLUSH' undeclared (first use in this function) +ui/gtk.c:1168: error: (Each undeclared identifier is reported only once +ui/gtk.c:1168: error: for each function it appears in.) +ui/gtk.c:1142: warning: unused variable 'tty' + +With the 1.5 release so near does no one really care that the Gtk+ frontend does not build? I would think this would be a pretty important bug to fix before the release. + +Sending a patch soon, please reply with Tested-by if it works. + +For *BSD OS's you have to include termios.h.. + +In file included from /usr/local/include/gtk-2.0/gtk/gtk.h:234, + from ui/gtk.c:44: +/usr/local/include/gtk-2.0/gtk/gtkitemfactory.h:47: warning: function declaration isn't a prototype +ui/gtk.c: In function 'gd_vc_init': +ui/gtk.c:1141: error: storage size of 'tty' isn't known +ui/gtk.c:1165: warning: implicit declaration of function 'tcgetattr' +ui/gtk.c:1165: warning: nested extern declaration of 'tcgetattr' +ui/gtk.c:1166: warning: implicit declaration of function 'cfmakeraw' +ui/gtk.c:1166: warning: nested extern declaration of 'cfmakeraw' +ui/gtk.c:1167: warning: implicit declaration of function 'tcsetattr' +ui/gtk.c:1167: warning: nested extern declaration of 'tcsetattr' +ui/gtk.c:1167: error: 'TCSAFLUSH' undeclared (first use in this function) +ui/gtk.c:1167: error: (Each undeclared identifier is reported only once +ui/gtk.c:1167: error: for each function it appears in.) +ui/gtk.c:1141: warning: unused variable 'tty' + +e.g. + +#if defined(__GLIBC__) +# include <pty.h> +#elif defined CONFIG_BSD +# include <termios.h> +# if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) +# include <libutil.h> +# else +# include <util.h> +# endif +#elif defined CONFIG_SOLARIS +# include <stropts.h> +#endif + +This should allow OS X to at least build. It looks like Solaris does not have openpty() and cfmakeraw() + +So the *BSD build has been fixed, but someone needs to look into fixing the Gtk+ backend on Solaris. + +Looks like this issue has been fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4efeabbbe8441cc327052304 +... so I think it should be OK to close this now. + diff --git a/results/classifier/118/review/1179731 b/results/classifier/118/review/1179731 new file mode 100644 index 000000000..8986bdb09 --- /dev/null +++ b/results/classifier/118/review/1179731 @@ -0,0 +1,106 @@ +x86: 0.920 +mistranslation: 0.903 +network: 0.890 +i386: 0.875 +files: 0.847 +architecture: 0.815 +PID: 0.806 +KVM: 0.800 +graphic: 0.770 +device: 0.767 +performance: 0.758 +semantic: 0.750 +user-level: 0.744 +ppc: 0.743 +socket: 0.691 +permissions: 0.688 +virtual: 0.669 +vnc: 0.656 +register: 0.653 +kernel: 0.646 +VMM: 0.640 +hypervisor: 0.634 +peripherals: 0.626 +risc-v: 0.620 +TCG: 0.615 +debug: 0.570 +boot: 0.499 +arm: 0.486 +assembly: 0.387 +-------------------- +x86: 0.825 +hypervisor: 0.729 +network: 0.156 +user-level: 0.115 +i386: 0.114 +virtual: 0.065 +register: 0.034 +debug: 0.025 +KVM: 0.018 +TCG: 0.016 +files: 0.011 +performance: 0.007 +kernel: 0.006 +PID: 0.006 +device: 0.005 +socket: 0.005 +semantic: 0.005 +VMM: 0.005 +risc-v: 0.002 +boot: 0.002 +ppc: 0.002 +architecture: 0.002 +vnc: 0.002 +assembly: 0.001 +graphic: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +permissions: 0.001 +arm: 0.000 + +is networking broken on windows hosts? + +just wondering as i just compiled the latest git and qemu goes into none responding mode when i try to do any networking stuff on guests (both linux and windows) + +On Tue, May 14, 2013 at 12:02:24AM -0000, therock247uk wrote: +> just wondering as i just compiled the latest git and qemu goes into none +> responding mode when i try to do any networking stuff on guests (both +> linux and windows) + +Works for me on qemu.git/master on Linux: + + $ git rev-parse HEAD + b087143b4d010451208264b7c841436aafe1cbb1 + $ x86_64-softmmu/qemu-system-x86_64 -m 1024 -enable-kvm -cpu host \ + -drive if=virtio,cache=none,file=test.img + +Please include more information, like the QEMU command-line and commit +ID. + +Stefan + + +latest git as of yesterday compiled under mingw using qemu-system-i386 -localtime -m 512 windows.img when ever it connects to the internet qemu hangs. + +trying other network adapters does not help either i tried the model=rtl8139 and the xp guest says limited or no connectivty. + +tried the patch did not work though still hangs/crashes has issues + +On 05/16/2013 10:59 AM, Paolo Bonzini wrote: +> Il 16/05/2013 07:52, TeLeMan ha scritto: +>> The patch is working on 134a03e0b3d34b01b68107104c525c3bff1211d4 and +>> is not working from cbff4b342b000a7642125dbdabf61113e05eee44. +> +> Thanks. +> +> Fabien or Stefan, can you take a look? +> + +Unfortunately I don't have time to investigate these days. + +-- +Fabien Chouteau + + +Looking at http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg02268.html it seems this has been fixed with commits 8db165b36ef893ac69af045 and 3cb8c205e36531a07dff1d84 ==> setting status to "Fix released" + diff --git a/results/classifier/118/review/1186 b/results/classifier/118/review/1186 new file mode 100644 index 000000000..2dcc567c6 --- /dev/null +++ b/results/classifier/118/review/1186 @@ -0,0 +1,77 @@ +architecture: 0.959 +device: 0.900 +i386: 0.835 +permissions: 0.793 +graphic: 0.768 +ppc: 0.710 +register: 0.700 +x86: 0.686 +hypervisor: 0.650 +PID: 0.591 +vnc: 0.574 +performance: 0.566 +semantic: 0.519 +socket: 0.490 +files: 0.457 +TCG: 0.375 +network: 0.356 +arm: 0.350 +user-level: 0.325 +boot: 0.300 +kernel: 0.292 +peripherals: 0.289 +debug: 0.232 +risc-v: 0.228 +assembly: 0.217 +mistranslation: 0.187 +virtual: 0.070 +VMM: 0.064 +KVM: 0.021 +-------------------- +kernel: 0.765 +user-level: 0.563 +TCG: 0.276 +x86: 0.193 +performance: 0.185 +hypervisor: 0.164 +i386: 0.146 +virtual: 0.118 +debug: 0.091 +files: 0.046 +device: 0.039 +register: 0.038 +PID: 0.023 +risc-v: 0.013 +architecture: 0.012 +ppc: 0.011 +arm: 0.010 +network: 0.006 +semantic: 0.004 +assembly: 0.004 +socket: 0.004 +boot: 0.004 +VMM: 0.003 +vnc: 0.003 +peripherals: 0.002 +graphic: 0.001 +permissions: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +qos-test fails when built with LTO and gcc-12 +Description of problem: +The issue is already discussed here [1]. I'm simply building latest QEMU release and running the test suite. I thought the issue was fixed in 7.0 but it has resurfaced. Do QEMU dev's not build with LTO? I'm not able to debug this but I can test any proposed fixes etc. Thanks. + +[1] https://lore.kernel.org/all/1d3bbff9e92e7c8a24db9e140dcf3f428c2df103.camel@suse.com/ +Steps to reproduce: +1. Build QEMU with gcc-12 and LTO enabled +2. Run make check +3. Observe test suite failures in qos-test +Additional information: +``` +Summary of Failures: + + 2/265 qemu:qtest+qtest-aarch64 / qtest-aarch64/qos-test ERROR 0.59s killed by signal 6 SIGABRT + 3/265 qemu:qtest+qtest-i386 / qtest-i386/qos-test ERROR 0.22s killed by signal 6 SIGABRT + 7/265 qemu:qtest+qtest-x86_64 / qtest-x86_64/qos-test ERROR 0.40s killed by signal 6 SIGABRT +``` diff --git a/results/classifier/118/review/1193 b/results/classifier/118/review/1193 new file mode 100644 index 000000000..885fc1436 --- /dev/null +++ b/results/classifier/118/review/1193 @@ -0,0 +1,76 @@ +x86: 0.927 +device: 0.901 +debug: 0.877 +boot: 0.875 +virtual: 0.858 +architecture: 0.845 +files: 0.843 +peripherals: 0.838 +PID: 0.810 +performance: 0.800 +VMM: 0.789 +ppc: 0.785 +socket: 0.784 +vnc: 0.781 +kernel: 0.775 +network: 0.759 +graphic: 0.740 +semantic: 0.738 +arm: 0.699 +risc-v: 0.688 +hypervisor: 0.635 +register: 0.627 +i386: 0.491 +TCG: 0.453 +assembly: 0.311 +user-level: 0.307 +permissions: 0.290 +mistranslation: 0.285 +KVM: 0.271 +-------------------- +virtual: 0.867 +hypervisor: 0.838 +x86: 0.825 +boot: 0.793 +debug: 0.765 +kernel: 0.167 +register: 0.167 +user-level: 0.154 +device: 0.090 +TCG: 0.079 +files: 0.060 +PID: 0.051 +VMM: 0.029 +KVM: 0.018 +performance: 0.014 +architecture: 0.007 +socket: 0.007 +peripherals: 0.007 +assembly: 0.007 +ppc: 0.007 +semantic: 0.005 +risc-v: 0.004 +network: 0.004 +i386: 0.003 +graphic: 0.002 +vnc: 0.001 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.000 + +io_uring / iothread regression 7.1.0 +Description of problem: +After upgrading to 7.1.0, some of my libvirt VM's failed to boot. I have narrowed down the issue to the combination of: + +- io_uring +- iothread +Steps to reproduce: +1. set up a VM with iothread and io_uring +2. try to boot and watch it "hang" +Additional information: +Here's the relevant command line from the libvirt log: +``` +-blockdev '{"driver":"file","filename":"/mnt/data/VMs/Arch-Linux-x86_64-basic.qcow2","aio":"io_uring","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"virtio-blk-pci","iothread":"iothread1","bus":"pci.4","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk0","bootindex":1 }' \ +``` diff --git a/results/classifier/118/review/1196145 b/results/classifier/118/review/1196145 new file mode 100644 index 000000000..766cff49f --- /dev/null +++ b/results/classifier/118/review/1196145 @@ -0,0 +1,85 @@ +mistranslation: 0.974 +semantic: 0.898 +device: 0.804 +graphic: 0.786 +architecture: 0.751 +network: 0.662 +peripherals: 0.633 +socket: 0.631 +debug: 0.627 +ppc: 0.600 +performance: 0.587 +PID: 0.581 +permissions: 0.574 +register: 0.559 +vnc: 0.550 +kernel: 0.530 +files: 0.490 +user-level: 0.480 +hypervisor: 0.466 +boot: 0.454 +assembly: 0.454 +risc-v: 0.451 +arm: 0.422 +VMM: 0.418 +i386: 0.353 +virtual: 0.331 +KVM: 0.330 +TCG: 0.329 +x86: 0.317 +-------------------- +user-level: 0.502 +debug: 0.488 +TCG: 0.142 +peripherals: 0.097 +device: 0.059 +x86: 0.041 +files: 0.021 +hypervisor: 0.019 +PID: 0.014 +virtual: 0.008 +arm: 0.007 +kernel: 0.006 +semantic: 0.005 +register: 0.003 +performance: 0.003 +ppc: 0.003 +i386: 0.002 +network: 0.002 +assembly: 0.001 +boot: 0.001 +architecture: 0.001 +graphic: 0.001 +risc-v: 0.001 +VMM: 0.001 +permissions: 0.001 +socket: 0.001 +mistranslation: 0.000 +vnc: 0.000 +KVM: 0.000 + +usb-host: hostaddr=0XX is parsed as octal number + +when doing + +device_add usb-host,hostaddr=010 + +taking 010 in the format of both lsusb or udev, qemu parses an octal number and assumes hostaddr=8. +(i used a 2.0 device on the ehci.0 bus) +at least to me that is confusing. + +also: + +when adding a non-existent usb device (bogus hostaddr), the following is created according to 'usb info': + + Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device + +in usb_qdev_init(): +usb_claim_port is called but usb_device_init does not report an error and thus usb_release_port is not called. + +ps: when using host-libusb.c and tested on 1.5.1.tgz + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1196498 b/results/classifier/118/review/1196498 new file mode 100644 index 000000000..7a6e2c376 --- /dev/null +++ b/results/classifier/118/review/1196498 @@ -0,0 +1,89 @@ +x86: 0.889 +debug: 0.867 +kernel: 0.866 +virtual: 0.854 +boot: 0.837 +KVM: 0.820 +semantic: 0.806 +device: 0.801 +graphic: 0.790 +files: 0.774 +network: 0.748 +performance: 0.743 +architecture: 0.703 +peripherals: 0.691 +user-level: 0.641 +VMM: 0.612 +ppc: 0.602 +socket: 0.593 +hypervisor: 0.592 +permissions: 0.585 +PID: 0.554 +register: 0.551 +mistranslation: 0.545 +vnc: 0.540 +assembly: 0.527 +i386: 0.455 +risc-v: 0.451 +TCG: 0.384 +arm: 0.357 +-------------------- +virtual: 0.987 +debug: 0.949 +hypervisor: 0.444 +KVM: 0.193 +x86: 0.144 +user-level: 0.140 +TCG: 0.084 +network: 0.022 +PID: 0.016 +VMM: 0.014 +socket: 0.010 +kernel: 0.010 +device: 0.009 +files: 0.009 +boot: 0.007 +peripherals: 0.007 +semantic: 0.006 +register: 0.005 +performance: 0.004 +assembly: 0.003 +architecture: 0.003 +risc-v: 0.003 +graphic: 0.002 +permissions: 0.001 +vnc: 0.001 +ppc: 0.001 +i386: 0.001 +mistranslation: 0.000 +arm: 0.000 + +Failed to create COM port in Windows Guest VM + +Hi, + +Tried to establish virtual serial connection between two Windows Guest VMs(Windows 2008 Server). + +As it mentioned under the link, +http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging + +Started VM using the below command with serial device as TCP port. +# qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -serial tcp:127.0.0.1:50001,server,nowait -hda /mnt/sda5/var/lib/libvirt/images/win2008host.img + +And started WinDbg in the Windows VM, with serial port:COM1 and Baudrate:115200. + +It throws the error "Could not start kernel debugging using com:port:COM1,baudrate:115200 parameters, Win32 error 0n2. The system cannot find the file specified." + +Checked under Device Manager and there is no COM1 port. +Does the -serial tcp:127.0.0.01:50001 creates COM1 port? I doubt. +If no what are the parameters I should pass to WinDbg for serial port? + +Please help me how to solve this issue. + +Thanks +Venkatesh + +Triaging 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/review/1197 b/results/classifier/118/review/1197 new file mode 100644 index 000000000..c45558895 --- /dev/null +++ b/results/classifier/118/review/1197 @@ -0,0 +1,875 @@ +user-level: 0.839 +permissions: 0.814 +peripherals: 0.801 +virtual: 0.792 +vnc: 0.789 +register: 0.787 +ppc: 0.779 +mistranslation: 0.775 +x86: 0.766 +hypervisor: 0.765 +device: 0.761 +boot: 0.756 +risc-v: 0.755 +graphic: 0.753 +KVM: 0.741 +debug: 0.727 +architecture: 0.726 +semantic: 0.725 +files: 0.709 +TCG: 0.708 +arm: 0.707 +i386: 0.706 +assembly: 0.701 +network: 0.700 +performance: 0.686 +PID: 0.668 +VMM: 0.651 +socket: 0.634 +kernel: 0.610 +-------------------- +virtual: 0.981 +hypervisor: 0.966 +KVM: 0.889 +x86: 0.813 +debug: 0.552 +user-level: 0.409 +TCG: 0.232 +register: 0.181 +kernel: 0.106 +files: 0.087 +VMM: 0.068 +PID: 0.056 +boot: 0.051 +device: 0.029 +graphic: 0.021 +architecture: 0.018 +socket: 0.018 +semantic: 0.016 +performance: 0.013 +peripherals: 0.012 +assembly: 0.006 +risc-v: 0.005 +vnc: 0.004 +permissions: 0.003 +network: 0.003 +mistranslation: 0.001 +ppc: 0.000 +i386: 0.000 +arm: 0.000 + +Use libvirt to create a Windows virtual machine and load NVIDIA's GPU. Installing NVIDIA driver causes the physical machine to restart +Description of problem: +As described in the title, When I created a Windows virtual machine and used NVIDIA's GPU and installed NVIDIA's driver in Windows VM, however, the physical machine will be restart. In the same create time, if it is a linux VM, It's ok! I don't know if there is a problem with my creation process or if the windows virtual machine is incompatible with NVIDIA graphics card. + + +GPU INFO: +``` +81:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2000] (rev a1) +81:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1) +``` + + +BR！ +Steps to reproduce: +1. +2. +3. +Additional information: +qemu info: +``` +libvirt-daemon-driver-qemu-4.5.0-36.el7_9.5.x86_64 +ipxe-roms-qemu-20180825-3.git133f4c.el7.noarch +qemu-kvm-common-1.5.3-175.el7_9.6.x86_64 +qemu-kvm-1.5.3-175.el7_9.6.x86_64 +qemu-img-1.5.3-175.el7_9.6.x86_64 +``` + + + +``` +<domain type="kvm"> + <name>win</name> + <uuid>a5efd8ed-fa6f-693c-2202-93183ec18b5e</uuid> + <description>None</description> + <memory unit="KiB">5242880</memory> + <currentMemory unit="KiB">5242880</currentMemory> + <vcpu placement="static">4</vcpu> + <os> + <type arch="x86_64" machine="pc-i440fx-rhel7.0.0">hvm</type> + <boot dev="hd"/> + <boot dev="cdrom"/> + <bootmenu enable="yes"/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode="host-passthrough" check="none"/> + <clock offset="utc"/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2"/> + <source file="/opt/panafs/1374467833802939042/win.img"/> + <target dev="sda" bus="sata"/> + <address type="drive" controller="0" bus="0" target="0" unit="0"/> + </disk> + <disk type="file" device="cdrom"> + <driver name="qemu" type="raw"/> + <source file="/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso"/> + <target dev="hda" bus="ide"/> + <readonly/> + <address type="drive" controller="0" bus="1" target="0" unit="1"/> + </disk> + <disk type="file" device="cdrom"> + <driver name="qemu" type="raw"/> + <source file="/var/lib/libvirt/images/virtio-win-0.1.217.iso"/> + <target dev="hdb" bus="ide"/> + <readonly/> + <address type="drive" controller="0" bus="0" target="0" unit="1"/> + </disk> + <controller type="usb" index="0" model="piix3-uhci"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x2"/> + </controller> + <controller type="pci" index="0" model="pci-root"/> + <controller type="ide" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x1"/> + </controller> + <controller type="sata" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x04" function="0x0"/> + </controller> + <controller type="virtio-serial" index="0"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0"/> + </controller> + <interface type="network"> + <mac address="52:54:00:1d:d8:7d"/> + <source network="default"/> + <model type="virtio"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/> + </interface> + <interface type="network"> + <mac address="52:54:00:09:bc:30"/> + <source network="default"/> + <model type="e1000"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x09" function="0x0"/> + </interface> + <serial type="pty"> + <target type="isa-serial" port="0"> + <model name="isa-serial"/> + </target> + </serial> + <console type="pty"> + <target type="serial" port="0"/> + </console> + <channel type="unix"> + <target type="virtio" name="org.qemu.guest_agent.0"/> + <address type="virtio-serial" controller="0" bus="0" port="2"/> + </channel> + <input type="mouse" bus="ps2"/> + <input type="tablet" bus="usb"> + <address type="usb" bus="0" port="1"/> + </input> + <input type="keyboard" bus="ps2"/> + <graphics type="vnc" port="-1" autoport="yes"> + <listen type="address"/> + </graphics> + <video> + <model type="cirrus" vram="16384" heads="1" primary="yes"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/> + </video> + <hostdev mode="subsystem" type="pci" managed="yes"> + <source> + <address domain="0x0000" bus="0x81" slot="0x00" function="0x0"/> + </source> + <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> + </hostdev> + <hostdev mode="subsystem" type="pci" managed="yes"> + <source> + <address domain="0x0000" bus="0x81" slot="0x00" function="0x1"/> + </source> + <address type="pci" domain="0x0000" bus="0x00" slot="0x08" function="0x0"/> + </hostdev> + <memballoon model="virtio"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x06" function="0x0"/> + </memballoon> + </devices> +</domain> +``` + + + +part log of VM: + +``` +2022-09-05 07:12:51.328+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid 49f538e1-4042-bbc4-1b2c-10f02219bba5 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:78:1a:32,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:12:51.328+0000: Domain id=3 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:14:02.309+0000: shutting down, reason=destroyed +2022-09-05 07:14:35.696+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid abcbac3c-fd61-57ac-f1ad-60387881c0a6 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:94:04:a7,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-4-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:14:35.696+0000: Domain id=4 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:15:54.690+0000: shutting down, reason=destroyed +2022-09-05 07:16:18.098+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:16:18.098+0000: Domain id=5 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:33:42.873+0000: shutting down, reason=destroyed +2022-09-05 07:37:05.200+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-6-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:37:05.200+0000: Domain id=6 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:37:37.578+0000: shutting down, reason=destroyed +2022-09-05 07:37:44.799+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=33,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-7-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:37:44.799+0000: Domain id=7 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +qemu: terminating on signal 15 from pid 3723 +2022-09-05 07:49:11.497+0000: shutting down, reason=destroyed +2022-09-05 07:49:34.883+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=32 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=33,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-8-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 07:49:34.883+0000: Domain id=8 is tainted: host-cpu +char device redirected to /dev/pts/4 (label charserial0) +2022-09-05 08:08:31.206+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-05 08:08:31.206+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15043 +2022-09-06 02:39:26.089+0000: shutting down, reason=destroyed +2022-09-06 02:39:32.783+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-sata0-0-1,media=cdrom,readonly=on \ +-device ide-cd,bus=sata0.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=2 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 \ +-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=34,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-7-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 02:39:32.783+0000: Domain id=7 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15043 +2022-09-06 02:40:52.065+0000: shutting down, reason=destroyed +2022-09-06 02:41:03.281+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-8-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=33 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=34,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-8-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 0.0.0.0:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 02:41:03.281+0000: Domain id=8 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +2022-09-06 03:08:33.510+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:08:33.510+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15135 +2022-09-06 03:09:18.992+0000: shutting down, reason=destroyed +2022-09-06 03:09:52.805+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=spice \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-2-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:09:52.805+0000: Domain id=2 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) + +(process:102539): Spice-WARNING **: 11:09:53.755: display-channel.c:2435:display_channel_validate_surface: canvas address is 0x55603dfbbb08 for 0 (and is NULL) + + +(process:102539): Spice-WARNING **: 11:09:53.755: display-channel.c:2436:display_channel_validate_surface: failed on 0 + +(process:102539): Spice-WARNING **: 11:09:53.755: red-worker.c:553:destroy_primary_surface: double destroy of primary surface + +(process:102539): Spice-WARNING **: 11:09:53.756: display-channel.c:2159:display_channel_create_surface: condition `!surface->context.canvas' failed +main_channel_link: add main channel client +main_channel_client_handle_pong: net test: latency 0.784000 ms, bitrate 50996015 bps (48.633590 Mbps) +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create +qemu: terminating on signal 15 from pid 15135 +2022-09-06 03:10:27.167+0000: shutting down, reason=destroyed +2022-09-06 03:10:39.556+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=29,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 127.0.0.1:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:10:39.556+0000: Domain id=3 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15135 +2022-09-06 03:50:33.032+0000: shutting down, reason=destroyed +2022-09-06 03:54:03.923+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=31,id=hostnet0,vhost=on,vhostfd=36 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=37,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-6-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 127.0.0.1:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 03:54:03.923+0000: Domain id=6 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +2022-09-06 04:16:48.831+0000: starting up libvirt version: 4.5.0, package: 36.el7_9.5 (CentOS BuildSystem <http://bugs.centos.org>, 2021-04-28-13:32:22, x86-01.bsys.centos.org), qemu version: 1.5.3 (qemu +-kvm-1.5.3-175.el7_9.6), kernel: 3.10.0-1160.el7.x86_64, hostname: localhost.localdomain +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +QEMU_AUDIO_DRV=none \ +/usr/libexec/qemu-kvm \ +-name win \ +-S \ +-machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off \ +-cpu host \ +-m 5120 \ +-realtime mlock=off \ +-smp 4,sockets=4,cores=1,threads=1 \ +-uuid a5efd8ed-fa6f-693c-2202-93183ec18b5e \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-win/monitor.sock,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot menu=on,strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device ahci,id=sata0,bus=pci.0,addr=0x4 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \ +-drive file=/opt/panafs/1374467833802939042/win.img,format=qcow2,if=none,id=drive-sata0-0-0 \ +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 \ +-drive file=/opt/panafs/13680547561012925528/cn_windows_10_consumer_edition_version_1803_updated_aug_2018_x64_dvd_2cf38490.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on \ +-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 \ +-drive file=/var/lib/libvirt/images/virtio-win-0.1.217.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ +-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1d:d8:7d,bus=pci.0,addr=0x3 \ +-netdev tap,fd=30,id=hostnet1 \ +-device e1000,netdev=hostnet1,id=net1,mac=52:54:00:09:bc:30,bus=pci.0,addr=0x9 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-win/org.qemu.guest_agent.0,server,nowait \ +-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +-device usb-tablet,id=input1,bus=usb.0,port=1 \ +-vnc 127.0.0.1:0 \ +-vga cirrus \ +-device vfio-pci,host=81:00.0,id=hostdev0,bus=pci.0,addr=0x7 \ +-device vfio-pci,host=81:00.1,id=hostdev1,bus=pci.0,addr=0x8 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-msg timestamp=on +2022-09-06 04:16:48.831+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/1 (label charserial0) +qemu: terminating on signal 15 from pid 15130 +2022-09-06 07:52:07.759+0000: shutting down, reason=destroyed + + + + +``` diff --git a/results/classifier/118/review/1204697 b/results/classifier/118/review/1204697 new file mode 100644 index 000000000..17561777e --- /dev/null +++ b/results/classifier/118/review/1204697 @@ -0,0 +1,191 @@ +user-level: 0.863 +graphic: 0.861 +PID: 0.859 +permissions: 0.844 +hypervisor: 0.824 +semantic: 0.824 +register: 0.808 +peripherals: 0.806 +KVM: 0.804 +virtual: 0.804 +device: 0.800 +performance: 0.795 +TCG: 0.768 +architecture: 0.764 +files: 0.759 +assembly: 0.751 +ppc: 0.750 +VMM: 0.750 +vnc: 0.733 +debug: 0.726 +risc-v: 0.710 +arm: 0.708 +boot: 0.673 +mistranslation: 0.633 +kernel: 0.604 +x86: 0.551 +socket: 0.539 +network: 0.491 +i386: 0.295 +-------------------- +KVM: 0.965 +kernel: 0.931 +virtual: 0.887 +hypervisor: 0.582 +user-level: 0.536 +boot: 0.429 +device: 0.282 +VMM: 0.177 +x86: 0.159 +debug: 0.129 +files: 0.097 +register: 0.093 +PID: 0.046 +performance: 0.042 +TCG: 0.028 +peripherals: 0.019 +socket: 0.014 +architecture: 0.013 +assembly: 0.012 +i386: 0.008 +network: 0.008 +semantic: 0.005 +graphic: 0.003 +risc-v: 0.002 +permissions: 0.001 +vnc: 0.001 +arm: 0.001 +ppc: 0.001 +mistranslation: 0.000 + +guest disk accesses lead to ATA errors + host vcpu0 unhandled wrmsr/rdmsr + +Hi. + +This is from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717724. + +Using Debian sid with 1.5.0-5 my Linux VMs (also Debian sid) are broken. When they boot I get gazillions of ATA errors inside the guest, as well as: +[ 242.479951] kvm [7790]: vcpu0 unhandled rdmsr: 0x345 +[ 242.483683] kvm [7790]: vcpu0 unhandled wrmsr: 0x680 data 0 +[ 242.483687] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c0 data 0 +[ 242.483689] kvm [7790]: vcpu0 unhandled wrmsr: 0x681 data 0 +[ 242.483691] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c1 data 0 +[ 242.483693] kvm [7790]: vcpu0 unhandled wrmsr: 0x682 data 0 +[ 242.483696] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c2 data 0 +[ 242.483698] kvm [7790]: vcpu0 unhandled wrmsr: 0x683 data 0 +[ 242.483700] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c3 data 0 +[ 242.483702] kvm [7790]: vcpu0 unhandled wrmsr: 0x684 data 0 +[ 242.483704] kvm [7790]: vcpu0 unhandled wrmsr: 0x6c4 data 0 +[ 242.988307] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8 +[ 242.988312] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7 +[ 242.988314] kvm [7790]: vcpu0 unhandled rdmsr: 0xce +[ 242.988316] kvm [7790]: vcpu0 unhandled rdmsr: 0xce +[ 242.988318] kvm [7790]: vcpu0 unhandled rdmsr: 0x1ad +[ 242.988320] kvm [7790]: vcpu0 unhandled rdmsr: 0xce +[ 242.988322] kvm [7790]: vcpu0 unhandled rdmsr: 0xe8 +[ 242.988324] kvm [7790]: vcpu0 unhandled rdmsr: 0xe7 +[ 242.988598] kvm [7790]: vcpu0 unhandled rdmsr: 0xce + +in the host. + +Please have a look at the Debian bug, for screenshots and more info. +The problem didn't occur in 1.5.0-4 and there were basically no changes inside the VM (i.e. no kernel upgrade or so). + +Thanks, +Chris. + +For the record, the difference between debian qemu 1.5.0-4 and 1.5.0-5 is the 1.5.1 patch - I applied it without actually changing the "upstream" version number. + + +Hi. + +Finally I was able to get it running with IDE instead of SATA. +That works,... fine... no ATA errors. + +As you already expected,.. I still get the: +[20424.793207] kvm [20947]: vcpu0 unhandled wrmsr: 0x6c1 data 0 +[20424.793211] kvm [20947]: vcpu0 unhandled wrmsr: 0x682 data 0 +[20424.793215] kvm [20947]: vcpu0 unhandled wrmsr: 0x6c2 data 0 +[20424.793218] kvm [20947]: vcpu0 unhandled wrmsr: 0x683 data 0 +[20424.793222] kvm [20947]: vcpu0 unhandled wrmsr: 0x6c3 data 0 +[20424.793226] kvm [20947]: vcpu0 unhandled wrmsr: 0x684 data 0 +[20424.793229] kvm [20947]: vcpu0 unhandled wrmsr: 0x6c4 data 0 +[20425.946617] kvm [20947]: vcpu0 unhandled rdmsr: 0xe8 +[20425.946623] kvm [20947]: vcpu0 unhandled rdmsr: 0xe7 +[20425.946625] kvm [20947]: vcpu0 unhandled rdmsr: 0xce +[20425.946628] kvm [20947]: vcpu0 unhandled rdmsr: 0xce + +So that seems to be unrelated... nevertheless.. I haven't seen these before with 1.5.0. + + +Anyway...I will try to get it running with virtio as well, as you suggested... but I have troubles to convince libvirt of using it. + + +btw: Might be unrealted... but with 1.5.1 and IDE now... when I do an update-initramfs -u inside the guest I gues these: +[ 276.130974] traps: ld-linux-x32.so[5642] general protection ip:f7788e8d sp:ffe12528 error:0 in ld-2.17.so[f7772000+21000] +[ 276.141129] traps: ld-linux-x32.so[5656] general protection ip:f77b8e8d sp:ff978458 error:0 in ld-2.17.so[f77a2000+21000] +[ 276.151444] traps: ld-linux-x32.so[5670] general protection ip:f7721e8d sp:ffd44cc8 error:0 in ld-2.17.so[f770b000+21000] +[ 276.207037] traps: ld-linux-x32.so[5714] general protection ip:f7770e8d sp:ff92cce8 error:0 in ld-2.17.so[f775a000+21000] +[ 276.278651] traps: ld-linux-x32.so[5775] general protection ip:f76fbe8d sp:ffe73048 error:0 in ld-2.17.so[f76e5000+21000] +[ 276.319277] traps: ld-linux-x32.so[5805] general protection ip:f76fee8d sp:fff486f8 error:0 in ld-2.17.so[f76e8000+21000] +[ 276.329552] traps: ld-linux-x32.so[5819] general protection ip:f77a8e8d sp:ffc9b448 error:0 in ld-2.17.so[f7792000+21000] +[ 276.338671] traps: ld-linux-x32.so[5833] general protection ip:f77bfe8d sp:ffe597b8 error:0 in ld-2.17.so[f77a9000+21000] +[ 276.347835] traps: ld-linux-x32.so[5847] general protection ip:f77b9e8d sp:ffcb1f08 error:0 in ld-2.17.so[f77a3000+21000] +[ 276.356548] traps: ld-linux-x32.so[5861] general protection ip:f77d1e8d sp:ffee16d8 error:0 in ld-2.17.so[f77bb000+21000] +[ 313.662052] do_general_protection: 24 callbacks suppressed +[ 313.662371] traps: ld-linux-x32.so[8926] general protection ip:f77e9e8d sp:ffa443a8 error:0 in ld-2.17.so[f77d3000+21000] +[ 313.670615] traps: ld-linux-x32.so[8940] general protection ip:f7796e8d sp:ff879cf8 error:0 in ld-2.17.so[f7780000+21000] +[ 313.677952] traps: ld-linux-x32.so[8954] general protection ip:f7791e8d sp:ffa25948 error:0 in ld-2.17.so[f777b000+21000] +[ 313.708061] traps: ld-linux-x32.so[8998] general protection ip:f7724e8d sp:ffe6b858 error:0 in ld-2.17.so[f770e000+21000] +[ 313.750866] traps: ld-linux-x32.so[9059] general protection ip:f77c7e8d sp:ff8a32a8 error:0 in ld-2.17.so[f77b1000+21000] +[ 313.771839] traps: ld-linux-x32.so[9089] general protection ip:f77b0e8d sp:ffdfa038 error:0 in ld-2.17.so[f779a000+21000] +[ 313.780747] traps: ld-linux-x32.so[9103] general protection ip:f777ae8d sp:ffc699a8 error:0 in ld-2.17.so[f7764000+21000] +[ 313.789250] traps: ld-linux-x32.so[9117] general protection ip:f778de8d sp:ffce6358 error:0 in ld-2.17.so[f7777000+21000] +[ 313.797782] traps: ld-linux-x32.so[9131] general protection ip:f7794e8d sp:ffcc8a38 error:0 in ld-2.17.so[f777e000+21000] +[ 313.806169] traps: ld-linux-x32.so[9145] general protection ip:f7703e8d sp:ff9e61a8 error:0 in ld-2.17.so[f76ed000+21000] + +Seems also kinda weird.... never seen that before in that context. + + +Cheers, +Chris. + +Also, when using SATA for the virtual disk,... it seems that it takes much longer till it get's to the point where it (the initrd) tries to mount root. + +Till that point I see no errors... but then, after some time hanging at the root mount... it starts with the ATA errors. + + +So, what changed so you were able to boot from IDE without errors? As far as I understand, your initial prob was I/O errors on IDE (virtual) drive, but now you can boot it without errors. Or was it always SATA not IDE? + +The rdmsr/wrmsr are unrelated, I already told you that, it is accessing optional CPU features which has nothing to do with disk access. + +The segfaults during mkinitrd are unrelated too _unless_ you're running it from "failing" virtual drive. If you run it from failing virtual drive, it is remotely possible to have errors due to some file not read properly due to errors, but even this is a very remote possibility. + +The time it takes to start mounting root is most likely also unrelated, it depends on the guest. + +It _looks_ like the whole prob is due to FLUSH CASHE command not working correctly with SATA and IDE, but you confused me here - I don't understand where you were and are getting errors and where you don't. + +Besides, you never answered to this: do you have enough free space in the host filesystem where your disk image(s) are located? + +Sorry for the confusion. +The initial problem was _always_ with SATA... I couldn't try IDE at first, as the guest initrd haven't had and the IDE drivers. + +Yesterday then, I tried IDE and it worked with that. + + +Sure, I just wanted to confirm that you were really right ;-) + + +Sorry I have missed the question about enough space before.. there is plenty of free host space left (133 GB). + +Having tried now with virtio as well: works + +So: +virtio, ide = OK +sata = broken + +The fix is in a62eaa26c1d6d48fbdc3ac1d32bd1314f5fdc8c9 "ahci: Fix FLUSH command", should be in 1.6 and 1.5.3. + +From a first test of the Debian package in experimental, I'd say that the issue has been fixed :) +Thanks a lot for all your help! + diff --git a/results/classifier/118/review/1212 b/results/classifier/118/review/1212 new file mode 100644 index 000000000..72b615704 --- /dev/null +++ b/results/classifier/118/review/1212 @@ -0,0 +1,69 @@ +semantic: 0.916 +device: 0.885 +PID: 0.881 +graphic: 0.865 +debug: 0.838 +network: 0.785 +vnc: 0.763 +socket: 0.711 +files: 0.687 +performance: 0.667 +ppc: 0.618 +boot: 0.532 +architecture: 0.465 +peripherals: 0.442 +TCG: 0.434 +permissions: 0.432 +i386: 0.347 +register: 0.343 +VMM: 0.319 +arm: 0.310 +x86: 0.286 +risc-v: 0.244 +kernel: 0.203 +assembly: 0.180 +hypervisor: 0.167 +user-level: 0.108 +virtual: 0.102 +mistranslation: 0.078 +KVM: 0.018 +-------------------- +debug: 0.988 +x86: 0.502 +TCG: 0.112 +files: 0.088 +virtual: 0.067 +kernel: 0.041 +i386: 0.025 +assembly: 0.021 +user-level: 0.016 +PID: 0.015 +register: 0.011 +hypervisor: 0.010 +ppc: 0.009 +semantic: 0.009 +graphic: 0.009 +risc-v: 0.007 +VMM: 0.006 +arm: 0.006 +performance: 0.005 +network: 0.003 +KVM: 0.002 +device: 0.002 +architecture: 0.001 +peripherals: 0.001 +boot: 0.001 +socket: 0.001 +vnc: 0.001 +permissions: 0.000 +mistranslation: 0.000 + +A NULL pointer dereference issue in elf2dmp +Description of problem: +SIGSEGV in get_pml4e for it didn't handle NULL result properly. +Steps to reproduce: +1.launch qemu and running "gab attach -p $QEMU_PID", run "gcore" inside gdb to generate coredump +2../elf2dmp ./core.111 ./out.dmp +3.get segemantation fault +Additional information: + diff --git a/results/classifier/118/review/1216368 b/results/classifier/118/review/1216368 new file mode 100644 index 000000000..e0471914b --- /dev/null +++ b/results/classifier/118/review/1216368 @@ -0,0 +1,99 @@ +mistranslation: 0.888 +semantic: 0.815 +graphic: 0.705 +device: 0.702 +socket: 0.666 +user-level: 0.620 +debug: 0.601 +register: 0.599 +ppc: 0.570 +files: 0.554 +performance: 0.550 +kernel: 0.545 +architecture: 0.526 +PID: 0.515 +vnc: 0.487 +boot: 0.449 +arm: 0.441 +assembly: 0.423 +virtual: 0.420 +risc-v: 0.417 +hypervisor: 0.416 +x86: 0.411 +network: 0.391 +i386: 0.387 +VMM: 0.375 +TCG: 0.368 +permissions: 0.365 +peripherals: 0.298 +KVM: 0.293 +-------------------- +virtual: 0.267 +x86: 0.099 +files: 0.047 +TCG: 0.045 +debug: 0.040 +semantic: 0.027 +hypervisor: 0.023 +user-level: 0.017 +i386: 0.008 +PID: 0.006 +register: 0.005 +VMM: 0.005 +performance: 0.005 +ppc: 0.004 +kernel: 0.003 +graphic: 0.003 +network: 0.003 +device: 0.003 +socket: 0.002 +arm: 0.002 +boot: 0.002 +risc-v: 0.002 +architecture: 0.001 +vnc: 0.001 +peripherals: 0.001 +KVM: 0.001 +assembly: 0.001 +mistranslation: 0.001 +permissions: 0.000 + +unsupported screen resolution crashes sdl-qemu + +if the (windows) guest sets a screen resolution that the SDL backend does not support, +qemu does an exit(1). +with this fix, the the resolution is still wrong (only part of the desktop is displayed), +but qemu keeps running and the guest can auto-revert the video mode: + +ui/sdl.c:do_sdl_resize() + SDL_Surface * tmp_screen; + tmp_screen = SDL_SetVideoMode(width, height, bpp, flags); + if (!tmp_screen) { +// fprintf(stderr, "Could not open SDL display (%dx%dx%d): %s\n", width, +// height, bpp, SDL_GetError()); +// exit(1); + } else { + real_screen = tmp_screen; + } + +Sorry, a little confusion what's the problem you want to solve? + +its in the first sentence. let me rephrase: the (windows) guest can select some screen resolution which SDL cannot +provide. what happens is that qemu quits without giving the quest a chance to shut down. thats like having a monitor +that crashes windows when it doesnt support the video mode. + +Yes, it is a bug. It should go back to the previous setting if the new screen resolution falied. +I will send a patch later. + +Thanks. + +Patch posted: + +http://patchwork.ozlabs.org/patch/270084/ + +this patch does solve the problem + +Patch has been included here a while ago already: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=898ae2846de4dcb1 +... so this ticket could now be marked as fixed. + diff --git a/results/classifier/118/review/1224414 b/results/classifier/118/review/1224414 new file mode 100644 index 000000000..c8259f19c --- /dev/null +++ b/results/classifier/118/review/1224414 @@ -0,0 +1,88 @@ +ppc: 0.877 +TCG: 0.875 +device: 0.854 +PID: 0.769 +graphic: 0.703 +socket: 0.648 +files: 0.627 +network: 0.621 +mistranslation: 0.606 +peripherals: 0.592 +vnc: 0.542 +permissions: 0.542 +semantic: 0.516 +arm: 0.496 +register: 0.477 +architecture: 0.464 +hypervisor: 0.433 +performance: 0.388 +kernel: 0.376 +x86: 0.376 +VMM: 0.350 +risc-v: 0.336 +i386: 0.333 +boot: 0.318 +assembly: 0.276 +KVM: 0.259 +user-level: 0.189 +virtual: 0.175 +debug: 0.127 +-------------------- +files: 0.580 +user-level: 0.087 +x86: 0.066 +TCG: 0.058 +VMM: 0.032 +network: 0.029 +hypervisor: 0.025 +arm: 0.017 +register: 0.016 +i386: 0.011 +debug: 0.008 +risc-v: 0.008 +KVM: 0.007 +PID: 0.006 +virtual: 0.006 +semantic: 0.006 +ppc: 0.006 +device: 0.005 +kernel: 0.004 +socket: 0.003 +peripherals: 0.002 +permissions: 0.001 +graphic: 0.001 +architecture: 0.001 +boot: 0.001 +assembly: 0.001 +vnc: 0.001 +performance: 0.001 +mistranslation: 0.000 + +dtc/.git file included in release tarball + +The release tarballs include the dtc/.git submodule file, causing when working git in some circumstances (e.g. doing git clean -fxd in a parent git repository): + +$ mkdir foo && cd foo +$ git init +$ echo yo >bar +$ curl http://wiki.qemu-project.org/download/qemu-1.6.0.tar.bz2 +$ tar xjf qemu-1.6.0.tar.bz2 +$ git clean -fxd +Removing bar +Removing qemu-1.6.0.tar.bz2 +Removing qemu-1.6.0/ +fatal: Not a git repository: qemu-1.6.0/pixman/../.git/modules/pixman + +Leaving the qemu-1.6.0 directory intact. + +So, my suggestion is, would it be possible to filter out the .git file from the release tarball when building a release? Thanks. + +Fixed upstream: + +commit 379e21c258d5faf0cd7c6f9208347726e14ae241 +Author: Cole Robinson <email address hidden> +Date: Fri Mar 14 12:49:13 2014 -0400 + + scripts/make-release: Don't distribute .git directories + + diff --git a/results/classifier/118/review/1239 b/results/classifier/118/review/1239 new file mode 100644 index 000000000..1a594956c --- /dev/null +++ b/results/classifier/118/review/1239 @@ -0,0 +1,96 @@ +user-level: 0.902 +graphic: 0.880 +mistranslation: 0.872 +performance: 0.851 +hypervisor: 0.845 +device: 0.844 +i386: 0.839 +KVM: 0.834 +ppc: 0.823 +VMM: 0.814 +vnc: 0.799 +kernel: 0.796 +x86: 0.788 +TCG: 0.787 +socket: 0.784 +register: 0.776 +network: 0.776 +PID: 0.770 +permissions: 0.762 +files: 0.753 +semantic: 0.745 +risc-v: 0.740 +peripherals: 0.735 +assembly: 0.735 +debug: 0.734 +architecture: 0.734 +boot: 0.712 +arm: 0.698 +virtual: 0.497 +-------------------- +hypervisor: 0.850 +user-level: 0.685 +TCG: 0.646 +debug: 0.561 +x86: 0.505 +virtual: 0.227 +register: 0.126 +files: 0.114 +i386: 0.103 +semantic: 0.081 +kernel: 0.079 +arm: 0.060 +device: 0.054 +VMM: 0.042 +ppc: 0.035 +PID: 0.035 +assembly: 0.024 +architecture: 0.024 +peripherals: 0.019 +risc-v: 0.017 +network: 0.017 +permissions: 0.015 +performance: 0.011 +boot: 0.010 +KVM: 0.010 +graphic: 0.006 +socket: 0.006 +vnc: 0.003 +mistranslation: 0.001 + +The help document of qemu-img misses some options +Description of problem: +The "--help" option of qemu-img misses the option "skip-broken-bitmaps" for convert , "image-opts" for bench, "object" for dd and "force-share" for measure. +Steps to reproduce: +1. For the option "skip-broken-bitmaps", the following code appears during option parsing for convert and modifies the skip_broken in qemu-img.c:2377-2379. + +``` + case OPTION_SKIP_BROKEN: + skip_broken = true; + break; +``` + +2. For the option "image-opts", the following code appears during option parsing for bench and modifies the image_opts in qemu-img.c:4511-4513. + +``` + case OPTION_IMAGE_OPTS: + image_opts = true; + break; +``` +3. For the option "object", the following code appears during option parsing for dd and calls the user_creatable_process_cmdline in qemu-img.c:4980-4982. + +``` + case OPTION_OBJECT: + user_creatable_process_cmdline(optarg); + break; +``` +4. For the option "force-share", the following code appears during option parsing for measure and modifies the force_share in qemu-img.c:5237-5239. +``` + case 'U': + force_share = true; + break; +``` +Additional information: +But they do not appear in the document provided by "--help". + +It may prevent users from using the relevant function. diff --git a/results/classifier/118/review/1248 b/results/classifier/118/review/1248 new file mode 100644 index 000000000..2cae34d79 --- /dev/null +++ b/results/classifier/118/review/1248 @@ -0,0 +1,71 @@ +mistranslation: 0.840 +graphic: 0.837 +architecture: 0.806 +assembly: 0.721 +device: 0.705 +performance: 0.641 +debug: 0.617 +semantic: 0.542 +permissions: 0.512 +socket: 0.500 +vnc: 0.496 +virtual: 0.492 +network: 0.472 +risc-v: 0.436 +ppc: 0.432 +boot: 0.417 +PID: 0.377 +files: 0.375 +user-level: 0.353 +TCG: 0.329 +VMM: 0.323 +kernel: 0.296 +register: 0.254 +i386: 0.219 +x86: 0.212 +KVM: 0.212 +arm: 0.165 +peripherals: 0.138 +hypervisor: 0.137 +-------------------- +virtual: 0.854 +assembly: 0.785 +debug: 0.195 +TCG: 0.163 +user-level: 0.090 +performance: 0.053 +files: 0.029 +register: 0.027 +device: 0.019 +semantic: 0.015 +peripherals: 0.014 +PID: 0.010 +hypervisor: 0.009 +VMM: 0.007 +network: 0.005 +architecture: 0.005 +kernel: 0.004 +graphic: 0.003 +KVM: 0.002 +socket: 0.002 +vnc: 0.001 +boot: 0.001 +risc-v: 0.001 +permissions: 0.001 +mistranslation: 0.001 +x86: 0.000 +ppc: 0.000 +arm: 0.000 +i386: 0.000 + +s390x: glibc widestring algorithms broken +Description of problem: +Several wide-string functions from glibc are broken und qemu user emulation. +Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. + +Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. +Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. +Steps to reproduce: +1. Compile the test program above +2. Run the program +3. Output is `0`, should be `1`. diff --git a/results/classifier/118/review/1249 b/results/classifier/118/review/1249 new file mode 100644 index 000000000..5acae6958 --- /dev/null +++ b/results/classifier/118/review/1249 @@ -0,0 +1,61 @@ +mistranslation: 0.996 +semantic: 0.691 +device: 0.662 +graphic: 0.613 +files: 0.264 +virtual: 0.200 +network: 0.163 +VMM: 0.157 +debug: 0.156 +architecture: 0.156 +PID: 0.130 +ppc: 0.123 +hypervisor: 0.109 +performance: 0.102 +boot: 0.097 +peripherals: 0.092 +user-level: 0.085 +register: 0.081 +vnc: 0.075 +arm: 0.075 +TCG: 0.071 +i386: 0.067 +kernel: 0.059 +KVM: 0.050 +permissions: 0.034 +socket: 0.024 +x86: 0.023 +assembly: 0.020 +risc-v: 0.012 +-------------------- +virtual: 0.925 +user-level: 0.413 +debug: 0.357 +hypervisor: 0.204 +PID: 0.028 +performance: 0.013 +files: 0.013 +x86: 0.013 +device: 0.008 +assembly: 0.006 +semantic: 0.006 +kernel: 0.005 +i386: 0.004 +VMM: 0.003 +peripherals: 0.003 +ppc: 0.003 +TCG: 0.002 +register: 0.002 +KVM: 0.002 +arm: 0.002 +boot: 0.001 +graphic: 0.001 +mistranslation: 0.001 +vnc: 0.000 +socket: 0.000 +architecture: 0.000 +permissions: 0.000 +network: 0.000 +risc-v: 0.000 + +qemu-edid Division By Zero -- by misuse of the option "-d" diff --git a/results/classifier/118/review/1254786 b/results/classifier/118/review/1254786 new file mode 100644 index 000000000..021abd187 --- /dev/null +++ b/results/classifier/118/review/1254786 @@ -0,0 +1,158 @@ +user-level: 0.882 +risc-v: 0.873 +semantic: 0.850 +permissions: 0.844 +PID: 0.840 +VMM: 0.835 +register: 0.834 +device: 0.831 +peripherals: 0.825 +architecture: 0.813 +TCG: 0.813 +ppc: 0.809 +arm: 0.803 +debug: 0.802 +vnc: 0.798 +performance: 0.783 +assembly: 0.775 +mistranslation: 0.770 +graphic: 0.767 +KVM: 0.765 +kernel: 0.753 +virtual: 0.749 +hypervisor: 0.742 +boot: 0.710 +x86: 0.709 +files: 0.692 +socket: 0.634 +network: 0.551 +i386: 0.502 +-------------------- +kernel: 0.862 +debug: 0.663 +virtual: 0.389 +PID: 0.247 +boot: 0.236 +hypervisor: 0.155 +architecture: 0.118 +TCG: 0.070 +register: 0.030 +ppc: 0.028 +assembly: 0.023 +user-level: 0.015 +performance: 0.013 +files: 0.009 +semantic: 0.009 +VMM: 0.005 +graphic: 0.004 +device: 0.004 +socket: 0.004 +x86: 0.003 +permissions: 0.001 +peripherals: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +vnc: 0.001 +KVM: 0.001 +network: 0.001 +arm: 0.001 +i386: 0.000 + +qemu-m68k-static: illegal instruction ebc0 during debootstrap second stage + +Host: Ubuntu Precise amd64 +Guest: Debian (ports) sid m68k + +$ sudo qemu-debootstrap --no-check-gpg --arch=m68k sid m68k http://ftp.debian-ports.org/debian +I: Running command: debootstrap --arch m68k --foreign --no-check-gpg sid m68k http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot m68k /debootstrap/debootstrap --second-stage +qemu: fatal: Illegal instruction: ebc0 @ f67e5662 +D0 = 6ffffef5 A0 = f67fbf58 F0 = 0000000000000000 ( 0) +D1 = 0000010a A1 = 00000000 F1 = 0000000000000000 ( 0) +D2 = 0000000f A2 = 00000000 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = f67e0000 F3 = 0000000000000000 ( 0) +D4 = 00000000 A4 = 00000000 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67fc000 F5 = 0000000000000000 ( 0) +D6 = 00000000 A6 = f6fff7cc F6 = 0000000000000000 ( 0) +D7 = 00000000 A7 = f6fff580 F7 = 0000000000000000 ( 0) +PC = f67e5662 SR = 0000 ----- FPRESULT = 0 +Aborted (core dumped) + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 16:08:26 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) + +Version: 1.6.0+dfsg-2ubuntu4 + +Still present in Trusty. + +Ken, is that really a bug in QEMU or is Debian expecting some Motorola 68k CPU rather than the ColdFire MCU QEMU emulates? + +ebc0 is a bitfield insn which the coldfire doesn't implement. + +Andreas. + +-- +Andreas Schwab, <email address hidden> +GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 +"And now for something completely different." + + +"Debian currently runs on the 68020, 68030, 68040 and 68060 processors" +http://www.debian.org/ports/m68k/ + +From 2006: +https://lists.debian.org/debian-devel-announce/2006/01/msg00005.html + +So I really don't know. :-/ + +Ken, + +this is known to currently *not* work. As Andreas has already indirectly explained, qemu does not provide full m68k emulation. + +Instead, it supports the reduced m68k instruction set of Motorola's ColdFire CPU only. +If you need a QEMU version with full m68k support, please have a look at Laurent Vivier's github repository [1]. + +You also shouldn't file bugs which are clearly upstream-related to the Ubuntu bugtracker. Ubuntu doesn't even support m68k but Debian does. Still, we also can't do anything about such bugs in Debian, these belong upstream. + +Adrian + +> [1] https://github.com/vivier/qemu-m68k + +Alright, I have created a page on the Debian Wiki which explains how to properly set up a chroot environment for sbuild/m68k on Debian [1]. + +With this set up, I was able to increase compile performance dramatically as compared to native m68k hardware or the Aranym Atari m68k emulator. + +Enjoy! + +Adrian + +> [1] https://wiki.debian.org/M68k/sbuildQEMU + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? There should now be support for "normal" 68k CPUs, too... + +0xebc0 is "bfexts" with register and is implemented since: + + ac815f46a3 target-m68k: Implement bitfield ops for registers + +Available since qemu v2.9.0 + diff --git a/results/classifier/118/review/1257 b/results/classifier/118/review/1257 new file mode 100644 index 000000000..e56f2752d --- /dev/null +++ b/results/classifier/118/review/1257 @@ -0,0 +1,63 @@ +mistranslation: 0.891 +semantic: 0.814 +device: 0.776 +architecture: 0.625 +socket: 0.558 +arm: 0.553 +performance: 0.531 +register: 0.458 +graphic: 0.383 +ppc: 0.377 +vnc: 0.376 +i386: 0.367 +risc-v: 0.359 +VMM: 0.297 +assembly: 0.287 +boot: 0.280 +x86: 0.271 +files: 0.250 +TCG: 0.248 +PID: 0.237 +debug: 0.224 +permissions: 0.202 +network: 0.177 +user-level: 0.177 +peripherals: 0.142 +virtual: 0.108 +KVM: 0.100 +hypervisor: 0.055 +kernel: 0.040 +-------------------- +virtual: 0.971 +hypervisor: 0.523 +debug: 0.165 +performance: 0.078 +user-level: 0.069 +TCG: 0.064 +device: 0.063 +semantic: 0.034 +x86: 0.024 +kernel: 0.021 +PID: 0.017 +files: 0.017 +network: 0.014 +socket: 0.014 +assembly: 0.013 +architecture: 0.012 +register: 0.009 +permissions: 0.007 +peripherals: 0.005 +arm: 0.005 +i386: 0.003 +ppc: 0.003 +VMM: 0.003 +graphic: 0.002 +KVM: 0.001 +risc-v: 0.001 +boot: 0.001 +vnc: 0.000 +mistranslation: 0.000 + +Windows guest agent shutdown requires user response to complete +Additional information: +The shutdown operation triggered by the Windows Guest Agent should prevent the system from waiting for a user response concerning unsaved work of open desktop applications. Instead, applications and services should be closed as gracefully as possible automatically, in advance of the power down event on the emulated hardware. diff --git a/results/classifier/118/review/1260555 b/results/classifier/118/review/1260555 new file mode 100644 index 000000000..e29942da9 --- /dev/null +++ b/results/classifier/118/review/1260555 @@ -0,0 +1,284 @@ +user-level: 0.866 +register: 0.855 +permissions: 0.848 +risc-v: 0.846 +mistranslation: 0.843 +assembly: 0.821 +virtual: 0.821 +graphic: 0.818 +ppc: 0.818 +semantic: 0.818 +PID: 0.815 +debug: 0.814 +device: 0.810 +architecture: 0.808 +arm: 0.802 +performance: 0.797 +boot: 0.794 +VMM: 0.790 +KVM: 0.790 +hypervisor: 0.789 +TCG: 0.788 +socket: 0.786 +files: 0.779 +vnc: 0.772 +network: 0.772 +peripherals: 0.756 +kernel: 0.747 +x86: 0.709 +i386: 0.504 +-------------------- +virtual: 0.851 +graphic: 0.321 +boot: 0.124 +user-level: 0.093 +files: 0.091 +TCG: 0.081 +debug: 0.076 +hypervisor: 0.046 +register: 0.039 +device: 0.037 +VMM: 0.034 +PID: 0.031 +socket: 0.015 +semantic: 0.015 +kernel: 0.013 +risc-v: 0.013 +vnc: 0.013 +network: 0.013 +peripherals: 0.010 +architecture: 0.009 +KVM: 0.007 +performance: 0.004 +assembly: 0.003 +i386: 0.003 +ppc: 0.003 +permissions: 0.003 +mistranslation: 0.002 +x86: 0.001 +arm: 0.001 + +SS-5 emulation doesn't work with Sun boot ROM + + +The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa. Screenshot attached. Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu. + +The following is my Qemu command: + +sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \ + -g 1024x768x24 \ + -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \ + -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \ + -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \ + -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \ + -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown + +Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS X, and config.log is not helpful to figure out why, but this is another issue. + + + +On 13 December 2013 01:04, Peter Bartoli <email address hidden> wrote: +> Public bug reported: +> +> +> The 32-bit SPARC emulator's TCX emulation seems to work with +> OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa + +This is actually two separate issues. + +(1) This SS-5 ROM doesn't boot on QEMU. You can see this if +you try it on a Linux host : the display stays black. + +(2) The Cocoa UI frontend doesn't black the screen on startup +(or on resize) the way the SDL frontend does, so if the guest +hasn't tried to display anything to the screen post-resize you +get the old garbage of the window decoration displayed. + +We should probably fix (2), though it's only a cosmetic issue +and you won't even see it if you have a functioning guest. +I expect you care more about (1) and you'll do better with a +bug report that's clear that it's a generic SPARC guest issue. + +thanks +-- PMM + + + +On Dec 23, 2013, at 3:50 PM, Peter Maydell <email address hidden> wrote: +> On 13 December 2013 01:04, Peter Bartoli <email address hidden> wrote: +>> Public bug reported: +>> +>> +>> The 32-bit SPARC emulator's TCX emulation seems to work with +>> OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa +> +> This is actually two separate issues. +> +> (1) This SS-5 ROM doesn't boot on QEMU. You can see this if +> you try it on a Linux host : the display stays black. +> +> (2) The Cocoa UI frontend doesn't black the screen on startup +> (or on resize) the way the SDL frontend does, so if the guest +> hasn't tried to display anything to the screen post-resize you +> get the old garbage of the window decoration displayed. +> +> We should probably fix (2), though it's only a cosmetic issue +> and you won't even see it if you have a functioning guest. +> I expect you care more about (1) and you'll do better with a +> bug report that's clear that it's a generic SPARC guest issue. +> +> thanks +> -- PMM +> +> +> ** Summary changed: +> +> - qemu-system-sparc UI doesn't work with Cocoa and Sun ROM +> + SS-5 emulation doesn't work with Sun boot ROM +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1260555 +> +> Title: +> SS-5 emulation doesn't work with Sun boot ROM +> +> Status in QEMU: +> New +> +> Bug description: +> +> The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa. Screenshot attached. Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu. +> +> The following is my Qemu command: +> +> sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \ +> -g 1024x768x24 \ +> -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \ +> -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \ +> -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \ +> -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \ +> -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown +> +> Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS +> X, and config.log is not helpful to figure out why, but this is +> another issue. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1260555/+subscriptions + + +Please accept my apology if I'm missing something, but I don't understand what you mean by #1; this ROM actually *does* boot on QEMU. Just not without the "-nographic" option. + +-peter + +Ah, I hadn't tried -nographic. However, my general point still stands: whether you run this on MacOS or Linux, you get the same behaviour. + +Experimenting I see that all that's happening here is that '-nographic' gives you a serial console, which the ROM outputs to. You can also specify that with '-serial stdio' instead, in which case you get ROM output to the terminal and a blank display. So the two parts of this bug are: + +(1) no graphics output with this ROM +(2) cocoa UI doesn't properly show a black window if there is no graphics output from the guest + +I have some patches which fix (2). + +(If you have a bug which is a general QEMU emulation bug, it's a really bad idea to describe it using phrases like"on Cocoa" or "on MacOS" which suggest that it's a MacOS host specific bug, because this will mean that it will get ignored by almost all the developers, most of whom use Linux. If you have access to a suitable machine it's definitely helpful to try reproducing on a Linux box before reporting a bug. If you've only been able to test on Mac you should say so somewhere in the bug report, though.) + + +These two patches for the Cocoa UI: + http://patchwork.ozlabs.org/patch/304879/ + http://patchwork.ozlabs.org/patch/304878/ + +fix issue (2) so Cocoa now also displays a plain black window for this guest, like the SDL frontend does on Linux. + + +On 23/12/13 23:50, Peter Maydell wrote: + +>> The 32-bit SPARC emulator's TCX emulation seems to work with +>> OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa +> +> This is actually two separate issues. +> +> (1) This SS-5 ROM doesn't boot on QEMU. You can see this if +> you try it on a Linux host : the display stays black. + +FWIW this should now work if you replace the QEMU,tcx.bin file from QEMU +1.7/master with the one uploaded to this bug: +https://bugs.launchpad.net/qemu/+bug/1262081. + +As OpenBIOS doesn't have its own git infrastructure, I need to get the +git.qemu.org git-svn mirror updated by Anthony in order to send a pull +request with updated binaries (Blue Swirl set up OpenBIOS to build as a +git submodule from the git.qemu.org mirror). I'll try and get them +updated as soon as I can. + + +ATB, + +Mark. + + + +Thanks, Peter ... will do, definitely have Linux and can use it to test in the future before reporting other bugs. That said, I think you can close this one. + +-peter + +On Dec 23, 2013, at 6:43 PM, Peter Maydell <email address hidden> wrote: +> Ah, I hadn't tried -nographic. However, my general point still stands: +> whether you run this on MacOS or Linux, you get the same behaviour. +> +> Experimenting I see that all that's happening here is that '-nographic' +> gives you a serial console, which the ROM outputs to. You can also +> specify that with '-serial stdio' instead, in which case you get ROM +> output to the terminal and a blank display. So the two parts of this bug +> are: +> +> (1) no graphics output with this ROM +> (2) cocoa UI doesn't properly show a black window if there is no graphics output from the guest +> +> I have some patches which fix (2). +> +> (If you have a bug which is a general QEMU emulation bug, it's a really +> bad idea to describe it using phrases like"on Cocoa" or "on MacOS" which +> suggest that it's a MacOS host specific bug, because this will mean that +> it will get ignored by almost all the developers, most of whom use +> Linux. If you have access to a suitable machine it's definitely helpful +> to try reproducing on a Linux box before reporting a bug. If you've only +> been able to test on Mac you should say so somewhere in the bug report, +> though.) +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1260555 +> +> Title: +> SS-5 emulation doesn't work with Sun boot ROM +> +> Status in QEMU: +> New +> +> Bug description: +> +> The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa. Screenshot attached. Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu. +> +> The following is my Qemu command: +> +> sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \ +> -g 1024x768x24 \ +> -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \ +> -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \ +> -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \ +> -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \ +> -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown +> +> Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS +> X, and config.log is not helpful to figure out why, but this is +> another issue. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1260555/+subscriptions + + + + diff --git a/results/classifier/118/review/1261 b/results/classifier/118/review/1261 new file mode 100644 index 000000000..c3327aac7 --- /dev/null +++ b/results/classifier/118/review/1261 @@ -0,0 +1,85 @@ +architecture: 0.977 +graphic: 0.797 +files: 0.784 +device: 0.741 +user-level: 0.658 +semantic: 0.622 +mistranslation: 0.592 +performance: 0.497 +PID: 0.469 +network: 0.462 +debug: 0.376 +socket: 0.376 +peripherals: 0.366 +ppc: 0.343 +vnc: 0.221 +TCG: 0.217 +virtual: 0.212 +arm: 0.195 +VMM: 0.189 +hypervisor: 0.184 +register: 0.171 +boot: 0.127 +permissions: 0.125 +kernel: 0.108 +risc-v: 0.092 +KVM: 0.063 +x86: 0.052 +assembly: 0.046 +i386: 0.030 +-------------------- +debug: 0.362 +user-level: 0.325 +architecture: 0.249 +virtual: 0.224 +hypervisor: 0.072 +kernel: 0.067 +TCG: 0.060 +register: 0.022 +files: 0.018 +PID: 0.015 +boot: 0.011 +assembly: 0.007 +semantic: 0.007 +device: 0.006 +performance: 0.005 +VMM: 0.003 +peripherals: 0.003 +network: 0.002 +socket: 0.002 +graphic: 0.001 +permissions: 0.001 +risc-v: 0.001 +arm: 0.001 +KVM: 0.001 +mistranslation: 0.001 +vnc: 0.001 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-user syscall 439 (faccessat2) not implemented - loongarch64 +Description of problem: +On LoongArch64 architecture faccessat syscall is missing and only faccessat2 is present, but it is not handled in linux-user/syscall +Steps to reproduce: +1. Launch a simple bash test script (call it test.sh): if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi +2. The result is "ERROR" even if the file "test.sh" exists and it is readeable +3. The correct result should be "OK" +Additional information: +test.sh: + ``` + if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi + ``` +qemu-loongarch -strace log: + ``` +[...] +12579 statx(255,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x0000004000802a50) = 0 +12579 lseek(255,0,SEEK_CUR) = 0 +12579 read(255,0x2016d490,56) = 56 +12579 Unknown syscall 439 +12579 write(1,0x20172010,6) = 6 +12579 read(255,0x2016d490,56) = 0 +12579 rt_sigprocmask(SIG_BLOCK,0x0000004000802b60,0x0000004000802be0) = 0 +12579 rt_sigprocmask(SIG_SETMASK,0x0000004000802be0,NULL) = 0 +12579 exit_group(0) + ``` diff --git a/results/classifier/118/review/1267 b/results/classifier/118/review/1267 new file mode 100644 index 000000000..92a2ed265 --- /dev/null +++ b/results/classifier/118/review/1267 @@ -0,0 +1,153 @@ +user-level: 0.843 +ppc: 0.822 +graphic: 0.821 +risc-v: 0.786 +TCG: 0.784 +vnc: 0.771 +device: 0.757 +permissions: 0.756 +KVM: 0.755 +performance: 0.750 +architecture: 0.747 +arm: 0.743 +register: 0.733 +debug: 0.723 +i386: 0.704 +VMM: 0.695 +PID: 0.694 +semantic: 0.691 +assembly: 0.688 +socket: 0.682 +virtual: 0.680 +hypervisor: 0.647 +boot: 0.645 +peripherals: 0.643 +x86: 0.638 +kernel: 0.624 +network: 0.606 +files: 0.593 +mistranslation: 0.587 +-------------------- +i386: 0.998 +debug: 0.919 +x86: 0.827 +user-level: 0.722 +assembly: 0.573 +hypervisor: 0.545 +virtual: 0.236 +files: 0.140 +PID: 0.116 +kernel: 0.032 +register: 0.024 +TCG: 0.018 +architecture: 0.015 +semantic: 0.012 +performance: 0.007 +boot: 0.004 +device: 0.003 +VMM: 0.002 +graphic: 0.002 +network: 0.001 +ppc: 0.001 +KVM: 0.001 +socket: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +permissions: 0.001 +vnc: 0.000 +risc-v: 0.000 +arm: 0.000 + +qemu-i386 missing VDSO +Description of problem: +Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue. +I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping` + +Interestingly, qemu-x86_64 and qemu-arm appear to work just fine. + +Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct: + +``` +~/src/qemu/build$ /bin/lldb ./qemu-i386 +(lldb) target create "./qemu-i386" +Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64). +(lldb) run /home/ayke/src/tinygo/tinygo/test +Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64) +Process 97986 stopped +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 +libc.so.6`__sigsuspend: +-> 0xfffff78fb9fc <+92>: svc #0 + 0xfffff78fba00 <+96>: cmn x0, #0x1, lsl #12 ; =0x1000 + 0xfffff78fba04 <+100>: b.hi 0xfffff78fba3c ; <+156> + 0xfffff78fba08 <+104>: mov w19, w0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 + frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5 + frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13 + frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13 + frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9 + frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5 + frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160 + frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81 +(lldb) ^D +``` + +I got a better (but still not great) backtrace in Qemu 7.0.0: + +``` +~/src/tinygo/tinygo$ /bin/lldb qemu-i386 +(lldb) target create "qemu-i386" +Current executable set to 'qemu-i386' (aarch64). +(lldb) run test +Process 98106 launched: '/usr/bin/qemu-i386' (aarch64) +Process 98106 stopped +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 +qemu-i386`cpu_ldub_code: +-> 0xaaaaaac4b564 <+32>: ldrb w0, [x0, w1, uxtw] + 0xaaaaaac4b568 <+36>: str xzr, [x2] + 0xaaaaaac4b56c <+40>: ret + +qemu-i386`cpu_lduw_code: + 0xaaaaaac4b570 <+0>: mrs x2, TPIDR_EL0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 + frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72 + frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144 + frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24 + frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400 + frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72 + frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364 + frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480 + frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208 + frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020 + frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160 + frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48 +(lldb) ^D +``` + +And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable: + +``` +#0 0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170 +#1 0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#2 translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#3 x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916 +#4 0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506 +#5 0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569 +#6 0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>) + at ../../accel/tcg/translator.c:103 +#7 0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512) + at ../../target/i386/translate.c:8631 +#8 0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, + cflags@entry=0) at ../../accel/tcg/translate-all.c:1744 +#9 0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414 +#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770 +#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207 +#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882 +``` diff --git a/results/classifier/118/review/1267520 b/results/classifier/118/review/1267520 new file mode 100644 index 000000000..9c24775e7 --- /dev/null +++ b/results/classifier/118/review/1267520 @@ -0,0 +1,90 @@ +architecture: 0.877 +kernel: 0.859 +virtual: 0.856 +user-level: 0.822 +device: 0.792 +graphic: 0.775 +ppc: 0.770 +boot: 0.764 +register: 0.725 +KVM: 0.715 +files: 0.698 +i386: 0.693 +semantic: 0.690 +permissions: 0.683 +x86: 0.676 +performance: 0.674 +peripherals: 0.652 +mistranslation: 0.651 +socket: 0.643 +network: 0.620 +hypervisor: 0.607 +vnc: 0.600 +risc-v: 0.521 +PID: 0.499 +VMM: 0.499 +debug: 0.490 +arm: 0.477 +TCG: 0.446 +assembly: 0.329 +-------------------- +i386: 0.928 +virtual: 0.910 +x86: 0.848 +user-level: 0.127 +kernel: 0.123 +hypervisor: 0.072 +TCG: 0.030 +files: 0.030 +debug: 0.028 +register: 0.020 +PID: 0.017 +boot: 0.013 +VMM: 0.007 +network: 0.006 +socket: 0.005 +device: 0.004 +semantic: 0.004 +performance: 0.003 +vnc: 0.003 +KVM: 0.002 +risc-v: 0.002 +architecture: 0.002 +ppc: 0.002 +assembly: 0.001 +permissions: 0.001 +peripherals: 0.001 +graphic: 0.001 +mistranslation: 0.000 +arm: 0.000 + +Keyboard input not working when the "-k en-us" argument is specified. + +This bug occurs on qemu compiled with i386_softmmu and x86-64_softmmu on linux kernel 3.5.0. +Whenever I run qemu (both i386 and x86_64) to use the en-us language (even though it is the default), I get "Warning: no scancode found for keysym X" (X is an integer). +In the disk image I need qemu to run, I had a shell set up. The shell doesn't register keyboard input when the '-k en-us' command line argument is set when running qemu. I did not have this problem with earlier versions of qemu. + +I think I stumbled on this bug. I was using packer to generate qemu-based virtual machines, and identical configurations would fail (complaining about invalid keymaps when keystrokes were sent) depending on where the current directory was. It doesn't work if qemu is run from a directory containing a directory named "common". + +Guessing this is related to qemu_find_file, maybe https://github.com/qemu/qemu/commit/31783203c3b74c11015b20194d57dada559940cf#diff-48a342a3d278d5bdcc69db8f9758dcd6 . + +Yes, that's exactly the issue. If you run qemu in a directory with a file or subdir called 'common' then the keymap won't load. + +I can confirm that this issue is still present with: +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.6) +Kernel: 4.4.0-53-generic + +I am using Packer and the QEMU builder and only the \ key was working in a Windows Guest. I had created folder called "common" to host all the Windows Powershell scripts and this is causing the issue. + +I confirm this too: Qemu 2.6.1. + +I have tried to install Fedora with kickstart file through Packer with `"boot_command": [ "<tab>text ks=http://{{.HTTPIP}}:{{.HTTPPort}}/ks.cfg<enter>"]`. But no symbol from `["<tab>", " ", "[:alpha:]"]` were printed. Only `["=", ":", "/", "."]` could be seen if I manually press "<tab>". + +I think this is likely fixed with QEMU 4.0 by this commit here: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=26b1cbf8b65b3b55c3f + +Could you please try again with QEMU 4.0-rc4 (or the final 4.0 release next week)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1269606 b/results/classifier/118/review/1269606 new file mode 100644 index 000000000..36db847ea --- /dev/null +++ b/results/classifier/118/review/1269606 @@ -0,0 +1,190 @@ +user-level: 0.927 +risc-v: 0.926 +permissions: 0.904 +assembly: 0.895 +register: 0.884 +ppc: 0.882 +mistranslation: 0.882 +architecture: 0.875 +semantic: 0.867 +performance: 0.864 +debug: 0.862 +arm: 0.862 +virtual: 0.861 +files: 0.861 +TCG: 0.858 +peripherals: 0.858 +device: 0.856 +graphic: 0.849 +KVM: 0.838 +x86: 0.821 +VMM: 0.817 +PID: 0.800 +network: 0.797 +socket: 0.796 +hypervisor: 0.796 +kernel: 0.781 +vnc: 0.751 +boot: 0.747 +i386: 0.708 +-------------------- +x86: 0.876 +network: 0.620 +user-level: 0.494 +virtual: 0.493 +files: 0.060 +hypervisor: 0.060 +PID: 0.040 +debug: 0.015 +register: 0.014 +device: 0.012 +boot: 0.009 +socket: 0.009 +semantic: 0.006 +ppc: 0.006 +TCG: 0.005 +kernel: 0.004 +performance: 0.003 +risc-v: 0.003 +architecture: 0.003 +i386: 0.003 +permissions: 0.002 +assembly: 0.002 +peripherals: 0.002 +VMM: 0.002 +graphic: 0.002 +arm: 0.002 +KVM: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +curl driver (http) always says "No such file or directory" + +I have a remote server, on which an http disk image definitely exists. However the qemu curl block driver cannot open it. It always gives the bogus error: + +CURL: Error opening file: Connection time-out +qemu-system-x86_64: -drive file=http://onuma/scratch/cirros-0.3.1-x86_64-disk.img,snapshot=on,cache=writeback,id=hd0,if=none: could not open disk image http://onuma/scratch/cirros-0.3.1-x86_64-disk.img: Could not open backing file: Could not open 'http://onuma/scratch/cirros-0.3.1-x86_64-disk.img': No such file or directory + +On the server, I can see from the logs that qemu/curl is opening it: + +192.168.0.175 - - [15/Jan/2014:21:25:37 +0000] "HEAD /scratch/cirros-0.3.1-x86_64-disk.img HTTP/1.1" 200 - "-" "-" +192.168.0.175 - - [15/Jan/2014:21:25:37 +0000] "GET /scratch/cirros-0.3.1-x86_64-disk.img HTTP/1.1" 206 264192 "-" "-" + +I am using qemu & curl from git today. + +curl: curl-7_34_0-177-gc7a76bb +qemu: for-anthony-839-g1cf892c + +Here is the full command I am using: + +http_proxy= \ +LD_LIBRARY_PATH=/home/rjones/d/curl/lib/.libs \ +LIBGUESTFS_BACKEND=direct \ +LIBGUESTFS_HV=/home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \ +guestfish -v --ro -a http://onuma/scratch/cirros-0.3.1-x86_64-disk.img run + +The full output (includes qemu command itself) is: + +libguestfs: launch: program=guestfish +libguestfs: launch: version=1.25.20fedora=21,release=1.fc21,libvirt +libguestfs: launch: backend registered: unix +libguestfs: launch: backend registered: uml +libguestfs: launch: backend registered: libvirt +libguestfs: launch: backend registered: direct +libguestfs: launch: backend=direct +libguestfs: launch: tmpdir=/tmp/libguestfsoQctgE +libguestfs: launch: umask=0002 +libguestfs: launch: euid=1000 +libguestfs: command: run: /usr/bin/supermin-helper +libguestfs: command: run: \ --verbose +libguestfs: command: run: \ -f checksum +libguestfs: command: run: \ --host-cpu x86_64 +libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d +supermin helper [00000ms] whitelist = (not specified) +supermin helper [00000ms] host_cpu = x86_64 +supermin helper [00000ms] dtb_wildcard = (not specified) +supermin helper [00000ms] inputs: +supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d +supermin helper [00000ms] outputs: +supermin helper [00000ms] kernel = (none) +supermin helper [00000ms] dtb = (none) +supermin helper [00000ms] initrd = (none) +supermin helper [00000ms] appliance = (none) +checking modpath /lib/modules/3.12.5-302.fc20.x86_64 is a directory +checking modpath /lib/modules/3.11.9-200.fc19.x86_64 is a directory +checking modpath /lib/modules/3.11.10-200.fc19.x86_64 is a directory +checking modpath /lib/modules/3.11.4-201.fc19.x86_64 is a directory +picked kernel vmlinuz-3.12.5-302.fc20.x86_64 +supermin helper [00000ms] finished creating kernel +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/base.img.gz +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img.gz +supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles +supermin helper [00041ms] visiting /usr/lib64/guestfs/supermin.d/init.img +supermin helper [00041ms] visiting /usr/lib64/guestfs/supermin.d/udev-rules.img +supermin helper [00041ms] adding kernel modules +supermin helper [00064ms] finished creating appliance +libguestfs: checksum of existing appliance: 2017df18eaeee7c45b87139c9bd80be2216d655a1513322c47f58a7a3668cd1f +libguestfs: [00066ms] begin testing qemu features +libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 +libguestfs: command: run: \ -display none +libguestfs: command: run: \ -help +libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 +libguestfs: command: run: \ -display none +libguestfs: command: run: \ -version +libguestfs: qemu version 1.7 +libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 +libguestfs: command: run: \ -display none +libguestfs: command: run: \ -machine accel=kvm:tcg +libguestfs: command: run: \ -device ? +libguestfs: [00127ms] finished testing qemu features +[00128ms] /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \ + -global virtio-blk-pci.scsi=off \ + -nodefconfig \ + -enable-fips \ + -nodefaults \ + -display none \ + -machine accel=kvm:tcg \ + -cpu host,+kvmclock \ + -m 500 \ + -no-reboot \ + -no-hpet \ + -kernel /var/tmp/.guestfs-1000/kernel.19645 \ + -initrd /var/tmp/.guestfs-1000/initrd.19645 \ + -device virtio-scsi-pci,id=scsi \ + -drive file=http://onuma/scratch/cirros-0.3.1-x86_64-disk.img,snapshot=on,cache=writeback,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ + -drive file=/var/tmp/.guestfs-1000/root.19645,snapshot=on,id=appliance,cache=unsafe,if=none \ + -device scsi-hd,drive=appliance \ + -device virtio-serial-pci \ + -serial stdio \ + -device sga \ + -chardev socket,path=/tmp/libguestfsoQctgE/guestfsd.sock,id=channel0 \ + -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ + -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color' +CURL: Error opening file: Connection time-out +qemu-system-x86_64: -drive file=http://onuma/scratch/cirros-0.3.1-x86_64-disk.img,snapshot=on,cache=writeback,id=hd0,if=none: could not open disk image http://onuma/scratch/cirros-0.3.1-x86_64-disk.img: Could not open image: Invalid argument +libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages +libguestfs: child_cleanup: 0x7f07bf6599b0: child process died +libguestfs: sending SIGTERM to process 19654 +libguestfs: error: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 exited with error status 1, see debug messages above +libguestfs: error: guestfs_launch failed, see earlier error messages +libguestfs: closing guestfs handle 0x7f07bf6599b0 (state 0) +libguestfs: command: run: rm +libguestfs: command: run: \ -rf /tmp/libguestfsoQctgE + +Turns out this is because of using "snapshot=on". + +Simple reproducer: + +./x86_64-softmmu/qemu-system-x86_64 -drive 'file=http://127.0.0.1/~rjones/cirros-0.3.1-x86_64-disk.img,if=virtio,snapshot=on' + + +I restored the original description. Please report a new bug. + +This seems to be working now: + +$ qemu-system-x86_64 -drive 'file=http://download.fedoraproject.org/pub/fedora-secondary/releases/29/Server/i386/iso/Fedora-Server-netinst-i386-29-1.2.iso,if=virtio,snapshot=on' + +... boots from the ISO image, without error message. So I assume this has been fixed, and I am closing this bug now. If there is anything left to do, feel free to open it again. + diff --git a/results/classifier/118/review/1276879 b/results/classifier/118/review/1276879 new file mode 100644 index 000000000..c1781a9bc --- /dev/null +++ b/results/classifier/118/review/1276879 @@ -0,0 +1,191 @@ +mistranslation: 0.821 +permissions: 0.777 +semantic: 0.771 +TCG: 0.764 +ppc: 0.755 +risc-v: 0.752 +debug: 0.750 +x86: 0.747 +assembly: 0.738 +virtual: 0.731 +user-level: 0.728 +device: 0.723 +graphic: 0.721 +PID: 0.717 +architecture: 0.701 +performance: 0.697 +KVM: 0.696 +register: 0.695 +arm: 0.694 +peripherals: 0.685 +kernel: 0.664 +vnc: 0.664 +hypervisor: 0.658 +VMM: 0.620 +network: 0.605 +boot: 0.599 +socket: 0.582 +files: 0.538 +i386: 0.499 +-------------------- +user-level: 0.395 +debug: 0.346 +virtual: 0.061 +x86: 0.053 +kernel: 0.024 +files: 0.022 +TCG: 0.019 +device: 0.019 +PID: 0.016 +i386: 0.013 +performance: 0.009 +assembly: 0.009 +register: 0.006 +VMM: 0.005 +architecture: 0.005 +network: 0.005 +risc-v: 0.004 +vnc: 0.003 +semantic: 0.003 +socket: 0.003 +hypervisor: 0.003 +peripherals: 0.002 +boot: 0.002 +graphic: 0.002 +arm: 0.002 +ppc: 0.002 +permissions: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +lots of dma command 10, 14 not supported + +Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. +In the terminal that started QEMU, there are a lot of + dma: command 10 not supported +and + dma: command 14 not supported +messages. When the installation of NeXTSTEP gets to +'preparing disk for nextstep installation', there are a lot +of messages that ATA command c5 failed and other info. +The result is a failed installation. + +Is this a bug in QEMU? Is there a workaround, e.g. by +disabling DMA altogether? + +thank you + +Getting the same result in QEMU 1.6.2. NeXT setup is reporting +'interrupt timeout, cmd: 0xc5', ATA command c5 failed, +resetting drives. +This repeats until it gives up. + + +On 02/06/14 02:14, tyler knosis wrote: +> Public bug reported: +> +> Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0. +> In the terminal that started QEMU, there are a lot of +> dma: command 10 not supported +> and +> dma: command 14 not supported +> messages. + +These correspond to + + CMD_CYCLIC_PRIORITY + +and + + CMD_CYCLIC_PRIORITY | CMD_BLOCK_CONTROLLER + +in write_cont() [hw/dma/i8257.c]. They are not supported (see +CMD_NOT_SUPPORTED in the same file). + +> When the installation of NeXTSTEP gets to +> 'preparing disk for nextstep installation', there are a lot +> of messages that ATA command c5 failed and other info. +> The result is a failed installation. + +0xC5 is WIN_MULTWRITE ("write sectors using multiple mode"), and it +seems to hook into DMA. + +> Is this a bug in QEMU? + +Probably not, it's more likely "incomplete" DMA emulation ("lack of +support"). + +> Is there a workaround, e.g. by +> disabling DMA altogether? + +It's worth a try I guess, if you can figure out a way how to do that. +FWIW, ide_identify() appears to report unconditional support for: +- single word dma0-2 +- mdma0-2 +- udma5 + +(I have no clue about IDE or DMA btw.) + +Laszlo + + +p.s. I tried Bochs 2.6.2, and it is not stuck at the same place. Did qemu take the bochs bios +and change anything regarding the IDE drives? + + +Successfully installed NextStep in bochs, but not qemu. + +Having same problem with OpenStep 4.2 in qemu. + + +http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg00889.html + +So, Zoltan pointed to two patches. I applied the first (v8-06-10-i8259-fix.....), +but the second patches a file that is not in version 1.7.0. + +With the one patch, I am now able to get past the step where it crapped out +before. The dma messages are still there, but it seems that they can be ignored. +NextStep can now install its basic system onto a file. + +Thank you for the help so far. + +Now, I get to the point when NeXTStep want me to click on something to configure +the new system, but QEMU is not grabbing the mouse. After this step, it will install +the remainder of the system + apps. + +I have a USB mouse on a x86_64 linux machine, and QEMU 1.7.0. This is the +command line I used: +qemu-system-x86_64 -hda x.img -fda f.img -cdrom cd.img + +I have tried ctl-alt (both sides of the keyboard) to no avail. + + +The other patch is for KVM. Here's a way to build a patched kvm module (I did not test it): +http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_0_kvm_kmod_build + +A click in the window should be enough to grab the mouse. If it's not working it may be that NeXTSTEP is using a different driver than what QEMU emulates. Since NeXTSTEP is quite old you may have better luck with a serial mouse emulation such as msmouse or make sure a PS/2 mouse driver is selected in NeXTSTEP (it may not autodetect it). + + +No luck with msmouse. NextStep assumes a PS/2 mouse, I believe, +which is what QEMU emulates by default. In bochs, the mouse does +work in NextStep. Do you know if bochs emulates the PS/2 mouse +by default? + + +I don't know about Bochs but here's another page with resources on running OPENSTEP on a VM: +http://www.zebpedersen.co.uk/?p=126 +The VMWare drivers (both svga and mouse) should work with QEMU too but I don't know if they are compatible with NeXTSTEP. +Now I remember there was some problem with mouse emulation with the PS/2 or serial driver also on VMWare which made the mouse pointer jump around and then freeze. This may also happen with QEMU but it was never debugged AFAIK. + +thank you. Will keep at it. + + +Mouse not working in WinXP with QEMU either. +But it is working with bochs (same disk image). + + +Triaging 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/review/1284874 b/results/classifier/118/review/1284874 new file mode 100644 index 000000000..5e3045940 --- /dev/null +++ b/results/classifier/118/review/1284874 @@ -0,0 +1,186 @@ +TCG: 0.896 +user-level: 0.891 +mistranslation: 0.878 +peripherals: 0.871 +KVM: 0.871 +hypervisor: 0.866 +ppc: 0.863 +graphic: 0.856 +x86: 0.852 +vnc: 0.850 +device: 0.847 +permissions: 0.846 +register: 0.846 +debug: 0.844 +performance: 0.843 +network: 0.840 +socket: 0.832 +kernel: 0.832 +virtual: 0.831 +assembly: 0.828 +arm: 0.828 +boot: 0.823 +semantic: 0.821 +architecture: 0.819 +PID: 0.818 +files: 0.818 +risc-v: 0.792 +VMM: 0.774 +i386: 0.689 +-------------------- +x86: 0.884 +virtual: 0.879 +debug: 0.672 +kernel: 0.348 +hypervisor: 0.156 +device: 0.120 +TCG: 0.087 +network: 0.086 +peripherals: 0.053 +user-level: 0.035 +register: 0.020 +VMM: 0.018 +PID: 0.016 +files: 0.015 +semantic: 0.010 +performance: 0.006 +architecture: 0.005 +risc-v: 0.004 +socket: 0.004 +boot: 0.004 +assembly: 0.003 +vnc: 0.002 +i386: 0.002 +graphic: 0.002 +KVM: 0.002 +permissions: 0.001 +ppc: 0.001 +arm: 0.001 +mistranslation: 0.000 + +Guest hangs during option rom loading with certain cards + +With a Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet card, device assignment does not work. The guest hangs during option rom execution. Moreover, if an attempt is made to quit qemu when the guest is in the hung state, the card gets into an inoperable state. Only a powercycle then, restores the card back into working order, just unloading/loading the driver does not help. + +Qemu version - 1.6.2 or current master +Distribution - FC19 +Kernel Version - 3.12.9-201.fc19.x86_64 + +Details of the card - + # ethtool -i p2p2 +driver: bnx2x +version: 1.78.17-0 +firmware-version: bc 7.8.22 +bus-info: 0000:08:00.1 +supports-statistics: yes +supports-test: yes +supports-eeprom-access: yes +supports-register-dump: yes +supports-priv-flags: yes + +The output of lspci when the card is broken - +03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev ff) (prog-if ff) + !!! Unknown header type 7f + Kernel driver in use: bnx2x +00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + +I will post if I get a chance to try out a newer than 7.8.22 for the option rom and see if this issue is fixed. However it appears we need to have a unified approach to automatically avoid loading the rom based on certain criteria. Manually, looking out for fixes to firmware and hard coding decisions based on those is neither desirable nor easy to maintain. + +Based on the trace in the attachment, the sequence of config space accesses leading up to the hang - + +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x1, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x9430, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa30c, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x7fffffff, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa5dc, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x0, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa2ec, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x3, len=0x4) +vfio: vfio_pci_read_config(0000:03:00.0, @0x98, len=0x4) 200 +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa408, len=0x4) +vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 + +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x4, len=0x4) +vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 + +The last 4 writes co-relate to the point where the guest hangs because they get repeated forever + +Comments from Alex Williamson : +> The sequence leading up to this is quite short. We do standard PCI BAR +> sizing and setup, read the ROM, then do: +> +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x1, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x9430, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa30c, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x7fffffff, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa5dc, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x0, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa2ec, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x3, len=0x4) +> vfio: vfio_pci_read_config(0000:03:00.0, @0x98, len=0x4) 200 +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0xa408, len=0x4) +> vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 +> +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x80, 0x4, len=0x4) +> vfio: vfio_pci_write_config(0000:03:00.0, @0x78, 0x86420, len=0x4) +> vfio: vfio_pci_read_config(0000:03:00.0, @0x80, len=0x4) 8 +> +> The last 4 operations are repeated forever. + +Based on the Linux driver we can see that 0x86420 is MCP_REG_MCPR_NVM_SW_ARB which arbitrates software locking of the nvram on the device. A write of 4 seems to indicate that we want to lock port 1 for nvram access. A successful lock would set bit 2 (0x4). The value 0x8 is read back, so the lock was not successful and the ROM repeats this forever. + +Perhaps there's a problem with how the port number is selected? It seems suspicious that we're using port 1 here. + + +The vfio code has logic that checks if a FLR is possible and attempts it before and after device assignment. Replacing the FLR with a bus reset succeeds past the stuck option rom loading phase and we are able to boot into the guest successfully which means that the first initialization (by the hardware) changes something in the nvram that needs to be reset back to default by a hard (bus) reset. + +We could add an ugly hack to vfio to do a bus reset for this specific card, but it should be noted that FLR if supported, should be able to take care of this condition. + +Note that it's really the FLR that's messing up the config space if it's attempted after the sequence of events leading upto the hang. + +It's easy to reproduce this using setpci writes to the card followed by a FLR in the following manner - + +#!/bin/bash +setpci -v -s 03:00.0 4.w=2 +setpci -v -s 03:00.0 4.w +setpci -v -s 03:00.0 4.w=103 +setpci -v -s 03:00.0 4.w +setpci -v -s 03:00.0 78.l=1 +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=9430 +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a30c +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=7fffffff +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a5dc +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=0 +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a2ec +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=3 +setpci -v -s 03:00.0 80.l +setpci -v -s 03:00.0 78.l=a408 +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 78.l=86420 +setpci -v -s 03:00.0 78.l +setpci -v -s 03:00.0 80.l=4 +setpci -v -s 03:00.0 80.l + +echo 1 > reset #flr then completely corrupts the config space + + +It has been suggested to blacklist loading of rom for this card (and for any other similar card that exhibit such issues) by default, a patch has been posted upstream and is going several iterations based on reviews. The most uptodate series is +[PATCH 0/2 v3] vfio: blacklist loading of unstable roms. A v4 will be posted soon. + + +Patch seems to have been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4b9430294ed406a00f045d + diff --git a/results/classifier/118/review/1285505 b/results/classifier/118/review/1285505 new file mode 100644 index 000000000..f2476cd7f --- /dev/null +++ b/results/classifier/118/review/1285505 @@ -0,0 +1,162 @@ +semantic: 0.816 +permissions: 0.811 +ppc: 0.796 +virtual: 0.790 +PID: 0.783 +debug: 0.783 +peripherals: 0.769 +risc-v: 0.769 +device: 0.755 +assembly: 0.754 +graphic: 0.736 +architecture: 0.721 +hypervisor: 0.718 +mistranslation: 0.713 +register: 0.712 +socket: 0.701 +vnc: 0.691 +performance: 0.681 +user-level: 0.671 +arm: 0.664 +files: 0.658 +KVM: 0.624 +TCG: 0.608 +kernel: 0.592 +VMM: 0.578 +network: 0.577 +x86: 0.523 +boot: 0.510 +i386: 0.463 +-------------------- +virtual: 0.913 +debug: 0.895 +x86: 0.886 +hypervisor: 0.365 +PID: 0.067 +user-level: 0.057 +ppc: 0.040 +TCG: 0.039 +files: 0.027 +performance: 0.027 +register: 0.021 +kernel: 0.019 +device: 0.006 +assembly: 0.006 +semantic: 0.006 +boot: 0.003 +socket: 0.003 +risc-v: 0.002 +network: 0.002 +graphic: 0.002 +KVM: 0.002 +i386: 0.002 +VMM: 0.002 +architecture: 0.002 +vnc: 0.001 +arm: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 + +[ppa 2.0~git-20140225] SIGABRT with -virtfs + +As requested on u-devel@, I tested QEMU 2.0~git-20140225.aa0d1f4-0ubuntu2 from ppa:ubuntu-virt/candidate. This has a regression with virtfs. + +I created a simple cloud-image based VM with autopkgtest: + + $ sudo apt-get install autopkgtest + $ adt-buildvm-ubuntu-cloud + $ mkdir -p /tmp/shared + $ qemu-system-x86_64 -enable-kvm -m 1024 -nographic -virtfs local,id=autopkgtest,path=/tmp/shared,security_model=none,mount_tag=myshare -snapshot adt-trusty-amd64-cloud.img +** +ERROR:/build/buildd/qemu-2.0~git-20140225.aa0d1f4/qom/object.c:331:object_initialize_with_type: assertion failed: (type != NULL) +Abgebrochen (Speicherabzug geschrieben) + +It should be easy enough to reproduce and the assertion message already should be clear, but this is the intersting part of the (unretraced) stack trace: + + #2 0x00007fe3329a9195 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x7fe334c5a8e8 "/build/buildd/qemu-2.0~git-20140225.aa0d1f4/qom/object.c", line=line@entry=331, func=func@entry=0x7fe334c5ac40 "object_initialize_with_type", message=message@entry=0x7fe336e06e40 "assertion failed: (type != NULL)") at /build/buildd/glib2.0-2.39.90/./glib/gtestutils.c:2291 + lstr = "331\000\377\177\000\000\320ޠF\377\177\000\000\220\026\321\066\343\177\000\000R\252\305\064\343\177\000" + s = 0x7fe336e06e70 "pp\340\066\343\177" + #3 0x00007fe3329a922a in g_assertion_message_expr (domain=0x0, file=0x7fe334c5a8e8 "/build/buildd/qemu-2.0~git-20140225.aa0d1f4/qom/object.c", line=331, func=0x7fe334c5ac40 "object_initialize_with_type", expr=<optimized out>) at /build/buildd/glib2.0-2.39.90/./glib/gtestutils.c:2306 + s = 0x7fe336e06e40 "assertion failed: (type != NULL)" + +Thanks, trivially reproduced. Will bisect. + +Actually, the interesting bit of the stack trace starts just below where you cut it off, because object_initialize_with_type() is just asserting that it wasn't called with a NULL pointer, so what we really want to know is what the caller was... + +Hm, sadly bisect gives me: + +ubuntu@c-trusty-0:~/qemu$ git bisect good +ba1183da9a10b94611cad88c44a5c6df005f9b55 is the first bad commit +commit ba1183da9a10b94611cad88c44a5c6df005f9b55 +Author: Fam Zheng <email address hidden> +Date: Mon Feb 10 14:48:52 2014 +0800 + + rules.mak: fix $(obj) to a real relative path + + Makefile.target includes rule.mak and unnested common-obj-y, then prefix + them with '../', this will ignore object specific QEMU_CFLAGS in subdir + Makefile.objs: + + $(obj)/curl.o: QEMU_CFLAGS += $(CURL_CFLAGS) + + Because $(obj) here is './block', instead of '../block'. This doesn't + hurt compiling because we basically build all .o from top Makefile, + before entering Makefile.target, but it will affact arriving per-object + libs support. + + The starting point of $(obj) is passed in as argument of unnest-vars, as + well as nested variables, so that different Makefiles can pass in a + right value. + + Signed-off-by: Fam Zheng <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +:100644 100644 807054b3a1797c911c81c58ae04c15cc599551f6 52b1958b4b43e9e90c68a6339b818f7893ba2551 M Makefile +:100644 100644 ac1d0e1c285073e1dc881061a3395189074289d0 1914080134d2559c63e76fe0650c9b86e57d3cd8 M Makefile.objs +:100644 100644 af6ac7eaa19f922cf5d006ee7eebd8ef2dfde3d4 9a6e7dd1b85e75baed2580d51456e614a0ba096f M Makefile.target +:100755 100755 4648117957465e554bd0005dc51d7e1750b97526 66b1d30c99a83a8856ecfa72bceb55a17928c70c M configure +:100644 100644 391d6eb8e612e5f7361249fe68040f50eb1c7bcc a95fb76626d5e30b5ac1b4ef5528ba5383f3ccd0 M rules.mak + + +gdb stack dump: + +Program received signal SIGABRT, Aborted. +0x00007ffff2849f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. +(gdb) where +#0 0x00007ffff2849f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007ffff284d388 in __GI_abort () at abort.c:89 +#2 0x00007ffff793c195 in g_assertion_message () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x00007ffff793c22a in g_assertion_message_expr () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#4 0x0000555555783d09 in object_initialize_with_type (data=data@entry=0x7fffe27fd910, + size=size@entry=6300032, type=0x0) at qom/object.c:331 +#5 0x0000555555783d78 in object_initialize (data=data@entry=0x7fffe27fd910, size=size@entry=6300032, + typename=typename@entry=0x555555914f28 "virtio-9p-device") at qom/object.c:350 +#6 0x0000555555735153 in virtio_9p_pci_instance_init (obj=0x7fffe27fd010) at hw/virtio/virtio-pci.c:943 +#7 0x0000555555783c23 in object_initialize_with_type (data=data@entry=0x7fffe27fd010, + size=<optimized out>, type=type@entry=0x5555561c0580) at qom/object.c:342 +#8 0x0000555555783dc0 in object_new_with_type (type=0x5555561c0580) at qom/object.c:441 +#9 0x0000555555783e55 in object_new (typename=typename@entry=0x5555561c79b0 "virtio-9p-pci") + at qom/object.c:451 +#10 0x0000555555768d2d in qdev_device_add (opts=0x5555561c7900) at qdev-monitor.c:526 +#11 0x00005555557b8289 in device_init_func (opts=<optimized out>, opaque=<optimized out>) at vl.c:2259 +#12 0x00005555558da5fb in qemu_opts_foreach (list=<optimized out>, + func=0x5555557b8270 <device_init_func>, opaque=0x0, abort_on_failure=<optimized out>) + at util/qemu-option.c:1149 +#13 0x00005555555e9743 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at vl.c:4249 + + +type passed to type_get_by_name() was "virtio-9p-device". It returned NULL. + +Looking at the compile output, in fact ./hw/9pfs/virtio-9p-device.o did not get compiled after commit ba1183da9a10b94611cad88c44a5c6df005f9b55. + +@pitti, + +the version now in ppa should fix your virtfs problem. + +Confirmed, this works now. Thanks! Closing, as this only affected the PPA. + +If I get the last two comments right, the problem was only about the Ubuntu PPA package, so I'm closing this for upstream QEMU, too. If you still have problems with upstream QEMU here, please feel free to open the ticket again. + diff --git a/results/classifier/118/review/1287195 b/results/classifier/118/review/1287195 new file mode 100644 index 000000000..3c6dd8939 --- /dev/null +++ b/results/classifier/118/review/1287195 @@ -0,0 +1,71 @@ +mistranslation: 0.851 +architecture: 0.849 +device: 0.792 +kernel: 0.715 +socket: 0.671 +arm: 0.662 +files: 0.660 +vnc: 0.658 +register: 0.643 +network: 0.632 +VMM: 0.593 +risc-v: 0.552 +permissions: 0.551 +PID: 0.541 +boot: 0.512 +ppc: 0.511 +user-level: 0.470 +TCG: 0.427 +graphic: 0.419 +semantic: 0.389 +debug: 0.328 +performance: 0.271 +hypervisor: 0.180 +KVM: 0.176 +peripherals: 0.166 +virtual: 0.133 +x86: 0.073 +assembly: 0.061 +i386: 0.022 +-------------------- +kernel: 0.963 +hypervisor: 0.511 +architecture: 0.218 +TCG: 0.177 +files: 0.089 +debug: 0.083 +KVM: 0.042 +VMM: 0.039 +virtual: 0.032 +user-level: 0.031 +arm: 0.021 +device: 0.013 +semantic: 0.009 +register: 0.008 +PID: 0.007 +boot: 0.004 +assembly: 0.004 +performance: 0.004 +network: 0.003 +permissions: 0.002 +socket: 0.002 +vnc: 0.001 +peripherals: 0.001 +graphic: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +x86: 0.000 +ppc: 0.000 +i386: 0.000 + +validate_guest_space incorrectly enabled on AArch64 + +When running linux-user targetting AArch64, validate_guest_space() in elfload.c reserves space in the guest address space for the ARM commpage. Since there is no commpage on AArch64, this function should be disable on that target. + +Thanks for the bug report -- I've just submitted this patch which should fix this: + http://patchwork.ozlabs.org/patch/328565/ + + +Fix will be in 2.0. + + diff --git a/results/classifier/118/review/1303926 b/results/classifier/118/review/1303926 new file mode 100644 index 000000000..de34dfa8c --- /dev/null +++ b/results/classifier/118/review/1303926 @@ -0,0 +1,359 @@ +user-level: 0.827 +ppc: 0.821 +risc-v: 0.812 +debug: 0.805 +hypervisor: 0.793 +register: 0.784 +peripherals: 0.764 +arm: 0.753 +x86: 0.748 +permissions: 0.744 +virtual: 0.728 +device: 0.725 +architecture: 0.721 +graphic: 0.717 +performance: 0.714 +vnc: 0.712 +i386: 0.705 +KVM: 0.702 +semantic: 0.683 +TCG: 0.682 +mistranslation: 0.678 +VMM: 0.639 +PID: 0.627 +boot: 0.624 +assembly: 0.620 +socket: 0.613 +kernel: 0.586 +files: 0.558 +network: 0.540 +-------------------- +x86: 0.994 +debug: 0.856 +user-level: 0.811 +kernel: 0.802 +hypervisor: 0.373 +virtual: 0.210 +register: 0.057 +vnc: 0.015 +performance: 0.010 +PID: 0.010 +TCG: 0.007 +architecture: 0.004 +semantic: 0.003 +files: 0.002 +i386: 0.002 +assembly: 0.002 +VMM: 0.001 +risc-v: 0.001 +graphic: 0.001 +ppc: 0.001 +device: 0.001 +boot: 0.001 +KVM: 0.001 +socket: 0.001 +network: 0.000 +mistranslation: 0.000 +peripherals: 0.000 +permissions: 0.000 +arm: 0.000 + +qemu-system-x86_64 crashed with SIGABRT + +I've been getting this periodically since my upgrade to qemu 2.0 in trusty this morning. + +ProblemType: Crash +DistroRelease: Ubuntu 14.04 +Package: qemu-system-x86 2.0.0~rc1+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8 +Uname: Linux 3.13.0-23-generic x86_64 +ApportVersion: 2.14.1-0ubuntu1 +Architecture: amd64 +Date: Mon Apr 7 13:31:53 2014 +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-11-26 (131 days ago) +InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) +ProcEnviron: PATH=(custom, no user) +Registers: No symbol table is loaded. Use the "file" command. +Signal: 6 +SourcePackage: qemu +StacktraceTop: + +Title: qemu-system-x86_64 crashed with SIGABRT +UpgradeStatus: Upgraded to trusty on 2014-01-17 (79 days ago) +UserGroups: + + + +It seems to happen when my quantal i386 guest is using the VMVGA driver. Switching to Cirrus fixes it. +Also happens to trusty amd64 guest with VMVGA driver. + +Stacktrace: + #0 0x00007f4eb7fa1f79 in ?? () + No symbol table info available. + Cannot access memory at address 0x7fffa1617188 +StacktraceSource: #0 0x00007f4eb7fa1f79 in ?? () +StacktraceTop: ?? () + + + + +And it is not just with vnc either. + +2f487a3d40faff1772e14da6b921900915501f9a was ok, so bisecting right now. + +Hm, bisect is pointing at 6ff45f01c734e1ad051f19913449e2577c9f4b7d which is very unlikely. I'll have to keep playing. + +Pretty sure that commit b533f658a98325d0e47b36113bd9f5bcc046fdae is the first bad commit. + +This is interesting. The commit is correct in that kvm_vm_ioctl() returns -errno, not -1, on error. However, the caller, kvm_physical_sync_dirty_bitmap, on seeing the error, shortcuts some extra errors to return -1 itself, but its caller then ignores its error. + +An extra debug statement shows that the ioctl is getting + +ioctl failed: No such file or directory + + +At the point when the ioctl fails, this is the backtrace: + +(gdb) where +#0 kvm_physical_sync_dirty_bitmap (section=0x7fffffffd820) at /home/serge/src/qemu/kvm-all.c:446 +#1 0x000055555580e30c in kvm_log_sync (listener=<optimized out>, section=<optimized out>) at /home/serge/src/qemu/kvm-all.c:803 +#2 0x000055555581390e in memory_region_sync_dirty_bitmap (mr=mr@entry=0x555556257ca8) at /home/serge/src/qemu/memory.c:1210 +#3 0x00005555557d943f in vga_sync_dirty_bitmap (s=0x555556257c98) at /home/serge/src/qemu/hw/display/vga.c:1618 +#4 vga_draw_graphic (full_update=0, s=0x555556257c98) at /home/serge/src/qemu/hw/display/vga.c:1653 +#5 vga_update_display (opaque=0x555556257c98) at /home/serge/src/qemu/hw/display/vga.c:1913 +#6 0x0000555555780d92 in dpy_refresh (s=0x555556203690) at ui/console.c:1416 +#7 gui_update (opaque=0x555556203690) at ui/console.c:194 +#8 0x0000555555764bd9 in timerlist_run_timers (timer_list=0x5555561d2460) at qemu-timer.c:488 +#9 0x0000555555764e44 in qemu_clock_run_timers (type=<optimized out>) at qemu-timer.c:499 +#10 qemu_clock_run_all_timers () at qemu-timer.c:605 +#11 0x0000555555729dbc in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:490 +#12 0x00005555555e6196 in main_loop () at vl.c:2051 +#13 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4506 + + +(which means my comment #8 is off track - the caller in this case is checking the return value, then aborting - and this is the exact same backtrace as we get anyway) + +Looking at arch/x86/kvm/x86.c, ENOENT (only) happens when memslot->dirty_bitmap is NULL in kvm_vm_ioctl_get_dirty_log(). + + + +It seems reasonable that if we are requesting writing a dirty bitmap, and kernel says it's not dirty, we ignore that failure? I.e. ignore ENOENT? + +ENOENT (iiuc) means the kernel has an empty dirty bitmap for this +slot. Don't abort in that case. This appears to solve the bug +reported at + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1303926 + +which first showed up with commit b533f658a98325d: fix return check for +KVM_GET_DIRTY_LOG ioctl + +Signed-off-by: Serge Hallyn <email address hidden> +--- + kvm-all.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/kvm-all.c b/kvm-all.c +index 82a9119..7b7ea8d 100644 +--- a/kvm-all.c ++++ b/kvm-all.c +@@ -441,10 +441,13 @@ static int kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section) + + d.slot = mem->slot; + +- if (kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) { ++ ret = kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); ++ if (ret < 0 && ret != -ENOENT) { + DPRINTF("ioctl failed %d\n", errno); + ret = -1; + break; ++ } else if (ret < 0) { ++ ret = 0; + } + + kvm_get_dirty_pages_log_range(section, d.dirty_bitmap); +-- +1.9.1 + + + +This bug was fixed in the package qemu - 2.0.0~rc1+dfsg-0ubuntu3 + +--------------- +qemu (2.0.0~rc1+dfsg-0ubuntu3) trusty; urgency=medium + + * d/p/ubuntu/kvm_physical_sync_dirty_bitmap-ignore-ENOENT-from-kv.patch + don't abort() just because the kernel has no dirty bitmap. + (LP: #1303926) + -- Serge Hallyn <email address hidden> Tue, 08 Apr 2014 22:32:00 -0500 + +Quoting Michael Tokarev (<email address hidden>): +> 09.04.2014 07:21, Serge Hallyn wrote: +> > ENOENT (iiuc) means the kernel has an empty dirty bitmap for this +> > slot. Don't abort in that case. This appears to solve the bug +> > reported at +> > +> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1303926 +> > +> > which first showed up with commit b533f658a98325d: fix return check for +> > KVM_GET_DIRTY_LOG ioctl +> > +> > Signed-off-by: Serge Hallyn <email address hidden> +> > --- +> > kvm-all.c | 5 ++++- +> > 1 file changed, 4 insertions(+), 1 deletion(-) +> > +> > diff --git a/kvm-all.c b/kvm-all.c +> > index 82a9119..7b7ea8d 100644 +> > --- a/kvm-all.c +> > +++ b/kvm-all.c +> > @@ -441,10 +441,13 @@ static int kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section) +> > +> > d.slot = mem->slot; +> > +> > - if (kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) { +> > + ret = kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d); +> > + if (ret < 0 && ret != -ENOENT) { +> > DPRINTF("ioctl failed %d\n", errno); +> > ret = -1; +> > break; +> > + } else if (ret < 0) { +> > + ret = 0; +> > } +> > +> > kvm_get_dirty_pages_log_range(section, d.dirty_bitmap); +> +> Should we omit calling kvm_get_dirty_pages_log_range() if there's +> no bitmap from kernel? + +If that's something we can know then certainly that'll be better. +It'll save an ioctl and copy_from_user of the whole of &d. + +> In particular, do we trust kernel to not +> touch d.dirty_bitmap when it returns ENOENT? + +Seems ok, kvm_vm_ioctl_get_dirty_log() doesn't change anything +in *log before returning when it finds no dirty_mapslot. + +-serge + + +Hi Serge, + +I keep getting the crash notification due to kvm crashes with the same bug title as this one. I see that the status is Fix Released, I'm on precise and fully up-to-date. + + +My package is: + +ii qemu-kvm 1.0+noroms-0ubuntu14.14 Full virtualization on i386 and amd64 hardware + +which seems the correct one. + + +However, from the changelog I cannot see anything that seems related to this bug fix: + +qemu-kvm (1.0+noroms-0ubuntu14.14) precise-security; urgency=medium + + * SECURITY UPDATE: arbitrary code execution via MAC address table update + - debian/patches/CVE-2014-0150.patch: fix overflow in hw/virtio-net.c. + - CVE-2014-0150 + * SECURITY UPDATE: denial of service and possible code execution via + smart self test counter + - debian/patches/CVE-2014-2894.patch: correct self-test count in + hw/ide/core.c. + - CVE-2014-2894 + + -- Marc Deslauriers <email address hidden> Fri, 25 Apr 2014 17:37:13 -0400 + +qemu-kvm (1.0+noroms-0ubuntu14.13) precise-security; urgency=medium + + * SECURITY UPDATE: privilege escalation via REPORT LUNS + - debian/patches/CVE-2013-4344.patch: support more than 256 LUNS in + hw/scsi-bus.c, hw/scsi.h. + - CVE-2013-4344 + + -- Marc Deslauriers <email address hidden> Tue, 28 Jan 2014 09:08:09 -0500 + + +(the other entries are older than these ones) + + +Has this fix really been released to precise? + + + +Thank you! + +Hi, + +the cause of this particular bug was introduced during 2014, so could not have been present in precise. We definately will want to figure out the cause of your bug, so please open a new bug report using 'ubuntu-bug qemu-kvm' immediately after a crash has happened. + +Thanks! + +Hi Serge, + + +I think I have already reported the required information a number of times with the Ubuntu built-in bug reporting facility (apport?), which asked me to report the crash information to developers. + +Are you able to find it out or do I need to manually open a new bug? + + +Thanks you. + +Unfortunately the only bug launchpad shows me when I search for bugs reported +by you is https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1180777 + +If you can give me a bug# that would be great, otherwise please do file a +new bug. + + +Hi Serge, + +I have opened this new bug: + +https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1320144 + +I have the similar issue, the KVM 2.0 keeps crashing, here is the stack I captured with GDB + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +[Switching to Thread 0x7ffede1f9700 (LWP 5555)] +0x00007ffeee4d4f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. +(gdb) bt +#0 0x00007ffeee4d4f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007ffeee4d8388 in __GI_abort () at abort.c:89 +#2 0x00007ffeee4cde36 in __assert_fail_base (fmt=0x7ffeee61f718 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x7ffef45f1c1e "s->current", + file=file@entry=0x7ffef45f17e0 "/build/buildd/qemu-2.0.0~rc1+dfsg/hw/scsi/lsi53c895a.c", line=line@entry=541, + function=function@entry=0x7ffef45f275b "lsi_do_dma") at assert.c:92 +#3 0x00007ffeee4cdee2 in __GI___assert_fail (assertion=0x7ffef45f1c1e "s->current", + file=0x7ffef45f17e0 "/build/buildd/qemu-2.0.0~rc1+dfsg/hw/scsi/lsi53c895a.c", line=541, + function=0x7ffef45f275b "lsi_do_dma") at assert.c:101 +#4 0x00007ffef43de87d in ?? () +#5 0x00007ffef43dca97 in ?? () +#6 0x00007ffef4507631 in ?? () +#7 0x00007ffef450c776 in ?? () +#8 0x00007ffef44b1933 in ?? () +#9 0x00007ffef4506615 in ?? () +#10 0x00007ffef44a6f42 in ?? () +#11 0x00007ffeee86c182 in start_thread (arg=0x7ffede1f9700) at pthread_create.c:312 +#12 0x00007ffeee59930d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +(gdb) + +My KVM command line +================== + +qemu-system-x86_64 -enable-kvm -name 015-win2k3-32bit-dev-target -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 2af25570-37cd-a3af-e157-0d85cf31d47d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/015-win2k3-32bit-dev-target.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x4 -drive file=/home/vm/015-win2k3-32bit-dev-target/disk.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,cache=writeback -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/vm/015-win2k3-32bit-dev-target/zhe_test.qcow2,if=none,id=drive-scsi0-0-0,format=qcow2,cache=writeback -device scsi-hd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=e0:db:55:04:dd:0f,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:115 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + + + +Anyone works on the crash now? The above back trace shows it crashed at assert(s->current) ? + +Do you still have this problem with the latest released version of QEMU (see http://wiki.qemu-project.org/Download)? + +OK, since there hasn't been a reply within 6 months, I assume this is now fixed. So closing this ticket now. + diff --git a/results/classifier/118/review/1307225 b/results/classifier/118/review/1307225 new file mode 100644 index 000000000..9dcbcbfe8 --- /dev/null +++ b/results/classifier/118/review/1307225 @@ -0,0 +1,532 @@ +semantic: 0.873 +user-level: 0.854 +virtual: 0.828 +debug: 0.807 +mistranslation: 0.796 +performance: 0.794 +arm: 0.791 +assembly: 0.788 +graphic: 0.784 +ppc: 0.781 +permissions: 0.780 +PID: 0.777 +risc-v: 0.773 +device: 0.772 +peripherals: 0.766 +KVM: 0.750 +TCG: 0.749 +register: 0.749 +kernel: 0.739 +architecture: 0.738 +hypervisor: 0.737 +VMM: 0.727 +vnc: 0.707 +files: 0.687 +boot: 0.671 +network: 0.643 +i386: 0.601 +x86: 0.535 +socket: 0.527 +-------------------- +virtual: 0.962 +debug: 0.796 +x86: 0.746 +architecture: 0.413 +user-level: 0.129 +hypervisor: 0.091 +performance: 0.048 +kernel: 0.039 +PID: 0.035 +socket: 0.032 +files: 0.027 +i386: 0.017 +VMM: 0.017 +device: 0.010 +register: 0.010 +TCG: 0.007 +semantic: 0.007 +risc-v: 0.006 +vnc: 0.006 +assembly: 0.005 +boot: 0.004 +KVM: 0.003 +network: 0.002 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.000 +ppc: 0.000 +arm: 0.000 + +Running a virtual machine on a Haswell system produces machine check events + +I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable version on Gentoo). I got a lot of machine check events ("mce: [Hardware Error]: Machine check events logged") in dmesg that always looked like (using mcelog): + +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1390267908 Tue Jan 21 02:31:48 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 6 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I found this discussion on the vmware community: https://communities.vmware.com/thread/452344 + +It seems that this is (at least partly) caused by the Qemu machine. I switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With this version, the errors almost disappeared, but from time to time, I still get machine check events. Anyways, they so not seem to affect neither the vm, nor the host. + +I created the virtual machine on an older Core 2 Duo machine and ran it for several weeks without a single error message, so I think this is actually some problem with the Haswell architecture. The errors didn't show up until I copied the virtual machine to my new machine. + +Still happens with qemu 2.0.0 and the same environment (Windows SBS 2003 32 bit guest on a Gentoo Linux amd64 Haswell host). + +Running the VM with "-cpu Haswell" set still causes those "Internal Parity Errors", but not so many … + +Used QEMU this morning, noticed mce error in log, searched, found this. + +* model name: Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz (it's a Haswell) +* kernel 3.14.4-gentoo +* app-emulation/qemu-1.6.1 +* qemu-system-i386 -enable-kvm andsoon +* [73468.545378] mce: [Hardware Error]: Machine check events logged + +# mcelog +Hardware event. This is not a software error. +MCE 0 +CPU 0 BANK 0 +TIME 1400824994 Fri May 23 08:03:14 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c07 APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I don't have anything to contribute other than that Tobias is not the only one who gets this hardware error message when using QEMU on a Haswell. + +I can confirm this. + +Using qemu-kvm for three virtual machines on Ubuntu 14.04 LTS using a Intel i7-4770 Haswell based server. + +dmesg: +[63429.847437] mce: [Hardware Error]: Machine check events logged +[65996.795630] mce: [Hardware Error]: Machine check events logged + +mcelog: +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1406265172 Fri Jul 25 07:12:52 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +It's the same error everytime, only APICID and CPU numbers are different. +The mce errors did not happen until i migrated the virtual machines from another system, the haswell-server was up for three days without any incidents, now, while running qemu-kvm there is a mce error every 6-12 hours. +After the first errors, i called the support of my server provider, they first exchanged RAM, upgraded BIOS... +Then, they replaced the whole server, only swapping my harddisks to the new one. But even that didn't help, i still got MCE errors. The harddisks where replaced too, one at a time (to resync raid). Now, i have a completely swapped hardware, but the MCE errors are still popping up. + +system information attached + +attachment +logfiles, dmidecode, system information + +I got a new Haswell based system a few days ago. It has been running fine without warnings but today I started a VirtualBox VM and got a MCE soon afterwards. "MCA: Internal parity error" like everyone else. From reading this bug and the vmware link in the first post it seems like this problem occurs on all virtualization solutions using hardware acceleration on Haswell based systems. It happens on Qemu, Virtualbox and Vmware and it happens on both Linux and Windows. + +Do anyone have connections within Intel and can pull some strings to have them look at this? It looks like the MCE is always non fatal but perhaps there are other unknown side effects. A microcode update might solve it. + +Try adding this to the Linux commandline, in your bootloader: + +mce=nobootlog + +From Documentation/x86/x86_64/boot-options.txt: + + mce=bootlog + Enable logging of machine checks left over from booting. + Disabled by default on AMD because some BIOS leave bogus ones. + If your BIOS doesn't do that it's a good idea to enable though + to make sure you log even machine check events that result + in a reboot. On Intel systems it is enabled by default. + mce=nobootlog + Disable boot machine check logging. + +How will this help to solve the problem? + +I think this is related to the Haswell erratum 131 of the 'Intel® Xeon® Processor E3-1200 v3 Product Family Specification Update' at: +http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v3-spec-update.pdf + + HSW131. Spurious Corrected Errors May be Reported + Problem: Due this erratum, spurious corrected errors may be logged in the IA32_MC0_STATUS + register with the valid field (bit 63) set, the uncorrected error field (bit 61) not set, a + Model Specific Error Code (bits [31:16]) of 0x000F, and an MCA Error Code (bits + [15:0]) of 0x0005. If CMCI is enabled, these spurious corrected errors also signal interrupts. + Implication: When this erratum occurs, software may see corrected errors that are benign. These + corrected errors may be safely ignored. + Workaround: None identified. + Status: For the steppings affected, see the Summary Table of Changes + + +I propose to work around this by mce=ignore_ce, as this is a spurious 'corrected error': +From Documentation/x86/x86_64/boot-options.txt: + mce=ignore_ce + Disable features for corrected errors, e.g. polling timer + and CMCI. All events reported as corrected are not cleared + by OS and remained in its error banks. + Usually this disablement is not recommended, however if + there is an agent checking/clearing corrected errors + (e.g. BIOS or hardware monitoring applications), conflicting + with OS's error handling, and you cannot deactivate the agent, + then this option will be a help. + +But I have not tried this yet. + + +So, at least, this does not seem to be something to worry about. But anyways, why does it only happen if a virtual machine is executed? + +Just my 2 cents. I have two Haswell boxes with Ubuntu Server 14.04 each running bunch of VMs. The first one is Intel Core i7-4770K and it runs only Linux VMs. There is no single MCE here for at least one year. The second box is Intel Core i7-4790K and it runs mix of Linux and Windows 2003 VMs. MCEs regularly appear in logs here. + +mce=ignore_ce indeed "fixes" the messages. However, it will mask real (important) errors as well. + +Since Intel can't or won't correct the bug with a microcode update, how about filtering it in the kernel? + +http://svnweb.freebsd.org/base/head/sys/x86/x86/mca.c?r1=269052&r2=269051&pathrev=269052 + +I'm seeing these MCE messages too. + +My hardware is i7 4790K on a Gigabyte Z97X Gaming GT motherboard. + +I run a mixture of Linux and Windows (client and server editions) guests. Hipervisor is kvm. I'm seeing these MCE messages since I virtualized a Windows Server 2008 R2 SP1. Neither Windows XP nor Windows 8.1 guests showed any messages. + +For a few minutes I was worried my hardware was faulty, but this bug reports somewhat gives me hope the hardware is OK. + +Pasted below is my /var/log/mcelog + + + +mcelog: failed to prefill DIMM database from DMI data +Hardware event. This is not a software error. +MCE 0 +CPU 0 BANK 0 +TIME 1440943174 Sun Aug 30 10:59:34 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 1 +CPU 0 BANK 0 +TIME 1441015741 Mon Aug 31 07:09:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 1 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 2 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 3 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 4 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 5 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 6 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 8 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 9 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 10 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 11 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 12 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 13 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1441064341 Mon Aug 31 20:39:01 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 +Hardware event. This is not a software error. +MCE 0 +CPU 2 BANK 0 +TIME 1441064371 Mon Aug 31 20:39:31 2015 +MCG status: +MCi status: +Error overflow +Corrected error +Error enabled +MCA: Internal parity error +STATUS d0000200000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + + +Minor Update: Bug occurs under Intel Skylake, too. + +System-information: Intel Core i7-6700 with 4x8 GB Samsung M378A1G43DB0-CPB DDR4-2133 RAM, Motherboard: Fujitsu D3401-H1 + + +Dec 15 06:53:30 srv01 kernel: [224214.850599] mce: [Hardware Error]: Machine check events logged +Dec 15 06:55:08 srv01 kernel: [224312.001142] mce: [Hardware Error]: Machine check events logged +Dec 15 06:57:12 srv01 kernel: [224435.836130] mce: [Hardware Error]: Machine check events logged +Dec 15 07:03:35 srv01 kernel: [224818.079136] mce: [Hardware Error]: Machine check events logged +Dec 15 07:07:55 srv01 kernel: [225077.697589] mce_notify_irq: 1 callbacks suppressed +Dec 15 07:07:55 srv01 kernel: [225077.697592] mce: [Hardware Error]: Machine check events logged +Dec 15 07:08:51 srv01 kernel: [225134.136571] mce: [Hardware Error]: Machine check events logged +Dec 15 07:12:25 srv01 kernel: [225347.598995] mce_notify_irq: 1 callbacks suppressed +Dec 15 07:12:25 srv01 kernel: [225347.598998] mce: [Hardware Error]: Machine check events logged +Dec 15 07:15:03 srv01 kernel: [225504.880462] mce: [Hardware Error]: Machine check events logged +Dec 15 07:17:49 srv01 kernel: [225670.907609] mce: [Hardware Error]: Machine check events logged +Dec 15 07:21:49 srv01 kernel: [225911.163547] mce: [Hardware Error]: Machine check events logged +Dec 15 07:22:57 srv01 kernel: [225978.227807] mce: [Hardware Error]: Machine check events logged +Dec 15 07:24:32 srv01 kernel: [226073.681985] mce: [Hardware Error]: Machine check events logged +Dec 15 07:28:31 srv01 kernel: [226312.111733] mce: [Hardware Error]: Machine check events logged +Dec 15 07:34:04 srv01 kernel: [226644.639095] mce: [Hardware Error]: Machine check events logged +Dec 15 07:35:58 srv01 kernel: [226757.904937] mce_notify_irq: 2 callbacks suppressed +Dec 15 07:35:58 srv01 kernel: [226757.904940] mce: [Hardware Error]: Machine check events logged +Dec 15 07:36:10 srv01 kernel: [226770.139237] mce: [Hardware Error]: Machine check events logged +Dec 15 07:41:14 srv01 kernel: [227073.719040] mce: [Hardware Error]: Machine check events logged +Dec 15 07:41:16 srv01 kernel: [227075.399257] mce: [Hardware Error]: Machine check events logged +Dec 15 07:44:14 srv01 kernel: [227253.699541] mce: [Hardware Error]: Machine check events logged +Dec 15 07:44:57 srv01 kernel: [227296.490305] mce: [Hardware Error]: Machine check events logged +Dec 15 07:52:44 srv01 kernel: [227762.621344] mce: [Hardware Error]: Machine check events logged +Dec 15 07:52:49 srv01 kernel: [227767.372259] mce: [Hardware Error]: Machine check events logged +Dec 15 07:54:39 srv01 kernel: [227877.219677] mce_notify_irq: 1 callbacks suppressed +Dec 15 07:54:39 srv01 kernel: [227877.219680] mce: [Hardware Error]: Machine check events logged +... + +mcelog: Family 6 Model 5e CPU: only decoding architectural errors +Hardware event. This is not a software error. +MCE 29 +CPU 0 BANK 0 +TIME 1450162369 Tue Dec 15 07:52:49 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 9000004000010005 MCGSTATUS 0 +MCGCAP c0a APICID 0 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 94 +mcelog: Family 6 Model 5e CPU: only decoding architectural errors +Hardware event. This is not a software error. +MCE 30 +CPU 2 BANK 0 +TIME 1450162422 Tue Dec 15 07:53:42 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 9000004000010005 MCGSTATUS 0 +MCGCAP c0a APICID 4 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 94 +mcelog: Family 6 Model 5e CPU: only decoding architectural errors +Hardware event. This is not a software error. +MCE 31 +CPU 1 BANK 0 +TIME 1450162479 Tue Dec 15 07:54:39 2015 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 9000004000010005 MCGSTATUS 0 +MCGCAP c0a APICID 2 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 94 + + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I'm not sure if this can still be reproduces but I've found a workaround quite a while ago. The problem disappeared once I migrated the virtual machines using 32 bit OS images to 64 bit. The mix of 32 and 64 bit VMs was the causing these problems at least on my server. + +Last time I saw this error in my mcelog was in August. Probably, some update fixed it. I'll check the next days/weeks if I still see it. This is a quite long time, at the time of my original bug report, I got the errors multiple times a day and later multiple times a week. + +About the workaround moving to 64 bit OS images: Well, if you're (like in my case) stuck with dinosaur OS (Windows SBS 2003), there's no way to simply move to a 64 bit image ;-) + +But as said: I think it simply disappeared by some update. I'm using 2.10.0 at the moment. + +The errors still keep appearing. The mcelog still shows the exact errors posted in the very fist comment. + + +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/101 + + diff --git a/results/classifier/118/review/1310714 b/results/classifier/118/review/1310714 new file mode 100644 index 000000000..730a7186c --- /dev/null +++ b/results/classifier/118/review/1310714 @@ -0,0 +1,241 @@ +user-level: 0.886 +ppc: 0.857 +x86: 0.846 +risc-v: 0.842 +KVM: 0.836 +hypervisor: 0.827 +mistranslation: 0.827 +VMM: 0.824 +vnc: 0.820 +graphic: 0.816 +peripherals: 0.800 +register: 0.793 +virtual: 0.793 +TCG: 0.789 +permissions: 0.787 +device: 0.785 +network: 0.780 +performance: 0.776 +assembly: 0.772 +debug: 0.772 +semantic: 0.768 +arm: 0.766 +architecture: 0.747 +socket: 0.736 +i386: 0.720 +PID: 0.712 +files: 0.698 +kernel: 0.685 +boot: 0.676 +-------------------- +x86: 0.986 +debug: 0.979 +virtual: 0.904 +user-level: 0.391 +performance: 0.129 +network: 0.086 +vnc: 0.082 +PID: 0.079 +assembly: 0.073 +TCG: 0.021 +files: 0.021 +semantic: 0.021 +VMM: 0.016 +hypervisor: 0.011 +register: 0.010 +KVM: 0.008 +device: 0.005 +kernel: 0.004 +architecture: 0.004 +socket: 0.003 +ppc: 0.002 +graphic: 0.002 +boot: 0.002 +permissions: 0.001 +peripherals: 0.001 +i386: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +arm: 0.000 + +User mode networking SLIRP rapid memory leak + +QEMU compiled from git HEAD at 2d03b49c3f225994c4b0b46146437d8c887d6774 and reproducible at tag v2.0.0. I first noticed this bug using Ubuntu Trusty's QEMU 2.0.0~rc1. I used to run QEMU 1.7 without this problem. + +This is the command I ran: + +qemu-system-x86_64 -enable-kvm -smp 2 -m 1G -usbdevice tablet -net nic,model=e1000 -net user -vnc localhost:99 -drive if=ide,file=test.img,cache=none -net nic -net user,tftp=/tmp/tftpdata -no-reboot + +The guest is Windows 7 64-bit. The VM starts off normally, but after a couple of minutes, the memory usage starts to swell. If let running, it eventually consumes all host memory and grinds the host to a halt due to heavy swapping. + +When running under gdb, I set a breakpoint on mmap, and this is the stack trace I obtained. + +Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 +81 in ../sysdeps/unix/syscall-template.S +(gdb) where +#0 mmap64 () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff0e65091 in new_heap (size=135168, size@entry=1728, + top_pad=<optimized out>) at arena.c:554 +#2 0x00007ffff0e687b2 in sysmalloc (av=0x7fffd0000020, nb=1664) + at malloc.c:2386 +#3 _int_malloc (av=0x7fffd0000020, bytes=1650) at malloc.c:3740 +#4 0x00007ffff0e69f50 in __GI___libc_malloc (bytes=1650) at malloc.c:2855 +#5 0x00005555557a091a in m_get (slirp=0x5555561fe960) + at /src/qemu/slirp/mbuf.c:73 +#6 0x00005555557a3151 in slirp_input (slirp=0x5555561fe960, + pkt=0x7ffff7e94b20 "RU\n", pkt_len=<optimized out>) + at /src/qemu/slirp/slirp.c:747 +#7 0x0000555555758b24 in net_slirp_receive (nc=<optimized out>, + buf=<optimized out>, size=54) at /src/qemu/net/slirp.c:113 +#8 0x00005555557567d1 in qemu_deliver_packet (sender=<optimized out>, + flags=<optimized out>, data=<optimized out>, size=<optimized out>, + opaque=<optimized out>) at /src/qemu/net/net.c:471 +#9 0x00005555557588d3 in qemu_net_queue_deliver (size=54, + data=0x7ffff7e94b20 "RU\n", flags=0, sender=0x5555561fe5e0, + queue=0x5555561fe1d0) at /src/qemu/net/queue.c:157 +#10 qemu_net_queue_send (queue=0x5555561fe1d0, sender=0x5555561fe5e0, flags=0, + data=0x7ffff7e94b20 "RU\n", size=54, sent_cb=<optimized out>) + at /src/qemu/net/queue.c:192 +---Type <return> to continue, or q <return> to quit--- +#11 0x000055555575536b in net_hub_receive (len=54, buf=0x7ffff7e94b20 "RU\n", + source_port=0x5555561fe310, hub=<optimized out>) at /src/qemu/net/hub.c:55 +#12 net_hub_port_receive (nc=0x5555561fe310, buf=0x7ffff7e94b20 "RU\n", len=54) + at /src/qemu/net/hub.c:114 +#13 0x00005555557567d1 in qemu_deliver_packet (sender=<optimized out>, + flags=<optimized out>, data=<optimized out>, size=<optimized out>, + opaque=<optimized out>) at /src/qemu/net/net.c:471 +#14 0x00005555557588d3 in qemu_net_queue_deliver (size=54, + data=0x7ffff7e94b20 "RU\n", flags=0, sender=0x555556531920, + queue=0x5555561fe090) at /src/qemu/net/queue.c:157 +#15 qemu_net_queue_send (queue=0x5555561fe090, sender=0x555556531920, flags=0, + data=0x7ffff7e94b20 "RU\n", size=54, sent_cb=<optimized out>) + at /src/qemu/net/queue.c:192 +#16 0x00005555556db95d in xmit_seg (s=0x7ffff7e72010) + at /src/qemu/hw/net/e1000.c:628 +#17 0x00005555556dbd38 in process_tx_desc (dp=0x7fffdf7fda30, s=0x7ffff7e72010) + at /src/qemu/hw/net/e1000.c:723 +#18 start_xmit (s=0x7ffff7e72010) at /src/qemu/hw/net/e1000.c:778 +#19 set_tctl (s=0x7ffff7e72010, index=<optimized out>, val=<optimized out>) + at /src/qemu/hw/net/e1000.c:1142 +#20 0x0000555555840fb0 in access_with_adjusted_size (addr=14360, + value=0x7fffdf7fdb10, size=4, access_size_min=<optimized out>, + access_size_max=<optimized out>, +---Type <return> to continue, or q <return> to quit--- + access=0x555555841160 <memory_region_write_accessor>, mr=0x7ffff7e747c0) + at /src/qemu/memory.c:478 +#21 0x00005555558462fe in memory_region_dispatch_write (size=4, data=454, + addr=14360, mr=0x7ffff7e747c0) at /src/qemu/memory.c:990 +#22 io_mem_write (mr=0x7ffff7e747c0, addr=14360, val=<optimized out>, size=4) + at /src/qemu/memory.c:1744 +#23 0x00005555557e8717 in address_space_rw ( + as=0x555556159c80 <address_space_memory>, addr=4273485848, + buf=0x7ffff7fed028 "\306\001", len=4, is_write=true) + at /src/qemu/exec.c:2034 +#24 0x000055555583ff65 in kvm_cpu_exec (cpu=<optimized out>) + at /src/qemu/kvm-all.c:1704 +#25 0x00005555557ddb6c in qemu_kvm_cpu_thread_fn (arg=0x55555651b730) + at /src/qemu/cpus.c:873 +#26 0x00007ffff11b6182 in start_thread (arg=0x7fffdf7fe700) + at pthread_create.c:312 +#27 0x00007ffff0ee1b2d in clone () + at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 + +Let me know if you have any questions. Thanks. + +liulk + +I investigated further and found that a program in guest (jusched.exe Java Updater) is simultaneously sending and receiving network packets rapidly. This is what exacerbates the memory leak. + +When the mmap breakpoint triggers, I now set additional breakpoints in m_get() and m_free() and found that the number of calls to these functions do not balance, hence making the leak evident. + +Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 +81 in ../sysdeps/unix/syscall-template.S +(gdb) info break +Num Type Disp Enb Address What +1 breakpoint keep y 0x00007ffff0edbfb0 ../sysdeps/unix/syscall-template.S:81 + breakpoint already hit 6 times +2 breakpoint keep y 0x0000555555848dfa in m_get + at /src/qemu/slirp/mbuf.c:66 + breakpoint already hit 645487 times + ignore next 354513 hits +3 breakpoint keep y 0x0000555555848eff in m_free + at /src/qemu/slirp/mbuf.c:103 + breakpoint already hit 484477 times + ignore next 515523 hits + +About 25% of the m_get() do not get m_free()'d. + +liulk + +I also noticed that the command I ran is causing this bug to happen. I had accidentally repeated -net nic twice, so there are two -net user network interfaces. Removing one of them makes the problem go away. + +liulk + +On Mon, Apr 21, 2014 at 08:53:43PM -0000, Likai Liu wrote: +> I also noticed that the command I ran is causing this bug to happen. I +> had accidentally repeated -net nic twice, so there are two -net user +> network interfaces. Removing one of them makes the problem go away. + +This is still a bug, the packets should be freed even with 2 -net user. + +Stefan + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I believe this is the issue i am seeing as well. QEMU continues to consume memory (>6GB) until the host machine runs out of memory (I am also using slirp for networking). I am able to reproduce it from qemu 2.5 (version found in apt-get for ubuntu 16.04.3 LTS) and I verified it exists after I compiled from source both 2.8.1.1 and 2.10.2 as well. + +$ uname -a +Linux siemens 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +$ cat qemu.cfg +# qemu config file + +[drive] + format = "raw" + file = "qemu_rootfs_512.img" + +[drive] + format = "raw" + file = "hmi_sl_oa.img" + +[drive] + format = "raw" + file = "swap_512m.img" + +[net] + type = "nic" + +[net] + type = "user" + +[machine] + kernel = "vmlinuz-2.6.11.12-vanilla.bz" + initrd = "initrd-2.6.11.12.img.gz" + append = "root=/dev/hda" + +[memory] + size = "2048" + +[vnc "default"] + vnc = ":1" + +$ qemu-system-x86_64 -readconfig qemu.cfg + +Let me know what other information you need. + +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/review/1315257 b/results/classifier/118/review/1315257 new file mode 100644 index 000000000..9105e3726 --- /dev/null +++ b/results/classifier/118/review/1315257 @@ -0,0 +1,115 @@ +architecture: 0.819 +graphic: 0.818 +permissions: 0.815 +performance: 0.814 +i386: 0.794 +x86: 0.772 +debug: 0.768 +peripherals: 0.749 +semantic: 0.734 +PID: 0.728 +device: 0.725 +register: 0.720 +KVM: 0.718 +TCG: 0.711 +user-level: 0.709 +assembly: 0.707 +mistranslation: 0.686 +socket: 0.678 +virtual: 0.674 +boot: 0.666 +kernel: 0.663 +hypervisor: 0.656 +ppc: 0.621 +arm: 0.606 +risc-v: 0.605 +files: 0.588 +network: 0.556 +VMM: 0.554 +vnc: 0.502 +-------------------- +x86: 0.643 +debug: 0.379 +PID: 0.257 +virtual: 0.177 +hypervisor: 0.122 +register: 0.074 +TCG: 0.060 +files: 0.055 +graphic: 0.041 +socket: 0.040 +device: 0.020 +user-level: 0.015 +assembly: 0.014 +network: 0.007 +performance: 0.007 +semantic: 0.007 +kernel: 0.005 +architecture: 0.003 +peripherals: 0.003 +VMM: 0.002 +risc-v: 0.002 +boot: 0.002 +i386: 0.002 +permissions: 0.002 +KVM: 0.001 +arm: 0.001 +ppc: 0.001 +mistranslation: 0.001 +vnc: 0.001 + +QEMU get black screen when adjust resolution in full screen mode. + +Description: +QEMU cause X11 error when adjust resolution in full screen mode or start QEMU with "-full-screen". + +Additional info: +* host OS infomation + Archlinux 64bit +* gest OS infomation + Windows XP SP3 32bit +* Archlinux package version(s) +qemu 1.7.1-1 +cinnamon 2.2.3-3 +sdl 1.2.15-5 +xf86-video-ati 1:7.3.0-1 +xf86-video-fbdev 0.4.4-2 +xf86-video-modesetting 0.8.1-2 +xf86-video-vesa 2.3.2-4 +xorg-server 1.15.1-1 + +* error output in Xterm +X Error of failed request: BadValue (integer parameter out of range for operation) + Major opcode of failed request: 153 (XFree86-VidModeExtension) + Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) + Value in failed request: 0x2c2 + Serial number of failed request: 412 + Current serial number in output stream: 414 + +* Xorg log output + *with the command "grep EE /var/log/Xorg.0.log" + (WW) warning, (EE) error, (NI) not implemented, (??) unknown. +[ 7726.317] Initializing built-in extension MIT-SCREEN-SAVER + *with the command "grep WW /var/log/Xorg.0.log" + (WW) warning, (EE) error, (NI) not implemented, (??) unknown. +[ 7726.314] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/misc/". +[ 7726.314] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/100dpi/". +[ 7726.314] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/75dpi/". +[ 7726.316] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) +[ 7726.334] (WW) Falling back to old probe method for modesetting +[ 7726.334] (WW) Falling back to old probe method for fbdev +[ 7726.335] (WW) Falling back to old probe method for vesa + +Steps to reproduce: +1.Start QEMU with the command: + qemu-system-i386 -enable-kvm -machine type=pc,accel=kvm -rtc base=localtime -nodefaults -no-quit -usbdevice tablet -cpu host -smp 2 -m 1G -vga std -soundhw ac97 -net nic,model=virtio -net bridge,br=virbr0 -drive if=virtio,index=0,media=disk,format=raw,cache=none,file=/home/user/VM/WinXP.img +2.Press ctl + alt + f to full screen. +3.Adjust resolution in guest OS. +or +1.Make sure the guest OS resolution is not the same as host OS. +2.Start QEMU with parameter "-full-screen". + +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/review/1318091 b/results/classifier/118/review/1318091 new file mode 100644 index 000000000..74c318302 --- /dev/null +++ b/results/classifier/118/review/1318091 @@ -0,0 +1,115 @@ +mistranslation: 0.921 +permissions: 0.904 +user-level: 0.902 +debug: 0.896 +semantic: 0.893 +virtual: 0.893 +kernel: 0.864 +architecture: 0.862 +arm: 0.858 +assembly: 0.857 +register: 0.848 +risc-v: 0.847 +graphic: 0.845 +device: 0.844 +TCG: 0.841 +PID: 0.837 +hypervisor: 0.830 +peripherals: 0.827 +vnc: 0.826 +ppc: 0.822 +performance: 0.817 +files: 0.814 +network: 0.806 +KVM: 0.789 +socket: 0.788 +boot: 0.774 +VMM: 0.770 +x86: 0.765 +i386: 0.638 +-------------------- +x86: 0.972 +kernel: 0.954 +performance: 0.818 +architecture: 0.470 +KVM: 0.262 +hypervisor: 0.237 +register: 0.177 +semantic: 0.123 +debug: 0.104 +virtual: 0.071 +files: 0.023 +PID: 0.013 +assembly: 0.010 +device: 0.009 +boot: 0.008 +TCG: 0.008 +VMM: 0.007 +socket: 0.005 +network: 0.002 +user-level: 0.002 +risc-v: 0.002 +peripherals: 0.001 +graphic: 0.001 +ppc: 0.001 +permissions: 0.001 +vnc: 0.001 +i386: 0.001 +mistranslation: 0.000 +arm: 0.000 + +Perfctr MSRs not available to Guest OS on AMD Phenom II + +The AMD Phenom(tm) II X4 965 Processor (family 16, model 4, stepping 3) has the 4 architecturally supported perf counters at MSRs. The selectors are c001000-c001003, and the counters are c001004-c001007. I've verified that the MSRs are there and working by manually setting the MSRs with msr-tools to count cycles. + +The processor does not support the extended perfctr or the perfctr_nb. These are in cpuid leaf 8000_0001. Qemu also sees that these cpuid flags are not set, when I try launching with -cpu host,perfctr_core,check. However, this flag is only for the extended perfctr MSRs, which also happen to map the original four counters at c0010200. + +When I run a Guest OS, that OS is unable to use the perf counter registers from c001000-7. rdmsr and wrmsr complete, but the results are always 0. By contrast, a wrmsr to one of the c0010200 registers causes a general protection fault (as it should, since those aren't supported). + +Kernel: 3.14.0-gentoo +Qemu: 2.0.0 (gentoo) and also with 2.0.50 (commit 06b4f00d5) +Qemu command: qemu-system-x86_64 -enable-kvm -cpu host -smp 8 -m 1024 -nographic -monitor /dev/pts/4 mnt/hdd.img +cat /proc/cpuinfo: +processor : 3 +vendor_id : AuthenticAMD +cpu family : 16 +model : 4 +model name : AMD Phenom(tm) II X4 965 Processor +stepping : 3 +cpu MHz : 800.000 +cache size : 512 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 5 +wp : yes +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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save +bogomips : 6803.79 +TLB size : 1024 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm stc 100mhzsteps hwpstate + +thanks. + +i don't understand this in detail, but since the last update of qemu i can't start my virtual win7 machine. i use gnome-boxes 3.24. qemu 2.8 works, 2.9 leads to this: +Preformatted text(gnome-boxes:4301): Boxes-WARNING **: machine.vala:611: Failed to start win7: Unable to start domain: the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor, rdtscp, svm + +i ask, because i also use an phenom 2 x4 and if this is the bug i don't need to opan a new one. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hi - + +I don't have the hardware readily available anymore, so I can't test it. Might as well close the bug. + +Regarding Oliver's question, it doesn't sound like the same issue I had. I do recall that processor and qemu not supporting rdtscp (which is fine), so that problem might be some qemu startup script requesting features that aren't available. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1318474 b/results/classifier/118/review/1318474 new file mode 100644 index 000000000..7ec8efcaa --- /dev/null +++ b/results/classifier/118/review/1318474 @@ -0,0 +1,80 @@ +mistranslation: 0.865 +ppc: 0.777 +device: 0.751 +i386: 0.690 +graphic: 0.656 +x86: 0.601 +hypervisor: 0.586 +kernel: 0.584 +register: 0.568 +vnc: 0.545 +boot: 0.528 +architecture: 0.522 +semantic: 0.503 +network: 0.469 +socket: 0.465 +permissions: 0.457 +risc-v: 0.454 +performance: 0.440 +VMM: 0.407 +assembly: 0.400 +PID: 0.373 +arm: 0.356 +peripherals: 0.333 +KVM: 0.326 +files: 0.318 +TCG: 0.308 +virtual: 0.304 +debug: 0.265 +user-level: 0.241 +-------------------- +virtual: 0.905 +hypervisor: 0.578 +user-level: 0.471 +x86: 0.467 +debug: 0.132 +TCG: 0.074 +boot: 0.032 +socket: 0.027 +PID: 0.021 +files: 0.021 +device: 0.012 +i386: 0.011 +kernel: 0.008 +register: 0.008 +network: 0.007 +semantic: 0.007 +risc-v: 0.006 +assembly: 0.005 +vnc: 0.004 +performance: 0.004 +architecture: 0.003 +VMM: 0.002 +graphic: 0.002 +ppc: 0.001 +peripherals: 0.001 +permissions: 0.001 +arm: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +QEMU update causes Windows reactivation + +After updating QEMU the guest OS's detect new hardware. As a result any Windows OS sees it as a significant change in hardware and require a reactivation. + +Host OS: Ubuntu 14.04 64-bit + +Guest OS's: +Windows Server 2003 R2 Enterprise +Windows Server 2008 R2 Enterprise +Windows Server 2008 R2 Web +Windows Server 2008 R2 Data Center + +QEMU version: 2.0.0 + +How did you start QEMU with the new version here? You might need to specify the correct machine type with the new version to avoid that the guest sees different hardware (e.g. with the "-machine pc-i440fx-2.0" option). + +[Expired for QEMU because there has been no activity for 60 days.] + +When updating QEMU use specific machine type and this will keep "old" HW. + diff --git a/results/classifier/118/review/1322 b/results/classifier/118/review/1322 new file mode 100644 index 000000000..af0c02aab --- /dev/null +++ b/results/classifier/118/review/1322 @@ -0,0 +1,61 @@ +mistranslation: 0.918 +virtual: 0.598 +device: 0.473 +user-level: 0.307 +network: 0.227 +semantic: 0.139 +graphic: 0.136 +performance: 0.116 +peripherals: 0.110 +permissions: 0.081 +i386: 0.067 +assembly: 0.044 +hypervisor: 0.043 +PID: 0.031 +ppc: 0.023 +arm: 0.021 +TCG: 0.017 +architecture: 0.016 +files: 0.016 +VMM: 0.013 +x86: 0.013 +KVM: 0.010 +boot: 0.009 +risc-v: 0.007 +debug: 0.006 +kernel: 0.004 +register: 0.004 +socket: 0.003 +vnc: 0.001 +-------------------- +network: 0.985 +virtual: 0.504 +user-level: 0.047 +semantic: 0.040 +debug: 0.008 +peripherals: 0.004 +files: 0.003 +device: 0.003 +permissions: 0.002 +register: 0.002 +arm: 0.002 +performance: 0.002 +boot: 0.002 +mistranslation: 0.001 +architecture: 0.001 +socket: 0.001 +kernel: 0.001 +PID: 0.001 +assembly: 0.000 +hypervisor: 0.000 +VMM: 0.000 +x86: 0.000 +i386: 0.000 +TCG: 0.000 +risc-v: 0.000 +graphic: 0.000 +ppc: 0.000 +vnc: 0.000 +KVM: 0.000 + +Unknown protocol 'ssh' diff --git a/results/classifier/118/review/1326533 b/results/classifier/118/review/1326533 new file mode 100644 index 000000000..8f1565d63 --- /dev/null +++ b/results/classifier/118/review/1326533 @@ -0,0 +1,83 @@ +mistranslation: 0.867 +device: 0.680 +graphic: 0.582 +performance: 0.525 +semantic: 0.454 +network: 0.417 +user-level: 0.333 +socket: 0.325 +PID: 0.313 +ppc: 0.311 +vnc: 0.296 +hypervisor: 0.287 +architecture: 0.243 +arm: 0.238 +peripherals: 0.233 +permissions: 0.210 +debug: 0.208 +register: 0.197 +i386: 0.156 +x86: 0.156 +files: 0.131 +risc-v: 0.105 +boot: 0.104 +VMM: 0.103 +TCG: 0.096 +virtual: 0.086 +kernel: 0.079 +KVM: 0.073 +assembly: 0.050 +-------------------- +debug: 0.916 +files: 0.164 +virtual: 0.060 +user-level: 0.060 +x86: 0.055 +TCG: 0.031 +register: 0.010 +i386: 0.009 +hypervisor: 0.005 +semantic: 0.004 +device: 0.004 +ppc: 0.004 +assembly: 0.003 +network: 0.003 +arm: 0.003 +performance: 0.003 +PID: 0.003 +kernel: 0.002 +boot: 0.002 +graphic: 0.002 +socket: 0.001 +architecture: 0.001 +VMM: 0.001 +peripherals: 0.001 +risc-v: 0.001 +permissions: 0.001 +KVM: 0.000 +vnc: 0.000 +mistranslation: 0.000 + +SDL2 UI sends a NULL to sdl_grab_start if fullscreen, which crashes + +in ui/sdl2.c: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(0); + } + +Is sent, but no null checks are made in sdl_grab_start (its assumed to be an allocated pointer). So a crash happens if you start qemu -full-screen. + +It should at lease send the first [0] of the newly allocated sdl2_console through. + +Quickly looking around should look something like: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(&sdl2_console[0]); + } + +The NULL pointer check has been added here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f2335791fd0ceb2f9e3 + diff --git a/results/classifier/118/review/1328996 b/results/classifier/118/review/1328996 new file mode 100644 index 000000000..ebdf2b365 --- /dev/null +++ b/results/classifier/118/review/1328996 @@ -0,0 +1,72 @@ +architecture: 0.956 +device: 0.871 +mistranslation: 0.798 +files: 0.798 +arm: 0.736 +graphic: 0.713 +semantic: 0.618 +network: 0.577 +socket: 0.504 +kernel: 0.458 +performance: 0.446 +risc-v: 0.420 +vnc: 0.395 +boot: 0.376 +permissions: 0.344 +register: 0.318 +ppc: 0.296 +debug: 0.292 +user-level: 0.240 +TCG: 0.229 +PID: 0.215 +VMM: 0.207 +peripherals: 0.175 +assembly: 0.134 +hypervisor: 0.116 +KVM: 0.107 +virtual: 0.070 +i386: 0.008 +x86: 0.008 +-------------------- +arm: 0.984 +files: 0.737 +virtual: 0.488 +hypervisor: 0.174 +TCG: 0.085 +kernel: 0.079 +register: 0.074 +debug: 0.068 +assembly: 0.043 +architecture: 0.036 +PID: 0.014 +device: 0.012 +user-level: 0.011 +network: 0.010 +semantic: 0.007 +VMM: 0.006 +peripherals: 0.006 +risc-v: 0.004 +performance: 0.004 +boot: 0.003 +socket: 0.002 +KVM: 0.002 +ppc: 0.001 +vnc: 0.001 +permissions: 0.001 +graphic: 0.001 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +[AArch64] - blr x30 is handled incorrectly + +Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device. + + + +I think this should already be fixed in master by commit 1b505f93bcf60 (about a month ago). Can you try a newer QEMU build, please? + + + +Thanks, Peter. I just built the latest development build, and it now passes. Sorry for the false alarm. + diff --git a/results/classifier/118/review/1333651 b/results/classifier/118/review/1333651 new file mode 100644 index 000000000..c3ffe0028 --- /dev/null +++ b/results/classifier/118/review/1333651 @@ -0,0 +1,675 @@ +user-level: 0.886 +KVM: 0.856 +register: 0.843 +x86: 0.837 +performance: 0.822 +TCG: 0.805 +peripherals: 0.802 +graphic: 0.797 +vnc: 0.795 +mistranslation: 0.776 +ppc: 0.772 +virtual: 0.750 +architecture: 0.748 +permissions: 0.747 +VMM: 0.746 +device: 0.739 +risc-v: 0.732 +semantic: 0.724 +assembly: 0.709 +hypervisor: 0.707 +arm: 0.706 +debug: 0.698 +network: 0.694 +kernel: 0.689 +PID: 0.665 +socket: 0.661 +boot: 0.660 +i386: 0.654 +files: 0.635 +-------------------- +KVM: 0.984 +virtual: 0.961 +debug: 0.870 +x86: 0.790 +hypervisor: 0.755 +kernel: 0.379 +performance: 0.069 +PID: 0.063 +assembly: 0.037 +TCG: 0.031 +files: 0.012 +semantic: 0.007 +register: 0.007 +VMM: 0.007 +architecture: 0.004 +device: 0.003 +i386: 0.003 +user-level: 0.003 +boot: 0.003 +network: 0.002 +ppc: 0.002 +socket: 0.001 +permissions: 0.001 +peripherals: 0.001 +arm: 0.001 +risc-v: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +qemu-2.0 occasionally segfaults with Windows 2012R2 + +This is with qemu-2.0 (KVM), linux kernel 3.10.35, using qcow2 images directly accessed via libgfapi (glusterfs-3.4.2). +Such a segfaults happens roughly once every 2 weeks and only for VMs with high network and/or disk activity. + +Guest OS with which we could reproduce this was always Windows Server 2012R2 using virtio-win-0.1-75. + +vhost-net is active, the disks are attached as virtio-blk devices (see also XML definition from libvirt further below) + +Following are the backtraces for all threads: + +(gdb) threads +Undefined command: "threads". Try "help". +(gdb) info threads + Id Target Id Frame + 32 Thread 0x7f5c1affd700 (LWP 16783) 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 + 31 Thread 0x7f5bfe2fc700 (LWP 19906) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 30 Thread 0x7f5c45f87880 (LWP 16769) 0x00007f5c42637ff6 in __GI_ppoll (fds=0x7f5c48bcd750, nfds=74, + timeout=0x7fff92d94e60, timeout@entry=0x7fff92d94f20, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57 + 29 Thread 0x7f5c1bfff700 (LWP 16781) 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 + 28 Thread 0x7f5c28de1700 (LWP 16780) 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 + 27 Thread 0x7f5c1a7fc700 (LWP 16784) __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + 26 Thread 0x7f5c295e2700 (LWP 16779) __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + 25 Thread 0x7f57b2ffd700 (LWP 18170) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 24 Thread 0x7f57c97fa700 (LWP 31326) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 23 Thread 0x7f57b3fff700 (LWP 5016) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 22 Thread 0x7f57c9ffb700 (LWP 25116) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 21 Thread 0x7f5c31f7c700 (LWP 16776) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 20 Thread 0x7f5c1b7fe700 (LWP 16782) __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + 19 Thread 0x7f57ca7fc700 (LWP 24029) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 18 Thread 0x7f57cbfff700 (LWP 19985) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 17 Thread 0x7f57c8ff9700 (LWP 31327) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 16 Thread 0x7f5bfcefa700 (LWP 19924) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 15 Thread 0x7f5c30ee7700 (LWP 16777) 0x00007f5c426421b3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 + 14 Thread 0x7f5c3dc17700 (LWP 16772) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 13 Thread 0x7f5bfd6fb700 (LWP 19907) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 12 Thread 0x7f5c18bff700 (LWP 16788) 0x00007f5c42637ded in poll () at ../sysdeps/unix/syscall-template.S:81 + 11 Thread 0x7f5c19ffb700 (LWP 16785) 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 + 10 Thread 0x7f57caffd700 (LWP 20235) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 9 Thread 0x7f5c2bfff700 (LWP 16778) 0x00007f5c4290e43d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 + 8 Thread 0x7f5bfecfd700 (LWP 17854) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 7 Thread 0x7f5c3e418700 (LWP 16771) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 6 Thread 0x7f57b37fe700 (LWP 18169) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 5 Thread 0x7f5c3bb57700 (LWP 16774) 0x00007f5c4290e43d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 + 4 Thread 0x7f5c3c97f700 (LWP 16773) 0x00007f5c426421b3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 + 3 Thread 0x7f5c3277d700 (LWP 16775) pthread_cond_timedwait () + at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 + 2 Thread 0x7f5c197fa700 (LWP 16786) 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +* 1 Thread 0x7f57cb7fe700 (LWP 19986) event_notifier_set (e=0x124) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/util/event_notifier-posix.c:97 +(gdb) bt +#0 event_notifier_set (e=0x124) at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/util/event_notifier-posix.c:97 +#1 0x00007f5c457145d1 in ?? () from /usr/lib64/libgfapi.so.0 +#2 0x00007f5c454d1d0a in synctask_wrap () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c4259d760 in ?? () from /lib64/libc.so.6 +#4 0x0000000000000000 in ?? () +(gdb) thread 2 +[Switching to thread 2 (Thread 0x7f5c197fa700 (LWP 16786))] +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c4627b5e9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f5c48b8ccd0, type=type@entry=44672) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1790 +#2 0x00007f5c4627b725 in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b8ccd0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1675 +#3 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b8ccd0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#4 0x00007f5c42906fda in start_thread (arg=0x7f5c197fa700) at pthread_create.c:308 +#5 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 3 +[Switching to thread 3 (Thread 0x7f5c3277d700 (LWP 16775))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5c3277d700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 4 +[Switching to thread 4 (Thread 0x7f5c3c97f700 (LWP 16773))] +#0 0x00007f5c426421b3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c426421b3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c454ea917 in ?? () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c45712584 in ?? () from /usr/lib64/libgfapi.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5c3c97f700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 5 +[Switching to thread 5 (Thread 0x7f5c3bb57700 (LWP 16774))] +#0 0x00007f5c4290e43d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c4290e43d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c454b4874 in gf_timer_proc () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c42906fda in start_thread (arg=0x7f5c3bb57700) at pthread_create.c:308 +#3 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 6 +[Switching to thread 6 (Thread 0x7f57b37fe700 (LWP 18169))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57b37fe700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 7 +[Switching to thread 7 (Thread 0x7f5c3e418700 (LWP 16771))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5c3e418700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 8 +[Switching to thread 8 (Thread 0x7f5bfecfd700 (LWP 17854))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5bfecfd700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 9 +[Switching to thread 9 (Thread 0x7f5c2bfff700 (LWP 16778))] +#0 0x00007f5c4290e43d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c4290e43d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c454b4874 in gf_timer_proc () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c42906fda in start_thread (arg=0x7f5c2bfff700) at pthread_create.c:308 +#3 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 10 +[Switching to thread 10 (Thread 0x7f57caffd700 (LWP 20235))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57caffd700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 11 +[Switching to thread 11 (Thread 0x7f5c19ffb700 (LWP 16785))] +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c4627b5e9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f5c48b7c720, type=type@entry=44672) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1790 +#2 0x00007f5c4627b725 in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b7c720) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1675 +#3 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b7c720) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#4 0x00007f5c42906fda in start_thread (arg=0x7f5c19ffb700) at pthread_create.c:308 +#5 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 12 +[Switching to thread 12 (Thread 0x7f5c18bff700 (LWP 16788))] +#0 0x00007f5c42637ded in poll () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c42637ded in poll () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c43521494 in ?? () from /usr/lib64/libspice-server.so.1 +#2 0x00007f5c42906fda in start_thread (arg=0x7f5c18bff700) at pthread_create.c:308 +#3 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 13 +[Switching to thread 13 (Thread 0x7f5bfd6fb700 (LWP 19907))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5bfd6fb700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 14 +[Switching to thread 14 (Thread 0x7f5c3dc17700 (LWP 16772))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5c3dc17700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 15 +[Switching to thread 15 (Thread 0x7f5c30ee7700 (LWP 16777))] +#0 0x00007f5c426421b3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c426421b3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c454ea917 in ?? () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c45712584 in ?? () from /usr/lib64/libgfapi.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5c30ee7700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 16 +[Switching to thread 16 (Thread 0x7f5bfcefa700 (LWP 19924))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5bfcefa700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 17 +[Switching to thread 17 (Thread 0x7f57c8ff9700 (LWP 31327))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57c8ff9700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 18 +[Switching to thread 18 (Thread 0x7f57cbfff700 (LWP 19985))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57cbfff700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 19 +[Switching to thread 19 (Thread 0x7f57ca7fc700 (LWP 24029))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57ca7fc700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 20 +[Switching to thread 20 (Thread 0x7f5c1b7fe700 (LWP 16782))] +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +135 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory. +(gdb) bt +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +#1 0x00007f5c4290923c in _L_lock_1001 () from /lib64/libpthread.so.0 +#2 0x00007f5c4290908b in __GI___pthread_mutex_lock (mutex=0x7f5c46b87dc0 <qemu_global_mutex>) at pthread_mutex_lock.c:64 +#3 0x00007f5c4631c6c9 in qemu_mutex_lock (mutex=mutex@entry=0x7f5c46b87dc0 <qemu_global_mutex>) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/util/qemu-thread-posix.c:76 +#4 0x00007f5c46221c50 in qemu_mutex_lock_iothread () + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:1043 +#5 0x00007f5c4627b72d in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b4b610) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1677 +#6 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b4b610) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#7 0x00007f5c42906fda in start_thread (arg=0x7f5c1b7fe700) at pthread_create.c:308 +#8 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 21 +[Switching to thread 21 (Thread 0x7f5c31f7c700 (LWP 16776))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5c31f7c700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 22 +[Switching to thread 22 (Thread 0x7f57c9ffb700 (LWP 25116))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57c9ffb700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 23 +[Switching to thread 23 (Thread 0x7f57b3fff700 (LWP 5016))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57b3fff700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 24 +[Switching to thread 24 (Thread 0x7f57c97fa700 (LWP 31326))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57c97fa700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 25 +[Switching to thread 25 (Thread 0x7f57b2ffd700 (LWP 18170))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f57b2ffd700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 26 +[Switching to thread 26 (Thread 0x7f5c295e2700 (LWP 16779))] +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +135 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory. +(gdb) bt +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +#1 0x00007f5c4290923c in _L_lock_1001 () from /lib64/libpthread.so.0 +#2 0x00007f5c4290908b in __GI___pthread_mutex_lock (mutex=0x7f5c46b87dc0 <qemu_global_mutex>) at pthread_mutex_lock.c:64 +#3 0x00007f5c4631c6c9 in qemu_mutex_lock (mutex=mutex@entry=0x7f5c46b87dc0 <qemu_global_mutex>) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/util/qemu-thread-posix.c:76 +#4 0x00007f5c46221c50 in qemu_mutex_lock_iothread () + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:1043 +#5 0x00007f5c4627b72d in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48aefab0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1677 +#6 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48aefab0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#7 0x00007f5c42906fda in start_thread (arg=0x7f5c295e2700) at pthread_create.c:308 +#8 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 27 +[Switching to thread 27 (Thread 0x7f5c1a7fc700 (LWP 16784))] +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +135 in ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S +(gdb) bt +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +#1 0x00007f5c4290923c in _L_lock_1001 () from /lib64/libpthread.so.0 +#2 0x00007f5c4290908b in __GI___pthread_mutex_lock (mutex=0x7f5c46b87dc0 <qemu_global_mutex>) at pthread_mutex_lock.c:64 +#3 0x00007f5c4631c6c9 in qemu_mutex_lock (mutex=mutex@entry=0x7f5c46b87dc0 <qemu_global_mutex>) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/util/qemu-thread-posix.c:76 +#4 0x00007f5c46221c50 in qemu_mutex_lock_iothread () + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:1043 +#5 0x00007f5c4627b72d in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b6c170) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1677 +#6 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b6c170) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#7 0x00007f5c42906fda in start_thread (arg=0x7f5c1a7fc700) at pthread_create.c:308 +#8 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 28 +[Switching to thread 28 (Thread 0x7f5c28de1700 (LWP 16780))] +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c4627b5e9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f5c48b2aab0, type=type@entry=44672) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1790 +#2 0x00007f5c4627b725 in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b2aab0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1675 +#3 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b2aab0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#4 0x00007f5c42906fda in start_thread (arg=0x7f5c28de1700) at pthread_create.c:308 +#5 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 29 +[Switching to thread 29 (Thread 0x7f5c1bfff700 (LWP 16781))] +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +81 in ../sysdeps/unix/syscall-template.S +(gdb) bt +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c4627b5e9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f5c48b3b060, type=type@entry=44672) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1790 +#2 0x00007f5c4627b725 in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b3b060) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1675 +#3 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b3b060) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#4 0x00007f5c42906fda in start_thread (arg=0x7f5c1bfff700) at pthread_create.c:308 +#5 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 30 +[Switching to thread 30 (Thread 0x7f5c45f87880 (LWP 16769))] +#0 0x00007f5c42637ff6 in __GI_ppoll (fds=0x7f5c48bcd750, nfds=74, timeout=0x7fff92d94e60, timeout@entry=0x7fff92d94f20, + sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57 +57 ../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory. +(gdb) bt +#0 0x00007f5c42637ff6 in __GI_ppoll (fds=0x7f5c48bcd750, nfds=74, timeout=0x7fff92d94e60, timeout@entry=0x7fff92d94f20, + sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:57 +#1 0x00007f5c461d5c39 in ppoll (__ss=0x0, __timeout=0x7fff92d94f20, __nfds=<optimized out>, __fds=<optimized out>) + at /usr/include/bits/poll2.h:77 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=313102) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/qemu-timer.c:316 +#3 0x00007f5c46199154 in os_host_main_loop_wait (timeout=313102) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/main-loop.c:229 +#4 main_loop_wait (nonblocking=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/main-loop.c:484 +#5 0x00007f5c460457ae in main_loop () at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/vl.c:2051 +#6 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/vl.c:4507 +(gdb) thread 31 +[Switching to thread 31 (Thread 0x7f5bfe2fc700 (LWP 19906))] +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +238 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such file or directory. +(gdb) bt +#0 pthread_cond_timedwait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 +#1 0x00007f5c454d34e3 in syncenv_task () from /usr/lib64/libglusterfs.so.0 +#2 0x00007f5c454d3920 in syncenv_processor () from /usr/lib64/libglusterfs.so.0 +#3 0x00007f5c42906fda in start_thread (arg=0x7f5bfe2fc700) at pthread_create.c:308 +#4 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 +(gdb) thread 32 +[Switching to thread 32 (Thread 0x7f5c1affd700 (LWP 16783))] +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +81 ../sysdeps/unix/syscall-template.S: No such file or directory. +(gdb) bt +#0 0x00007f5c42639607 in ioctl () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007f5c4627b5e9 in kvm_vcpu_ioctl (cpu=cpu@entry=0x7f5c48b5bbc0, type=type@entry=44672) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1790 +#2 0x00007f5c4627b725 in kvm_cpu_exec (cpu=cpu@entry=0x7f5c48b5bbc0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/kvm-all.c:1675 +#3 0x00007f5c4622095c in qemu_kvm_cpu_thread_fn (arg=0x7f5c48b5bbc0) + at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/cpus.c:873 +#4 0x00007f5c42906fda in start_thread (arg=0x7f5c1affd700) at pthread_create.c:308 +#5 0x00007f5c42641b1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 + +XML definition from libvirt: + +<domain type='kvm' id='9'> + <name>b1032388-abb8-4176-897b-0c30a1a73714</name> + <uuid>b1032388-abb8-4176-897b-0c30a1a73714</uuid> + <memory unit='KiB'>16777216</memory> + <currentMemory unit='KiB'>16777216</currentMemory> + <vcpu placement='static'>8</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <pae/> + <hap/> + </features> + <cpu mode='host-model'> + <model fallback='allow'/> + </cpu> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-kvm</emulator> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/virtualization/iso/571196f0-4b29-48c9-b250-50697cbe4317.iso'/> + <backingStore/> + <target dev='hdb' bus='ide'/> + <readonly/> + <alias name='ide0-0-1'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/virtualization/iso/85d7e9f5-4288-4a3f-b209-c12ff11c61f3.iso'/> + <backingStore/> + <target dev='hdc' bus='ide'/> + <readonly/> + <alias name='ide0-1-0'/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <disk type='network' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source protocol='gluster' name='virtualization/vm-persistent/0f83f084-8080-413e-b558-b678e504836e/d35a6600-91bf-4fd1-aba4-1fe6a813d481.qcow2'> + <host name='1.2.3.4'/> + </source> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </disk> + <disk type='network' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source protocol='gluster' name='virtualization/vm-persistent/0f83f084-8080-413e-b558-b678e504836e/V5qtOlCs-8PgV-64tQ-a79N-j4ko4GIBijT4.qcow2'> + <host name='1.2.3.4'/> + </source> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb0'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb0'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb0'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='XX.XX.XX.XX:XX:XX'/> + <source bridge='vmbr0'/> + <target dev='kvm-XYZ_0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/b1032388-abb8-4176-897b-0c30a1a73714.org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <alias name='channel1'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' port='5900' autoport='no' listen='1.2.3.4'> + <listen type='address' address='1.2.3.4'/> + </graphics> + <sound model='ac97'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' heads='1'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir0'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir1'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir2'/> + </redirdev> + <redirfilter> + <usbdev allow='no'/> + </redirfilter> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + <rng model='virtio'> + <rate bytes='1024' period='1000'/> + <backend model='random'>/dev/random</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> + </rng> + </devices> + <seclabel type='none'/> +</domain> + +On Tue, Jun 24, 2014 at 11:17:51AM -0000, dev-zero wrote: +> (gdb) bt +> #0 event_notifier_set (e=0x124) at /var/tmp/portage/app-emulation/qemu-2.0.0/work/qemu-2.0.0/util/event_notifier-posix.c:97 +> #1 0x00007f5c457145d1 in ?? () from /usr/lib64/libgfapi.so.0 +> #2 0x00007f5c454d1d0a in synctask_wrap () from /usr/lib64/libglusterfs.so.0 +> #3 0x00007f5c4259d760 in ?? () from /lib64/libc.so.6 +> #4 0x0000000000000000 in ?? () + +e=0x124 is an invalid address. This crash is probably fixed by: + + commit 924fe1293c3e7a3c787bbdfb351e7f168caee3e9 + Author: Stefan Hajnoczi <email address hidden> + Date: Tue Jun 3 11:21:01 2014 +0200 + + aio: fix qemu_bh_schedule() bh->ctx race condition + +Please apply the patch or try QEMU 2.1-rc0: +http://wiki.qemu.org/download/qemu-2.1.0-rc0.tar.bz2 + +Stefan + + +Assuming this has been fixed by the patch that Stefan pointed out in comment #1, so closing this ticket now (feel free to re-open if you still can reproduce it with the latest version of QEMU) + diff --git a/results/classifier/118/review/1336 b/results/classifier/118/review/1336 new file mode 100644 index 000000000..5e0f90ce3 --- /dev/null +++ b/results/classifier/118/review/1336 @@ -0,0 +1,61 @@ +mistranslation: 0.986 +device: 0.769 +virtual: 0.755 +network: 0.711 +performance: 0.613 +architecture: 0.382 +hypervisor: 0.309 +arm: 0.291 +graphic: 0.245 +register: 0.230 +socket: 0.203 +peripherals: 0.193 +files: 0.173 +vnc: 0.172 +boot: 0.164 +kernel: 0.160 +assembly: 0.146 +permissions: 0.137 +semantic: 0.136 +ppc: 0.131 +risc-v: 0.127 +i386: 0.126 +x86: 0.120 +VMM: 0.090 +debug: 0.087 +user-level: 0.055 +PID: 0.046 +TCG: 0.017 +KVM: 0.002 +-------------------- +virtual: 0.954 +hypervisor: 0.905 +debug: 0.180 +mistranslation: 0.056 +x86: 0.031 +assembly: 0.024 +network: 0.019 +device: 0.017 +files: 0.014 +user-level: 0.012 +performance: 0.009 +semantic: 0.007 +i386: 0.006 +graphic: 0.006 +TCG: 0.005 +kernel: 0.004 +PID: 0.004 +peripherals: 0.003 +socket: 0.003 +arm: 0.002 +boot: 0.001 +risc-v: 0.001 +KVM: 0.001 +ppc: 0.001 +permissions: 0.001 +register: 0.001 +VMM: 0.001 +architecture: 0.001 +vnc: 0.000 + +QEMU qxl_phys2virt Unsafe Address Translation Lead to OOB Read diff --git a/results/classifier/118/review/1337 b/results/classifier/118/review/1337 new file mode 100644 index 000000000..a571ca694 --- /dev/null +++ b/results/classifier/118/review/1337 @@ -0,0 +1,76 @@ +mistranslation: 0.962 +architecture: 0.919 +device: 0.785 +socket: 0.784 +x86: 0.723 +network: 0.679 +graphic: 0.648 +semantic: 0.637 +performance: 0.605 +PID: 0.534 +peripherals: 0.513 +files: 0.502 +virtual: 0.497 +i386: 0.491 +user-level: 0.462 +permissions: 0.444 +VMM: 0.444 +boot: 0.422 +hypervisor: 0.409 +debug: 0.405 +register: 0.395 +arm: 0.385 +risc-v: 0.355 +kernel: 0.333 +vnc: 0.296 +ppc: 0.265 +assembly: 0.242 +TCG: 0.184 +KVM: 0.136 +-------------------- +hypervisor: 0.938 +virtual: 0.753 +user-level: 0.705 +debug: 0.370 +VMM: 0.187 +kernel: 0.152 +x86: 0.150 +PID: 0.065 +TCG: 0.064 +socket: 0.057 +device: 0.056 +files: 0.053 +register: 0.053 +architecture: 0.032 +boot: 0.020 +network: 0.018 +semantic: 0.015 +performance: 0.007 +i386: 0.006 +assembly: 0.006 +risc-v: 0.005 +KVM: 0.005 +ppc: 0.002 +peripherals: 0.002 +permissions: 0.002 +graphic: 0.002 +vnc: 0.001 +arm: 0.001 +mistranslation: 0.001 + +Incorrect warnings when using vhost without numa +Description of problem: +Part A: Misleading error message. Running the above command for any architecture fails to initialize vhost, and prints the following, incorrect advice +``` +qemu-system-mips: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on +qemu-system-mips: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-mips: Error starting vhost: 22 +``` + +Since the command line already contains `-object memory-backend-file,id=mem1,mem-path=/tmp/mem,size=256M,share=on` this error message should not be printed. For x86_64, this can be resolved by adding `-numa node,memdev=mem0` to the command line. As such, I think this error message should instead guide a user to adding that argument. + +Part B: No documented configuration to run vhost-user for machines that don't support numa. +The mips malta machine does not support the `-numa` flag. It is unclear if this means that `vhost` cannot be used with this platform or if a non-numa configuration with a memory-backend-file can be used. +Steps to reproduce: +1. Run `vhost-user-vsock --socket=/tmp/vhost4.socket --uds-path=/tmp/foo` from https://github.com/rust-vmm/vhost-device. +1. Run the above QEMU command diff --git a/results/classifier/118/review/1338563 b/results/classifier/118/review/1338563 new file mode 100644 index 000000000..1d548c97c --- /dev/null +++ b/results/classifier/118/review/1338563 @@ -0,0 +1,102 @@ +user-level: 0.802 +network: 0.680 +semantic: 0.652 +mistranslation: 0.643 +files: 0.532 +device: 0.513 +hypervisor: 0.472 +permissions: 0.471 +performance: 0.452 +PID: 0.451 +architecture: 0.434 +socket: 0.426 +ppc: 0.425 +kernel: 0.416 +register: 0.408 +x86: 0.367 +graphic: 0.361 +KVM: 0.344 +i386: 0.343 +vnc: 0.340 +peripherals: 0.305 +TCG: 0.298 +virtual: 0.294 +VMM: 0.291 +arm: 0.283 +risc-v: 0.275 +boot: 0.272 +assembly: 0.230 +debug: 0.210 +-------------------- +files: 0.242 +user-level: 0.166 +x86: 0.092 +hypervisor: 0.057 +arm: 0.028 +i386: 0.015 +ppc: 0.011 +network: 0.010 +semantic: 0.008 +virtual: 0.006 +VMM: 0.006 +risc-v: 0.005 +register: 0.004 +PID: 0.003 +vnc: 0.003 +TCG: 0.003 +device: 0.002 +mistranslation: 0.002 +socket: 0.002 +debug: 0.001 +kernel: 0.001 +boot: 0.001 +performance: 0.001 +architecture: 0.001 +peripherals: 0.001 +graphic: 0.001 +permissions: 0.001 +assembly: 0.001 +KVM: 0.000 + +README refers to a non-extant file + +The current stable QEMU release (1.4.2-89400a8) README consists of a single line telling the new user to "read the documentation in qemu-doc.html or on http://wiki.qemu.org". The distribution includes no qemu-doc.html, just a qemu-doc.texi. + +qemu-doc.html appears when you build QEMU. + +Having qemu-doc.html appear once QEMU is built and installed (in the source folder and in /usr/local/share/doc/qemu) defeats the purpose of the README, which is the very first place a new user looks for building and installation instructions. + +The README needs to instruct the user to first run './configure', then 'make', then 'sudo make install'. The fourth bullet would then be something like "for further details, see qemu-doc.html or http://wiki.qemu.org" + +The QEMU wiki which is mentioned in the README includes documention, and there is a link to qemu-doc.html on http://wiki.qemu-project.org/Manual. + + +On 7 July 2014 18:57, Stefan Weil <email address hidden> wrote: +> The QEMU wiki which is mentioned in the README includes documention, and +> there is a link to qemu-doc.html on http://wiki.qemu-project.org/Manual. + +This is true, but I think it would be helpful if we specifically pointed the +user there for the how-to-compile-from-source instructions, since it's +otherwise not very obvious. + +In fact, the "compilation from source" section of qemu-doc.texi is +pretty badly out of date in several ways. It would probably be better +to extract it into a separate COMPILING plain text file, since it's +also not very friendly to require somebody compiling QEMU to have +either network access or to read raw .texi sources (and conversely +if you've got a pre-compiled QEMU then you don't have any interest +in reading stuff about configure and make). + +thanks +-- PMM + + +In 2020, the qemu documentation is now hosted online and doesn't require a build: https://www.qemu.org/documentation/ + +We are also very deep into a tree-wide overhaul to move our documentation onto Sphinx and begin providing versioned manuals. + +I'm closing this as fixed. + +This has actually been fixed by this commit here in 2015: +https://gitlab.com/qemu-project/qemu/-/commit/0a3c190098e1cb3da + diff --git a/results/classifier/118/review/1345 b/results/classifier/118/review/1345 new file mode 100644 index 000000000..ef4855819 --- /dev/null +++ b/results/classifier/118/review/1345 @@ -0,0 +1,61 @@ +mistranslation: 0.893 +device: 0.789 +graphic: 0.612 +network: 0.543 +arm: 0.491 +performance: 0.329 +files: 0.269 +architecture: 0.245 +semantic: 0.243 +debug: 0.171 +socket: 0.151 +kernel: 0.147 +boot: 0.146 +register: 0.138 +virtual: 0.134 +ppc: 0.128 +VMM: 0.117 +i386: 0.093 +PID: 0.089 +x86: 0.071 +hypervisor: 0.051 +TCG: 0.041 +peripherals: 0.041 +vnc: 0.034 +user-level: 0.033 +assembly: 0.020 +permissions: 0.009 +risc-v: 0.005 +KVM: 0.001 +-------------------- +virtual: 0.904 +hypervisor: 0.839 +semantic: 0.407 +files: 0.126 +user-level: 0.044 +VMM: 0.014 +debug: 0.014 +register: 0.012 +KVM: 0.009 +TCG: 0.009 +device: 0.008 +x86: 0.007 +kernel: 0.004 +boot: 0.004 +peripherals: 0.004 +performance: 0.003 +network: 0.003 +ppc: 0.003 +assembly: 0.002 +i386: 0.002 +graphic: 0.002 +socket: 0.002 +arm: 0.001 +mistranslation: 0.001 +PID: 0.001 +vnc: 0.001 +risc-v: 0.001 +architecture: 0.001 +permissions: 0.000 + +qemu-img manpage and is missing info on compression_type option diff --git a/results/classifier/118/review/1349277 b/results/classifier/118/review/1349277 new file mode 100644 index 000000000..c92defdb8 --- /dev/null +++ b/results/classifier/118/review/1349277 @@ -0,0 +1,122 @@ +architecture: 0.911 +graphic: 0.870 +performance: 0.856 +user-level: 0.837 +mistranslation: 0.829 +vnc: 0.820 +arm: 0.811 +device: 0.810 +permissions: 0.804 +PID: 0.804 +ppc: 0.783 +risc-v: 0.761 +semantic: 0.747 +socket: 0.732 +VMM: 0.715 +files: 0.691 +debug: 0.686 +TCG: 0.682 +register: 0.681 +KVM: 0.680 +network: 0.654 +boot: 0.651 +hypervisor: 0.650 +kernel: 0.639 +x86: 0.632 +i386: 0.631 +assembly: 0.592 +peripherals: 0.585 +virtual: 0.390 +-------------------- +kernel: 0.287 +architecture: 0.100 +debug: 0.088 +files: 0.087 +VMM: 0.086 +hypervisor: 0.078 +TCG: 0.073 +PID: 0.043 +network: 0.029 +virtual: 0.023 +risc-v: 0.020 +vnc: 0.020 +ppc: 0.020 +socket: 0.018 +user-level: 0.018 +semantic: 0.013 +performance: 0.013 +register: 0.012 +boot: 0.010 +device: 0.009 +arm: 0.008 +assembly: 0.007 +permissions: 0.002 +peripherals: 0.002 +KVM: 0.002 +graphic: 0.001 +mistranslation: 0.001 +x86: 0.001 +i386: 0.001 + +AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater + +The AArch64 emulation ignores SPSel=0 when: + +(1) taking an interrupt from an exception level greater than EL0 (e.g., EL1t), + +(2) returning from an exception (via ERET) to an exception level greater than EL0 (e.g., EL1t), with SPSR_ELx[SPSel]=0. + +The attached patch fixes the problem in my application. + +Background: + +I'm running a standalone application (toy OS) that is performing preemptive multithreading between threads running at EL1t, with exception handling / context switching occurring at EL1h. This bug causes the stack pointer to be corrupted in the threads running at EL1t (they end up with a version of the EL1h stack pointer (SP_EL1)). + +Occurs in: + qemu-2.1.0-rc1 (found in) + commit c60a57ff497667780132a3fcdc1500c83af5d5c0 (current master) + + + +On Mon, Jul 28, 2014 at 07:40:56AM -0000, T McIntosh wrote: +> Public bug reported: +> +> The AArch64 emulation ignores SPSel=0 when: +> +> (1) taking an interrupt from an exception level greater than EL0 (e.g., +> EL1t), +> +> (2) returning from an exception (via ERET) to an exception level greater +> than EL0 (e.g., EL1t), with SPSR_ELx[SPSel]=0. +> +> The attached patch fixes the problem in my application. + +Hi, + +Patches 1-3 in the following series fix the this problem. +http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg03675.html + +Cheers, +Edgar + + +The attachment "Proposed fix" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] + +Uploaded fixed package for Vivid: https://launchpad.net/ubuntu/+source/qemu/2.1+dfsg-7ubuntu3 + +Please let me know if this fixes the issue. + +This bug was fixed in the package qemu - 2.1+dfsg-7ubuntu3 + +--------------- +qemu (2.1+dfsg-7ubuntu3) vivid; urgency=medium + + * d/p/target-arm-A64-Break-out-aarch64_save-restore_sp.patch + d/p/target-arm-A64-Respect-SPSEL-in-ERET-SP-restore.patch + d/p/target-arm-A64-Respect-SPSEL-when-taking-exceptions.patch: + Cherry-pick of upstream patches in order to fix AArch64 emulation ignoring + SPSel=0 in certain conditions. (LP: #1349277) + -- Chris J Arges <email address hidden> Thu, 04 Dec 2014 14:17:01 -0600 + diff --git a/results/classifier/118/review/1352 b/results/classifier/118/review/1352 new file mode 100644 index 000000000..5ff58f462 --- /dev/null +++ b/results/classifier/118/review/1352 @@ -0,0 +1,61 @@ +architecture: 0.808 +device: 0.729 +virtual: 0.718 +performance: 0.571 +graphic: 0.539 +network: 0.520 +assembly: 0.445 +debug: 0.435 +hypervisor: 0.429 +arm: 0.389 +semantic: 0.362 +boot: 0.359 +VMM: 0.358 +permissions: 0.312 +PID: 0.308 +i386: 0.306 +TCG: 0.265 +vnc: 0.256 +ppc: 0.217 +files: 0.215 +x86: 0.214 +user-level: 0.145 +mistranslation: 0.123 +peripherals: 0.119 +KVM: 0.105 +register: 0.099 +socket: 0.085 +kernel: 0.059 +risc-v: 0.038 +-------------------- +hypervisor: 0.543 +virtual: 0.414 +VMM: 0.363 +assembly: 0.184 +files: 0.077 +x86: 0.056 +semantic: 0.047 +TCG: 0.039 +KVM: 0.024 +device: 0.023 +graphic: 0.020 +ppc: 0.007 +user-level: 0.007 +i386: 0.006 +register: 0.005 +arm: 0.004 +debug: 0.004 +boot: 0.004 +architecture: 0.003 +PID: 0.002 +kernel: 0.002 +risc-v: 0.001 +peripherals: 0.001 +performance: 0.001 +permissions: 0.001 +socket: 0.000 +vnc: 0.000 +mistranslation: 0.000 +network: 0.000 + +Building hw-display-virtio-*-gl modules with empty source set diff --git a/results/classifier/118/review/1355 b/results/classifier/118/review/1355 new file mode 100644 index 000000000..d0ddd3d09 --- /dev/null +++ b/results/classifier/118/review/1355 @@ -0,0 +1,61 @@ +architecture: 0.881 +debug: 0.832 +device: 0.795 +performance: 0.670 +network: 0.549 +graphic: 0.520 +x86: 0.513 +peripherals: 0.402 +kernel: 0.381 +semantic: 0.350 +mistranslation: 0.308 +socket: 0.293 +ppc: 0.293 +register: 0.293 +boot: 0.255 +arm: 0.243 +assembly: 0.193 +permissions: 0.174 +hypervisor: 0.163 +vnc: 0.147 +files: 0.135 +VMM: 0.048 +virtual: 0.040 +PID: 0.028 +user-level: 0.026 +TCG: 0.019 +KVM: 0.016 +risc-v: 0.015 +i386: 0.003 +-------------------- +virtual: 0.960 +hypervisor: 0.910 +debug: 0.687 +x86: 0.267 +PID: 0.182 +assembly: 0.175 +kernel: 0.076 +user-level: 0.045 +files: 0.039 +KVM: 0.026 +register: 0.025 +architecture: 0.017 +TCG: 0.015 +semantic: 0.011 +device: 0.009 +boot: 0.008 +performance: 0.005 +VMM: 0.003 +peripherals: 0.002 +ppc: 0.001 +graphic: 0.001 +permissions: 0.001 +risc-v: 0.001 +socket: 0.001 +network: 0.000 +i386: 0.000 +mistranslation: 0.000 +vnc: 0.000 +arm: 0.000 + +qemu-system-x86_64: Issue while setting TUNSETSTEERINGEBPF: Invalid argument with fd: 13, prog_fd: -1 diff --git a/results/classifier/118/review/1357175 b/results/classifier/118/review/1357175 new file mode 100644 index 000000000..89cfc1b2b --- /dev/null +++ b/results/classifier/118/review/1357175 @@ -0,0 +1,85 @@ +TCG: 0.902 +device: 0.837 +files: 0.798 +ppc: 0.790 +performance: 0.782 +architecture: 0.778 +hypervisor: 0.745 +socket: 0.742 +graphic: 0.699 +PID: 0.685 +network: 0.679 +semantic: 0.674 +permissions: 0.650 +peripherals: 0.626 +kernel: 0.613 +boot: 0.604 +arm: 0.596 +register: 0.552 +vnc: 0.549 +assembly: 0.516 +debug: 0.515 +user-level: 0.510 +risc-v: 0.490 +x86: 0.470 +mistranslation: 0.416 +virtual: 0.373 +i386: 0.341 +KVM: 0.324 +VMM: 0.309 +-------------------- +ppc: 0.941 +TCG: 0.479 +files: 0.241 +hypervisor: 0.094 +debug: 0.080 +user-level: 0.013 +PID: 0.011 +architecture: 0.009 +kernel: 0.008 +register: 0.008 +socket: 0.005 +semantic: 0.005 +device: 0.004 +virtual: 0.004 +boot: 0.003 +performance: 0.002 +assembly: 0.002 +VMM: 0.002 +vnc: 0.001 +risc-v: 0.001 +graphic: 0.001 +peripherals: 0.001 +KVM: 0.001 +network: 0.001 +permissions: 0.000 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 +arm: 0.000 + +qemu fails to build on powerpc64 + +Qemu fails to build on powerpc64, ELFv1 ABI, since the introduction of the ELFv2 ABI support. On FreeBSD/powerpc64 I see the following error building HEAD from today (8/14/2014): + +In file included from /home/chmeee/qemu-git/tcg/tcg.c:264: +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1737:3: error: #error "Unhandled abi" +In file included from /home/chmeee/qemu-git/tcg/tcg.c:264: +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c: In function 'tcg_target_qemu_prologue': +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: 'LINK_AREA_SIZE' undeclared (first use in this function) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: (Each undeclared identifier is reported only once +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: for each function it appears in.) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1778: error: 'LR_OFFSET' undeclared (first use in this function) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c: At top level: +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:2579: error: 'LINK_AREA_SIZE' undeclared here (not in a function) +/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:2605: error: 'LR_OFFSET' undeclared here (not in a function) +gmake[1]: *** [tcg/tcg.o] Error 1 + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU? + +It looks like this has been fixed in the intervening 3 years. I just tried building head on FreeBSD/powerpc64, and was successful. + +It looks like this has been fixed in the intervening 3 years. I just tried building head on FreeBSD/powerpc64, and was successful. + +OK, thanks for checking! + diff --git a/results/classifier/118/review/1362635 b/results/classifier/118/review/1362635 new file mode 100644 index 000000000..409c7d9ed --- /dev/null +++ b/results/classifier/118/review/1362635 @@ -0,0 +1,180 @@ +semantic: 0.891 +permissions: 0.885 +graphic: 0.878 +assembly: 0.851 +user-level: 0.851 +register: 0.846 +debug: 0.834 +architecture: 0.827 +mistranslation: 0.817 +PID: 0.816 +virtual: 0.812 +socket: 0.811 +risc-v: 0.811 +hypervisor: 0.805 +performance: 0.799 +device: 0.784 +boot: 0.780 +vnc: 0.778 +kernel: 0.771 +arm: 0.758 +TCG: 0.757 +peripherals: 0.701 +network: 0.692 +KVM: 0.675 +ppc: 0.661 +files: 0.655 +x86: 0.652 +VMM: 0.572 +i386: 0.536 +-------------------- +kernel: 0.758 +debug: 0.643 +assembly: 0.072 +x86: 0.064 +hypervisor: 0.038 +semantic: 0.034 +device: 0.033 +files: 0.030 +TCG: 0.029 +VMM: 0.023 +i386: 0.022 +PID: 0.018 +risc-v: 0.017 +virtual: 0.012 +architecture: 0.012 +ppc: 0.010 +performance: 0.009 +peripherals: 0.009 +KVM: 0.009 +arm: 0.009 +register: 0.008 +user-level: 0.006 +boot: 0.006 +socket: 0.006 +vnc: 0.005 +permissions: 0.004 +network: 0.003 +graphic: 0.001 +mistranslation: 0.001 + +bdrv_read co-routine re-entered recursively + +calling bdrv_read in a loop leads to the follwing situation: + +bs->drv->bdrv_aio_readv is called, and finally calls bdrv_co_io_em_complete in other thread context. +there is a possibility of calling bdrv_co_io_em_complete before calling qemu_coroutine_yield in bdrv_co_io_em. And qemu fails with "co-routine re-entered recursively". + +static void bdrv_co_io_em_complete(void *opaque, int ret) +{ + CoroutineIOCompletion *co = opaque; + + co->ret = ret; + qemu_coroutine_enter(co->coroutine, NULL); +} + +static int coroutine_fn bdrv_co_io_em(BlockDriverState *bs, int64_t sector_num, + int nb_sectors, QEMUIOVector *iov, + bool is_write) +{ + CoroutineIOCompletion co = { + .coroutine = qemu_coroutine_self(), + }; + BlockDriverAIOCB *acb; + + if (is_write) { + acb = bs->drv->bdrv_aio_writev(bs, sector_num, iov, nb_sectors, + bdrv_co_io_em_complete, &co); + } else { + acb = bs->drv->bdrv_aio_readv(bs, sector_num, iov, nb_sectors, + bdrv_co_io_em_complete, &co); + } + + trace_bdrv_co_io_em(bs, sector_num, nb_sectors, is_write, acb); + if (!acb) { + return -EIO; + } + qemu_coroutine_yield(); + + return co.ret; +} + +is it a bug, or may be I don't understand something? + +the problem is taking place only when call bdrv_read frome separate thread. + +On Fri, Aug 29, 2014 at 11:16:16AM -0000, senya wrote: +> the problem is taking place only when call bdrv_read frome separate +> thread. + +You probably shouldn't be using threads. + +Can you explain what you are trying to do? + +Stefan + + +I'm trying to reanimate github.com/jagane/qemu-kvm-livebackup +there is a separate thread which connects with client through socket and sends disk blocks to it. + +It seems like I only need to put all my bdrv_read's into one co-routine and start it + +On Mon, Sep 01, 2014 at 07:55:22AM -0000, senya wrote: +> I'm trying to reanimate github.com/jagane/qemu-kvm-livebackup +> there is a separate thread which connects with client through socket and sends disk blocks to it. + +Regarding your original question about threads: it is possible to do +block I/O from threads but there are rules about how to do that safely. +The natural way to do things in QEMU is not with threads, this was +always an issue with Jagane's patches (I guess he didn't want to spend +time integrating it into QEMU's main loop when prototyping the code but +it's not a good long-term solution). + +More about livebackup: + +There has been more recent work by Fam Zheng to achieve the same thing. +The advantage of Fam's approach is that it reuses existing QEMU +primitives instead of adding special case livebackup code. + +Fam has moved on to other work but his latest patches are from May so +picking them up again shouldn't be that hard. + +It consists of two things: image fleecing and dirty bitmap commands. + +Image fleecing gives cheap access to a point-in-time snapshot of the +disk (over NBD). Internally it uses the run-time NBD server and the +block-backup command to export a point-in-time snapshot. + +The dirty bitmap provides what Jagane did but the plan is to also +persist bitmaps across QEMU shutdown. This will make incremental +backups easy. + +Please see Part IV of the "Block layer status report" presentation for +an overview: +http://www.linux-kvm.org/wiki/images/4/41/Kvm-forum-2013-block-layer-status-report.pdf + +Here are Fam's patch series: +https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03880.html +https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05250.html + +The first step is getting the image fleecing code merged. Then the +in-memory dirty bitmap can be merged. Finally, persistent dirty bitmap +support can be written. + +Stefan + + +Thanks.. I know about Fam's patch, but I need reverse delta backups, and Jagane's work is more appropriate then qemu snapshot approach. + +On Mon, Sep 08, 2014 at 08:01:18AM -0000, senya wrote: +> Thanks.. I know about Fam's patch, but I need reverse delta backups, and +> Jagane's work is more appropriate then qemu snapshot approach. + +Jagane's approach needs a lot of work to make it mergable, that's why I +suggested Fam's work. + +Stefan + + +Closing this ticket now, since it's not about upstream QEMU code. + diff --git a/results/classifier/118/review/1367365 b/results/classifier/118/review/1367365 new file mode 100644 index 000000000..7c6c8c6b5 --- /dev/null +++ b/results/classifier/118/review/1367365 @@ -0,0 +1,87 @@ +mistranslation: 0.917 +graphic: 0.742 +files: 0.714 +device: 0.712 +architecture: 0.611 +network: 0.602 +ppc: 0.585 +semantic: 0.578 +performance: 0.575 +socket: 0.528 +hypervisor: 0.518 +register: 0.498 +kernel: 0.469 +peripherals: 0.455 +vnc: 0.440 +permissions: 0.429 +PID: 0.407 +risc-v: 0.399 +boot: 0.389 +user-level: 0.369 +VMM: 0.368 +KVM: 0.309 +debug: 0.302 +x86: 0.298 +TCG: 0.274 +i386: 0.257 +virtual: 0.254 +arm: 0.235 +assembly: 0.233 +-------------------- +hypervisor: 0.875 +debug: 0.083 +files: 0.063 +virtual: 0.056 +TCG: 0.042 +user-level: 0.018 +semantic: 0.008 +device: 0.007 +x86: 0.007 +PID: 0.005 +kernel: 0.004 +network: 0.004 +socket: 0.004 +performance: 0.004 +boot: 0.002 +assembly: 0.002 +risc-v: 0.002 +register: 0.002 +i386: 0.002 +VMM: 0.002 +graphic: 0.002 +ppc: 0.001 +architecture: 0.001 +permissions: 0.001 +vnc: 0.001 +arm: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +qemu-img fixed vhd issues + +qemu-img returns fixed vhd images file format to be raw. + +This happens because only the header is seeked for image signatures when getting the image format. In fact, unlike dynamic vhd images, differencing vhds don't have the footer copied in the header. + +An easy fix would be to just search the last 512B for the 'conectix' signature. + +Also, the fixed vhds created by qemu-img seem to be corrupted from Powershell POV. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Otherwise, can you provide some test images or a description how to create such images? + +Yes I can reproduce this issue on Windows 10 with newest version of QEMU (until 03/28/2018) + +I've posted my way of reproduce in a new bug issue: +`#1759522 windows qemu-img create vpc/vhdx error` + +Sorry for the mistaken operation (changed to confirmed), I didn't mean to change the status + + +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/107 + + diff --git a/results/classifier/118/review/1381 b/results/classifier/118/review/1381 new file mode 100644 index 000000000..3b763bacd --- /dev/null +++ b/results/classifier/118/review/1381 @@ -0,0 +1,63 @@ +user-level: 0.910 +network: 0.881 +device: 0.876 +graphic: 0.850 +ppc: 0.737 +performance: 0.684 +semantic: 0.663 +arm: 0.635 +vnc: 0.547 +socket: 0.530 +boot: 0.494 +debug: 0.440 +risc-v: 0.438 +VMM: 0.394 +i386: 0.365 +x86: 0.341 +PID: 0.284 +architecture: 0.282 +mistranslation: 0.278 +TCG: 0.210 +kernel: 0.195 +assembly: 0.193 +files: 0.185 +register: 0.176 +virtual: 0.164 +KVM: 0.116 +hypervisor: 0.103 +permissions: 0.048 +peripherals: 0.039 +-------------------- +debug: 0.655 +virtual: 0.086 +TCG: 0.063 +files: 0.054 +x86: 0.046 +VMM: 0.045 +user-level: 0.034 +KVM: 0.032 +register: 0.031 +performance: 0.025 +semantic: 0.013 +assembly: 0.008 +ppc: 0.008 +risc-v: 0.008 +PID: 0.007 +hypervisor: 0.005 +device: 0.003 +kernel: 0.003 +i386: 0.003 +network: 0.003 +arm: 0.002 +architecture: 0.002 +boot: 0.002 +permissions: 0.001 +vnc: 0.001 +socket: 0.001 +graphic: 0.001 +mistranslation: 0.000 +peripherals: 0.000 + +plugins: plugin_mem_cbs is not consistently NULL'ed when returning from execution +Description of problem: +This is an invariant that we should have been checking for; when returning from execution, cpu->plugin_mem_cbs should be NULL. Otherwise we open a door for a use-after-free; admittedly this door isn't that large (it requires a tb_flush to occur while we have the dangling plugin_mem_cbs), but at least one plugin user has encountered this problem: https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg02703.html diff --git a/results/classifier/118/review/1383 b/results/classifier/118/review/1383 new file mode 100644 index 000000000..2318575f5 --- /dev/null +++ b/results/classifier/118/review/1383 @@ -0,0 +1,61 @@ +mistranslation: 0.952 +device: 0.806 +architecture: 0.648 +semantic: 0.533 +PID: 0.461 +performance: 0.414 +graphic: 0.400 +network: 0.284 +ppc: 0.255 +debug: 0.201 +risc-v: 0.124 +hypervisor: 0.106 +arm: 0.094 +boot: 0.093 +register: 0.073 +peripherals: 0.073 +virtual: 0.058 +user-level: 0.056 +permissions: 0.056 +vnc: 0.041 +VMM: 0.034 +assembly: 0.021 +kernel: 0.020 +socket: 0.016 +files: 0.013 +TCG: 0.010 +i386: 0.006 +x86: 0.005 +KVM: 0.004 +-------------------- +x86: 0.938 +semantic: 0.726 +PID: 0.683 +device: 0.141 +ppc: 0.098 +performance: 0.067 +user-level: 0.046 +virtual: 0.019 +VMM: 0.016 +debug: 0.015 +register: 0.012 +files: 0.006 +kernel: 0.005 +assembly: 0.005 +boot: 0.004 +socket: 0.004 +permissions: 0.003 +mistranslation: 0.003 +TCG: 0.003 +i386: 0.003 +architecture: 0.002 +graphic: 0.002 +KVM: 0.001 +peripherals: 0.001 +hypervisor: 0.001 +arm: 0.001 +vnc: 0.000 +network: 0.000 +risc-v: 0.000 + +Pentium Pro cpuid capabilities are wrong, resulting in wrong definition of athlon and others diff --git a/results/classifier/118/review/1390 b/results/classifier/118/review/1390 new file mode 100644 index 000000000..ec13ef999 --- /dev/null +++ b/results/classifier/118/review/1390 @@ -0,0 +1,61 @@ +architecture: 0.976 +device: 0.706 +performance: 0.600 +mistranslation: 0.542 +graphic: 0.468 +ppc: 0.453 +boot: 0.315 +semantic: 0.307 +kernel: 0.295 +permissions: 0.287 +x86: 0.275 +socket: 0.269 +risc-v: 0.239 +virtual: 0.191 +debug: 0.187 +PID: 0.181 +vnc: 0.175 +assembly: 0.160 +register: 0.144 +VMM: 0.126 +TCG: 0.119 +arm: 0.113 +user-level: 0.100 +network: 0.068 +files: 0.062 +i386: 0.051 +KVM: 0.033 +hypervisor: 0.016 +peripherals: 0.002 +-------------------- +user-level: 0.725 +x86: 0.710 +device: 0.654 +PID: 0.288 +VMM: 0.104 +ppc: 0.101 +virtual: 0.067 +socket: 0.043 +peripherals: 0.026 +semantic: 0.025 +kernel: 0.020 +files: 0.020 +TCG: 0.016 +KVM: 0.012 +register: 0.011 +performance: 0.010 +risc-v: 0.009 +boot: 0.007 +architecture: 0.006 +hypervisor: 0.005 +assembly: 0.004 +arm: 0.003 +network: 0.003 +mistranslation: 0.002 +vnc: 0.002 +graphic: 0.002 +permissions: 0.002 +i386: 0.001 +debug: 0.001 + +Any plans for P5020 P5040 CPUs? diff --git a/results/classifier/118/review/1392468 b/results/classifier/118/review/1392468 new file mode 100644 index 000000000..19784706a --- /dev/null +++ b/results/classifier/118/review/1392468 @@ -0,0 +1,86 @@ +user-level: 0.822 +graphic: 0.516 +device: 0.443 +semantic: 0.401 +performance: 0.378 +architecture: 0.333 +ppc: 0.329 +mistranslation: 0.290 +permissions: 0.265 +socket: 0.253 +register: 0.212 +files: 0.206 +boot: 0.177 +network: 0.163 +PID: 0.158 +vnc: 0.129 +peripherals: 0.128 +x86: 0.116 +arm: 0.108 +risc-v: 0.092 +kernel: 0.092 +VMM: 0.087 +i386: 0.087 +virtual: 0.084 +debug: 0.082 +TCG: 0.068 +hypervisor: 0.064 +KVM: 0.038 +assembly: 0.024 +-------------------- +graphic: 0.761 +user-level: 0.198 +hypervisor: 0.131 +x86: 0.113 +files: 0.105 +TCG: 0.008 +register: 0.005 +PID: 0.003 +virtual: 0.003 +network: 0.003 +device: 0.003 +i386: 0.002 +semantic: 0.002 +arm: 0.002 +boot: 0.002 +socket: 0.001 +performance: 0.001 +debug: 0.001 +ppc: 0.001 +kernel: 0.001 +architecture: 0.001 +peripherals: 0.001 +risc-v: 0.001 +permissions: 0.001 +vnc: 0.000 +VMM: 0.000 +assembly: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +qemu uses a bitmap icon + +qemu currently uses the icon in pc-bios/qemu-icon.bmp, which, obviously, is a bitmap file. It is loaded such that white pixels will be transparent. This can cause nasty artifacts in the display. + +Unless there is a specific reason to use bitmaps, I'd suggest moving to, e.g., a PNG file with a proper alpha channel. + +For me the icon looks ugly if QEMU is run by the normal user. However, when run via sudo, it looks normal for some reason and does not display any of the white pixels. + +I also see an ugly icon when running QEMU as a user in GNOME. I tried running QEMU as root to see if there is any difference, but it doesn't work at all. I think QEMU should use pc-bios/qemu_logo_no_text.svg instead of pc-bios/qemu-icon.bmp. + +Gees, some please fix this already! Ubuntu 16.04.2 also uses some ugly icon. Why not ditch the bitmaps and use this official svg? + +http://git.qemu.org/?p=qemu.git;a=blob_plain;f=pc-bios/qemu_logo_no_text.svg;hb=HEAD + + + +On Ubuntu 18.04 and this is still an issue. + +Please don't make QEMU look like a crappy piece of software. It deserves a crisp icon. + +This series gives the QEMU SDL2 & GTK frontends high quality icons http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg04475.html + + +Finally fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a442fe2f2b2f20e7be0 + diff --git a/results/classifier/118/review/1392504 b/results/classifier/118/review/1392504 new file mode 100644 index 000000000..276c10bf8 --- /dev/null +++ b/results/classifier/118/review/1392504 @@ -0,0 +1,359 @@ +risc-v: 0.857 +virtual: 0.844 +user-level: 0.841 +permissions: 0.834 +peripherals: 0.796 +arm: 0.793 +hypervisor: 0.792 +device: 0.790 +KVM: 0.786 +socket: 0.767 +boot: 0.767 +register: 0.765 +debug: 0.759 +TCG: 0.754 +graphic: 0.752 +network: 0.745 +performance: 0.745 +mistranslation: 0.722 +files: 0.722 +architecture: 0.719 +VMM: 0.706 +assembly: 0.706 +ppc: 0.705 +x86: 0.693 +PID: 0.687 +vnc: 0.686 +kernel: 0.683 +semantic: 0.638 +i386: 0.630 +-------------------- +virtual: 0.877 +x86: 0.603 +hypervisor: 0.598 +KVM: 0.380 +register: 0.122 +user-level: 0.085 +TCG: 0.059 +debug: 0.045 +boot: 0.043 +kernel: 0.042 +device: 0.040 +files: 0.038 +peripherals: 0.035 +PID: 0.028 +socket: 0.025 +VMM: 0.019 +network: 0.017 +semantic: 0.017 +ppc: 0.014 +risc-v: 0.010 +i386: 0.006 +assembly: 0.005 +performance: 0.005 +vnc: 0.004 +architecture: 0.004 +arm: 0.002 +graphic: 0.002 +permissions: 0.002 +mistranslation: 0.001 + +libvirt not relabeling devices on USB Passthrough + +After upgrading from Ubuntu 14.04 to Ubuntu 14.10 USB passthrough in QEMU (version is now 2.1.0 - Debian2.1+dfsg-4ubuntu6.1) is not working any more. Already tried to remove and attach the USB devices. I use 1 USB2 HDD + 1 USB3 HDD to a virtual linux machine; 1 USB2 HDD to a virual FNAS machine and a USB 2camera to virtual Win7 machine. All these devices are not working any more. + +On 2014/11/14 6:12, Leen Keus wrote: + +> Public bug reported: +> +> After upgrading from Ubuntu 14.04 to Ubuntu 14.10 USB passthrough in +> QEMU (version is now 2.1.0 - Debian2.1+dfsg-4ubuntu6.1) is not working +> any more. Already tried to remove and attach the USB devices. I use 1 +> USB2 HDD + 1 USB3 HDD to a virtual linux machine; 1 USB2 HDD to a +> virual FNAS machine and a USB 2camera to virtual Win7 machine. All these +> devices are not working any more. +> + +What's your meaning "are not working any more", any details? + +Regards, +-Gonglei + + + + +Under Ubuntu 14.04 the USB devices where attached to the virtual machines. After upgrading to Ubuntu 14.10 the USB devices are not visible in the virtual machines anymore. Same issue appeard after upgrading from Ubuntu 13.04 to 13.10, but I can not find that bug report anymore. + +On 2014/11/14 16:47, Leen Keus wrote: + +> Under Ubuntu 14.04 the USB devices where attached to the virtual +> machines. After upgrading to Ubuntu 14.10 the USB devices are not +> visible in the virtual machines anymore. Same issue appeard after +> upgrading from Ubuntu 13.04 to 13.10, but I can not find that bug report +> anymore. +> + +Please show your command line booting VM. +Or you can get the latest Qemu master code to reproduce your +problem. Maybe it is a resolved issue. :) + +Best regards, +-Gonglei + + + +Command lines generated by virsh from the libvirt xml files (let me know if you also need the xml configuration files): + +qemu-system-x86_64 -enable-kvm -name fsg -S -machine pc-1.2,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 30619811-d285-944a-026a-cdd4a753b77a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fsg.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5 -drive file=/vm2/fsgorg/disk-sda2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/vm2/fsgorg/disk-sdb.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -netdev tap,fd=23,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:76:fd:b6,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=1,hostaddr=4,id=hostdev0 -device usb-host,hostbus=4,hostaddr=2,id=hostdev1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on + + + +qemu-system-x86_64 -enable-kvm -name fnas -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 7c2703e5-b8b8-acd9-df8b-6284382fb58b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fnas.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/vm2/FreeNAS/fnas.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/vm2/FreeNAS/fnas2.qcow2,if=none,id=drive-ide0-0-1,format=qcow2 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:d8:31:b5,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:5 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=2,hostaddr=3,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + + +qemu-system-x86_64 -enable-kvm -name win7 -S -machine pc-1.2,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 717d41d2-cfc9-5d70-e2f5-817c2ed1a90a -nouser-config -nodefaults -chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -drive file=/vm/Windows7/win7.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/vm/Windows7/joespb.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3c:7b:7f,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:2 -device VGA,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=1,hostaddr=3,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -usb -msg timestamp=on + +Regards, +Leen + +At first glance I see "-machine pc-1.2,accel=kvm,usb=off" and then "-device nec-usb-xhci,id=usb,bus=pci.0,addr=0x5"... I'm not sure if those should be used together. + +Can you look in your libvirt logs from before the upgrade to see if it was using the usb=off option before? + +@kraxel-redhat do you know if that's a legitimate set of options? + +Yes, it is valid. libvirt is disabling the automagic UHCI controller, which makes sense since he is using XHCI. + +On 2014/11/14 19:57, Leen Keus wrote: + +> Command lines generated by virsh from the libvirt xml files (let me know if you also need the xml configuration files): +> +Does this below patch fix your problem? + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=79ae25af1569a50a0ec799901a1bb280c088f121 + +Regards, +-Gonglei + + + + +I greatly appriciate your help to find a solution for this issue, but I have used apt-get to installed QEMU already since version 12.10. I never used the QEMU source code for something. Is it possible that you provide an updated executable or library? +Regards, +Leen + + +@Leen, + +I am pushing qemu 2.1+dfsg-4ubuntu6.3~ppa1 (which includes the fix proposed by Gonglei in comment #7) to ppa:serge-hallyn/libvirt-testing. Please let us know whether it does in fact solve your issue. + +Hi Serge, just tested your solution but unfortunately with no success. I also removed a vm and created it again, also with no luck. Sorry ... + +Same issue appeard after upgrading from Ubuntu 13.04 to 13.10; bug: 1245251 (Apparmor blocks usb devices in libvirt in Saucy). Could it be related to this issue? Maybe a new or other line in /etc/apparmor.d/abstractions/libvirt-qemu? + + +I just wanted to add another data point -- I migrated my old WinXP VM from my 14.04 install to my new 14.10 install and found out that the USB passthrough is not working -- Same libvirt XML definition file. Tried removing and re-adding with no luck. + +I think it is related to Apparmor, I see the following lines in /etc/syslog: + +Nov 22 14:36:23 uvir kernel: [18882.602278] audit: type=1400 audit(1416663383.171:69): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb3/uevent" pid=14279 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 22 14:36:23 uvir kernel: [18882.602295] audit: type=1400 audit(1416663383.171:70): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb3/3-0:1.0/uevent" pid=14279 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 22 14:36:23 uvir kernel: [18882.602306] audit: type=1400 audit(1416663383.171:71): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/uevent" pid=14279 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 22 14:36:23 uvir kernel: [18882.602318] audit: type=1400 audit(1416663383.171:72): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-0:1.0/uevent" pid=14279 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 22 14:36:23 uvir kernel: [18882.602330] audit: type=1400 audit(1416663383.171:73): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-2/uevent" pid=14279 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 00:28:39 uvir kernel: [35109.848778] audit: type=1400 audit(1416698919.255:181): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb3/uevent" pid=25427 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 00:28:39 uvir kernel: [35109.848799] audit: type=1400 audit(1416698919.255:182): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb3/3-0:1.0/uevent" pid=25427 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 00:28:39 uvir kernel: [35109.848815] audit: type=1400 audit(1416698919.255:183): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/uevent" pid=25427 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 00:28:39 uvir kernel: [35109.848831] audit: type=1400 audit(1416698919.255:184): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-0:1.0/uevent" pid=25427 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 00:28:39 uvir kernel: [35109.848847] audit: type=1400 audit(1416698919.255:185): apparmor="DENIED" operation="open" profile="libvirt-30619811-d285-944a-026a-cdd4a753b77a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-2/uevent" pid=25427 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 09:07:11 uvir kernel: [ 33.270565] audit: type=1400 audit(1416730031.240:59): apparmor="DENIED" operation="open" profile="libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb3/uevent" pid=3599 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 09:07:11 uvir kernel: [ 33.270588] audit: type=1400 audit(1416730031.240:60): apparmor="DENIED" operation="open" profile="libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb3/3-0:1.0/uevent" pid=3599 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 09:07:11 uvir kernel: [ 33.270606] audit: type=1400 audit(1416730031.240:61): apparmor="DENIED" operation="open" profile="libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/uevent" pid=3599 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 +Nov 23 09:07:11 uvir kernel: [ 33.270625] audit: type=1400 audit(1416730031.240:62): apparmor="DENIED" operation="open" profile="libvirt-717d41d2-cfc9-5d70-e2f5-817c2ed1a90a" name="/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/usb4/4-0:1.0/uevent" pid=3599 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=106 ouid=0 + + +I just noticed that after I applied the latest updates (apt-get dist-ugrade) to my Ubuntu 14.04 system that USB redirection is now failing on THIS system as well - just like the 14.10 system failed. + +FWIW, I do not see any apparomor denial messages in /var/log/syslog or anywhere else. So far I've not found anything to indicate why passthrough failed, seems like a silent failure whatever it is. + +I don't know if it is relevant, but in the error message of apparmor is says: comm="qemu-system-x86"; while libvirt starts qemu-system-x86_64. Anybody searching for a solution? I am not able to make backups since the upgrade to 14.10... + +Please disregard my previous comment about being broken in 14.04 -- In fact I was running 14.10 and didn't realize it (a reboot and 14.10 being the grub default). In fact the passthrough still works in 14.04 just fine, and still fully broken in 14.10. + +I did confirm, however, that there are NO apparmor messages regarding qemu on my 14.10 system. + + +Found the following lines in /var/log/libvirt/qemu/<machine>.log +libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device /dev/bus/usb/001/004: Permission denied +libusbx: error [_get_usbfs_fd] libusbx requires write access to USB device nodes. +libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device /dev/bus/usb/001/004: Permission denied +libusbx: error [_get_usbfs_fd] libusbx requires write access to USB device nodes. +libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device /dev/bus/usb/001/004: Permission denied +libusbx: error [_get_usbfs_fd] libusbx requires write access to USB device nodes. + +I just installed libvirt 1.2.8 on ubuntu utopic and usb passthrough does not work on a linux vm +I got the libusbx error in the livert VM log + +@lj-keus + +if you turn off apparmor + +sudo /etc/init.d/apparmor stop +sudo /etc/init.d/apparmor teardown + +does that fix the issue for you? + +(Please re-enable apparmor immediately after the test using + +sudo /etc/init.d/apparmor start +sudo stop libvirt-bin +sudo start libvirt-bin +) + +Hi Serge, + +Following error message appears after I teared down apparmor and when I tried to start the vm: + +$sudo virsh start <vm> +error: Failed to start domain <vm> +error: error from service: ListActivatableNames: Failed to query AppArmor policy: No such file or directory + +Can anybody provide me a list of settings, for the OS, apparmor, libvirt, qemu, etc., etc. that can I check for this issue? + + + +I haven't seen an error like that, and cannot reproduce it here. + +Another way to test that apparmor is causing the problem would be to add + + /dev/** rw, + +at the bottom of the file /etc/apparmor.d/abstractions/libvirt-qemu. When you next start the vm apparmor should allow it full access to all devices. + +You also should be able to do + + aa-audit /usr/sbin/libvirtd + +which should put informative messages into /var/log/syslog or +/var/log/audit/audit.log as well. + + +I don't run apparmor. + +Ubuntu 14.10 host + +Have this same issue with USB Host Attachment on Windows and Linux guests. +USB Redirection using SPICE is unaffected and works as expected. + +Libvirt logs show... +libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device /dev/bus/usb/003/006: Permission denied +libusbx: error [_get_usbfs_fd] libusbx requires write access to USB device nodes. + +'chown libvirt-qemu:kvm /dev/bus/usb/003/006' solves the problem and USB Host Attachment now works again. + +Host dmesg shows... +usb 3-13: reset high-speed USB device number 9 using xhci_hcd +[ 3346.483029] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8807ba9beb40 +...USB device needs to be physically detached and re-attached for host to see again. + +Tested this with a Sandisk Cruzer Blade 16GB and a Logitech HD C525. + + +Hi Kevin, finally somebody that found a solution. Great, thank you very much! It is working now. + +Has anyone tested whether this is still broken in 15.04? + +I'm running an ACS patched linux mainline 3.18 as well as Ubuntu 14.10 stock. Haven't tested the Ubuntu 15.04 stock but will grab the debs and confirm. + +...actually are you talking kernel or the full 15.04 pre-release? + +Actually I was talking about just libvirt. cmment #23 (and 24) suggests that the problem is libvirt not re-labeling the devices, so i'm wondering whether 1.2.12 fixes it. + +I have done the suggested in comment 23 , but the problem persist, after i lunch the guest, i receive the following erros, and lsusb in the guest doesnt show the attached usb device: + +Host: + + ll /dev/bus/usb/001/ +crw-rw-r-- 1 libvirt-qemu kvm 189, 9 Mar 29 21:21 010 + +lsusb: +Bus 001 Device 010: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n + +syslog + +Mar 29 21:21:57 ivan-desktop kernel: [168754.517390] usb 1-1: reset high-speed USB device number 10 using xhci_hcd +Mar 29 21:21:57 ivan-desktop kernel: [168754.666064] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264600 +Mar 29 21:21:57 ivan-desktop kernel: [168754.666080] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264648 +Mar 29 21:21:57 ivan-desktop kernel: [168754.666086] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264690 +Mar 29 21:21:57 ivan-desktop kernel: [168754.666090] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a2646d8 +Mar 29 21:21:57 ivan-desktop kernel: [168754.666095] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264720 +Mar 29 21:21:57 ivan-desktop kernel: [168754.666099] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264768 + + +libvirt-bin 1.2.8-0ubuntu11.4 +qemu 2.1+dfsg-4ubuntu6.4 +Ubuntu 14.10 3.19.2-031902-generic + + +Hey nickmaelao, your outputs show you've only changed the ownership of the USB bus and not the USB device itself...I'd suspect if you looked at 'ls -la /dev/bus/usb/001/' then the actual USB device will still have root ownership. Ergo if libvirtd is still creating the vm's with qemu and a non-root user you will still have the problem. + +chmod libvirt-qemu:kvm /dev/bus/usb/001/xxx (xxx being the USB device numeber) should resolve. + +Alternatively you could change /etc/libvirtd/qemu.conf and make libvirtd create guests with qemu as the root user, look for the 'user = ' and 'group = ' lines. I can't comment on the risk associated to this so you'll need to look into that yourself but I've taken this approach and have no problems with USB attachment and I don't need to manually change device ownerships. + +Sorry, i posted the wrong output, i had modified the ownership of usb the device /dev/bus/usb/001/010 to libvirt-qemu:kvm, but the problem persists. + +I configured libvirt to run as root, but the problem is the same, in syslog im still receiving + +Mar 29 22:54:42 ivan-desktop kernel: [174324.769452] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264600 +Mar 29 22:54:42 ivan-desktop kernel: [174324.769470] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264648 +Mar 29 22:54:42 ivan-desktop kernel: [174324.769479] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264690 +Mar 29 22:54:42 ivan-desktop kernel: [174324.769489] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a2646d8 +Mar 29 22:54:42 ivan-desktop kernel: [174324.769497] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264720 +Mar 29 22:54:42 ivan-desktop kernel: [174324.769506] xhci_hcd 0000:00:10.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010a264768 +Mar 29 22:54:42 ivan-desktop kernel: [174324.981362] usb 1-1: reset high-speed USB device number 10 using xhci_hcd + +Heres the portion of the qemu xml of the guest: + +<hostdev mode='subsystem' type='usb' managed='yes'> + <source> + <vendor id='0x0cf3'/> + <product id='0x9271'/> + <address bus='1' device='10'/> + </source> + <alias name='hostdev0'/> + </hostdev> + + + +The syslog output looks like its from the Host not the guest? + +What does the libvirtd log say for the guest...typically at /var/log/libvirt/qemu/XXX (XXX being the name of the guest). + +There are 2 separate issues/related in this thread, first being USB attachment to guests not working which is believed ownership related hence my *workaround* in post #23. The second is about how the USB device is re-atrached to the Host once the guest has been destroyed...this is what the syslog/dmesg outputs are about and why Serge has renamed the bug report. + +Your posts say you are having problem with both which seems odd and not possible? + +Hi all, recently upgraded to 15.04 and the issue is solved in this version. + +Hi, same problem on my machine ... Comment #23 does not work for me. In my VM log I found this line: + +libusb_set_configuration: -6 [BUSY] + +I'm running 14.04 (fresh install), QEMU 2.0.0. Any suggestions? + +Status changed to 'Confirmed' because the bug affects multiple users. + +Hi, +seeing this due to the move of upstream qemu->qemu(ubuntu). +This is a libvirt issue, not qemu so marking this as that. + +Xenial was already better in this regard which also seems to match the report in comment #33. +Furthermore I fixed quite some usb passthrough issues (4 I think) on the way from xenial to Bionic. +Also I didn't hear about is anymore for years other than in the post-xenial context that I was driving with a few bug reporters since then. + +I'll mark the bug invalid, but if anyone really is still affected I would ask you to (also) test with Bionic (18.04) if possible. + +[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1393440 b/results/classifier/118/review/1393440 new file mode 100644 index 000000000..15cc9de9a --- /dev/null +++ b/results/classifier/118/review/1393440 @@ -0,0 +1,81 @@ +ppc: 0.937 +mistranslation: 0.857 +device: 0.853 +network: 0.773 +socket: 0.749 +register: 0.749 +files: 0.681 +performance: 0.658 +peripherals: 0.634 +PID: 0.614 +vnc: 0.607 +architecture: 0.599 +semantic: 0.591 +permissions: 0.561 +graphic: 0.556 +hypervisor: 0.506 +debug: 0.483 +kernel: 0.482 +i386: 0.451 +user-level: 0.427 +x86: 0.418 +TCG: 0.409 +arm: 0.371 +KVM: 0.336 +risc-v: 0.331 +VMM: 0.291 +boot: 0.275 +assembly: 0.252 +virtual: 0.229 +-------------------- +debug: 0.607 +x86: 0.318 +hypervisor: 0.208 +files: 0.138 +ppc: 0.114 +TCG: 0.091 +device: 0.053 +register: 0.044 +virtual: 0.039 +i386: 0.033 +user-level: 0.033 +kernel: 0.026 +semantic: 0.023 +VMM: 0.022 +architecture: 0.018 +peripherals: 0.018 +PID: 0.016 +KVM: 0.009 +assembly: 0.008 +network: 0.006 +arm: 0.006 +boot: 0.006 +performance: 0.004 +risc-v: 0.003 +graphic: 0.003 +permissions: 0.003 +socket: 0.002 +vnc: 0.001 +mistranslation: 0.001 + +pcie.c:148: possible error in OR expression ? + +[qemu/hw/pci/pcie.c:148] -> [qemu/hw/pci/pcie.c:148]: (style) Same expression on both sides of '|'. + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_URD | PCI_EXP_DEVSTA_URD); + +I am guessing that something like + + pci_long_test_and_set_mask(dev->w1cmask + pos + PCI_EXP_DEVSTA, + PCI_EXP_DEVSTA_CED | PCI_EXP_DEVSTA_NFED | + PCI_EXP_DEVSTA_FED | PCI_EXP_DEVSTA_URD); + +was intended. + +I used static analyser cppcheck to find this bug. + +Fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8e815eeefe205155f5 + diff --git a/results/classifier/118/review/1397157 b/results/classifier/118/review/1397157 new file mode 100644 index 000000000..d0f8af9b4 --- /dev/null +++ b/results/classifier/118/review/1397157 @@ -0,0 +1,95 @@ +user-level: 0.869 +permissions: 0.820 +virtual: 0.819 +hypervisor: 0.804 +TCG: 0.772 +KVM: 0.761 +ppc: 0.756 +peripherals: 0.755 +register: 0.751 +risc-v: 0.737 +vnc: 0.730 +performance: 0.726 +VMM: 0.723 +architecture: 0.702 +graphic: 0.694 +boot: 0.691 +x86: 0.691 +files: 0.690 +device: 0.682 +semantic: 0.674 +debug: 0.672 +assembly: 0.666 +socket: 0.645 +network: 0.638 +arm: 0.634 +PID: 0.631 +kernel: 0.628 +i386: 0.587 +mistranslation: 0.578 +-------------------- +virtual: 0.986 +KVM: 0.973 +hypervisor: 0.968 +performance: 0.393 +debug: 0.211 +socket: 0.186 +device: 0.098 +kernel: 0.087 +x86: 0.053 +VMM: 0.044 +boot: 0.041 +PID: 0.037 +TCG: 0.037 +register: 0.020 +peripherals: 0.019 +architecture: 0.016 +assembly: 0.012 +files: 0.011 +semantic: 0.010 +user-level: 0.006 +network: 0.003 +graphic: 0.003 +vnc: 0.003 +permissions: 0.003 +ppc: 0.002 +i386: 0.001 +risc-v: 0.001 +arm: 0.001 +mistranslation: 0.000 + +cpu high with ps2 keyboard on multi-core win7 guest os + + +qemu ver: 1.5.3-Latest + +guest os: window 7 64bit with 2 cpu and ps2 keybord. + +problem: Use virt-viwer as client to connect, When input quickly, the guest and host cpu will high and the input-char will display later. but when only 1 cpu on the vm, the problem will not display or When qemu ver is 0.12.1, the problem will not display. + +qemu cmd: +/usr/libexec/qemu-kvm -name xx_win7 -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu qemu64,+sse4.2,+sse4.1,+ssse3,-svm,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid 0860a434-6560-591b-f92f-c13c5caaf52d -rtc base=localtime -no-shutdown -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/lfs/xx_win7/xx_win7.vda,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=::,disable-ticketing,plaintext-channel=main,plaintext-channel=display,plaintext-channel=inputs,plaintext-channel=cursor,plaintext-channel=playback,plaintext-channel=record,plaintext-channel=usbredir,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,playback-compression=on,disable-copy-paste,seamless-migration=on -vga qxl -global qxl-vga.ram_size=268435456 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 + +Hi +I meet the same problem today, and according to +http://serverfault.com/questions/624690/windows-guest-on-kvm-qemu-suffers-horrible-key-lag +it may be the Windows' fault. + +You can try it, at least it solves my problem. + +thanks, it is perfect on windows, but on linux (redhat), have corresponds parameter? + +Hi - could you all specify the exact qemu versions you are using please (If it's a packaged version please give the package version). + + + +to Dr. David Alan Gilbert (dgilbert-h): +qemu 1.5.3-60 or 82 in rhel 7.0 has the problem, +qemu 0.12.1-x in rhel 6.5 has not the problem. + +Thanks; I see your matching RH bugzilla entry; https://bugzilla.redhat.com/show_bug.cgi?id=1169267 + +Triaging 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/review/1399191 b/results/classifier/118/review/1399191 new file mode 100644 index 000000000..816491f1f --- /dev/null +++ b/results/classifier/118/review/1399191 @@ -0,0 +1,1236 @@ +risc-v: 0.814 +user-level: 0.806 +hypervisor: 0.785 +KVM: 0.780 +virtual: 0.779 +register: 0.772 +VMM: 0.772 +graphic: 0.767 +permissions: 0.750 +assembly: 0.749 +semantic: 0.739 +device: 0.733 +architecture: 0.733 +mistranslation: 0.732 +arm: 0.719 +PID: 0.718 +performance: 0.715 +vnc: 0.712 +kernel: 0.707 +debug: 0.705 +TCG: 0.704 +files: 0.702 +boot: 0.701 +network: 0.680 +socket: 0.670 +x86: 0.665 +ppc: 0.661 +peripherals: 0.633 +i386: 0.460 +-------------------- +virtual: 0.960 +hypervisor: 0.882 +user-level: 0.817 +x86: 0.534 +TCG: 0.222 +debug: 0.079 +files: 0.077 +VMM: 0.071 +register: 0.059 +device: 0.054 +socket: 0.054 +PID: 0.044 +semantic: 0.043 +risc-v: 0.038 +i386: 0.023 +kernel: 0.022 +assembly: 0.018 +ppc: 0.013 +network: 0.013 +architecture: 0.012 +KVM: 0.011 +vnc: 0.010 +performance: 0.008 +peripherals: 0.006 +arm: 0.004 +boot: 0.004 +permissions: 0.003 +graphic: 0.002 +mistranslation: 0.001 + +Large VHDX image size + +We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + +Why is that the VHDX generates large sized images for both the formats? + +The following commands were used to convert the vmdk image to VHDX format + +1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk Test-fixed.vhdx + +qemu-img info Test-fixed.vhdx +image: Test-fixed.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + + + +2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + +qemu-img info Test-dynamic.vhdx +image: Test-dynamic.vhdx +file format: vhdx +virtual size: 50G (53687091200 bytes) +disk size: 50G +cluster_size: 16777216 + + +We tried this with the following version of qemu +1. qemu-2.0.0 +2. qemu-2.1.2 +3. qemu-2.2.0-rc4 + + +Please let us know how to create compact VHDX images using qemu-img. +Thank you + +On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> Public bug reported: +> +> We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> +> Why is that the VHDX generates large sized images for both the formats? +> +> The following commands were used to convert the vmdk image to VHDX +> format + +Jeff, did you fix this recently in commit +85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +.bdrv_has_zero_init to bdrv_has_zero_init_1")? + +Stefan + + +On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > Public bug reported: +> > +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> +> Jeff, did you fix this recently in commit +> 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> +> Stefan + + + +Yes, although there has been a report that there are issues in the +resulting vhdx image in a MS server, after this patch. I am going to +test and fix (if confirmed) once my MSDN subscription is renewed (in +process now, I expect it anytime). + +Jeff + + +Please find comments inline + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jeff Cody +Sent: Wednesday, January 07, 2015 9:11 PM +To: Lokesha, Amulya +Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size + +On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > Public bug reported: +> > +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> +> Jeff, did you fix this recently in commit +> 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> +> Stefan + + +Yes, although there has been a report that there are issues in the resulting vhdx image in a MS server, after this patch. I am going to test and fix (if confirmed) once my MSDN subscription is renewed (in process now, I expect it anytime). + +Jeff + +-- + +Hi Jeff, + +Could you please give us a possible timeline of when fix will be available. Our customers are waiting on this as we are blocked with the image creation. + +Thanks, +Amulya + + +You received this bug notification because you are subscribed to the bug report. +https://bugs.launchpad.net/bugs/1399191 + +Title: + Large VHDX image size + +Status in QEMU: + New + +Bug description: + We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. + We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). + + Why is that the VHDX generates large sized images for both the + formats? + + The following commands were used to convert the vmdk image to VHDX + format + + 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk + Test-fixed.vhdx + + qemu-img info Test-fixed.vhdx + image: Test-fixed.vhdx + file format: vhdx + virtual size: 50G (53687091200 bytes) + disk size: 50G + cluster_size: 16777216 + + + + 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx + + qemu-img info Test-dynamic.vhdx + image: Test-dynamic.vhdx + file format: vhdx + virtual size: 50G (53687091200 bytes) + disk size: 50G + cluster_size: 16777216 + + + We tried this with the following version of qemu + 1. qemu-2.0.0 + 2. qemu-2.1.2 + 3. qemu-2.2.0-rc4 + + + Please let us know how to create compact VHDX images using qemu-img. + Thank you + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + +On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> Please find comments inline +> +> -----Original Message----- +> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Jeff Cody +> Sent: Wednesday, January 07, 2015 9:11 PM +> To: Lokesha, Amulya +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > Public bug reported: +> > > +> > > We are trying to convert a VMDK image to VHDX image for deploy +> > > to HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > converting the image using both 'fixed' as well as 'dynamic' +> > > format. We found that both the disks occupy the same size of +> > > 50GB. When the same is done with VHD image, we found that the +> > > dynamic disks are much lesser in size (5 GB) than the fixed disk +> > > (50GB). +> > > +> > > Why is that the VHDX generates large sized images for both the +> > > formats? +> > > +> > > The following commands were used to convert the vmdk image to +> > > VHDX format +> > +> > Jeff, did you fix this recently in commit +> > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > +> > Stefan +> +> +> Yes, although there has been a report that there are issues in the +> resulting vhdx image in a MS server, after this patch. I am going +> to test and fix (if confirmed) once my MSDN subscription is renewed +> (in process now, I expect it anytime). +> +> Jeff +> +> -- +> +> Hi Jeff, +> +> Could you please give us a possible timeline of when fix will be +> available. Our customers are waiting on this as we are blocked with +> the image creation. +> +> Thanks, Amulya + +Hi Amulya, + +I have my MSDN stuff sorted out now, so give me a day or two get my +test machine up and running & testing. + +-Jeff +> +> +> You received this bug notification because you are subscribed to the bug report. +> https://bugs.launchpad.net/bugs/1399191 +> +> Title: +> Large VHDX image size +> +> Status in QEMU: +> New +> +> Bug description: +> We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> +> Why is that the VHDX generates large sized images for both the +> formats? +> +> The following commands were used to convert the vmdk image to VHDX +> format +> +> 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> Test-fixed.vhdx +> +> qemu-img info Test-fixed.vhdx +> image: Test-fixed.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> +> 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test-dynamic.vhdx +> +> qemu-img info Test-dynamic.vhdx +> image: Test-dynamic.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> We tried this with the following version of qemu +> 1. qemu-2.0.0 +> 2. qemu-2.1.2 +> 3. qemu-2.2.0-rc4 +> +> +> Please let us know how to create compact VHDX images using qemu-img. +> Thank you +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + + + +-----Original Message----- +From: Jeff Cody [mailto:<email address hidden>] +Sent: Tuesday, January 13, 2015 9:18 AM +To: Lokesha, Amulya +Cc: Bug 1399191; Geoffroy, Daniel +Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size + +On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> Please find comments inline +> +> -----Original Message----- +> From: <email address hidden> [mailto:<email address hidden>] On Behalf +> Of Jeff Cody +> Sent: Wednesday, January 07, 2015 9:11 PM +> To: Lokesha, Amulya +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > Public bug reported: +> > > +> > > We are trying to convert a VMDK image to VHDX image for deploy to +> > > HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > converting the image using both 'fixed' as well as 'dynamic' +> > > format. We found that both the disks occupy the same size of 50GB. +> > > When the same is done with VHD image, we found that the dynamic +> > > disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > > +> > > Why is that the VHDX generates large sized images for both the +> > > formats? +> > > +> > > The following commands were used to convert the vmdk image to VHDX +> > > format +> > +> > Jeff, did you fix this recently in commit +> > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > +> > Stefan +> +> +> Yes, although there has been a report that there are issues in the +> resulting vhdx image in a MS server, after this patch. I am going to +> test and fix (if confirmed) once my MSDN subscription is renewed (in +> process now, I expect it anytime). +> +> Jeff +> +> -- +> +> Hi Jeff, +> +> Could you please give us a possible timeline of when fix will be +> available. Our customers are waiting on this as we are blocked with +> the image creation. +> +> Thanks, Amulya + +Hi Amulya, + +I have my MSDN stuff sorted out now, so give me a day or two get my test machine up and running & testing. + +-Jeff + + +Hi Jeff, + +Any updates on this? Where you able to get it tested + + Thanks, +-Amulya + +> +> +> You received this bug notification because you are subscribed to the bug report. +> https://bugs.launchpad.net/bugs/1399191 +> +> Title: +> Large VHDX image size +> +> Status in QEMU: +> New +> +> Bug description: +> We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> +> Why is that the VHDX generates large sized images for both the +> formats? +> +> The following commands were used to convert the vmdk image to VHDX +> format +> +> 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> Test-fixed.vhdx +> +> qemu-img info Test-fixed.vhdx +> image: Test-fixed.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> +> 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +> Test.vmdk Test-dynamic.vhdx +> +> qemu-img info Test-dynamic.vhdx +> image: Test-dynamic.vhdx +> file format: vhdx +> virtual size: 50G (53687091200 bytes) +> disk size: 50G +> cluster_size: 16777216 +> +> +> We tried this with the following version of qemu +> 1. qemu-2.0.0 +> 2. qemu-2.1.2 +> 3. qemu-2.2.0-rc4 +> +> +> Please let us know how to create compact VHDX images using qemu-img. +> Thank you +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + +On Mon, Jan 19, 2015 at 03:19:05PM +0000, Lokesha, Amulya wrote: +> +> +> -----Original Message----- +> From: Jeff Cody [mailto:<email address hidden>] +> Sent: Tuesday, January 13, 2015 9:18 AM +> To: Lokesha, Amulya +> Cc: Bug 1399191; Geoffroy, Daniel +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> > Please find comments inline +> > +> > -----Original Message----- +> > From: <email address hidden> [mailto:<email address hidden>] On Behalf +> > Of Jeff Cody +> > Sent: Wednesday, January 07, 2015 9:11 PM +> > To: Lokesha, Amulya +> > Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> > +> > On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > > Public bug reported: +> > > > +> > > > We are trying to convert a VMDK image to VHDX image for deploy to +> > > > HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > > converting the image using both 'fixed' as well as 'dynamic' +> > > > format. We found that both the disks occupy the same size of 50GB. +> > > > When the same is done with VHD image, we found that the dynamic +> > > > disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > > > +> > > > Why is that the VHDX generates large sized images for both the +> > > > formats? +> > > > +> > > > The following commands were used to convert the vmdk image to VHDX +> > > > format +> > > +> > > Jeff, did you fix this recently in commit +> > > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > > +> > > Stefan +> > +> > +> > Yes, although there has been a report that there are issues in the +> > resulting vhdx image in a MS server, after this patch. I am going to +> > test and fix (if confirmed) once my MSDN subscription is renewed (in +> > process now, I expect it anytime). +> > +> > Jeff +> > +> > -- +> > +> > Hi Jeff, +> > +> > Could you please give us a possible timeline of when fix will be +> > available. Our customers are waiting on this as we are blocked with +> > the image creation. +> > +> > Thanks, Amulya +> +> Hi Amulya, +> +> I have my MSDN stuff sorted out now, so give me a day or two get my test machine up and running & testing. +> +> -Jeff +> +> +> Hi Jeff, +> +> Any updates on this? Where you able to get it tested +> +> Thanks, +> -Amulya +> + +Yes, I have sent a patch that I believe fixes the issue (I cc'ed you +on the patch). If you wouldn't mind testing, and verifying that it +fixes your particular issue, that would be great. I tested on Windows +Server 2012 w/Hyper-V, and I was able to verify the original problem +and the fix. + +On what the issue was: + +The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the +block state field is 'reserved' for blocks in the state +PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file +offset value for that block into the field, and just ignored it during +reads. + +If we force the FileOffsetMB field to be zero, then Hyper-V is able to +read the images. Furthermore, inspecting images converted by +Hyper-V shows that Hyper-V writes '0' for the FileOffsetMB +field in BAT entries that are in the PAYLOAD_BLOCK_ZERO state. + +The patch I sent mimics that behavior, and forces any BAT writes of +PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. + +> > +> > +> > You received this bug notification because you are subscribed to the bug report. +> > https://bugs.launchpad.net/bugs/1399191 +> > +> > Title: +> > Large VHDX image size +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the +> > formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> > +> > 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> > Test-fixed.vhdx +> > +> > qemu-img info Test-fixed.vhdx +> > image: Test-fixed.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > +> > 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +> > Test.vmdk Test-dynamic.vhdx +> > +> > qemu-img info Test-dynamic.vhdx +> > image: Test-dynamic.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > We tried this with the following version of qemu +> > 1. qemu-2.0.0 +> > 2. qemu-2.1.2 +> > 3. qemu-2.2.0-rc4 +> > +> > +> > Please let us know how to create compact VHDX images using qemu-img. +> > Thank you +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + + + +-----Original Message----- +From: Jeff Cody [mailto:<email address hidden>] +Sent: Wednesday, January 21, 2015 2:41 AM +To: Lokesha, Amulya +Cc: Bug 1399191; Geoffroy, Daniel +Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size + +On Mon, Jan 19, 2015 at 03:19:05PM +0000, Lokesha, Amulya wrote: +> +> +> -----Original Message----- +> From: Jeff Cody [mailto:<email address hidden>] +> Sent: Tuesday, January 13, 2015 9:18 AM +> To: Lokesha, Amulya +> Cc: Bug 1399191; Geoffroy, Daniel +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Sun, Jan 11, 2015 at 11:33:31PM -0500, Lokesha, Amulya wrote: +> > Please find comments inline +> > +> > -----Original Message----- +> > From: <email address hidden><mailto:<email address hidden>> [mailto:<email address hidden>] On Behalf +> > Of Jeff Cody +> > Sent: Wednesday, January 07, 2015 9:11 PM +> > To: Lokesha, Amulya +> > Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> > +> > On Wed, Jan 07, 2015 at 03:30:28PM +0000, Stefan Hajnoczi wrote: +> > > On Thu, Dec 04, 2014 at 01:31:38PM -0000, AMULYA L wrote: +> > > > Public bug reported: +> > > > +> > > > We are trying to convert a VMDK image to VHDX image for deploy +> > > > to HyperV Server ( SCVMM 2012 SP1) using qemu-img. We tried +> > > > converting the image using both 'fixed' as well as 'dynamic' +> > > > format. We found that both the disks occupy the same size of 50GB. +> > > > When the same is done with VHD image, we found that the dynamic +> > > > disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > > > +> > > > Why is that the VHDX generates large sized images for both the +> > > > formats? +> > > > +> > > > The following commands were used to convert the vmdk image to +> > > > VHDX format +> > > +> > > Jeff, did you fix this recently in commit +> > > 85b712c9d5b873562c864e72f69cbf0d87d2fe40 ("block: vhdx - set +> > > .bdrv_has_zero_init to bdrv_has_zero_init_1")? +> > > +> > > Stefan +> > +> > +> > Yes, although there has been a report that there are issues in the +> > resulting vhdx image in a MS server, after this patch. I am going +> > to test and fix (if confirmed) once my MSDN subscription is renewed +> > (in process now, I expect it anytime). +> > +> > Jeff +> > +> > -- +> > +> > Hi Jeff, +> > +> > Could you please give us a possible timeline of when fix will be +> > available. Our customers are waiting on this as we are blocked with +> > the image creation. +> > +> > Thanks, Amulya +> +> Hi Amulya, +> +> I have my MSDN stuff sorted out now, so give me a day or two get my test machine up and running & testing. +> +> -Jeff +> +> +> Hi Jeff, +> +> Any updates on this? Where you able to get it tested +> +> Thanks, +> -Amulya +> + +Yes, I have sent a patch that I believe fixes the issue (I cc'ed you on the patch). If you wouldn't mind testing, and verifying that it fixes your particular issue, that would be great. I tested on Windows Server 2012 w/Hyper-V, and I was able to verify the original problem and the fix. + +On what the issue was: + +The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the block state field is 'reserved' for blocks in the state PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file offset value for that block into the field, and just ignored it during reads. + +If we force the FileOffsetMB field to be zero, then Hyper-V is able to read the images. Furthermore, inspecting images converted by Hyper-V shows that Hyper-V writes '0' for the FileOffsetMB field in BAT entries that are in the PAYLOAD_BLOCK_ZERO state. + +The patch I sent mimics that behavior, and forces any BAT writes of PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. + + +Hi Jeff, + +Thanks a lot for the fix. We tested the VHDX creation with the new patch fix and were able to get it deployed successfully into our Windows HyperV Server 2012. + +However we have one more issue and were hoping if we could get any help. We have a vmdk image (size 13MB) with a 500 GB data disk size. After conversion of vmdk image to vhdx format, the image size is 126 GB. + +# qemu-img info Test.vmdk +image: Test.vmdk +file format: vmdk +virtual size: 500G (536870912000 bytes) +disk size: 13M +cluster_size: 65536 +Format specific information: + cid: 4124953209 + parent cid: 4294967295 + create type: streamOptimized + extents: + [0]: + compressed: true + virtual size: 536870912000 + filename: Test.vmdk + cluster size: 65536 + format: + +qemu conversion to vhdx done as below +# qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk Test.vhdx + (100.00/100%) + +# ls -ltrh +total 69M +-rw-r--r-- 1 root root 13M Jan 21 21:42 Test.vmdk +-rw-r--r-- 1 root root 126G Jan 22 05:03 Test.vhdx + +# qemu-img info Test.vhdx +image: Test.vhdx +file format: vhdx +virtual size: 500G (536870912000 bytes) +disk size: 56M +cluster_size: 33554432 + + +When we tried to copy this to the SCVMM manager server (Windows OS) it failed due to disk limitation. Windows does think it is a 126 GB file. Can anything be done to fix this issue? + +Thanks, +Amulya +> > +> > +> > You received this bug notification because you are subscribed to the bug report. +> > https://bugs.launchpad.net/bugs/1399191 +> > +> > Title: +> > Large VHDX image size +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > We are trying to convert a VMDK image to VHDX image for deploy to HyperV Server ( SCVMM 2012 SP1) using qemu-img. +> > We tried converting the image using both 'fixed' as well as 'dynamic' format. We found that both the disks occupy the same size of 50GB. When the same is done with VHD image, we found that the dynamic disks are much lesser in size (5 GB) than the fixed disk (50GB). +> > +> > Why is that the VHDX generates large sized images for both the +> > formats? +> > +> > The following commands were used to convert the vmdk image to VHDX +> > format +> > +> > 1. qemu-img convert -p -o subformat=fixed -f vmdk -O vhdx Test.vmdk +> > Test-fixed.vhdx +> > +> > qemu-img info Test-fixed.vhdx +> > image: Test-fixed.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > +> > 2. qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +> > Test.vmdk Test-dynamic.vhdx +> > +> > qemu-img info Test-dynamic.vhdx +> > image: Test-dynamic.vhdx +> > file format: vhdx +> > virtual size: 50G (53687091200 bytes) +> > disk size: 50G +> > cluster_size: 16777216 +> > +> > +> > We tried this with the following version of qemu +> > 1. qemu-2.0.0 +> > 2. qemu-2.1.2 +> > 3. qemu-2.2.0-rc4 +> > +> > +> > Please let us know how to create compact VHDX images using qemu-img. +> > Thank you +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1399191/+subscriptions + + + +On Thu, Jan 22, 2015 at 05:20:20AM +0000, Lokesha, Amulya wrote: +> +> + +[...] + +> +>> Yes, I have sent a patch that I believe fixes the issue (I cc'ed you on +>> the patch). If you wouldn't mind testing, and verifying that it fixes +>> your particular issue, that would be great. I tested on Windows Server +>> 2012 w/Hyper-V, and I was able to verify the original problem and the fix. +>> +>> On what the issue was: +>> +>> The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the +>> block state field is 'reserved' for blocks in the state +>> PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file offset +>> value for that block into the field, and just ignored it during reads. +>> +>> If we force the FileOffsetMB field to be zero, then Hyper-V is able to +>> read the images. Furthermore, inspecting images converted by Hyper-V +>> shows that Hyper-V writes '0' for the FileOffsetMB field in BAT entries +>> that are in the PAYLOAD_BLOCK_ZERO state. +>> +>> The patch I sent mimics that behavior, and forces any BAT writes of +>> PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. +> +> +> Hi Jeff, +> +> Thanks a lot for the fix. We tested the VHDX creation with the new patch +> fix and were able to get it deployed successfully into our Windows HyperV +> Server 2012. +> + +You're welcome! + +> However we have one more issue and were hoping if we could get any help. +> We have a vmdk image (size 13MB) with a 500 GB data disk size. After +> conversion of vmdk image to vhdx format, the image size is 126 GB. +> +> # qemu-img info Test.vmdk +> image: Test.vmdk +> file format: vmdk +> virtual size: 500G (536870912000 bytes) +> disk size: 13M +> cluster_size: 65536 +> Format specific information: +> cid: 4124953209 +> parent cid: 4294967295 +> create type: streamOptimized +> extents: +> [0]: +> compressed: true +> virtual size: 536870912000 +> filename: Test.vmdk +> cluster size: 65536 +> format: +> +> qemu conversion to vhdx done as below +> # qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk +> Test.vhdx +> (100.00/100%) +> +> # ls -ltrh +> total 69M +> -rw-r--r-- 1 root root 13M Jan 21 21:42 Test.vmdk +> -rw-r--r-- 1 root root 126G Jan 22 05:03 Test.vhdx +> +> # qemu-img info Test.vhdx +> image: Test.vhdx +> file format: vhdx +> virtual size: 500G (536870912000 bytes) +> disk size: 56M +> cluster_size: 33554432 +> +> +> When we tried to copy this to the SCVMM manager server (Windows OS) it +> failed due to disk limitation. Windows does think it is a 126 GB file. Can +> anything be done to fix this issue? +> +> Thanks, +> Amulya + +It sounds like a 126G sparse image was created (reported size 126G, on +disk size 55M), and QEMU still recognizes it as a 500G image (file +size sounds large, but nothing indicates yet the vhdx image isn't +valid, at least). + +I am not sure what your disk limitation limit was under Windows, can +you elaborate? + +I tried to reproduce it here, and could not: + +# ./qemu-img create -f vmdk test-500G.vmdk 500G + +# ./qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx test-500G.vmdk test-500G.vhdx + +# ls -lhs test-500G* +1.3M -rw-r--r--. 1 jcody jcody 8.0M Jan 22 10:25 test-500G.vhdx +136K -rw-r--r--. 1 jcody jcody 63M Jan 22 10:25 test-500G.vmdk + +I was also able to inspect test.vhdx on Windows Server 2012, using +Hyper-V Manager, and it reported that it was a vhdx dynamic disk, with +a maximum size of 500G. + +Can you place your source vmdk image someplace for me to download and +test with, if it does not contain sensitive data? You can send me the +link offlist, if you like. + +Thanks, +Jeff + +> > > +> > > +> > > You received this bug notification because you are subscribed to the +> bug report. +> > > [5]https://bugs.launchpad.net/bugs/1399191 +> > > + + +[...] + + +On Thu, Jan 22, 2015 at 04:24:45PM +0000, Lokesha, Amulya wrote: +> +> -----Original Message----- +> From: Jeff Cody [mailto:<email address hidden>] +> Sent: Thursday, January 22, 2015 9:33 PM +> To: Lokesha, Amulya +> Cc: Bug 1399191; Geoffroy, Daniel +> Subject: Re: [Qemu-devel] [Bug 1399191] [NEW] Large VHDX image size +> +> On Thu, Jan 22, 2015 at 05:20:20AM +0000, Lokesha, Amulya wrote: +> > +> > +> +> [...] +> +>>> +>>>> Yes, I have sent a patch that I believe fixes the issue (I cc'ed you on +>>>> the patch). If you wouldn't mind testing, and verifying that it fixes +>>>> your particular issue, that would be great. I tested on Windows Server +>>>> 2012 w/Hyper-V, and I was able to verify the original problem and the fix. +>>>> +>>>> On what the issue was: +>>>> +>>>> The v1.0.0 spec for VHDX denotes that the FileOffsetMB portion of the +>>>> block state field is 'reserved' for blocks in the state +>>>> PAYLOAD_BLOCK_ZERO. Before, we just went ahead and wrote the file offset +>>>> value for that block into the field, and just ignored it during reads. +>>>> +>>>> If we force the FileOffsetMB field to be zero, then Hyper-V is able to +>>>> read the images. Furthermore, inspecting images converted by Hyper-V +>>>> shows that Hyper-V writes '0' for the FileOffsetMB field in BAT entries +>>>> that are in the PAYLOAD_BLOCK_ZERO state. +>>>> +>>>> The patch I sent mimics that behavior, and forces any BAT writes of +>>>> PAYLOAD_BLOCK_ZERO state to have a FileOffsetMB value of 0. +>>> +>>> +>>> Hi Jeff, +>>> +>>> Thanks a lot for the fix. We tested the VHDX creation with the new patch +>>> fix and were able to get it deployed successfully into our Windows HyperV +>>> Server 2012. +>>> +>> +>>You're welcome! +>> +>>> However we have one more issue and were hoping if we could get any help. +>>> We have a vmdk image (size 13MB) with a 500 GB data disk size. After +>>> conversion of vmdk image to vhdx format, the image size is 126 GB. +>>> +>>> # qemu-img info Test.vmdk +>>> image: Test.vmdk +>>> file format: vmdk +>>> virtual size: 500G (536870912000 bytes) +>>> disk size: 13M +>>> cluster_size: 65536 +>>> Format specific information: +>>> cid: 4124953209 +>>> parent cid: 4294967295 +>>> create type: streamOptimized +>>> extents: +>>> [0]: +>>> compressed: true +>>> virtual size: 536870912000 +>>> filename: Test.vmdk +>>> cluster size: 65536 +>>> format: +>>> +>>> qemu conversion to vhdx done as below +>>> # qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx Test.vmdk +>>> Test.vhdx +>>> (100.00/100%) +>>> +>>> # ls -ltrh +>>> total 69M +>>> -rw-r--r-- 1 root root 13M Jan 21 21:42 Test.vmdk +>>> -rw-r--r-- 1 root root 126G Jan 22 05:03 Test.vhdx +>>> +>>> # qemu-img info Test.vhdx +>>> image: Test.vhdx +>>> file format: vhdx +>>> virtual size: 500G (536870912000 bytes) +>>> disk size: 56M +>>> cluster_size: 33554432 +>>> +>>> +>>> When we tried to copy this to the SCVMM manager server (Windows OS) it +>>> failed due to disk limitation. Windows does think it is a 126 GB file. Can +>>> anything be done to fix this issue? +>>> +>>> Thanks, +>>> Amulya +>> +>> It sounds like a 126G sparse image was created (reported size 126G, +>> on disk size 55M), and QEMU still recognizes it as a 500G image +>> (file size sounds large, but nothing indicates yet the vhdx image +>> isn't valid, at least). +>> +>> +>> I tried to reproduce it here, and could not: +>> +>> # ./qemu-img create -f vmdk test-500G.vmdk 500G +>> +>> # ./qemu-img convert -p -o subformat=dynamic -f vmdk -O vhdx +>> test-500G.vmdk test-500G.vhdx +>> +>> # ls -lhs test-500G* +>> 1.3M -rw-r--r--. 1 jcody jcody 8.0M Jan 22 10:25 test-500G.vhdx +>> 136K -rw-r--r--. 1 jcody jcody 63M Jan 22 10:25 test-500G.vmdk +>> +>> I was also able to inspect test.vhdx on Windows Server 2012, using +>> Hyper-V Manager, and it reported that it was a vhdx dynamic disk, +>> with a maximum size of 500G. +>> +>> Can you place your source vmdk image someplace for me to download +>> and test with, if it does not contain sensitive data? You can send +>> me the link offlist, if you like. +>> +> +> Hi Jeff, +> +> The disk limitation which I mentioned above was just about the free +> space available on Windows hyperV Server. I am sending the sample +> Test.vmdk attached in zip format which we used for converting to +> vhdx format. Please let me know if you are able to download this zip +> file. +> +> Thanks, Amulya +> +> + +Hi Amulya, + +(I added the bug tracker back on the cc list) + +I was able to download the VMDK image fine to test. What is going +on is due to the nature of the VHDX image format, due to its +relatively large block size (1MB min, 256 MB max). + +Brief background: + +In the VHDX image format, data is broken up into blocks. Those blocks +may take various states, such as a 'ZERO' state, and a 'PRESENT' +state. + +When an entire block is zeroes, the state stays in the 'ZERO' state, +which is now the default state for new VHDX dynamic image files. +There is no data written to disk for these zeros, so the file size +stays small. + +However, if we write even 1 byte to a block that is the ZERO state, it +is now in the 'PRESENT' state, and that block data must be written to +disk (complete with the surrounding zeroes in that block). + +Block sizes for VHDX images range from 1MB - 256MB. The larger the +block size, the larger the image may be on disk for partially filled +blocks. + +The qemu vhdx driver does take advantage of underlying file system +sparseness, however, and just extends the file out and only writes the +requested sectors on a write. + + +What is going on in your VMDK image: + +You VMDK image as a lot of (repetitive) data spread out far enough +apart that it hits a lot of different blocks [1]. If you run hexdump on +the resulting vhdx image, this will be apparent (hexdump will elide +excessively duplicate data, so the output is manageable). + +The resulting image with the default block size then becomes ~126G, +but as it is quite sparse, the on disk usage is only 41M. If you play +with the block size parameter during conversion, you can get file size +down to around 4G (with a block_size of 1MB). + +I am not sure the best way to copy a sparse file over to Windows +2012 Server, but it would probably be nice to preserve any sparseness +if possible. + +I think we can close the BZ, as it seems the posted patch solves +the original issue. + + +[1] Example of data from the converted VHDX image: + +7f000000 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f000040 0003 0000 0000 0000 0000 0000 0000 0000 +7f000050 0000 0000 0000 0000 0000 0000 0000 0000 +* +7f001400 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f002000 0000 0000 0000 0000 0000 0000 0000 0000 +* +7f100000 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f100040 0003 0000 0000 0000 0000 0000 0000 0000 +7f100050 0000 0000 0000 0000 0000 0000 0000 0000 +* +7f101400 ffff ffff ffff ffff ffff ffff ffff ffff +* +7f102000 0000 0000 0000 0000 0000 0000 0000 0000 + + +The default block size for a 500G vhdx image created by QEMU is 32M. +In the above, you can see that most of the data is 0, but still within +one block-sized chunk. + +(I am assuming that the data was converted correctly, of course). + +When I tested with a qcow2 output format, using a 1MB cluster size in +qcow2, I get roughly similar results as when using a block size of 1M +with vhdx (Test.qcow2 and Test.vhdx were then both ~4G). + +-Jeff + +>>> > > +>>> > > +>>> > > You received this bug notification because you are subscribed to the +>>> bug report. +>>> > > https://bugs.launchpad.net/bugs/1399191 +>>> > > +>> +>> +>>[...] + + + + +We have encountered the same problem. +We have a 1.4 GB size vmdk image and after converting it to vhdx, its size is 62GB. But qemu-img info show the size is 2.9 G. +=========== +$ qemu-img info dd_test.vmdk +image: dd_test.vmdk +file format: vmdk +virtual size: 250G (268435456000 bytes) +disk size: 1.4G +$ qemu-img convert -p -f vmdk dd_test.vmdk -O vhdx t.vhdx + (98.02/100%) + +$ qemu-img info t.vhdx +image: t.vhdx +file format: vhdx +virtual size: 250G (268435456000 bytes) +disk size: 2.9G +$ ls -ltrh t.vhdx +-rw-r--r-- 1 wangj85 wangj85 62G Dec 28 2015 t.vhdx + + + + +qemu-img version is 1.5.3. I also use newer version to do the conversion, it has the same result. + +If your image contains an ext4 partition it may be worth viewing the advice MS gives about Dynamic VHDX blocksizes: https://technet.microsoft.com/en-GB/library/dn720239.aspx . + +Hi Jan, + +ls -l returns the length of the file; qemu-img info prints the size of the file (just like du does). Those are not necessarily the same, as you can see. On modern filesystems, files can have holes in them which do contribute to the file length, but which do not use any space on disk and thus do not contribute to file size. + +Besides using qemu-img, you can obtain the actual disk usage (the file size) by using du or ls --size (-s for short). + +Max + +Sorry. +Please ignore above change. I just find that I change the status of this bug +https://bugs.launchpad.net/qemu/+bug/1490611 +I really don't know I have privilege to modify that. +Sorry again. + +Triaging 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/review/1402755 b/results/classifier/118/review/1402755 new file mode 100644 index 000000000..a8ca5dbcf --- /dev/null +++ b/results/classifier/118/review/1402755 @@ -0,0 +1,136 @@ +user-level: 0.914 +architecture: 0.906 +assembly: 0.901 +permissions: 0.896 +peripherals: 0.892 +register: 0.891 +kernel: 0.891 +device: 0.883 +debug: 0.882 +KVM: 0.874 +network: 0.873 +performance: 0.873 +vnc: 0.871 +mistranslation: 0.870 +ppc: 0.867 +risc-v: 0.864 +virtual: 0.856 +graphic: 0.854 +PID: 0.851 +semantic: 0.846 +VMM: 0.842 +TCG: 0.838 +files: 0.838 +socket: 0.830 +hypervisor: 0.822 +arm: 0.821 +boot: 0.803 +x86: 0.733 +i386: 0.557 +-------------------- +KVM: 0.940 +debug: 0.879 +virtual: 0.806 +network: 0.757 +x86: 0.592 +hypervisor: 0.408 +kernel: 0.317 +semantic: 0.051 +register: 0.033 +files: 0.032 +vnc: 0.027 +i386: 0.022 +TCG: 0.020 +device: 0.018 +PID: 0.015 +user-level: 0.011 +assembly: 0.009 +performance: 0.008 +VMM: 0.008 +socket: 0.008 +architecture: 0.006 +peripherals: 0.006 +risc-v: 0.004 +ppc: 0.004 +graphic: 0.002 +boot: 0.002 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.000 + +qemu-kvm: e1000 RX ring is filled with partial-pkt of size 0 + +Hello, +We are using CentOS 6.5 with qemu-kvm-0.12.1.2-2.415 as a host of or VMs. +In the VM we use e1000 as the NIC emulation. +We've modified the e1000 driver to our needs. This modification start the RX engine while the RX ring is empty (RDH == RDT) +and at a later stage we fill the RX descriptors with buffers. This scheme works well on intel chips and VMware. +What we observe in this setup is that from time to time the RX ring is filled with "partial packets" of size 0 (meaning, DD bit is set, +No other status bits are set and packet size is also 0). + +Looking at the e1000 RX routine in qemu-kvm you can observe the following flow: +1. A packet is avail for receive: +2. The routine checks for RCTL_EN - it is enabled +3. The routine checks that the RDH equal RDT (they are as the ring is empty) but also checks if rxov is on (it is still off) so it doesn’t +Exit as it is supposed to. +4. The routine now updates the descriptor status with the DD bit (and vlan which we don’t care) +5. The routine checks if a buffer address is not NULL (it is as NULL since we haven’t filled it yet) – so is logs something. +6. The routine now updates the guest memory with this value (DD is 1) +7. The routine updates the check_rxov flag in order to allow ovf check the next time around. +(but ovf will not occur since in the next iteration RDH != RDT) +8. The routine loops over all the descriptors with the NULL buffer (which is all our ring) and writes the DD bit +9. We get this endless partial packet problem we see. + +qemu-kvm-0.12.1.2-2.415.el6_5.3/qemu-kvm-0.12.1.2/hw/e1000.c +static ssize_t +e1000_receive(VLANClientState *nc, const uint8_t *buf, size_t size) +{ +: : : +if (!(s->mac_reg[RCTL] & E1000_RCTL_EN)) +return -1; + +: : : +do { +if (s->mac_reg[RDH] == s->mac_reg[RDT] && s->check_rxov) { +set_ics(s, 0, E1000_ICS_RXO); +return -1; +} +base = ((uint64_t)s->mac_reg[RDBAH] << 32) + s->mac_reg[RDBAL] + +sizeof(desc) * s->mac_reg[RDH]; +cpu_physical_memory_read(base, (void *)&desc, sizeof(desc)); +desc.special = vlan_special; +desc.status |= (vlan_status | E1000_RXD_STAT_DD); +if (desc.buffer_addr) { +cpu_physical_memory_write(le64_to_cpu(desc.buffer_addr), +(void *)(buf + vlan_offset), size); +desc.length = cpu_to_le16(size); +desc.status |= E1000_RXD_STAT_EOP|E1000_RXD_STAT_IXSM; +} else // as per intel docs; skip descriptors with null buf addr +DBGOUT(RX, "Null RX descriptor!!\n"); +cpu_physical_memory_write(base, (void *)&desc, sizeof(desc)); + +: : : +if (++s->mac_reg[RDH] * sizeof(desc) >= s->mac_reg[RDLEN]) +s->mac_reg[RDH] = 0; +s->check_rxov = 1; +: : : +} while (desc.buffer_addr == 0); +} + + +A workaround is to enable the RX machine only after the descriptor ring is filled for the first time. + +Moti + +On Mon, Dec 15, 2014 at 04:59:55PM -0000, Moti wrote: +> We are using CentOS 6.5 with qemu-kvm-0.12.1.2-2.415 as a host of or VMs. + +Do you see the problem with qemu.git/master? + +Stefan + + +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/review/1402802 b/results/classifier/118/review/1402802 new file mode 100644 index 000000000..7461bf046 --- /dev/null +++ b/results/classifier/118/review/1402802 @@ -0,0 +1,78 @@ +mistranslation: 0.886 +ppc: 0.741 +graphic: 0.652 +device: 0.520 +semantic: 0.472 +network: 0.446 +files: 0.421 +performance: 0.355 +register: 0.354 +socket: 0.344 +x86: 0.316 +architecture: 0.312 +vnc: 0.288 +TCG: 0.278 +i386: 0.266 +hypervisor: 0.226 +peripherals: 0.203 +debug: 0.180 +PID: 0.177 +virtual: 0.173 +arm: 0.170 +permissions: 0.155 +user-level: 0.144 +boot: 0.142 +VMM: 0.140 +risc-v: 0.107 +assembly: 0.091 +KVM: 0.080 +kernel: 0.066 +-------------------- +ppc: 0.458 +files: 0.109 +TCG: 0.103 +hypervisor: 0.059 +x86: 0.043 +register: 0.025 +debug: 0.025 +i386: 0.019 +architecture: 0.017 +arm: 0.015 +virtual: 0.011 +semantic: 0.009 +device: 0.007 +user-level: 0.007 +performance: 0.006 +kernel: 0.004 +VMM: 0.004 +PID: 0.004 +assembly: 0.003 +risc-v: 0.003 +boot: 0.002 +KVM: 0.002 +graphic: 0.002 +network: 0.002 +peripherals: 0.002 +socket: 0.001 +vnc: 0.001 +mistranslation: 0.001 +permissions: 0.001 + +target-tricore/translate.c:3812: possible bad expression ? + + +From a run of cppcheck, a static analysis checker, over the +source code of qemu trunk, dated 20141215, is the new error: + +[qemu/target-tricore/translate.c:3812]: (style) Expression '(X & 0x3f) == 0x6f' is always false. + +Source code is + + if (unlikely((op1 & 0x3f) == OPCM_32_BRN_JTT)) { + +Suggest code rework. + +Absolutly correct. The mask should be 0x7f. I will fix that asap. + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7f13420ec000ad7644b65e + diff --git a/results/classifier/118/review/1406016 b/results/classifier/118/review/1406016 new file mode 100644 index 000000000..92e3d29f8 --- /dev/null +++ b/results/classifier/118/review/1406016 @@ -0,0 +1,167 @@ +user-level: 0.885 +register: 0.881 +risc-v: 0.866 +performance: 0.854 +graphic: 0.852 +virtual: 0.836 +permissions: 0.832 +architecture: 0.826 +device: 0.810 +mistranslation: 0.802 +semantic: 0.783 +debug: 0.778 +assembly: 0.775 +arm: 0.765 +KVM: 0.758 +vnc: 0.746 +boot: 0.733 +hypervisor: 0.723 +kernel: 0.723 +TCG: 0.721 +PID: 0.696 +socket: 0.696 +ppc: 0.686 +network: 0.683 +VMM: 0.667 +files: 0.653 +peripherals: 0.637 +i386: 0.467 +x86: 0.429 +-------------------- +arm: 0.998 +boot: 0.932 +kernel: 0.926 +debug: 0.626 +virtual: 0.403 +hypervisor: 0.157 +PID: 0.122 +vnc: 0.046 +user-level: 0.027 +performance: 0.024 +files: 0.016 +register: 0.015 +assembly: 0.009 +TCG: 0.008 +device: 0.007 +architecture: 0.007 +semantic: 0.006 +socket: 0.004 +network: 0.003 +VMM: 0.002 +graphic: 0.002 +peripherals: 0.001 +permissions: 0.001 +KVM: 0.000 +risc-v: 0.000 +mistranslation: 0.000 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-system-arm hangs at start on OS X + +Both from release 2.1.2 and built from a recent source, qemu-system-arm seems to hang on a mutex immediately after starting up, never getting to the point of actually booting. + +I've tried qemu-system-mipsel with another image and it worked fine, so this seems to be specific to the ARM runtime. I've tried two different ARM kernels, and I also ran into this with QEMU 2.1.2 release, installed from a bottle using homebrew. + +Host: Mac OS X 10.9.5 (Darwin Kernel Version 13.4.0) +QEMU version: built from HEAD@ab0302ee76 +Build command: ./configure --enable-cocoa --target-list=arm-softmmu,mipsel-softmmu && make +Run command: + +qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 256 -sd disk.img -net nic,macaddr=52:54:00:fa:ce:13 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.gz -append "root=/dev/ram" -display vnc=localhost:17 -net user,hostfwd=tcp::5022-:22 -append "console=ttyS0" + +I also tried this, with a different kernel & root: + +qemu-system-arm -kernel zImage -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -hda rootfs-chromium.ext2 -append "root=/dev/sda" + +Thread dump: + +(lldb) thread list +Process 34364 stopped +* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP + thread #2: tid = 0x13598b, 0x00007fff89f4ae6a libsystem_kernel.dylib`__workq_kernreturn + 10 + thread #3: tid = 0x13598c, 0x00007fff89f4b662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' + thread #7: tid = 0x1359b2, 0x00007fff89f4acc2 libsystem_kernel.dylib`__sigwait + 10 + thread #9: tid = 0x1359c1, 0x00000001091bc5d9 + thread #11: tid = 0x1359cc, 0x00007fff89f4a716 libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #12: tid = 0x1359da, 0x00007fff89f46a1a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.audio.IOThread.client' + +------- +* thread #1: tid = 0x135966, 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP + * frame #0: 0x00007fff89f4a746 libsystem_kernel.dylib`__psynch_mutexwait + 10 + frame #1: 0x00007fff8e05f779 libsystem_pthread.dylib`_pthread_mutex_lock + 372 + frame #2: 0x000000010033e8e9 qemu-system-arm`qemu_mutex_lock(mutex=<unavailable>) + 25 at qemu-thread-posix.c:76 + frame #3: 0x000000010002d742 qemu-system-arm`qemu_mutex_lock_iothread + 98 at cpus.c:1137 + frame #4: 0x00000001002c84b5 qemu-system-arm`main_loop_wait [inlined] os_host_main_loop_wait(timeout=<unavailable>) + 191 at main-loop.c:242 + frame #5: 0x00000001002c83f6 qemu-system-arm`main_loop_wait(nonblocking=<unavailable>) + 278 at main-loop.c:494 + frame #6: 0x000000010014961a qemu-system-arm`qemu_main [inlined] main_loop + 73 at vl.c:1789 + frame #7: 0x00000001001495d1 qemu-system-arm`qemu_main(argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) + 17057 at vl.c:4353 + frame #8: 0x000000010029b45e qemu-system-arm`-[QemuCocoaAppController startEmulationWithArgc:argv:](self=<unavailable>, _cmd=<unavailable>, argc=<unavailable>, argv=<unavailable>) + 30 at cocoa.m:897 + +Do these guest images and command lines work on Linux QEMU? (The most common cause of "nothing happens" is "wrong kernel for this board" or similar misconfiguration, where QEMU is correctly emulating a crashed guest that never made any output...) + + +Ah, good question! I found an image and instructions at http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu#Using_QEMU_without_libvirt that was a bit easier to work through, and sure enough, it works on Linux but not on OS X. + +Linux precise64 3.2.0-37-generic: + +vagrant@precise64:/opt/qemu-images/arm/fedora$ /home/vagrant/qemu-2.2.0/arm-softmmu/qemu-system-arm -M versatilepb -kernel zImage-qemu-versatile-3.0.8-4.fc17.armv5tel -hdc rootfs-f12 -append "root=0800 console=ttyAMA0" -nographic +audio: Could not init `oss' audio driver +Uncompressing Linux... done, booting the kernel. +Linux version 3.0.8 (jcapik@vega) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)) #16 Wed Mar 28 15:07:56 CEST 2012 +CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177 +CPU: VIVT data cache, VIVT instruction cache +Machine: ARM-Versatile PB +Memory policy: ECC disabled, Data cache writeback +sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms +... + +------------------------- + + +OS X (just built QEMU 2.2.0 from source): + +$ /Users/epall/bigcode/qemu/arm-softmmu/qemu-system-arm -M versatilepb -kernel zImage-qemu-versatile-3.0.8-4.fc17.armv5tel -hdc rootfs-f12 -append "root=0800 console=ttyAMA0" -nographic +Uncompressing Linux... done, booting the kernel. + +That zImage works for me with QEMU commit ab0302ee76 on OSX 10.9.5 (at least it boots fine to the point of the kernel complaining it couldn't find the rootfs, because I didn't bother to build that.) I tested with the v2.2.0 tag and that works fine too. + +Sanity check: use md5sum to check that the images you ended up with on OSX and Linux are actually the same and didn't get corrupted in download somehow. Otherwise I'm not sure what's going on. + + +Peter, the bug occurs when mounting the rootfs. + +I can reproduce this bug too, with a kernel that works perfectly on QEMU on linux, windows and linux running on the same mac under vmware. In the case where I ran it under vmware on the mac the raspi kernel is the same file shared between the host os (os x) and the guest (linux) os. + +Here's how I built QEMU on my brandy new mac + + 34 xcode-select --install + 35 ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" + 38 brew doctor + 47 brew install pkg-config + 51 git checkout 2b7b4b3 Library/Formula/qemu.rb + 53 $: brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb + 54 brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb + 55 brew install qemu --env=std --cc=gcc-4.2 + 56 cd + 57 cd Desktop/qemu + +here's what happens when I run it: + +GSSLA40052111:Qemu jgallun$ cat pi.sh +#!/bin/sh + +qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2014-09-09-wheezy-raspbian.img + +I've attached a screenshot of what happens when I boot this kernel on the mac. + +The kernel I used in this example came from this website: http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ + + > brew install qemu --env=std --cc=gcc-4.2 + +Aha. Don't do that, that's an ancient gcc. Use the system 'clang' (which configure should pick by default). + + +Thanks for the quick response. Being a total mac n00b I just followed the directions in the top google link for installing qemu on os x and I ended up where I did. I replaced the old version of the qemu formula in my brew library with the current one and re-installed and all is well, running qemu 2.2.0. Not that it matters, but the directions I followed have you checkout an old version of qemu (1.1.0) that won't compile with clang or a modern gcc, hence the ancient version of gcc + diff --git a/results/classifier/118/review/1407813 b/results/classifier/118/review/1407813 new file mode 100644 index 000000000..e5bb33e97 --- /dev/null +++ b/results/classifier/118/review/1407813 @@ -0,0 +1,76 @@ +mistranslation: 0.912 +device: 0.683 +semantic: 0.661 +vnc: 0.627 +ppc: 0.606 +graphic: 0.596 +network: 0.587 +performance: 0.583 +peripherals: 0.528 +register: 0.527 +socket: 0.506 +architecture: 0.433 +virtual: 0.412 +hypervisor: 0.393 +files: 0.358 +kernel: 0.337 +risc-v: 0.330 +arm: 0.328 +VMM: 0.327 +debug: 0.326 +permissions: 0.324 +user-level: 0.293 +PID: 0.264 +TCG: 0.262 +i386: 0.255 +x86: 0.245 +assembly: 0.211 +boot: 0.190 +KVM: 0.163 +-------------------- +virtual: 0.428 +mistranslation: 0.158 +debug: 0.152 +hypervisor: 0.096 +TCG: 0.055 +user-level: 0.020 +files: 0.014 +register: 0.012 +network: 0.011 +device: 0.008 +socket: 0.008 +ppc: 0.008 +i386: 0.008 +x86: 0.006 +PID: 0.005 +semantic: 0.005 +kernel: 0.004 +performance: 0.003 +graphic: 0.002 +peripherals: 0.002 +VMM: 0.002 +architecture: 0.002 +assembly: 0.002 +KVM: 0.001 +vnc: 0.001 +arm: 0.001 +permissions: 0.001 +risc-v: 0.001 +boot: 0.001 + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line). + +I think this bug relates to: +https://bugs.launchpad.net/qemu/+bug/1715296 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/118/review/1409 b/results/classifier/118/review/1409 new file mode 100644 index 000000000..ff301ea1c --- /dev/null +++ b/results/classifier/118/review/1409 @@ -0,0 +1,61 @@ +architecture: 0.872 +performance: 0.758 +device: 0.698 +mistranslation: 0.626 +graphic: 0.486 +arm: 0.446 +debug: 0.443 +hypervisor: 0.365 +permissions: 0.308 +assembly: 0.257 +semantic: 0.228 +network: 0.194 +vnc: 0.188 +peripherals: 0.172 +register: 0.170 +user-level: 0.169 +risc-v: 0.128 +VMM: 0.115 +ppc: 0.108 +files: 0.083 +boot: 0.076 +socket: 0.075 +PID: 0.073 +virtual: 0.069 +TCG: 0.065 +kernel: 0.051 +x86: 0.028 +KVM: 0.017 +i386: 0.011 +-------------------- +hypervisor: 0.971 +arm: 0.829 +virtual: 0.797 +user-level: 0.090 +debug: 0.051 +PID: 0.050 +architecture: 0.040 +files: 0.038 +semantic: 0.020 +TCG: 0.013 +device: 0.009 +KVM: 0.008 +assembly: 0.008 +kernel: 0.007 +boot: 0.003 +graphic: 0.002 +performance: 0.002 +VMM: 0.001 +register: 0.001 +ppc: 0.001 +risc-v: 0.001 +permissions: 0.001 +network: 0.001 +x86: 0.000 +socket: 0.000 +mistranslation: 0.000 +peripherals: 0.000 +i386: 0.000 +vnc: 0.000 + +make check failed about qemu@7.2.0on suse15_aarch64 diff --git a/results/classifier/118/review/1414293 b/results/classifier/118/review/1414293 new file mode 100644 index 000000000..81b9f4561 --- /dev/null +++ b/results/classifier/118/review/1414293 @@ -0,0 +1,71 @@ +mistranslation: 0.961 +device: 0.752 +graphic: 0.682 +files: 0.569 +socket: 0.502 +ppc: 0.487 +network: 0.409 +semantic: 0.400 +vnc: 0.349 +register: 0.332 +TCG: 0.287 +boot: 0.233 +architecture: 0.200 +VMM: 0.196 +i386: 0.165 +x86: 0.165 +PID: 0.161 +arm: 0.148 +risc-v: 0.144 +kernel: 0.144 +user-level: 0.131 +debug: 0.124 +performance: 0.109 +virtual: 0.109 +KVM: 0.095 +assembly: 0.088 +hypervisor: 0.084 +peripherals: 0.083 +permissions: 0.079 +-------------------- +i386: 0.653 +x86: 0.328 +TCG: 0.130 +files: 0.110 +kernel: 0.067 +ppc: 0.050 +hypervisor: 0.046 +arm: 0.038 +debug: 0.033 +virtual: 0.023 +VMM: 0.021 +KVM: 0.017 +register: 0.016 +assembly: 0.013 +device: 0.011 +semantic: 0.009 +architecture: 0.008 +risc-v: 0.007 +PID: 0.006 +user-level: 0.006 +boot: 0.005 +peripherals: 0.005 +network: 0.003 +permissions: 0.003 +mistranslation: 0.002 +graphic: 0.002 +performance: 0.002 +socket: 0.002 +vnc: 0.002 + +target-lm32/translate.c:336: bad ? : operator + +[qemu/target-lm32/translate.c:336]: (style) Same expression in both branches of ternary operator. + + int rY = (dc->format == OP_FMT_RR) ? dc->r0 : dc->r0; + +Patch has been committed: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=5db35b616b8d3a27783ec + +Released with version 2.8 + diff --git a/results/classifier/118/review/1416246 b/results/classifier/118/review/1416246 new file mode 100644 index 000000000..76403594c --- /dev/null +++ b/results/classifier/118/review/1416246 @@ -0,0 +1,115 @@ +x86: 0.857 +architecture: 0.823 +graphic: 0.790 +kernel: 0.757 +device: 0.703 +debug: 0.700 +performance: 0.665 +semantic: 0.654 +assembly: 0.621 +mistranslation: 0.593 +network: 0.556 +PID: 0.535 +hypervisor: 0.534 +peripherals: 0.502 +files: 0.452 +ppc: 0.432 +KVM: 0.429 +user-level: 0.404 +socket: 0.377 +register: 0.374 +VMM: 0.358 +permissions: 0.350 +vnc: 0.306 +virtual: 0.301 +risc-v: 0.290 +arm: 0.279 +i386: 0.244 +TCG: 0.241 +boot: 0.222 +-------------------- +x86: 0.678 +KVM: 0.544 +virtual: 0.367 +hypervisor: 0.313 +TCG: 0.271 +debug: 0.245 +files: 0.073 +register: 0.053 +kernel: 0.040 +PID: 0.008 +semantic: 0.005 +device: 0.005 +socket: 0.005 +risc-v: 0.004 +user-level: 0.004 +architecture: 0.003 +performance: 0.003 +boot: 0.003 +vnc: 0.002 +assembly: 0.002 +graphic: 0.002 +network: 0.001 +VMM: 0.001 +i386: 0.001 +permissions: 0.001 +mistranslation: 0.001 +peripherals: 0.001 +ppc: 0.001 +arm: 0.000 + +create guest fail when compile qemu with parameter "--disable-gtk" + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:8fff5e374a2f6047d1bb52288af7da119bc75765 +qemu.kvm Commit:16017c48547960539fcadb1f91d252124f442482 +Host Kernel Version:3.19.0-rc3 +Hardware:Ivytown_EP, Haswell_EP + + +Bug detailed description: +-------------------------- +compile the qemu with disable gtk, the create guest , the guest create fail + +note: +1.qemu.git: 699eae17b841e6784dc3864bf357e26bff1e9dfe +when compile the qemu with enable gtk or disable gtk, the guest create pass + +2. this should be a qemu bug +kvm.git + qemu.git = result +8fff5e37 + 16017c48 = bad +8fff5e37 + 699eae17 = good + +Reproduce steps: +---------------- +1. git clone git://vt-sync/qemu.git qemu.git +2. cd qemu.git +3. ./configure --target-list=x86_64-softmmu --disable-sdl --disable-gtk +4. make -j16 +5. ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -net none /root/rhel6u5.qcow + +Current result: +---------------- +create gust fail when compile qemu with disable gtk + +Expected result: +---------------- +create guest pass when compile qemu with disable or enable gtk + +Basic root-causing log: +---------------------- +[root@vt-ivt2 qemu.git]# ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4G -smp 2 -net none /root/rhel6u5-1.qcow +qemu-system-x86_64: Invalid parameter 'to' +Segmentation fault (core dumped) + +some dmesg message: +qemu-system-x86[96364]: segfault at 24 ip 00007fe6d9636a69 sp 00007fffc03cf970 error 4 in qemu-system-x86_64[7fe6d9330000+4ba000] + +Triaging 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/review/1429841 b/results/classifier/118/review/1429841 new file mode 100644 index 000000000..d19c45dd2 --- /dev/null +++ b/results/classifier/118/review/1429841 @@ -0,0 +1,179 @@ +mistranslation: 0.813 +permissions: 0.809 +register: 0.778 +architecture: 0.770 +hypervisor: 0.769 +semantic: 0.759 +arm: 0.751 +assembly: 0.732 +virtual: 0.730 +device: 0.729 +kernel: 0.728 +user-level: 0.725 +PID: 0.723 +risc-v: 0.711 +VMM: 0.692 +network: 0.686 +TCG: 0.680 +peripherals: 0.675 +graphic: 0.669 +debug: 0.657 +vnc: 0.653 +files: 0.649 +boot: 0.642 +performance: 0.637 +i386: 0.630 +socket: 0.607 +ppc: 0.601 +KVM: 0.588 +x86: 0.535 +-------------------- +arm: 0.998 +kernel: 0.420 +debug: 0.191 +virtual: 0.170 +VMM: 0.092 +files: 0.085 +TCG: 0.064 +boot: 0.051 +hypervisor: 0.043 +user-level: 0.037 +register: 0.034 +semantic: 0.031 +device: 0.025 +architecture: 0.021 +PID: 0.019 +KVM: 0.011 +assembly: 0.009 +performance: 0.008 +peripherals: 0.006 +vnc: 0.006 +permissions: 0.006 +socket: 0.004 +graphic: 0.004 +risc-v: 0.003 +network: 0.003 +mistranslation: 0.002 +ppc: 0.001 +x86: 0.000 +i386: 0.000 + +error "rom: requested regions overlap" for NOLOAD sections + +command line: +qemu-system-arm -semihosting -nographic -monitor null -serial null -no-reboot -kernel build/fw/0HNFcomSLuP1_CUNIT.elf + +output: +rom: requested regions overlap (rom phdr #6: build/fw/0HNFcomSLuP1_CUNIT.elf. free=0x8001effc, addr=0x8001c000) +rom loading failed + +I checked the sections of the .elf file with arm-none-eabi-objdump -h: +Sections: +Idx Name Size VMA LMA File off Algn +... + 35 .marker_appli 00001000 801ae000 801ae000 00025000 2**0 + ALLOC + 36 .safe_data 00000014 80200000 8001b000 00020000 2**2 + CONTENTS, ALLOC, LOAD, DATA + 37 .safe_bss 00000488 80200020 8001b020 00020014 2**2 + ALLOC + 38 .marker_safe_data 00001000 80201000 8001c000 00029000 2**0 + ALLOC + 39 .data 000008cc 80202000 8001b600 00022000 2**3 + CONTENTS, ALLOC, LOAD, DATA + 40 .bss 0000312c 802028d0 8001bed0 000228cc 2**3 + ALLOC + 41 .marker_data 00001000 80206000 8001f600 00026000 2**0 + ALLOC + 42 .cunit 00010000 80300000 80119600 00028000 2**0 + ALLOC + 43 .marker_code 00001000 8001c000 8001c000 00024000 2**0 + ALLOC +... + +So I had a look where the values in the error message could come from: +0x8001c000: is the "LMA" value of section .marker_safe_data +0x8001effc: is "Size" + "LMA" of the .bss section (0x0000312c + 0x8001bed0) + +So it is correct that (regarding the "LMA" value) the .marker_safe_data section collides with .bss section. +But actually these sections have no "LOAD" attribute, so I would guess that their "LMA" should not be used anyway. +Those section should reside at their "VMA" addresses (0x802xxxxx) during runtime but they have no data to load. + +Or am I getting something completely wrong? +Should I give an additional option to qemu? + +I got this error with 2.0.0+dfsg-2ubuntu1.10 and 1.0.50-2012.03-0ubuntu2.1 +I didn't get this error (but others) with 0.10.2 + + + +I did a test (with version 2.2.0) to simply not fail out upon this error (removed the "return -1" in function rom_load_all() in file hw/core/loader.c). + +With that hack I got the elf file running I'll attach with *this* comment (note that attachment #1 won't run correctly but probably for some other reason as I never had this working anywhere). +So when I run with my hack: +qemu-system-arm -M integratorcp -semihosting -nographic -monitor null -serial null -no-reboot -kernel 0MFWSL_EmoDatauP1_CUNIT.elf + +I get: +rom: requested regions overlap (rom phdr #4: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000017ae0, addr=0x0000000000016aac) +rom: requested regions overlap (rom phdr #5: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000000185e8, addr=0x0000000000017e64) + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: MFWSL_EmoData + Test: MFWSL_EmoFileOpen ... passed + Test: MFWSL_ChkEmosSodHdr ... passed + Test: MFWSL_ChkEmosFileHdr ... passed + Test: MFWSL_ChkEmosSodSect ... passed + Test: MFWSL_ChkEmosFileSect ... passed + Test: MFWSL_AddEntryToCpyList ... passed + Test: MFWSL_EmosAvailableForSect ... passed + Test: MFWSL_CreateCpyListFromSect ... passed + Test: MFWSL_SodEmosActive ... passed + Test: MFWSL_CreateExtMoList ... passed + Test: MFWSL_ExtendedEmosActive ... passed + +--Run Summary: Type Total Ran Passed Failed + suites 1 1 n/a 0 + tests 11 11 11 0 + asserts 2854 2854 2854 0 + +...where the last part is the output I expected for a clean run. + +regarding the values in the error messages I it looks like: +free=0x0000000000017ae0 = end of .safe_bss (0x16aac + 0x1034) which is NOLOAD +addr=0x0000000000016aac = start of .data which is LOAD +free=0x00000000000185e8 = end of .bss (0x17570 + 0x1078) which is NOLOAD +addr=0x0000000000017e64 = start of .marker1 which is NOLOAD + +Any optinions? + +additional info: +0MFWSL_EmoDatauP1_CUNIT.elf from previous post runs fine with 1.0.50 (Debian 1.0.50-2012.03-0ubuntu2.1) and 0.10.2 + +To make things more easy I added some debug output to function rom_load_all(). +It prints infos for every rom section is processes: + +rom phdr #1: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000000000, size=0x000000000000003c, addr=0x0000000000000000) +rom phdr #2: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000000008a0, size=0x00000000000161c4, addr=0x000000000000003c) +rom phdr #3: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000016a64, size=0x000000000000107c, addr=0x0000000000016a64) +rom phdr #4: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000016aac, size=0x0000000000001b3c, addr=0x0000000000017ae0) +rom: requested regions overlap (rom phdr #4: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000017ae0, addr=0x0000000000016aac, size=0x0000000000001b3c) +rom phdr #5: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000017e64, size=0x0000000000000400, addr=0x00000000000185e8) +rom: requested regions overlap (rom phdr #5: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000000185e8, addr=0x0000000000017e64, size=0x0000000000000400) +rom phdr #6: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000001152ac, size=0x0000000000000400, addr=0x0000000000018264) +rom phdr #7: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000001a7000, size=0x0000000000000400, addr=0x00000000001156ac) + +Retest with qemu 2.7.0: issue still occours +Same fix works for me: removed 'return -1;' in function rom_check_and_register_reset() (line 1030 of file hw/core/loader.c) + +This bug is fixed in QEMU master by commits bf1733392ca2 and f33e5e6299288c, which will be in the upcoming QEMU 2.11 release. + +(PS: the thing the loader cares about is not elf sections but elf segments in the program header, so the section table and its attributes isn't relevant here, only the program header. In any case your example ELF file loads OK with the bugfixes applied.) + + +Just tested with QEMU 2.10.93 in cygwin: problem does not occour anymore! + +Thanks a lot! + diff --git a/results/classifier/118/review/1431 b/results/classifier/118/review/1431 new file mode 100644 index 000000000..bf3f26165 --- /dev/null +++ b/results/classifier/118/review/1431 @@ -0,0 +1,110 @@ +mistranslation: 0.819 +graphic: 0.796 +device: 0.622 +KVM: 0.470 +files: 0.389 +x86: 0.364 +socket: 0.356 +PID: 0.355 +debug: 0.353 +semantic: 0.338 +permissions: 0.305 +register: 0.256 +vnc: 0.251 +kernel: 0.240 +VMM: 0.223 +peripherals: 0.223 +virtual: 0.210 +hypervisor: 0.193 +user-level: 0.173 +boot: 0.171 +TCG: 0.163 +performance: 0.161 +architecture: 0.157 +ppc: 0.147 +risc-v: 0.145 +i386: 0.133 +arm: 0.129 +network: 0.121 +assembly: 0.082 +-------------------- +virtual: 0.963 +KVM: 0.961 +x86: 0.959 +hypervisor: 0.953 +user-level: 0.325 +debug: 0.150 +device: 0.067 +kernel: 0.035 +architecture: 0.028 +files: 0.026 +socket: 0.018 +TCG: 0.016 +performance: 0.015 +graphic: 0.014 +semantic: 0.009 +boot: 0.009 +register: 0.008 +peripherals: 0.008 +PID: 0.006 +ppc: 0.005 +VMM: 0.004 +network: 0.003 +permissions: 0.002 +assembly: 0.002 +risc-v: 0.001 +i386: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +qemu spice support opengl +Steps to reproduce: +I wan to use spice support opengl, but my qemu seems not support,what can i do to support opengl for spice? + +qemu configure: +``` +./configure --target-list=x86_64-softmmu --enable-kvm --enable-debug --enable-spice --enable-numa --enable-libusb --enable-curl --enable-usb-redir --enable-libiscsi --enable-virglrenderer --enable-opengl --enable-gtk --prefix="/usr" +``` + +xml: +```xml +<domain type='kvm'> + <name>test</name> + <memory>1048576</memory> + <currentMemory>1048576</currentMemory> + <vcpu>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + </os> + <cpu mode='custom' match='exact' check='full'> + <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/root/kk.img'/> + <target dev='hda' bus='ide'/> + </disk> + <input type='mouse' bus='ps2'/> + <graphics type='spice'> + <listen type='none'/> + <gl enable='yes' rendernode='/dev/dri/renderD128'/> + </graphics> + </devices> +</domain> +``` + +error report: + + diff --git a/results/classifier/118/review/1431084 b/results/classifier/118/review/1431084 new file mode 100644 index 000000000..e97abd8ff --- /dev/null +++ b/results/classifier/118/review/1431084 @@ -0,0 +1,75 @@ +mistranslation: 0.996 +graphic: 0.895 +semantic: 0.879 +user-level: 0.878 +device: 0.877 +kernel: 0.824 +architecture: 0.793 +arm: 0.755 +TCG: 0.751 +ppc: 0.727 +VMM: 0.723 +vnc: 0.714 +PID: 0.690 +network: 0.690 +files: 0.689 +register: 0.672 +boot: 0.638 +risc-v: 0.623 +performance: 0.619 +debug: 0.597 +socket: 0.545 +KVM: 0.475 +permissions: 0.458 +x86: 0.446 +hypervisor: 0.440 +peripherals: 0.439 +virtual: 0.293 +i386: 0.239 +assembly: 0.198 +-------------------- +user-level: 0.370 +TCG: 0.125 +semantic: 0.070 +VMM: 0.050 +debug: 0.034 +files: 0.030 +kernel: 0.019 +register: 0.011 +risc-v: 0.010 +device: 0.008 +virtual: 0.006 +PID: 0.005 +socket: 0.004 +network: 0.004 +performance: 0.003 +permissions: 0.002 +architecture: 0.002 +boot: 0.002 +vnc: 0.002 +assembly: 0.001 +peripherals: 0.001 +ppc: 0.001 +KVM: 0.001 +mistranslation: 0.001 +hypervisor: 0.001 +x86: 0.001 +graphic: 0.001 +arm: 0.000 +i386: 0.000 + +improve configure error message "ERROR: User requested feature nptl" + +Running `./configure` on Ubuntu 14.10 amd64 with Linux 3.19.1 causes the error + + ERROR: User requested feature nptl + configure was not able to find it. + Install glibc and linux kernel headers. + +Both linux kernel headers and `libglib2.0-dev` are installed in my case, so the error message definitely misses a point and is at least confusing and should either omit the hint if the recommended dependencies are already installed or - better - give one that fixes the issue. + +experienced with git commit d598911b6f5e7bf7bafb63b8e1d074729e94aca7 + +You say "Both linux kernel headers and `libglib2.0-dev` are installed", but the error message says "Install glibc and linux kernel headers". "glibc" is not "libglib". I suspect you didn't have what on Ubuntu is the "libc6-dev" package. Unfortunately it's difficult to be specific in these error messages, because different distros call their dev packages by different names. + + diff --git a/results/classifier/118/review/1434 b/results/classifier/118/review/1434 new file mode 100644 index 000000000..9b9a8df14 --- /dev/null +++ b/results/classifier/118/review/1434 @@ -0,0 +1,63 @@ +architecture: 0.976 +arm: 0.788 +device: 0.692 +mistranslation: 0.475 +network: 0.461 +boot: 0.366 +register: 0.296 +risc-v: 0.290 +VMM: 0.283 +performance: 0.211 +socket: 0.209 +semantic: 0.209 +permissions: 0.197 +graphic: 0.194 +TCG: 0.189 +ppc: 0.174 +PID: 0.169 +debug: 0.143 +peripherals: 0.137 +vnc: 0.102 +files: 0.098 +virtual: 0.070 +hypervisor: 0.064 +user-level: 0.062 +kernel: 0.030 +assembly: 0.029 +KVM: 0.013 +i386: 0.002 +x86: 0.001 +-------------------- +arm: 0.988 +architecture: 0.169 +hypervisor: 0.051 +virtual: 0.050 +device: 0.030 +VMM: 0.025 +semantic: 0.020 +TCG: 0.015 +files: 0.013 +boot: 0.007 +assembly: 0.005 +socket: 0.005 +user-level: 0.004 +debug: 0.003 +kernel: 0.003 +register: 0.002 +network: 0.002 +risc-v: 0.001 +PID: 0.001 +KVM: 0.001 +graphic: 0.001 +permissions: 0.001 +performance: 0.001 +ppc: 0.001 +vnc: 0.000 +mistranslation: 0.000 +peripherals: 0.000 +x86: 0.000 +i386: 0.000 + +Windows on ARM64 host support +Additional information: + diff --git a/results/classifier/118/review/1437811 b/results/classifier/118/review/1437811 new file mode 100644 index 000000000..ebb7e1b19 --- /dev/null +++ b/results/classifier/118/review/1437811 @@ -0,0 +1,71 @@ +mistranslation: 0.834 +graphic: 0.729 +device: 0.712 +socket: 0.694 +files: 0.688 +TCG: 0.519 +network: 0.511 +register: 0.476 +ppc: 0.434 +performance: 0.399 +x86: 0.396 +debug: 0.378 +i386: 0.369 +arm: 0.350 +vnc: 0.348 +semantic: 0.330 +architecture: 0.307 +kernel: 0.302 +peripherals: 0.302 +boot: 0.301 +assembly: 0.274 +PID: 0.265 +risc-v: 0.222 +hypervisor: 0.184 +user-level: 0.160 +KVM: 0.144 +VMM: 0.142 +virtual: 0.088 +permissions: 0.085 +-------------------- +debug: 0.711 +files: 0.590 +TCG: 0.247 +hypervisor: 0.144 +x86: 0.141 +kernel: 0.084 +i386: 0.056 +arm: 0.047 +architecture: 0.021 +register: 0.017 +performance: 0.015 +PID: 0.014 +virtual: 0.014 +device: 0.013 +ppc: 0.011 +KVM: 0.010 +assembly: 0.010 +boot: 0.008 +semantic: 0.008 +VMM: 0.005 +risc-v: 0.004 +network: 0.003 +peripherals: 0.003 +user-level: 0.003 +permissions: 0.002 +graphic: 0.002 +socket: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +target-tricore/op_helper.c:2576: bad if statement + +[qemu/target-tricore/op_helper.c:2576]: (style) Expression '(X & 0x400000) == 0x1' is always false. + + if ((env->PCXI & MASK_PCXI_UL) == 1) { + /* CTYP trap */ + } + +This problem has been fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7b4b0b5795e934a9b7efb + diff --git a/results/classifier/118/review/1438144 b/results/classifier/118/review/1438144 new file mode 100644 index 000000000..ba7ea6823 --- /dev/null +++ b/results/classifier/118/review/1438144 @@ -0,0 +1,77 @@ +mistranslation: 0.884 +device: 0.760 +semantic: 0.744 +user-level: 0.660 +performance: 0.653 +network: 0.649 +graphic: 0.623 +kernel: 0.607 +architecture: 0.580 +permissions: 0.563 +socket: 0.557 +files: 0.550 +ppc: 0.495 +register: 0.472 +vnc: 0.471 +hypervisor: 0.419 +debug: 0.393 +peripherals: 0.386 +risc-v: 0.359 +boot: 0.351 +VMM: 0.340 +i386: 0.316 +arm: 0.312 +x86: 0.294 +assembly: 0.251 +PID: 0.235 +virtual: 0.225 +KVM: 0.220 +TCG: 0.194 +-------------------- +x86: 0.621 +files: 0.517 +register: 0.281 +i386: 0.244 +architecture: 0.173 +arm: 0.105 +semantic: 0.097 +hypervisor: 0.086 +virtual: 0.052 +kernel: 0.052 +TCG: 0.043 +user-level: 0.034 +ppc: 0.019 +device: 0.016 +debug: 0.016 +VMM: 0.016 +PID: 0.008 +assembly: 0.008 +risc-v: 0.008 +performance: 0.005 +peripherals: 0.003 +network: 0.003 +socket: 0.002 +boot: 0.002 +KVM: 0.001 +vnc: 0.001 +graphic: 0.001 +permissions: 0.000 +mistranslation: 0.000 + +Page sizes are not interpreted correctly for E500/E500MC + +http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf - see 2.12.5.2 MAS Register 1 (MAS1), p. 2-41 +http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf - see 2.16.6.2 MAS Register 1 (MAS1), p. 2-54 + +According to these documents, variable page size for TLB1 is computed as 4K ** TSIZE. + +However, QEMU always treats it as if it was 1K << TSIZE, even if options like "-cpu e500mc" are supplied to qemu. + +This is not a bug. MMU v2 (implemented in e6500) extended the TSIZE field so that 1K << +TSIZE is correct. The extension was on the LSB side so that it works +fine as long as the low bit of the new TSIZE (which is reserved on +e500v2/mc) is zero. + + +You're absolutely right. Sorry for bothering. + diff --git a/results/classifier/118/review/1458 b/results/classifier/118/review/1458 new file mode 100644 index 000000000..eeb1e3c2b --- /dev/null +++ b/results/classifier/118/review/1458 @@ -0,0 +1,87 @@ +architecture: 0.881 +x86: 0.784 +device: 0.779 +graphic: 0.761 +VMM: 0.636 +register: 0.629 +TCG: 0.564 +network: 0.487 +vnc: 0.469 +socket: 0.446 +performance: 0.434 +permissions: 0.434 +ppc: 0.423 +PID: 0.369 +semantic: 0.366 +debug: 0.355 +kernel: 0.354 +arm: 0.353 +hypervisor: 0.323 +boot: 0.318 +mistranslation: 0.304 +peripherals: 0.288 +user-level: 0.243 +virtual: 0.231 +files: 0.228 +i386: 0.225 +assembly: 0.210 +risc-v: 0.201 +KVM: 0.187 +-------------------- +register: 0.841 +virtual: 0.632 +debug: 0.456 +TCG: 0.210 +architecture: 0.203 +hypervisor: 0.200 +device: 0.117 +semantic: 0.075 +x86: 0.072 +VMM: 0.029 +files: 0.019 +PID: 0.018 +kernel: 0.016 +assembly: 0.009 +peripherals: 0.009 +risc-v: 0.008 +user-level: 0.008 +socket: 0.008 +performance: 0.006 +ppc: 0.004 +boot: 0.003 +vnc: 0.003 +KVM: 0.003 +network: 0.003 +arm: 0.002 +i386: 0.002 +permissions: 0.002 +graphic: 0.001 +mistranslation: 0.001 + +ns16550a reg-shift incorrect for qemu-system-riscv64 +Description of problem: +Missing reg-shift 0 on the ns16550n in qemu-system-riscv64 creates an impossible assumption case. +Steps to reproduce: +1. qemu-system-riscv64 -M virt,dumpdtb=dtb +2. dtc dtb | less + + serial@10000000 { + interrupts = <0x0a>; + interrupt-parent = <0x03>; + clock-frequency = "\08@"; + reg = <0x00 0x10000000 0x00 0x100>; + compatible = "ns16550a"; + }; + +Generally, ns16550a has a default reg-shift of 0 on x86,x86_64 for compatibility reasons. All other architectures have an assumed reg-shift of 2 (or having the reg-shift assumption overridden by fdt providing a reg-shift property) + +Beyond the above, anything non-standard is assumed to be specified by the "reg-shift" property fdt. + +qemu-system-riscv64 seems to "assume" a reg-shift of 0. Other riscv64 devices don't supply "reg-shift" (SiFive Unmatched) and "assume" 2. +The above means driver writers don't actually know what to "assume" on riscv64 ns16550a when no reg-shift is present. + + +Essentially, qemu-system-riscv64 needs to do one of the following: + +* If serial ns16550a with a uart reg-shift of 0 is intentional, qemu needs to advertise the deviance via "reg-shift 0" +* If serial ns16550a with a uart reg-shift of 0 is unintentional, it needs updated to 2 so drivers can assume 2 on riscv64. diff --git a/results/classifier/118/review/1459626 b/results/classifier/118/review/1459626 new file mode 100644 index 000000000..36546b572 --- /dev/null +++ b/results/classifier/118/review/1459626 @@ -0,0 +1,80 @@ +x86: 0.934 +architecture: 0.934 +virtual: 0.919 +user-level: 0.765 +graphic: 0.717 +performance: 0.716 +device: 0.689 +peripherals: 0.613 +i386: 0.573 +KVM: 0.566 +kernel: 0.555 +mistranslation: 0.512 +boot: 0.506 +hypervisor: 0.479 +semantic: 0.476 +ppc: 0.421 +permissions: 0.412 +PID: 0.373 +register: 0.336 +network: 0.329 +files: 0.328 +socket: 0.269 +VMM: 0.244 +vnc: 0.225 +debug: 0.213 +TCG: 0.208 +risc-v: 0.188 +assembly: 0.105 +arm: 0.084 +-------------------- +virtual: 0.984 +hypervisor: 0.809 +debug: 0.807 +x86: 0.763 +TCG: 0.177 +VMM: 0.065 +user-level: 0.035 +files: 0.030 +PID: 0.027 +KVM: 0.019 +performance: 0.013 +device: 0.010 +socket: 0.010 +boot: 0.010 +network: 0.007 +semantic: 0.006 +kernel: 0.004 +graphic: 0.004 +architecture: 0.003 +register: 0.003 +peripherals: 0.003 +ppc: 0.002 +vnc: 0.001 +permissions: 0.001 +arm: 0.001 +assembly: 0.001 +i386: 0.001 +risc-v: 0.001 +mistranslation: 0.000 + +emacs (gtk3) core dumped with -vga qxl + +Emacs (gtk3) exited with bus error and core dumped with -vga qxl. If I use the builtin modesetting xorg driver, emacs could survive for a short while sometimes. If I use xf86-video-qxl (git r587.8babd05), it dies right away with the same error. It seems to corrupt xorg at some point as well, because sometimes I cannot exit i3 properly and gnome-terminal can go crazy afterwards (all letters become empty retangles). + +It doesn't seem to happen with other -vga driver. + +Error message is attached. Can also provide the core dumped but it's of 47M. + +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, xorg-server 1.17.1, linux 4.0.4, gtk 3.16.3, glib 2.44.1 + + + +Looking through old bug tickets... can you still reproduce this issue with the latest versions of QEMU, x11, kernel, spice, etc.? 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/review/146 b/results/classifier/118/review/146 new file mode 100644 index 000000000..9331b56eb --- /dev/null +++ b/results/classifier/118/review/146 @@ -0,0 +1,61 @@ +mistranslation: 0.992 +device: 0.888 +semantic: 0.874 +user-level: 0.571 +peripherals: 0.544 +graphic: 0.528 +performance: 0.514 +permissions: 0.462 +network: 0.451 +virtual: 0.429 +boot: 0.314 +architecture: 0.311 +arm: 0.267 +files: 0.263 +vnc: 0.226 +risc-v: 0.220 +socket: 0.192 +debug: 0.148 +register: 0.141 +TCG: 0.126 +ppc: 0.108 +VMM: 0.102 +PID: 0.048 +assembly: 0.035 +hypervisor: 0.029 +KVM: 0.027 +kernel: 0.016 +x86: 0.003 +i386: 0.003 +-------------------- +peripherals: 0.623 +virtual: 0.430 +mistranslation: 0.288 +semantic: 0.109 +PID: 0.057 +device: 0.053 +debug: 0.036 +user-level: 0.031 +kernel: 0.015 +performance: 0.014 +hypervisor: 0.012 +KVM: 0.005 +x86: 0.005 +VMM: 0.003 +vnc: 0.003 +assembly: 0.002 +TCG: 0.002 +files: 0.002 +boot: 0.002 +risc-v: 0.002 +graphic: 0.002 +arm: 0.001 +register: 0.001 +permissions: 0.001 +socket: 0.001 +architecture: 0.001 +ppc: 0.001 +i386: 0.001 +network: 0.000 + +macOS Guest Reading USB 3.0 Bus as USB 2.0 diff --git a/results/classifier/118/review/1461 b/results/classifier/118/review/1461 new file mode 100644 index 000000000..0392ba513 --- /dev/null +++ b/results/classifier/118/review/1461 @@ -0,0 +1,61 @@ +mistranslation: 0.878 +graphic: 0.787 +performance: 0.734 +device: 0.713 +architecture: 0.686 +virtual: 0.651 +semantic: 0.647 +risc-v: 0.411 +assembly: 0.366 +arm: 0.248 +vnc: 0.236 +network: 0.205 +ppc: 0.190 +permissions: 0.178 +register: 0.170 +debug: 0.166 +user-level: 0.161 +boot: 0.139 +hypervisor: 0.114 +VMM: 0.099 +PID: 0.076 +i386: 0.071 +x86: 0.037 +TCG: 0.032 +files: 0.022 +peripherals: 0.021 +kernel: 0.014 +KVM: 0.014 +socket: 0.013 +-------------------- +hypervisor: 0.953 +virtual: 0.925 +user-level: 0.090 +semantic: 0.031 +mistranslation: 0.030 +files: 0.022 +debug: 0.022 +device: 0.015 +performance: 0.009 +network: 0.008 +x86: 0.007 +boot: 0.004 +VMM: 0.004 +assembly: 0.003 +arm: 0.003 +kernel: 0.003 +register: 0.002 +permissions: 0.002 +peripherals: 0.001 +PID: 0.001 +TCG: 0.001 +ppc: 0.001 +i386: 0.001 +graphic: 0.001 +socket: 0.001 +risc-v: 0.000 +vnc: 0.000 +KVM: 0.000 +architecture: 0.000 + +Virgl on Upstream windows builds? diff --git a/results/classifier/118/review/1463172 b/results/classifier/118/review/1463172 new file mode 100644 index 000000000..583187504 --- /dev/null +++ b/results/classifier/118/review/1463172 @@ -0,0 +1,91 @@ +architecture: 0.922 +graphic: 0.861 +x86: 0.848 +arm: 0.814 +performance: 0.809 +i386: 0.803 +semantic: 0.760 +mistranslation: 0.728 +device: 0.721 +hypervisor: 0.616 +boot: 0.601 +register: 0.574 +virtual: 0.525 +network: 0.523 +debug: 0.519 +ppc: 0.512 +PID: 0.479 +permissions: 0.472 +socket: 0.455 +kernel: 0.450 +files: 0.428 +user-level: 0.390 +assembly: 0.387 +VMM: 0.354 +peripherals: 0.345 +KVM: 0.344 +vnc: 0.343 +risc-v: 0.300 +TCG: 0.290 +-------------------- +arm: 0.976 +debug: 0.100 +user-level: 0.092 +TCG: 0.051 +virtual: 0.028 +hypervisor: 0.024 +PID: 0.015 +network: 0.015 +semantic: 0.014 +architecture: 0.014 +boot: 0.013 +files: 0.013 +socket: 0.011 +risc-v: 0.010 +register: 0.009 +device: 0.007 +vnc: 0.007 +VMM: 0.006 +performance: 0.005 +x86: 0.005 +kernel: 0.003 +i386: 0.003 +assembly: 0.003 +peripherals: 0.003 +permissions: 0.002 +graphic: 0.001 +ppc: 0.001 +KVM: 0.001 +mistranslation: 0.001 + +destination arm board hangs after migration from x86 source + +The qemu destination on an arm board hangs after migration from a x86 source. With qemu emulating Arch, the migration works fine while the vm is still in the boot selection screen, but if the machine is booted, then the destination arm board vm hangs indefinitely after migrating from the x86 source. This bug does not occur the other way around, meaning a booted vm originally run on arm board will continue to work after migrating to a x86 destination. + +To be sure I'm understanding right, are you migrating from qemu-system-arm on x86 to a native arm board? What are the exact parameters you are passing the emulator, and what exactly is the physical board? + +I am migrating qemu-system-i386 on a x86 to an other qemu-system-i386 on an arm. The exact command line is "qemu-system-i386 -hda arch.img -boot d". The arm board is the APM883208 X-C1. The hard drive image is stored in a share nsf system. + +Sorry, I forgot the include in the ram size parameter. I normally set it to 512m so qemu-system-i386 -hda arch.img -boot d -m 512m. + +Thanks for the information. + +I'm suspect that this sort of migration is not expected to work, but I've marked the bug as affecting upstream in case someone there can comment. + +I'm going to mark this invalid as I don't believe this is a supported case. If someone can vouch for the fact that this is supposed to work, please leave a comment. + +I think it is in theory supposed to work, but possibly in practice it doesn't... + + +Hm, ok, thanks - sadly i don't have any board I can test this on with me. Wonder whether a rpi2 (which I have but not with me) would work. + +Hi, + +would it be possible to run the emulator on arm under gdb (with debugging symbols intalled), do the incoming migration, and then when it hangs, show a backtrace from gdb? + +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 (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1463812 b/results/classifier/118/review/1463812 new file mode 100644 index 000000000..871108131 --- /dev/null +++ b/results/classifier/118/review/1463812 @@ -0,0 +1,237 @@ +register: 0.900 +permissions: 0.888 +PID: 0.878 +ppc: 0.875 +socket: 0.867 +graphic: 0.861 +arm: 0.857 +risc-v: 0.857 +user-level: 0.854 +device: 0.848 +assembly: 0.840 +semantic: 0.837 +architecture: 0.836 +vnc: 0.831 +peripherals: 0.828 +performance: 0.828 +KVM: 0.828 +files: 0.824 +hypervisor: 0.819 +debug: 0.815 +boot: 0.807 +kernel: 0.797 +VMM: 0.793 +network: 0.786 +TCG: 0.779 +mistranslation: 0.724 +virtual: 0.709 +x86: 0.706 +i386: 0.443 +-------------------- +hypervisor: 0.568 +ppc: 0.451 +virtual: 0.435 +debug: 0.339 +TCG: 0.170 +register: 0.144 +socket: 0.104 +user-level: 0.071 +files: 0.062 +network: 0.060 +kernel: 0.050 +risc-v: 0.047 +PID: 0.040 +semantic: 0.032 +device: 0.030 +vnc: 0.030 +VMM: 0.025 +boot: 0.020 +x86: 0.015 +permissions: 0.009 +performance: 0.009 +architecture: 0.008 +KVM: 0.008 +assembly: 0.008 +peripherals: 0.007 +i386: 0.006 +arm: 0.003 +graphic: 0.003 +mistranslation: 0.002 + +qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption + +copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +Run the image on qemu 1.5.3, no problem. + +Hi, + Can you add some details about your host and guest please: + 1) What's your host system? (ppc64 or x86? which os?) + 2) What's the guest disk image format - raw or qcow2? + 3) could you try some of the versions in between 2.3.0 and 1.5.3 ? + 4) Is it just the 5.9 image that has problems or is it more general? + +Dave + +Oh and: + 5) What's your disk image stored on - local disk or network? + 6) WHat's the command line you're using for your guest + +2.3.0 running RHEL7,1 little-endian version no problem. + +I'm using: qemu-system-ppc64 -hda ppcrhel5.img -cpu POWER7 -machine type=pseries,usb=off -m 768 -nographic -net nic -net tap,ifname=tap0,script=no +It's on local disk. +same as on qemu 1.5.3. +> Date: Wed, 10 Jun 2015 12:29:56 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> Oh and: +> 5) What's your disk image stored on - local disk or network? +> 6) WHat's the command line you're using for your guest +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1463812 +> +> Title: +> qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> Status in QEMU: +> New +> +> Bug description: +> copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +> Run the image on qemu 1.5.3, no problem. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions + + +I'm running qemu 2.3.0 on a RHEL5.3/x86 box, 1.5.3 on a CentOS6.6/x86 box. + +> Date: Wed, 10 Jun 2015 12:25:22 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> Hi, +> Can you add some details about your host and guest please: +> 1) What's your host system? (ppc64 or x86? which os?) +> 2) What's the guest disk image format - raw or qcow2? +> 3) could you try some of the versions in between 2.3.0 and 1.5.3 ? +> 4) Is it just the 5.9 image that has problems or is it more general? +> +> Dave +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1463812 +> +> Title: +> qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> Status in QEMU: +> New +> +> Bug description: +> copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +> Run the image on qemu 1.5.3, no problem. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions + + +if you're running the 2.3.0 on the RHEL5.3 and the 1.53 on CentOS6.6 we can't know if the problem +is with the qemu 2.3.0 or with running it on the older host? Please run the two qemus on the same host +and see if the problem follows the host or the qemu version. + +Also, just checking; is that 64bit x86 host or 32 ? + + +and I've just seen your older bug report - https://bugs.launchpad.net/qemu/+bug/1289898 - isn't this exactly the same problem? Why open a new bug? + +Both X86_64. + +> Date: Wed, 10 Jun 2015 16:56:35 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> if you're running the 2.3.0 on the RHEL5.3 and the 1.53 on CentOS6.6 we can't know if the problem +> is with the qemu 2.3.0 or with running it on the older host? Please run the two qemus on the same host +> and see if the problem follows the host or the qemu version. +> +> Also, just checking; is that 64bit x86 host or 32 ? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1463812 +> +> Title: +> qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> Status in QEMU: +> New +> +> Bug description: +> copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +> Run the image on qemu 1.5.3, no problem. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions + + +I already forgot the old one: I got a 2.3.0 qemu installed on the RHEL 5.3 machine, and since this machine has more disk spaces than the CentOS6.4 (now 6.6), so I copied again all emulated machine images from CentOS to RHEL machine, and started to build a new one for RHEL7.1 LE for Power on the 2.3.0, and found it's working quite well, and also other emulated machines are all working fine (mips32, mips32el, mips64el, armv7) on the 2.3.0.Then I just tried to use the RHEL5.9 Power qemu machine, but found root filesystem corrupted, copied from OS image from CentOS, start the qemu machine, again, root filesystem damaged. So, I created the bug report, didn't think about old bug report I made. So, now it's clear, it's on the RHEL5.3 machine, multiple qemu versions have issue with RHEL5.9 for power. + +> Date: Wed, 10 Jun 2015 16:58:40 +0000 +> From: <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> and I've just seen your older bug report - +> https://bugs.launchpad.net/qemu/+bug/1289898 - isn't this exactly the +> same problem? Why open a new bug? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1463812 +> +> Title: +> qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption +> +> Status in QEMU: +> New +> +> Bug description: +> copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +> Run the image on qemu 1.5.3, no problem. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions + + +I built 2.3.0 on CentOS 6.6 machine, and run the RHEL5.9 using the new qemu-system-64 ,and gets the same issue as 2.3.0 on RHEL5.3: + +Checking filesystems +Checking all file systems. +[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda5 +/: Resize inode not valid. + +/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. + (i.e., without -a or -p options) +[FAILED] + +As I stated before on the CentOS6.6, the qemu 1.5.3 running the RHEL5.9 for power is ok. That proves it's not because of RHEL5.3 machine that fs is corrupted, it's the newer qemu for power emulation has issue to run big-endian version of RHEL. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +It seems to me that no one has really looked into the matter, I can't find any comments,that this issue has been worked on. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1463909 b/results/classifier/118/review/1463909 new file mode 100644 index 000000000..fca2ab3c0 --- /dev/null +++ b/results/classifier/118/review/1463909 @@ -0,0 +1,134 @@ +user-level: 0.836 +hypervisor: 0.787 +graphic: 0.783 +risc-v: 0.757 +KVM: 0.751 +arm: 0.747 +VMM: 0.746 +register: 0.744 +virtual: 0.742 +mistranslation: 0.740 +semantic: 0.736 +x86: 0.734 +ppc: 0.727 +vnc: 0.710 +permissions: 0.709 +device: 0.700 +peripherals: 0.691 +assembly: 0.688 +TCG: 0.686 +debug: 0.683 +PID: 0.668 +network: 0.659 +performance: 0.658 +files: 0.647 +kernel: 0.625 +architecture: 0.618 +i386: 0.589 +boot: 0.547 +socket: 0.485 +-------------------- +network: 0.981 +virtual: 0.939 +hypervisor: 0.682 +kernel: 0.311 +TCG: 0.252 +risc-v: 0.116 +register: 0.053 +debug: 0.040 +device: 0.039 +PID: 0.030 +files: 0.027 +x86: 0.023 +socket: 0.019 +boot: 0.017 +VMM: 0.011 +ppc: 0.007 +KVM: 0.007 +semantic: 0.006 +user-level: 0.005 +permissions: 0.003 +assembly: 0.003 +architecture: 0.002 +performance: 0.002 +vnc: 0.002 +peripherals: 0.001 +graphic: 0.001 +arm: 0.001 +i386: 0.001 +mistranslation: 0.000 + +virtio: networking not working when guest's eth0 is not in promiscuous mode + +We are unable to get http responses from qemu guest machine until interface inside qemu guest machine is in promiscuous mode. + +Our configuration is following: + +<pre> + ------------------------ + | Host server | + ------------------------ + | /eth1.10(IP1) | +LAN2-|-eth1-eth1.11(IP2) | + | \eth1.12(IP3) | + | | +LAN1-|-eth0(IP4) <IP[1-4]> | + | / | + | iptables[nat] | + | / ________________ + | | | Guest system | + | tap0-|-eth0(guestIP)| + ------------------------ +</pre> + +Host server is connected to LAN1 with eth0 and to LAN2 with eth1. eth0 has IP4 assigned. eth1 is connected to the switch in trunk mode that has vlans 10, 11 and 12 allows. Thus in Host systems we have eth1.10, eth1.11 and eth1.12 interfaces with IP1, IP2 and IP3 respectfully. + +Inside Host systems we start Guest system using following command: + +> qemu-system-x86_64 -m 3G -nographic -monitor stdio -serial none -kernel /vmlinuz -initrd /webiface.gz -hda /data/data.img -net nic,model=virtio,macaddr=fe:32:31:30:29:00 -net tap,ifname=tap0,script=no,downscript=no + +tap interface was created with commands: +> ip tuntap add dev tap0 mode tap user user +> ip addr add 172.31.31.253/30 brd + dev tap0 +> ip link set dev tap0 up + + +Routing for packets comming from LAN1 or LAN2 to guest system is identical and is done by iptables DNAT target: + +> iptables -t nat -A PREROUTING -d <IP1> -p tcp --dport 8580 -j DNAT --to-destination <guest IP>:80 +... +> iptables -t nat -A PREROUTING -d <IP4> -p tcp --dport 8580 -j DNAT --to-destination <guest IP>:80 + +Now the problem is that requests for @http://<IP4>:8580/index.html@ stall, until we put eth0 on Guest system in promiscuous mode. Note this concerns only packets coming through eth0 on Host system. Requests for @http://<IP[1-3]>:8580/index.html@ work as the should! + +It is really strange how promiscuous mode of the interface on guest system affects the way it receives packets. So we did further debuging with tcpdump. + +For interesting (broken) case when packets arrive through eth0 of Host system, using tcpdump, we found that syn requests are coming out at tap0 interface: + +> 12:40:11.049007 c2:30:61:72:8d:14 > fe:32:31:30:29:00, ethertype IPv4 (0x0800), length 74: <IP>.45661 > <guestIP>.80: Flags [S], seq 1998302974, win 29200, options [mss 1352,sackOK,TS val 3509464 ecr 0,nop,wscale 7], length 0 + +but no packet arrives on guest's eth0 interface! We confirmed that with tcpdump running with promiscuous mode disabled. So packets gone out from tap0 but never archived eth0 of the Guest system! Of course, once we run tcpdump without -p, guest interface will run in promiscuous mode and all packets/traffic will be visible on Guest also and everything works as expected. + +ifconfig shows no drops on tap0 interface. I've check MAC addresses of tap0(c2:30:61:72:8d:14) and guest's eth0 (fe:32:31:30:29:00). I don't see problem here. + +We've tried with eth1 interface not configured (no vlans) and still have this problem. + +This is Ubuntu 12.04.4 LTS server system with 3.2.0-67-generic kernel and QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard. + +Googling we found that similar problem was reported with much older system (but very few details unfortunately): +http://www.serverphorums.com/read.php?12,28222 + +We failed to find any confirmation that this problem was fixed in newer version. Is this a known bug? Any suggestions how to debug? + +I'm seeing this as Thomas was so kind to mark it for Ubuntu after all the time. +To finally answer your closing question, no this is neither a known bug nor reported anywhere else to my knowledge so far. Due to that I can't point to any "here it was fixed" change of later. + +I have to beg your pardon after so much time and ask you if this still happens to whatever setup you have today. And if possible at least use Ubuntu Bionic for the much newer stack of virtualization software. + +For debugging I think you did what you'd expect. +You could start switching device types from virtio to one of the emulated types just to check if it is related. +Further pretty often in "manual" setups there are minor flaws (had some myself) that are already covered by quirks in libvirt. So the next step would to push your setup into a libvirt based guest and if it is working then comparing how it had started your guest. + + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1465935 b/results/classifier/118/review/1465935 new file mode 100644 index 000000000..606bb8756 --- /dev/null +++ b/results/classifier/118/review/1465935 @@ -0,0 +1,349 @@ +user-level: 0.881 +ppc: 0.819 +x86: 0.818 +KVM: 0.818 +i386: 0.814 +vnc: 0.808 +hypervisor: 0.805 +mistranslation: 0.802 +register: 0.792 +virtual: 0.789 +debug: 0.788 +peripherals: 0.773 +VMM: 0.746 +TCG: 0.746 +arm: 0.741 +performance: 0.738 +risc-v: 0.730 +device: 0.728 +graphic: 0.711 +assembly: 0.711 +semantic: 0.706 +architecture: 0.706 +permissions: 0.684 +kernel: 0.664 +PID: 0.661 +boot: 0.656 +network: 0.643 +socket: 0.618 +files: 0.581 +-------------------- +x86: 0.940 +debug: 0.933 +hypervisor: 0.885 +kernel: 0.839 +KVM: 0.808 +virtual: 0.655 +files: 0.103 +user-level: 0.067 +performance: 0.058 +TCG: 0.024 +PID: 0.023 +architecture: 0.020 +device: 0.015 +register: 0.011 +assembly: 0.005 +semantic: 0.005 +boot: 0.004 +socket: 0.004 +ppc: 0.003 +VMM: 0.002 +peripherals: 0.002 +graphic: 0.002 +network: 0.002 +permissions: 0.002 +vnc: 0.001 +risc-v: 0.001 +arm: 0.001 +mistranslation: 0.001 +i386: 0.000 + +kvm_irqchip_commit_routes: Assertion `ret == 0' failed + +Several my QEMU instances crashed, and in the qemu log, I can see this assertion failure, + + qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/kvm-all.c:984: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. + +The QEMU version is 2.0.0, HV OS is ubuntu 12.04, kernel 3.2.0-38. Guest OS is RHEL 6.3. + +The problem can be re-produced by the script in the below in link. +http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg03739.html + +i.e. +vda_irq_num=25 +vdb_irq_num=27 +while [ 1 ] +do + for irq in {1,2,4,8,10,20,40,80} + do + echo $irq > /proc/irq/$vda_irq_num/smp_affinity + echo $irq > /proc/irq/$vdb_irq_num/smp_affinity + dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct + dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct + done +done + +http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg03739.html + +Seems that this patch hasn't been accpeted yet, and also no comments for it. + +From the debug log, we can see that virq is only 1008, but irq route table has been full, i.e. 1024. +In kvm_irqchip_get_virq(), it only calls kvm_flush_dynamic_msi_routes() when all virqs(total gsi_count, 1024 too) have been allocated, but irq route table has two kind of entry type, KVM_IRQ_ROUTING_IRQCHIP and KVM_IRQ_ROUTING_MSI. Seems that 16 KVM_IRQ_ROUTING_IRQCHIP entries has been reserved, if max gsi_count is still 1024, then irq route table is possible to be overflow. +The fix could be either set gsi_cout=1008 or increase max irq route count to 1040. + +kvm_irqchip_send_msi, virq=1008, nr=1024 +kvm_irqchip_commit_routes, ret=-22 +kvm_irqchip_commit_routes, irq_routes nr=1024 + +From kvm_pc_setup_irq_routing() function, we can see that 15 routes from PIC and 23 routes from IOAPIC are added into irq route table, but only 23 irq(gsi) are reserved. This leads to irq route table has been full but there are still tens of free gsi. So the "retry" part of kvm_irqchip_get_virq() shall never have chance to be executed. + + + +void kvm_pc_setup_irq_routing(bool pci_enabled) +{ + KVMState *s = kvm_state; + int i; + + if (kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) { + for (i = 0; i < 8; ++i) { + if (i == 2) { + continue; + } + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_PIC_MASTER, i); + } + for (i = 8; i < 16; ++i) { + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_PIC_SLAVE, i - 8); + } + if (pci_enabled) { + for (i = 0; i < 24; ++i) { + if (i == 0) { + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_IOAPIC, 2); + } else if (i != 2) { + kvm_irqchip_add_irq_route(s, i, KVM_IRQCHIP_IOAPIC, i); + } + } + } + kvm_irqchip_commit_routes(s); + } +} + +static int kvm_irqchip_get_virq(KVMState *s) +{ + uint32_t *word = s->used_gsi_bitmap; + int max_words = ALIGN(s->gsi_count, 32) / 32; + int i, bit; + bool retry = true; + +again: + /* Return the lowest unused GSI in the bitmap */ + for (i = 0; i < max_words; i++) { + bit = ffs(~word[i]); + if (!bit) { + continue; + } + + return bit - 1 + i * 32; + } + if (!s->direct_msi && retry) { + retry = false; + kvm_flush_dynamic_msi_routes(s); + goto again; + } + return -ENOSPC; + +} + + + +Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal: + +apport-collect 1465935 + +When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs. + +It appears that the latest version of the patch is here: + +http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00822.html + +However, this hasn't yet be accepted upstream. The most recent discussion requires the submitter to respond to the maintainers questions here: + +http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00623.html + + + +Have you be able to reproduce this issue on a wily host? What about a different guest? Or is only RHEL6.3 affected? + +Ryan, +Our Hypervisors are running in the internal network which can't access to Launchpad, +# apport-collect 1465935 +ERROR: connecting to Launchpad failed: [Errno 110] Connection timed out + +We saw this qemu crash on 18 Hypervisor nodes. So far all our hypervisors are ubuntu 12.04, qemu-2.0.0+dfsg, and guest OS is only RHEL6.3 + + +http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg00822.html + +Seems that the latest version code has answered maintainers questions. + + +-----Original Message----- +From: Paolo Bonzini [mailto:<email address hidden>] +Sent: 2015年7月1日 21:39 +To: Li, Chengyuan +Cc: <email address hidden> +Subject: Re: [Qemu-devel] [PATCH] Fix irq route entries exceed KVM_MAX_IRQ_ROUTES + +On 30/06/2015 05:47, Li, Chengyuan wrote: +> Here is my understanding, +> +> 1) why isn't the existing check in kvm_irqchip_get_virq enough to fix +> the bug? +> +> From kvm_pc_setup_irq_routing() function, we can see that 15 routes +> from PIC and 23 routes from IOAPIC are added into irq route table, but +> only +> 23 irq(gsi) are reserved. This leads to irq route table has been full +> but there are still 15 free gsi. So the "retry" part of +> kvm_irqchip_get_virq() shall never have chance to be executed. +> +> 2) If you introduce this extra call to kvm_flush_dynamic_msi_routes, +> does the existing check become obsolete? +> +> As gsi_count is the max number of irq route table, if below code is +> merged, then existing check is obsolete and can be removed. +> +> + if (!s->direct_msi && s->irq_routes->nr == s->gsi_count) { +> + kvm_flush_dynamic_msi_routes(s); +> + } +> +> Please let me know if you have some other comments for the patch? Thanks! + +Thanks for finally clearing up my doubts about the patch! I'll apply it soon. + +Paolo + + +The proposed fix seems not yet part of any qemu release but applied as + +commit bdf026317daa3b9dfa281f29e96fbb6fd48394c8 +Author: 马文霜 <email address hidden> +Date: Wed Jul 1 15:41:41 2015 +0200 + + Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES + +to v2.4.0-rc0. So this would affect all current releases and the current development release (Wily/15.10). I would start there with reproduction/verification and work backwards from there. + +Unfortunately I seem to be unable to get this bug triggered with the reproducer. It could be a detail of the guest setup I am missing. Since I do not have access to RHEL I used CentOS 6.3 in a 8core guest with 2 virtio disks. Host was 14.04. Left the script running for quite a bit but no crash happened. +So it would be up to you to confirm that with a current 14.04 host you still can trigger the bug and with the patched version of qemu from http://people.canonical.com/~smb/lp1465935/ it would be gone. Thanks. + +Bader, + +Sorry to response late. +We patch our QEMU 2.0 and running on ubuntu 12.04, and shall keep it running for a while. +I'll let you know if this problem is gone after weeks. + +Regards, +CY. + +Marking as incomplete while waiting for test feedback. + +Bader, + +We don't see this problem after the patch is applied. I think we can close this case. + +Regards, +CY. + +Utopic is out of support now. + +SRU Justification: + +Impact: Moving around interrupt handling on SMP (like irqbalance does) in qemu instances can cause the qemu guest to crash due to an internal accounting mismatch. + +Fix: Backported patch from upstream qemu + +Testcase: See above. Verified for Trusty with provided test qemu package(s). + +@Li Chengyuan, is your host OS really 12.04 (aka Precise)? Because in 12.04 the qemu version is 1.0 and the fix would not apply. I am not sure that old qemu is even affected since the code is very different. Backports of the fix seem only to make sense up (or back) to 14.04 (aka Trusty) which would also match the qemu version 2.0 which you mentioned. + +Just saw kernel version 3.2 mentioned. So this seems to be a mix of older base OS (Precise) and a more recent qemu (maybe from Trusty). I am trying to clarify how far this needs to be backported. So I think the original qemu version in Precise is unaffected. + +This bug was fixed in the package qemu - 1:2.3+dfsg-5ubuntu9 + +--------------- +qemu (1:2.3+dfsg-5ubuntu9) wily; urgency=low + + * debian/patches/upstream-fix-irq-route-entries.patch + Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed" + (LP: #1465935) + + -- Stefan Bader <email address hidden> Fri, 09 Oct 2015 15:38:53 +0200 + +@Stefan Bader, +The host OS is ubuntu 12.04, and we upgraded the QEMU to 2.0.0 from ubuntu cloud-archive repo. +https://wiki.ubuntu.com/ServerTeam/CloudArchive + +@Li Chengyuan, thank you for the clarification. So just formally I will mark the Precise task of this report as invalid (since the qemu in Precise is actually a different source package and also not affected as far as I can tell). I will need to figure out how to ensure this fix is also pulled into the cloud-archive after it landed in the Trusty/Vivid main archive. + +Hello Li, or anyone else affected, + +Accepted qemu into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/2.0.0+dfsg-2ubuntu1.20 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Hello Li, or anyone else affected, + +Accepted qemu into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.2+dfsg-5expubuntu9.6 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +@chengyuanli + +could you please verify this? + +This package is causing a regression in lp:qa-regression-testing's +scripts/test-qemu.py. + +I'm running the testcase one more time (after having verified that the +current package did not suffer the same failure), then I'm going to mark this +verification-failed. + + +Hm, a second run did not reproduce the error. If I can't get it to happen again in a few hours of re-trying, I'll assume it was a fluke or related to the host. + +I could not reproduce the original issue, but the new qemu packages appear to be regression-free, so marked this verification-done on that grounds. If the SRU team prefers to kick this package I'm ok with that as well. + +Fixed in QEMU 2.4. + +This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.20 + +--------------- +qemu (2.0.0+dfsg-2ubuntu1.20) trusty; urgency=low + + * debian/patches/upstream-fix-irq-route-entries.patch + Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed" + (LP: #1465935) + + -- Stefan Bader <email address hidden> Fri, 09 Oct 2015 17:16:30 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 1:2.2+dfsg-5expubuntu9.6 + +--------------- +qemu (1:2.2+dfsg-5expubuntu9.6) vivid; urgency=low + + * debian/patches/upstream-fix-irq-route-entries.patch + Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed" + (LP: #1465935) + + -- Stefan Bader <email address hidden> Fri, 09 Oct 2015 17:04:26 +0200 + diff --git a/results/classifier/118/review/1469924 b/results/classifier/118/review/1469924 new file mode 100644 index 000000000..460b986e2 --- /dev/null +++ b/results/classifier/118/review/1469924 @@ -0,0 +1,115 @@ +user-level: 0.885 +register: 0.783 +mistranslation: 0.775 +permissions: 0.772 +TCG: 0.749 +hypervisor: 0.735 +performance: 0.728 +peripherals: 0.699 +risc-v: 0.690 +virtual: 0.675 +device: 0.649 +KVM: 0.649 +ppc: 0.631 +vnc: 0.615 +boot: 0.609 +arm: 0.604 +architecture: 0.602 +network: 0.595 +files: 0.592 +debug: 0.582 +x86: 0.569 +graphic: 0.557 +semantic: 0.528 +VMM: 0.517 +assembly: 0.517 +socket: 0.497 +PID: 0.482 +kernel: 0.428 +i386: 0.407 +-------------------- +KVM: 0.989 +virtual: 0.930 +hypervisor: 0.919 +boot: 0.889 +x86: 0.823 +debug: 0.691 +socket: 0.400 +PID: 0.146 +kernel: 0.090 +device: 0.079 +register: 0.044 +peripherals: 0.036 +performance: 0.035 +TCG: 0.028 +assembly: 0.025 +architecture: 0.021 +user-level: 0.018 +files: 0.011 +ppc: 0.009 +semantic: 0.008 +permissions: 0.008 +i386: 0.007 +VMM: 0.005 +graphic: 0.003 +risc-v: 0.002 +network: 0.002 +arm: 0.002 +vnc: 0.001 +mistranslation: 0.001 + +qemu-kvm crash when guest os is booting + +this is the command line of qemu. + + +2015-06-30 01:52:59.508+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name rhel7 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2a3f1d8a-850d-4e37-aecd-65cbf1e4e415 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/var/lib/libvirt/images/rhel7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/jemmy/Downloads/rhel-server-7.1-x86_64-dvd.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=2 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b4:7b:bb,bus=pci.0,addr=0x8 -chardev socket,id=charserial0,host=127.0.0.1,port=4555,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev file,id=charserial1,path=/tmp/log.txt -device isa-serial,chardev=charserial1,id=serial1 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on +char device redirected to /dev/pts/2 (label charconsole0) + + +this is the error log of qemu when crash. + +id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, delta 0 +id 1, group 1, virt start 7fbe20000000, virt end 7fbe23ffe000, generation 0, delta 7fbe20000000 +id 2, group 1, virt start 7fbe1c000000, virt end 7fbe20000000, generation 0, delta 7fbe1c000000 +((null):16237): Spice-CRITICAL **: red_memslots.c:69:validate_virt: virtual address out of range + virt=0x0+0x18 slot_id=0 group_id=1 + slot=0x0-0x0 delta=0x0 +Thread 4 (Thread 0x7fbeb3a32700 (LWP 16278)): +#0 0x00007fbec182d407 in ioctl () at /lib64/libc.so.6 +#1 0x00007fbecc80e565 in kvm_vcpu_ioctl () +#2 0x00007fbecc80e61c in kvm_cpu_exec () +#3 0x00007fbecc7fd0a2 in qemu_kvm_cpu_thread_fn () +#4 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#5 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 3 (Thread 0x7fbeb15ff700 (LWP 16287)): +#0 0x00007fbecb2fe1cd in read () at /lib64/libpthread.so.0 +#1 0x00007fbec2a50499 in spice_backtrace_gstack () at /lib64/libspice-server.so.1 +#2 0x00007fbec2a57dae in spice_logv () at /lib64/libspice-server.so.1 +#3 0x00007fbec2a57f05 in spice_log () at /lib64/libspice-server.so.1 +#4 0x00007fbec2a177ff in validate_virt () at /lib64/libspice-server.so.1 +#5 0x00007fbec2a1791e in get_virt () at /lib64/libspice-server.so.1 +#6 0x00007fbec2a17fb9 in red_get_clip_rects () at /lib64/libspice-server.so.1 +#7 0x00007fbec2a1976f in red_get_drawable () at /lib64/libspice-server.so.1 +#8 0x00007fbec2a30332 in red_process_commands.constprop () at /lib64/libspice-server.so.1 +#9 0x00007fbec2a3638a in red_worker_main () at /lib64/libspice-server.so.1 +#10 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#11 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 2 (Thread 0x7fbeb0bff700 (LWP 16289)): +#0 0x00007fbecb2fb590 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 +#1 0x00007fbecca954c9 in qemu_cond_wait () +#2 0x00007fbecca3bfe3 in vnc_worker_thread_loop () +#3 0x00007fbecca3c3c8 in vnc_worker_thread () +#4 0x00007fbecb2f652a in start_thread () at /lib64/libpthread.so.0 +#5 0x00007fbec183722d in clone () at /lib64/libc.so.6 +Thread 1 (Thread 0x7fbeccd2ca80 (LWP 16237)): +#0 0x00007fbec182bd51 in ppoll () at /lib64/libc.so.6 +#1 0x00007fbecca4d2ec in qemu_poll_ns () +#2 0x00007fbecca4ca94 in main_loop_wait () +#3 0x00007fbecc7d58dd in main () + +Which version of QEMU are you using? Does the problem still occur with the latest version of QEMU? What kind of guest and host OS are you using? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1470536 b/results/classifier/118/review/1470536 new file mode 100644 index 000000000..347e2578f --- /dev/null +++ b/results/classifier/118/review/1470536 @@ -0,0 +1,79 @@ +mistranslation: 0.813 +graphic: 0.768 +device: 0.725 +files: 0.616 +ppc: 0.600 +semantic: 0.592 +network: 0.566 +performance: 0.554 +architecture: 0.456 +socket: 0.441 +kernel: 0.429 +vnc: 0.396 +peripherals: 0.392 +arm: 0.349 +PID: 0.329 +boot: 0.280 +register: 0.261 +TCG: 0.252 +debug: 0.252 +VMM: 0.240 +x86: 0.231 +virtual: 0.216 +risc-v: 0.210 +hypervisor: 0.183 +user-level: 0.178 +i386: 0.173 +permissions: 0.156 +KVM: 0.106 +assembly: 0.083 +-------------------- +hypervisor: 0.685 +debug: 0.678 +x86: 0.646 +user-level: 0.478 +i386: 0.457 +files: 0.089 +TCG: 0.083 +virtual: 0.076 +kernel: 0.076 +ppc: 0.059 +device: 0.050 +peripherals: 0.033 +VMM: 0.020 +arm: 0.016 +network: 0.013 +register: 0.011 +performance: 0.011 +architecture: 0.010 +PID: 0.009 +semantic: 0.009 +boot: 0.006 +socket: 0.004 +permissions: 0.004 +risc-v: 0.003 +KVM: 0.002 +graphic: 0.002 +assembly: 0.002 +vnc: 0.001 +mistranslation: 0.001 + +qemu-img incorrectly prints "qemu-img: Host floppy pass-through is deprecated" + +qemu-img incorrectly prints this warning when you use /dev/fd/<NN> to pass in file descriptors. A simple way to demonstrate this uses bash process substitution, so the following will only work if you are using bash as your shell: + +$ qemu-img info <( cat /dev/null ) +qemu-img: Host floppy pass-through is deprecated +Support for it will be removed in a future release. +qemu-img: Could not open '/dev/fd/63': Could not refresh total sector count: Illegal seek + +The root cause is a bug in block/raw-posix.c:floppy_probe_device() where it thinks anything starting with /dev/fd is a floppy drive, which is not the case here: + +http://git.qemu.org/?p=qemu.git;a=blob;f=block/raw-posix.c;h=cbe6574bf4da90a124436a40422dce3667da71e6;hb=HEAD#l2425 + +I sent a patch to qemu-devel which should fix this. + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=25d9747b6427de825322 +... so I am assuming it's OK to close this ticket now. + diff --git a/results/classifier/118/review/1471583 b/results/classifier/118/review/1471583 new file mode 100644 index 000000000..307db9f82 --- /dev/null +++ b/results/classifier/118/review/1471583 @@ -0,0 +1,219 @@ +register: 0.818 +peripherals: 0.815 +graphic: 0.795 +user-level: 0.790 +assembly: 0.755 +device: 0.737 +virtual: 0.727 +debug: 0.726 +semantic: 0.725 +ppc: 0.712 +network: 0.702 +hypervisor: 0.688 +VMM: 0.686 +TCG: 0.682 +permissions: 0.678 +PID: 0.670 +architecture: 0.660 +risc-v: 0.660 +mistranslation: 0.658 +x86: 0.654 +performance: 0.654 +arm: 0.651 +vnc: 0.642 +boot: 0.635 +socket: 0.618 +kernel: 0.591 +KVM: 0.536 +files: 0.502 +i386: 0.295 +-------------------- +x86: 0.996 +virtual: 0.969 +hypervisor: 0.954 +KVM: 0.941 +peripherals: 0.650 +debug: 0.451 +network: 0.299 +device: 0.201 +kernel: 0.132 +boot: 0.109 +files: 0.036 +VMM: 0.033 +user-level: 0.029 +socket: 0.029 +PID: 0.027 +architecture: 0.013 +register: 0.011 +semantic: 0.009 +risc-v: 0.009 +TCG: 0.006 +ppc: 0.005 +i386: 0.004 +performance: 0.004 +permissions: 0.003 +vnc: 0.002 +assembly: 0.002 +graphic: 0.002 +arm: 0.001 +mistranslation: 0.000 + +QCA988X Wifi Card Not PCI Passing Through + +CPU: Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz +KVM: qemu-kvm-1.5.3-86.el7_1.2.x86_64 +Kernel: 4.1.1-1.el7.elrepo.x86_64, and kernel-3.10.0-229.7.2.el7.x86_64 +Host & Guest: CentOS 7.1 +Using virt-manager-1.1.0-12.el7.noarch to create, configure, and start guest + +I am trying to do a PCI passthrough of a QCA988X wifi card. It's a Doodle Labs military-grade 802.11ac miniPCI card, which uses the ath10k kernel driver. This card configures nicely on the host, and seems to pass through to the guest, but early in the boot of the guest it says "Unknown header type" at the wifi's bus address. And sure enough, lspci -vv on the host then shows: + !!! Unknown header type 7f + Kernel driver in use: vfio-pci + +When the guest has booted, of course it shows as an Unclassified device. Host and guest must run at least kernel 4.0 so the wifi card's current firmware will load, and so that its driver comes with the kernel. I have both host and guest set up for the wifi card. I tried running kernel 3.10 in the host and passing through the PCI device, but same behavior. + +I am passing through to the guest an Intel i350 ethernet card just fine, in fact I'm passing through two of its SR-IOV virt interfaces to the guest, so that works. + +On the host, before I start the guest, the wifi card looks like this (lspci -vv): + +0a:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 43 + Region 0: Memory at f7000000 (64-bit, non-prefetchable) [size=2M] + Expansion ROM at f7200000 [disabled] [size=64K] + Capabilities: [40] Power Management version 2 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit- + Address: fee00618 Data: 0000 + Masking: 00000000 Pending: 00000000 + Capabilities: [70] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- + DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us + ClockPM- Surprise- LLActRep- BwNot- + LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled + LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- + EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ + AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- + Capabilities: [140 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 + Status: NegoPending- InProgress- + Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 + Kernel driver in use: ath10k_pci + +It probably needs a quirk like this to avoid bus resets: + +http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/quirks.c?id=c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 + +IOW, add a line like this below the line added by the above patch: + +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c, quirk_no_bus_reset); + +Double check that vendor:device ID against 'lspci -nn', that's 168c:003c. + +It does sound exactly like what I'm seeing. + +From http://www.gossamer-threads.com/lists/linux/kernel/2054846 + +"Yes. If you *re*start the VM . ... The first start (after reboot) was not a problem." + +It seems clear that this problem began with kernel 3.13. I tried applying the backports ath10k to kernel 3.10, but the kernel didn't recognize it, or install put it in the wrong place or something. So I tried kernel 4.1 and the module that comes with it fails this way. From the listserv I should have thought this would be fixed by kernel 4.1, but then maybe my device is so new and this has to be device-specific? + +Thanks for your instructions Alex, but I don't fully understand. I searched for an options line I could put in /etc/modprobe.d/blacklist.conf to prevent PCI bus reset for the module, but couldn't find anything. The "Unknown header type" happens very early in the boot of the guest so I don't see how fixing the guest module would help. + +Maybe you're saying that I must compile the backports module with some patch in the above link and add the line you suggest? Only thing is I don't understand why the module install failed. And I don't know whether the host should have the patched ath10k module as well as the guest. Does the host need the module at all of PCI passthrough? + + + +Actually my card locks up *on* boot of the guest, not after its reboot. + +This generation of Atheros cards requires firmware files: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware +So kernel 3.10 (default with CentOS 7.1) is not an option; 3.11 is the minimum, and that doesn't allow AP mode which I need. So hell, I might as well go with ElRepo's ml kernel, unless you recommend otherwise. + +I compile the ath10k module (from somewhere), and somehow supplant the default ath10k module that comes with the kernel. + + + +The host kernel ath10k drivers and firmware are irrelevant. The change I'm asking about in comment #2 requires a patch and recompile to the host kernel. + +You mean 'a patch and recompile to the -guest- kernel'? Otherwise I'm confused. + +No, the -host- kernel. The problem is that these Atheros WiFi chips do not come back when we do a PCI bus reset. These devices only offer two ways to reset the device, a power management reset and a PCI bus reset. The extent of a power management reset is poorly defined, so we tend to prefer a PCI bus reset. A PCI bus reset is a standard part of the PCI specification and the device is expected to return from reset and be accessible. These devices never recover from reset, resulting in the behavior you're seeing. I've been unsuccessful in contacting Qualcomm/Atheros regarding this problem, so we're effectively blacklisting the devices in the host kernel to disallow the PCI bus reset mechanism. + +I see. And now I also understand that the patch is to the *PCI* driver, not the ath10k driver. + +I was busily trying to get the SRPM for ElRepo's 4.1 kernel to recompile for the guest, but it is not there. He has something called "kernel-ml-4.1.1-1.el7.elrepo.nosrc.rpm" which is incomplete, and so is completely baffling. There are no instructions; instructions are for sissies... + +I was about to give up. + +But since I now see the patch has to be applied to the host kernel, I have a chance at getting the 3.10 SRPM. I guess I'd compile the kernel with rpmbuild and then just graft the PCI module into the regular binary kernel. + + + +Oh this is not good. The current kernel (3.10.0-229.7.2.el7.x86_64) that comes with the current CentOS (7.1) does not have in quirks.c the preceeding or succeeding stanzas in the patch here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/quirks.c?id=c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 + +Apparently that patch was designed for kernel 3.14, so I'd better not move forward with 3.10. Even kernel-plus is still at 3.10. And ElRepo's 4.1 kernel-ml doesn't come with a complete kernel SRPM. So I'm stuck now. I want to stay with el7 packages if possible. I'm running KVM so need a kernel compatible with that. + +I've figured out how to compile ElRepo's kernel-ml and make the change to pci's quirks. But now the KVM's VM won't even boot. It gives a popup with: +"Error starting domain: Unable to read from monitor: Connection reset by peer + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/domain.py", line 1393, in startup + self._backend.create() + File "/usr/lib64/python2.7/site-packages/libvirt.py", line 966, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: Unable to read from monitor: Connection reset by peer" + +It only happens when I add the Atheros QCS988x PCI device. + +No idea. + + +Oh I see. It's because the path that was shared on the host is no longer available, apparently causing this weird error message. + +0a:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter (rev ff) (prog-if ff) + !!! Unknown header type 7f + +So even earlier than PCI reset on the guest, my device on the host is getting jammed. + +I guess it has to go back. Nobody knows what's wrong. This is a Doodle Labs ACE-DB-3. + + + + +Yep, lack of interest here. The ACE-DB-3 (and probably all QCA988x) simply does not work with Linux. No more time for this. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and the kernel? 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/review/1471904 b/results/classifier/118/review/1471904 new file mode 100644 index 000000000..117ff1ec1 --- /dev/null +++ b/results/classifier/118/review/1471904 @@ -0,0 +1,221 @@ +risc-v: 0.865 +graphic: 0.853 +user-level: 0.849 +register: 0.840 +mistranslation: 0.829 +device: 0.812 +ppc: 0.792 +i386: 0.791 +debug: 0.782 +performance: 0.775 +boot: 0.770 +semantic: 0.769 +virtual: 0.768 +vnc: 0.765 +peripherals: 0.758 +arm: 0.757 +architecture: 0.750 +assembly: 0.733 +hypervisor: 0.729 +VMM: 0.726 +permissions: 0.718 +TCG: 0.715 +PID: 0.699 +files: 0.699 +x86: 0.698 +KVM: 0.676 +kernel: 0.657 +socket: 0.649 +network: 0.633 +-------------------- +x86: 0.974 +i386: 0.930 +virtual: 0.735 +debug: 0.381 +kernel: 0.292 +PID: 0.256 +device: 0.057 +files: 0.050 +user-level: 0.038 +hypervisor: 0.029 +boot: 0.029 +register: 0.026 +TCG: 0.015 +semantic: 0.009 +socket: 0.004 +architecture: 0.003 +KVM: 0.003 +assembly: 0.003 +graphic: 0.003 +VMM: 0.003 +peripherals: 0.003 +performance: 0.002 +network: 0.001 +ppc: 0.001 +permissions: 0.001 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974 + +I try to do a fresh install of NeXTStep 3.3 on qemu. After all install floppies are successfully read in, the installation shall start, but aborts right away. During installation process the SCSI host adapter is correctly detected. I don't know, if these adapter where equipped with some special ROM. I thought of installing NeXTStep on a SCSI system due to the IDE problems already known under #1276879. If necessary I would use gdb to track more into this. + +System info: +Linux prerow 3.11.10-29-desktop #1 SMP PREEMPT Thu Mar 5 16:24:00 UTC 2015 (338c513) x86_64 x86_64 x86_64 GNU/Linux +NAME=openSUSE +VERSION="13.1 (Bottle)" +VERSION_ID="13.1" +PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" + +qemu commandline parameter: +/usr/bin/qemu-system-i386 \ + -cpu pentium \ + -monitor stdio \ + -k de \ + -vga cirrus \ + -m 128 \ + -localtime \ + -drive \ + file=.qemu/floppy/3.3_Boot_Disk.floppyimage,format=raw,if=floppy,index=0 \ + -drive \ + file=.qemu/disk/scsihd-2G.qcow2,format=qcow2,id=scsihd0,if=none \ + -drive \ + file=.qemu/cdrom/3.3_InstallCD-NeXTIntel.cdromimage,format=raw,id=scsicd0,if=none \ + -net \ + none \ + -device \ + am53c974,id=AMD0 \ + -device \ + scsi-cd,drive=scsicd0,bus=AMD0.0,lun=0,scsi-id=1,physical_block_size=512,logical_block_size=512 \ + -device \ + scsi-hd,drive=scsihd0,bus=AMD0.0,lun=0,scsi-id=0,removable=off,secs=125,heads=8,cyls=4176,product="ST32151N ",vendor="Seagate ",serial="89683587",ver="2356",physical_block_size=512,logical_block_size=512,dpofua=off + +qemu error message: +qemu: fatal: Trying to execute code outside RAM or ROM at 0xc01754a8 + +EAX=000000ff EBX=0000fffb ECX=000000ff EDX=000000a1 +ESI=00000009 EDI=00011010 EBP=0000ff84 ESP=0000ff6c +EIP=001754a8 EFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +CS =0008 c0000000 3fffffff 00c39a00 DPL=0 CS32 [-R-] +SS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +DS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +FS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +GS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] +LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 001c9a58 000000ff +IDT= 001c9bac 000007ff +CR0=00000033 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000001 CCD=0000000c CCO=INCL +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +Am 21.06.2018 um 16:37 schrieb Thomas Huth: +Dear Thomas, + +the issue is still reproducible. I'm still eager to run this old beast +because of an old database application that has not been converted to +our new platform. There is an old NeXTStep Black Hardware that is +running the sybase database. The frontend runs under NeXTStep intel. +Using qemu would allow to remove some old i486 NeXTStep systems. + +The error looks like: + +qemu-system-i386: Trying to execute code outside RAM or ROM at 0xc01754a8 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it +crashed on startup (eg trying to run a raspberry pi kernel on a +versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU +executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line +and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest +with the -d debug options; in particular -d guest_errors will cause the +log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +Best regards + + +Uwe +> Looking through old bug tickets... can you still reproduce this issue +> with the latest version of QEMU? Or could we close this ticket nowadays? +> +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + + +On Tue, 26 Jun 2018, Uwe Lienig wrote: +> the issue is still reproducible. I'm still eager to run this old beast +> because of an old database application that has not been converted to +> our new platform. There is an old NeXTStep Black Hardware that is +> running the sybase database. The frontend runs under NeXTStep intel. +> Using qemu would allow to remove some old i486 NeXTStep systems. + +This reminds me to this: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-09/msg00280.html + +my reply to a patch submitted on list a few years ago that was needed to +fix OpenStep (which might be the same for NeXTStep too) but at the end +after several iterations it was not accepted due to fear that it may break +backwards migration which was deemed more important than supporting old +guests at the time. Maybe this could be reconsidered now if it fixes your +problem or at least you can have a local fix. + +The actual patch needed is just this: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg02360.html + +from this series: + +http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg02356.html + +which is the last version I've found. You can discover the whole story and +a lot of background info by searching the qemu-devel list archives for +"Microport UNIX". For KVM, I think another set of patches are needed (or +one of those patches) that are linked from one of those messages +somewhere but I don't remember that. + +This may not fix your SCSI problems but could be relevant to the other IDE +bug mentioned in this bug but it was easier to reply to this email than +trying to log into launchpad. Sorry for the noise if this turns out not to +be relevant. + +Regards, +BALATON Zoltan + + + +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/116 + + diff --git a/results/classifier/118/review/1474263 b/results/classifier/118/review/1474263 new file mode 100644 index 000000000..ab78b2380 --- /dev/null +++ b/results/classifier/118/review/1474263 @@ -0,0 +1,224 @@ +user-level: 0.867 +permissions: 0.838 +register: 0.775 +semantic: 0.748 +risc-v: 0.737 +architecture: 0.730 +device: 0.730 +mistranslation: 0.726 +virtual: 0.724 +arm: 0.718 +PID: 0.704 +performance: 0.702 +ppc: 0.691 +peripherals: 0.685 +assembly: 0.670 +TCG: 0.661 +VMM: 0.660 +debug: 0.607 +graphic: 0.602 +vnc: 0.600 +files: 0.574 +network: 0.567 +hypervisor: 0.565 +boot: 0.500 +KVM: 0.438 +kernel: 0.436 +x86: 0.392 +socket: 0.369 +i386: 0.189 +-------------------- +virtual: 0.328 +user-level: 0.064 +x86: 0.026 +hypervisor: 0.024 +debug: 0.017 +ppc: 0.013 +arm: 0.013 +kernel: 0.013 +semantic: 0.010 +files: 0.010 +TCG: 0.009 +PID: 0.007 +i386: 0.007 +permissions: 0.007 +VMM: 0.007 +register: 0.007 +risc-v: 0.007 +boot: 0.006 +device: 0.004 +peripherals: 0.003 +vnc: 0.002 +KVM: 0.002 +architecture: 0.002 +network: 0.001 +socket: 0.001 +assembly: 0.001 +mistranslation: 0.001 +performance: 0.000 +graphic: 0.000 + +"Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver + +Running + +qemu -drive file.driver=vvfat,file.dir=. + +displays + +WARNING: Image format was not specified for 'json:{"dir": ".", "driver": "vvfat"}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +However, since "images" provided by the vvfat driver are always raw (and the first sector isn't writeable in any case), this warning is superfluous and should not be displayed. + +A similar warning is displayed for NBD devices; I suspect it should be also disabled for similar reasons, but I'm not sure if serving non-raw images is actually a violation of the protocol. qemu-nbd translates them to raw images, for what it's worth, even if it may be suppressed with -f raw. + +Noticed on 2.3.0; the code that causes this behaviour is still apparently present in today's git master (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you may want to update the copyright notice that qemu -version displays. + +Hi, + +Indeed using non-raw images should not be used over NBD. The warning however is not superfluous, since qemu does indeed probe the image format, so a malicious guest might write a qcow2 header into the raw image, thus making qemu probe a qcow2 image the next time the same configuration is used. The problem would be solved by not making qemu probe the image format over NBD, but always assume raw; but I guess this will break existing use cases, even though they were wrong from the start. Anyway, this is solved by explicitly specifying the image format to be raw, which is what the warning says. + +When it comes to vvfat, we might actually put up another warning saying that vvfat is deprecated, but anyway: Here, too, the warning is suppressed by doing what the warning says. Use -drive format=raw,file.driver=vvfat,file.dir=. and the warning disappears (or driver=raw instead of format=raw, it's the same). + +Concluding: Doing what the warning says makes it disappear (-drive format=raw,…), which is, not coincidentally, the warning's purpose, actually. If we want to do something about this, we would have to allow protocols like NBD and vvfat be able to force the default image format used on top of them (i.e. raw). But this may break existing use cases, at least for NBD, so I'd be wary about that. + +Max + +On 07/15/2015 09:42 AM, Max Reitz wrote: +> Hi, +> +> Indeed using non-raw images should not be used over NBD. The warning +> however is not superfluous, since qemu does indeed probe the image +> format, so a malicious guest might write a qcow2 header into the raw +> image, thus making qemu probe a qcow2 image the next time the same +> configuration is used. The problem would be solved by not making qemu +> probe the image format over NBD, but always assume raw; but I guess this +> will break existing use cases, even though they were wrong from the +> start. Anyway, this is solved by explicitly specifying the image format +> to be raw, which is what the warning says. + +I could actually see the use of non-raw over NBD. We support nested +protocols (where you can use qcow2->qcow2->file), that is, where a file +contains a qcow2 file whose contents are themselves a qcow2 image. +(Perhaps useful in nested guests, where the outer qcow2 layer serves a +disk to an L0 guest, which in turn uses the inner layer to present a +disk to an L1 guest). In such a case, opening just one layer of qcow2 +for service over NBD will expose the inner qcow2 image, and connecting +qemu as an NBD client with format=raw will directly manipulate the qcow2 +data seen by the L0 guest, while connecting as an NBD client with +format=qcow2 will see the raw data seen by the L1 guest. + +But it's more likely to encounter this scenario with NBD, and not with +vvfat. + +> +> When it comes to vvfat, we might actually put up another warning saying +> that vvfat is deprecated, but anyway: Here, too, the warning is +> suppressed by doing what the warning says. Use -drive +> format=raw,file.driver=vvfat,file.dir=. and the warning disappears (or +> driver=raw instead of format=raw, it's the same). +> +> Concluding: Doing what the warning says makes it disappear (-drive +> format=raw,…), which is, not coincidentally, the warning's purpose, +> actually. If we want to do something about this, we would have to allow +> protocols like NBD and vvfat be able to force the default image format +> used on top of them (i.e. raw). But this may break existing use cases, +> at least for NBD, so I'd be wary about that. + +Yeah, I don't have any objections to vvfat forcing raw, but I'm very +reluctant to have NBD force raw. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On Wed, Jul 15, 2015 at 10:54:47AM -0600, Eric Blake wrote: +> On 07/15/2015 09:42 AM, Max Reitz wrote: +> > Hi, +> > +> > Indeed using non-raw images should not be used over NBD. The warning +> > however is not superfluous, since qemu does indeed probe the image +> > format, so a malicious guest might write a qcow2 header into the raw +> > image, thus making qemu probe a qcow2 image the next time the same +> > configuration is used. The problem would be solved by not making qemu +> > probe the image format over NBD, but always assume raw; but I guess this +> > will break existing use cases, even though they were wrong from the +> > start. Anyway, this is solved by explicitly specifying the image format +> > to be raw, which is what the warning says. +> +> I could actually see the use of non-raw over NBD. We support nested +> protocols (where you can use qcow2->qcow2->file), that is, where a file +> contains a qcow2 file whose contents are themselves a qcow2 image. +> (Perhaps useful in nested guests, where the outer qcow2 layer serves a +> disk to an L0 guest, which in turn uses the inner layer to present a +> disk to an L1 guest). In such a case, opening just one layer of qcow2 +> for service over NBD will expose the inner qcow2 image, and connecting +> qemu as an NBD client with format=raw will directly manipulate the qcow2 +> data seen by the L0 guest, while connecting as an NBD client with +> format=qcow2 will see the raw data seen by the L1 guest. +> +> But it's more likely to encounter this scenario with NBD, and not with +> vvfat. + +I agree that it's perfectly okay to use non-raw on top of NBD. + +We allow image formats on host block devices and iSCSI LUNs. Why +shouldn't they be allowed on NBD exports? + +Stefan + + +> I could actually see the use of non-raw over NBD. We support nested +> protocols (where you can use qcow2->qcow2->file), that is, where a file +> contains a qcow2 file whose contents are themselves a qcow2 image. +> (Perhaps useful in nested guests, where the outer qcow2 layer serves a +> disk to an L0 guest, which in turn uses the inner layer to present a +> disk to an L1 guest). In such a case, opening just one layer of qcow2 +> for service over NBD will expose the inner qcow2 image, and connecting +> qemu as an NBD client with format=raw will directly manipulate the qcow2 +> data seen by the L0 guest, while connecting as an NBD client with +> format=qcow2 will see the raw data seen by the L1 guest. + +Seems like an academic exercise, really. But if this use case is practical, I believe three levels of wrapping is just as useful, and the only way to work with that one is to run two or three instances of qemu-nbd. With more layers, the set-up quickly becomes tangled and unmanageable. + +And I still doubt anyone would actually want to create a set-up like this. It seems incredibly wasteful (but then, so is virtualisation in general, so maybe that isn't an issue) and doesn't seem to accomplish anything that couldn't be done with just one layer of wrapping. + +Looking through old bug tickets... can you still reproduce this bug with the latest version of QEMU? At least for vvfat, the warning message does not seem to occur anymore. + +Yes, it does appear, you just need to make vvfat rw: + +$ qemu-system-x86_64 -drive file.driver=vvfat,file.dir=foo,file.rw=on +vvfat foo chs 1024,16,63 +WARNING: Image format was not specified for 'json:{"dir": "foo", "driver": "vvfat", "rw": "on"}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +(The warning is not shown with R/O devices because they don’t have the security issue.) + +My point hasn’t changed, though, I fundamentally agree with the points in this report, but I don‘t think “fixing” this is worth it. + +For NBD, “fixing” it would mean potentially breaking existing use cases (which I still don’t see the point of, but there’s no point in breaking them just to make a warning disappear). + +For vvfat, there are three things: First of all, I don’t like it very much, so as I said, I’d rather deprecate it altogether (though this BZ shows we shouldn’t do that). +Secondly, in order for the warning to disappear, a protocol driver would need to enforce a certain format on top when probing. That would require a bit of new infrastructure, although I have to admit it wouldn’t be impossible. +Thirdly, I suppose most people use vvfat with block device options like done in the bug report? In that case, it is trivial to add a format=raw (or driver=raw), exactly like the warning suggests. + +(Though you can use vvfat with a plain filename, too: + +$ qemu-system-x86_64 fat:32:rw:foo +qemu-system-x86_64: warning: FAT32 has not been tested. You are welcome to do so! +vvfat foo chs 1024,16,63 +WARNING: Image format was not specified for 'json:{"fat-type": 32, "dir": "foo", "driver": "vvfat", "floppy": false, "rw": true}' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +) + +So all in all I think this is indeed kind of a bug (at least it’s a nuisance that could be better), fixing it would not be impossible, but it’s just very low on at least my priority list (probably somewhere around “implement bdrv_refresh_filename() for vvfat so you don't get the json:{} filenames you can see above”). + +Max + diff --git a/results/classifier/118/review/1478376 b/results/classifier/118/review/1478376 new file mode 100644 index 000000000..bb14ec7bc --- /dev/null +++ b/results/classifier/118/review/1478376 @@ -0,0 +1,109 @@ +semantic: 0.907 +register: 0.815 +architecture: 0.758 +device: 0.743 +ppc: 0.626 +mistranslation: 0.625 +arm: 0.587 +peripherals: 0.587 +performance: 0.582 +socket: 0.577 +kernel: 0.543 +graphic: 0.511 +vnc: 0.458 +user-level: 0.456 +hypervisor: 0.437 +network: 0.436 +PID: 0.400 +permissions: 0.384 +assembly: 0.371 +risc-v: 0.352 +virtual: 0.340 +x86: 0.329 +files: 0.311 +debug: 0.290 +boot: 0.283 +i386: 0.278 +TCG: 0.264 +VMM: 0.255 +KVM: 0.225 +-------------------- +arm: 0.936 +register: 0.776 +peripherals: 0.269 +kernel: 0.115 +performance: 0.110 +architecture: 0.082 +debug: 0.056 +assembly: 0.050 +device: 0.029 +network: 0.026 +semantic: 0.024 +user-level: 0.023 +files: 0.022 +TCG: 0.013 +virtual: 0.013 +hypervisor: 0.013 +PID: 0.012 +VMM: 0.012 +socket: 0.007 +risc-v: 0.006 +vnc: 0.005 +boot: 0.005 +permissions: 0.003 +x86: 0.003 +KVM: 0.003 +i386: 0.002 +ppc: 0.002 +mistranslation: 0.001 +graphic: 0.001 + +PL050 KMIDATA register does not reset + +static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){ + ... + case 2: /* KMIDATA */ + if (s->pending) + s->last = ps2_read_data(s->dev); + return s->last; +} + +When the receive queue is empty (s->pending is false), is the KMIDATA register supposed to be reset to 0x00? In the current implementation, the KMIDATA does not reverse its value after interrupt is lowered. + +On 26 July 2015 at 19:16, T-T Yu <email address hidden> wrote: +> Public bug reported: +> +> static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){ +> ... +> case 2: /* KMIDATA */ +> if (s->pending) +> s->last = ps2_read_data(s->dev); +> return s->last; +> } +> +> When the receive queue is empty (s->pending is false), is the KMIDATA +> register supposed to be reset to 0x00? In the current implementation, +> the KMIDATA does not reverse its value after interrupt is lowered. + +The documentation for the PL050: +http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0143c/i1014040.html + +just says that when KMIDATA is read you get the value in the +receive data register. The implication is that if you read +it multiple times you'll just continue to read the same +value it holds until the keyboard sends further data to be +clocked into the register. + +Are you saying that real hardware behaves differently? + +thanks +-- PMM + + +Yes. In our pl050 keyboard controller, the KMIDATA is reset once the receive queue is empty. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1480562 b/results/classifier/118/review/1480562 new file mode 100644 index 000000000..2fbbf8841 --- /dev/null +++ b/results/classifier/118/review/1480562 @@ -0,0 +1,113 @@ +register: 0.881 +arm: 0.785 +kernel: 0.737 +hypervisor: 0.708 +device: 0.695 +mistranslation: 0.691 +architecture: 0.685 +semantic: 0.675 +socket: 0.667 +performance: 0.664 +x86: 0.632 +risc-v: 0.620 +ppc: 0.601 +network: 0.599 +assembly: 0.586 +peripherals: 0.546 +PID: 0.541 +permissions: 0.540 +user-level: 0.526 +vnc: 0.522 +VMM: 0.518 +TCG: 0.518 +boot: 0.513 +graphic: 0.502 +i386: 0.496 +KVM: 0.469 +debug: 0.457 +files: 0.449 +virtual: 0.402 +-------------------- +arm: 0.820 +peripherals: 0.506 +debug: 0.298 +device: 0.240 +TCG: 0.211 +performance: 0.210 +register: 0.202 +semantic: 0.188 +socket: 0.185 +vnc: 0.185 +VMM: 0.154 +risc-v: 0.152 +files: 0.139 +network: 0.130 +user-level: 0.127 +boot: 0.106 +kernel: 0.102 +PID: 0.102 +permissions: 0.100 +KVM: 0.100 +architecture: 0.086 +assembly: 0.085 +virtual: 0.077 +hypervisor: 0.062 +mistranslation: 0.041 +ppc: 0.024 +graphic: 0.018 +x86: 0.004 +i386: 0.003 + +register values in sp804 timer + +In the arm_timer.c, when first reading the load register, I got 0. + +... +case 0: /* TimerLoad */ +... + +According to the specification at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0271d/index.html, +"The minimum valid value for TimerXLoad is 1". Is the initial value supposed to be 0xffffffff? + + +When the 5th and 7th bit in Control Register are set, RIS and MIS remain 0. But should they be enabled (i.e., 0x1 and 0x1) as both interrupt and timer module are set. + +Thanks. + +On 1 August 2015 at 15:46, T-T Yu <email address hidden> wrote: +> Public bug reported: +> +> In the arm_timer.c, when first reading the load register, I got 0. +> +> ... +> case 0: /* TimerLoad */ +> ... +> +> According to the specification at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0271d/index.html, +> "The minimum valid value for TimerXLoad is 1". Is the initial value +> supposed to be 0xffffffff? + +No. See the "summary of registers" table 3.1 in section 3.1, +which lists this register's reset value as zero (and also +section 2.2.6 which agrees that on reset the load register +value is zero). + +The text you quote is attempting to describe the minimum +value which it is sensible to write to the register -- it +makes no sense for an OS to write 0 to this register because +it would always just interrupt immediately with no actual +timer function, so the shortest possible timeout is +obtained by writing a 1. + +> When the 5th and 7th bit in Control Register are set, RIS and MIS +> remain 0. But should they be enabled (i.e., 0x1 and 0x1) as both +> interrupt and timer module are set. + +RIS and MIS will only become 1 when the timer generates an +interrupt. They don't get set merely because the OS has +enabled interrupts. + +thanks +-- PMM + + diff --git a/results/classifier/118/review/1481750 b/results/classifier/118/review/1481750 new file mode 100644 index 000000000..94e000cfd --- /dev/null +++ b/results/classifier/118/review/1481750 @@ -0,0 +1,96 @@ +ppc: 0.896 +boot: 0.876 +register: 0.840 +permissions: 0.818 +graphic: 0.818 +device: 0.788 +performance: 0.785 +PID: 0.781 +user-level: 0.738 +mistranslation: 0.712 +peripherals: 0.707 +debug: 0.688 +architecture: 0.681 +semantic: 0.646 +network: 0.582 +x86: 0.555 +files: 0.541 +vnc: 0.535 +arm: 0.534 +kernel: 0.522 +socket: 0.515 +VMM: 0.509 +i386: 0.489 +hypervisor: 0.481 +risc-v: 0.473 +TCG: 0.463 +KVM: 0.440 +virtual: 0.431 +assembly: 0.355 +-------------------- +debug: 0.913 +ppc: 0.178 +assembly: 0.132 +virtual: 0.031 +hypervisor: 0.028 +files: 0.015 +TCG: 0.011 +x86: 0.010 +PID: 0.009 +boot: 0.009 +user-level: 0.007 +register: 0.005 +performance: 0.004 +semantic: 0.003 +device: 0.002 +network: 0.002 +architecture: 0.002 +kernel: 0.002 +arm: 0.002 +socket: 0.002 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.001 +vnc: 0.001 +VMM: 0.001 +risc-v: 0.001 +i386: 0.001 +KVM: 0.001 +mistranslation: 0.000 + +qemu-system-ppc hangs when running -M ppce500 -bios u-boot.e500 + +On recent qemu versions (tested on locally built versions 2.3.50 and 2.3.93) +the command below causes qemu to hang before the u-boot command prompt is reached. +However in an older version (2.2.1) the u-boot bootprompt is reached and can be typed into, +so apparenly something has broken along the way. + + +ppc-softmmu/qemu-system-ppc -d guest_errors -d in_asm -M ppce500 -nographic -bios pc-bios/u-boot.e500 + + +From the -d in_asm argument you can compare the runs and the 2.2.1 version +outputs a lot more. + +------ +- I use the unmodified u-boot.e500 that is inlcuded with each respective version. +- when building qemu my configure paramters were in all three cases : +'./configure' '--target-list=ppc-softmmu,arm-softmmu' '--audio-drv-list=' '--enable-debug' + +It is not qemu that hangs. +The u-boot.e500 software falls into an eternal loop at the addresses 0x00f1f964 to 0x00f1f94c +due to the registers r9 and r10 (both) being 0x0 in the newer versions and 0x40 in the working 2.2.1 version. + +Howerver, those values ought to have originated from the qemu environment somehow. + +Looks like this has been broken by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6b4e5f4795b2591fd91bea671e3e22e08fd0e75 +("PPC: e500: Move CCSR and MMIO space to upper end of address space") + +Problem should now be fixed with this commit: +http://git.qemu-project.org/?p=qemu.git;a=commit;h=d4574435a6530bbd96ae130eddfe5b676f91367a +Please test, and close this bug if it is working now. + +Yes, It works fine now. Thanks! +I cannot find an option to close this bug, perhaps I'm not authorized to do it? + diff --git a/results/classifier/118/review/1484 b/results/classifier/118/review/1484 new file mode 100644 index 000000000..7e8a66908 --- /dev/null +++ b/results/classifier/118/review/1484 @@ -0,0 +1,89 @@ +user-level: 0.882 +ppc: 0.724 +KVM: 0.718 +hypervisor: 0.715 +mistranslation: 0.708 +VMM: 0.703 +risc-v: 0.688 +vnc: 0.672 +peripherals: 0.664 +TCG: 0.660 +x86: 0.658 +virtual: 0.631 +graphic: 0.628 +debug: 0.617 +register: 0.610 +arm: 0.559 +boot: 0.532 +semantic: 0.532 +assembly: 0.532 +performance: 0.527 +PID: 0.519 +architecture: 0.518 +device: 0.493 +permissions: 0.481 +i386: 0.447 +kernel: 0.401 +network: 0.399 +socket: 0.394 +files: 0.355 +-------------------- +boot: 0.900 +virtual: 0.876 +x86: 0.619 +hypervisor: 0.530 +kernel: 0.447 +KVM: 0.182 +files: 0.078 +socket: 0.050 +TCG: 0.041 +register: 0.030 +network: 0.026 +device: 0.024 +VMM: 0.019 +debug: 0.019 +PID: 0.018 +performance: 0.014 +architecture: 0.012 +semantic: 0.011 +user-level: 0.003 +assembly: 0.003 +graphic: 0.002 +permissions: 0.002 +vnc: 0.002 +peripherals: 0.002 +mistranslation: 0.001 +ppc: 0.001 +risc-v: 0.001 +i386: 0.001 +arm: 0.000 + +cachy linux iso not booting in linux, host machine freezes +Description of problem: +- cachyos-gnome-linux-230121.iso + - boots native (core-i7 haswell) via ventoy-boot + - boots on windows (Win10 22H2 19045.2546) using + ``` + qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -bios E:\vstorage\win_m01_edk2-x8_64.fd -boot d -cdrom E:/transcend/cachyos-gnome-linux-230121.iso -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15,hostfwd=tcp::9551-:22 -device virtio-net,netdev=vmnic1 -device virtio-serial -chardev socket,path=C:/tmpq/Downloads/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -qmp "tcp:127.0.0.1:5955,server,nowait" + ``` + - does not boot on Linux. Infact it crashes the host, which is a much bigger problem + ``` + qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot d -drive "index=0,if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd" -drive "index=1,if=pflash,format=raw,file=/vol/15KJ_Images/vstorage/m20_OVMF_VARS.fd" -cdrom /vol/15KJ_Images/transcend/cachyos-gnome-linux-230121.iso -device virtio-vga-gl -display "spice-app,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -device virtio-serial -chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=ch1,name=vdagent,clipboard=on -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0 -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" -qmp tcp:0:5955,server,nowait + ``` + when qemu windows pops up graphics inside the popped up virtviewer spice VM-window is garbled, seemingly of the grub2 bootscreen. + Initially, after window popup the mouse pointer can move for a few more seconds. + Then host machine GUI freezes + Then caps lock toggle/LED works for a while + Then host machine itself freezes. Even Ctrl-Alt-Fx to linux-console does not work. + Then forced to long-press power button and reboot + +Its one thing for the qemu to not be able to boot VM/iso, Its a whole different level bug to freeze the host-machine. +Fault inside VM should not affect outside. Plus, I think, I ran qemu-system-x86-64 as ordinary user and not as root. + +The self-built qemu-7.2.0 from handcrafted srpm has worked well with my other images. + +It may have something to do with virtio-vga-gl in linux but will need to test on next reboot to linux. +Steps to reproduce: +1. just run qemu command on linux +Additional information: + diff --git a/results/classifier/118/review/1486 b/results/classifier/118/review/1486 new file mode 100644 index 000000000..3960a46b3 --- /dev/null +++ b/results/classifier/118/review/1486 @@ -0,0 +1,149 @@ +architecture: 0.874 +virtual: 0.864 +device: 0.855 +ppc: 0.838 +VMM: 0.836 +permissions: 0.833 +assembly: 0.825 +files: 0.825 +peripherals: 0.822 +graphic: 0.817 +vnc: 0.813 +register: 0.811 +arm: 0.806 +debug: 0.796 +hypervisor: 0.792 +PID: 0.791 +semantic: 0.786 +socket: 0.781 +user-level: 0.777 +network: 0.774 +TCG: 0.760 +KVM: 0.752 +x86: 0.731 +performance: 0.730 +kernel: 0.723 +mistranslation: 0.669 +boot: 0.602 +risc-v: 0.457 +i386: 0.241 +-------------------- +virtual: 0.962 +x86: 0.935 +debug: 0.214 +user-level: 0.130 +hypervisor: 0.124 +PID: 0.075 +files: 0.057 +TCG: 0.050 +network: 0.032 +VMM: 0.026 +register: 0.023 +kernel: 0.017 +boot: 0.016 +device: 0.014 +socket: 0.007 +architecture: 0.006 +semantic: 0.005 +vnc: 0.005 +assembly: 0.003 +performance: 0.002 +permissions: 0.002 +graphic: 0.001 +peripherals: 0.001 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.001 +KVM: 0.000 +arm: 0.000 +i386: 0.000 + +LXD fails to create VM with QEMU 7.2.0: "../../net/net.c:1106: net_client_init1: Assertion `nc' failed." +Description of problem: +Beginning with QEMU 7.2.0, LXD is unable to launch virtual machines using the default network profile, which breaks the out-of-box experience if a user wishes to create a virtual machine. This worked correctly with QEMU 7.1.0. + +Multiple users across different Linux distributions are reporting this issue: +- https://discuss.linuxcontainers.org/t/failed-adding-nic-netdev-monitor-is-disconnected/15946 +- https://forums.gentoo.org/viewtopic-p-8774212.html +- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030365 + +``` +gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm +Creating debian-sid-vm +Starting debian-sid-vm +Error: Failed setting up device via monitor: Failed setting up device "eth0": Failed adding NIC netdev: Monitor is disconnected +Try `lxc info --show-log local:debian-sid-vm` for more info +gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm +Name: debian-sid-vm +Status: STOPPED +Type: virtual-machine +Architecture: x86_64 +Created: 2023/02/10 23:47 UTC + +Log: + +warning: tap: open vhost char device failed: Permission denied +warning: tap: open vhost char device failed: Permission denied +qemu-system-x86_64: ../../net/net.c:1106: net_client_init1: Assertion `nc' failed. + +``` + +``` +gibmat@tharkun:~$ qemu-system-x86_64 --version +QEMU emulator version 7.2.0 (Debian 1:7.2+dfsg-2) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +gibmat@tharkun:~$ lxc version +Client version: 5.0.2 +Server version: 5.0.2 +``` +Steps to reproduce: +1. Install LXD and QEMU 7.2.0 +2. `lxc launch images:debian/sid debian-sid-vm --vm` + - This will fail as reported above +3. Downgrade to QEMU 7.1.0 (such as from https://snapshot.debian.org/package/qemu/1%3A7.1%2Bdfsg-2/) +4. `lxc launch images:debian/sid debian-sid-vm --vm` + - Now VM creation is successful + ``` + gibmat@tharkun:~$ lxc launch images:debian/sid debian-sid-vm --vm + Creating debian-sid-vm + Starting debian-sid-vm + gibmat@tharkun:~$ lxc list + +---------------+---------+------+-----------------------------------------------+-----------------+-----------+ + | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | + +---------------+---------+------+-----------------------------------------------+-----------------+-----------+ + | debian-sid-vm | RUNNING | | fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c (eth0) | VIRTUAL-MACHINE | 0 | + +---------------+---------+------+-----------------------------------------------+-----------------+-----------+ + gibmat@tharkun:~$ lxc info --show-log local:debian-sid-vm + Name: debian-sid-vm + Status: RUNNING + Type: virtual-machine + Architecture: x86_64 + PID: 2502 + Created: 2023/02/11 15:08 UTC + Last Used: 2023/02/11 15:08 UTC + + Resources: + Processes: -1 + Network usage: + eth0: + Type: broadcast + State: UP + Host interface: tap5efa7582 + MAC address: 00:16:3e:b8:2e:8c + MTU: 1500 + Bytes received: 3.13kB + Bytes sent: 164B + Packets received: 12 + Packets sent: 2 + IP addresses: + inet6: fd42:ea61:feb4:55ef:216:3eff:feb8:2e8c/64 (global) + + Log: + + warning: tap: open vhost char device failed: Permission denied + warning: tap: open vhost char device failed: Permission denied + + gibmat@tharkun:~$ qemu-system-x86_64 --version + QEMU emulator version 7.1.0 (Debian 1:7.1+dfsg-2+b3) + Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers + ``` diff --git a/results/classifier/118/review/1487264 b/results/classifier/118/review/1487264 new file mode 100644 index 000000000..114fe3f73 --- /dev/null +++ b/results/classifier/118/review/1487264 @@ -0,0 +1,83 @@ +risc-v: 0.837 +user-level: 0.824 +hypervisor: 0.791 +permissions: 0.779 +register: 0.764 +virtual: 0.755 +TCG: 0.755 +KVM: 0.753 +network: 0.750 +performance: 0.745 +peripherals: 0.745 +VMM: 0.723 +architecture: 0.716 +socket: 0.709 +graphic: 0.707 +mistranslation: 0.706 +vnc: 0.704 +device: 0.702 +arm: 0.702 +boot: 0.699 +debug: 0.694 +files: 0.694 +assembly: 0.689 +ppc: 0.686 +PID: 0.681 +kernel: 0.676 +semantic: 0.668 +i386: 0.585 +x86: 0.545 +-------------------- +hypervisor: 0.978 +KVM: 0.957 +x86: 0.913 +socket: 0.696 +debug: 0.674 +virtual: 0.221 +PID: 0.196 +kernel: 0.062 +VMM: 0.046 +TCG: 0.028 +register: 0.026 +device: 0.020 +performance: 0.016 +files: 0.014 +user-level: 0.010 +assembly: 0.007 +architecture: 0.005 +semantic: 0.005 +boot: 0.004 +peripherals: 0.003 +permissions: 0.002 +risc-v: 0.002 +graphic: 0.002 +i386: 0.002 +ppc: 0.002 +network: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +Windows 8.1/10 Crashes during upgrade - SYSTEM_THREAD_EXCEPTION_NOT_HANDLED + +Ever since Windows 8.x, 10 I cannot upgrade or upgrade to tech builds within Windows 10 without hard shutting off the VM. + +Physical hardware: Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz [Haswell] + +QEMU 2.1-2.3.x seem all broken, I am using Q35 chipset w/ BIOS mode. + +Launch command via virt-manager/libvirt launch: + +QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name Windows_10 -S -machine pc-q35-2.3,accel=kvm,usb=off -cpu Haswell-noTSX,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid ed7e372b-ebf9-4feb-a305-869f82e6aaee -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows_10.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device ich9-usb-ehci1,id=usb,bus=pci.2,addr=0x3.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.2,multifunction=on,addr=0x3 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.2,addr=0x3.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.2,addr=0x3.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/var/lib/libvirt/images/Windows_10.qcow2,if=none,id=drive-sata0-0-0,format=qcow2 -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -drive file=/usr/share/virtio-win/virtio-win-0.1.109.iso,if=none,media=cdrom,id=drive-sata0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:54:14:20,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=268435456,vram_size=268435456,vgamem_mb=256,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-host,hostbus=1,hostaddr=2,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on + +The workaround I've been able to come up with is to set boot menu in virt-manager, then put in a bootable CD so I have enough time to hard power off the QEMU/KVM instance, when I power it back on, it continues upgrade/install without issue, each time it needs to restart however I go though same exercise. + +Anything known about this issue? The workaround is a kludge, but it does get it to upgrade/install Windows 8.1, and upgrade between Windows 10 X builds. + +Thanks, +Shawn + +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/review/1490 b/results/classifier/118/review/1490 new file mode 100644 index 000000000..9854e2516 --- /dev/null +++ b/results/classifier/118/review/1490 @@ -0,0 +1,121 @@ +mistranslation: 0.895 +register: 0.880 +performance: 0.844 +risc-v: 0.828 +user-level: 0.825 +graphic: 0.824 +virtual: 0.824 +architecture: 0.822 +ppc: 0.811 +device: 0.809 +peripherals: 0.807 +permissions: 0.802 +semantic: 0.799 +arm: 0.793 +KVM: 0.789 +assembly: 0.778 +network: 0.761 +boot: 0.758 +socket: 0.757 +hypervisor: 0.752 +files: 0.742 +TCG: 0.741 +VMM: 0.740 +kernel: 0.737 +debug: 0.730 +PID: 0.724 +vnc: 0.673 +i386: 0.643 +x86: 0.631 +-------------------- +virtual: 0.978 +KVM: 0.969 +x86: 0.966 +debug: 0.960 +hypervisor: 0.947 +TCG: 0.300 +socket: 0.208 +register: 0.144 +device: 0.138 +VMM: 0.123 +kernel: 0.096 +files: 0.088 +PID: 0.083 +risc-v: 0.076 +performance: 0.058 +boot: 0.039 +semantic: 0.037 +user-level: 0.025 +peripherals: 0.019 +assembly: 0.019 +architecture: 0.013 +permissions: 0.011 +graphic: 0.010 +ppc: 0.007 +network: 0.007 +vnc: 0.007 +i386: 0.003 +mistranslation: 0.002 +arm: 0.001 + +Keystrokes for F13-24 are not forwarded by an evdev input device +Description of problem: +Currently, keystrokes for F13-F24 are not forwarded by an evdev input device. +Steps to reproduce: +``` +/usr/bin/qemu-system-x86_64 \ +-name guest=win10,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-11-win10/master-key.aes"}' \ +-machine pc-q35-7.2,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff \ +-m 4096 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' \ +-overcommit mem-lock=off \ +-smp 4,sockets=1,dies=1,cores=4,threads=1 \ +-uuid ca2e9d01-6e02-4aa7-9feb-7846499f7d8a \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci.1","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/tmp/win10.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":2}' \ +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' \ +-audiodev '{"id":"audio1","driver":"spice"}' \ +-spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ +-device '{"driver":"qxl-vga","id":"video0","max_outputs":1,"ram_size":67108864,"vram_size":67108864,"vram64_size_mb":0,"vgamem_mb":16,"bus":"pcie.0","addr":"0x1"}' \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.2","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +``` + +This is probably not a minimal example, but I didn't know how to generate one. I think the only relevant lines are these: +``` +-object '{"qom-type":"input-linux","id":"input2","evdev":"/dev/input/by-id/usb-04d9_f50e-event-mouse"}' \ +-object '{"qom-type":"input-linux","id":"input3","evdev":"/dev/input/by-id/usb-0c45_6515-event-kbd","repeat":true,"grab_all":true,"grab-toggle":"scrolllock"}' +``` diff --git a/results/classifier/118/review/1497711 b/results/classifier/118/review/1497711 new file mode 100644 index 000000000..361de652b --- /dev/null +++ b/results/classifier/118/review/1497711 @@ -0,0 +1,97 @@ +semantic: 0.958 +graphic: 0.803 +device: 0.783 +ppc: 0.781 +register: 0.767 +socket: 0.754 +vnc: 0.750 +mistranslation: 0.747 +network: 0.718 +kernel: 0.693 +risc-v: 0.664 +files: 0.657 +performance: 0.644 +architecture: 0.615 +hypervisor: 0.613 +PID: 0.598 +permissions: 0.533 +user-level: 0.532 +i386: 0.531 +debug: 0.530 +arm: 0.526 +TCG: 0.513 +x86: 0.510 +boot: 0.466 +VMM: 0.436 +assembly: 0.412 +virtual: 0.399 +peripherals: 0.389 +KVM: 0.334 +-------------------- +x86: 0.180 +semantic: 0.127 +files: 0.108 +hypervisor: 0.090 +debug: 0.056 +performance: 0.050 +i386: 0.044 +virtual: 0.038 +register: 0.036 +VMM: 0.033 +arm: 0.030 +device: 0.030 +PID: 0.025 +architecture: 0.020 +risc-v: 0.018 +ppc: 0.017 +boot: 0.016 +kernel: 0.014 +network: 0.011 +TCG: 0.010 +peripherals: 0.010 +vnc: 0.006 +socket: 0.006 +KVM: 0.005 +user-level: 0.004 +assembly: 0.004 +permissions: 0.002 +mistranslation: 0.001 +graphic: 0.001 + +tests/libqos/ahci.c:745: redundant condition ? + +[qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq || props.lba48' + + g_assert(!props->ncq || (props->ncq && props->lba48)); + +On Sun, Sep 20, 2015 at 10:08:49AM -0000, dcb wrote: +> Public bug reported: +> +> [qemu/tests/libqos/ahci.c:745]: (style) Redundant condition: props.ncq. +> '!props.ncq || (props.ncq && props.lba48)' is equivalent to '!props.ncq +> || props.lba48' +> +> g_assert(!props->ncq || (props->ncq && props->lba48)); + +CCing John Snow, AHCI maintainer + + +Fixed in: + +commit 3d937150dce20cb95cbaae99b6fd48dca4261f32 +Author: John Snow <email address hidden> +Date: Mon Oct 5 12:00:55 2015 -0400 + + qtest/ahci: fix redundant assertion + + Fixes https://bugs.launchpad.net/qemu/+bug/1497711 + + (!ncq || (ncq && lba48)) is the same as + (!ncq || lba48). + + The intention is simply: "If a command is NCQ, + it must also be LBA48." + + Signed-off-by: John Snow <email address hidden> + Message-id: <email address hidden> + diff --git a/results/classifier/118/review/1501 b/results/classifier/118/review/1501 new file mode 100644 index 000000000..92f4186db --- /dev/null +++ b/results/classifier/118/review/1501 @@ -0,0 +1,61 @@ +architecture: 0.963 +device: 0.904 +arm: 0.742 +network: 0.652 +hypervisor: 0.538 +performance: 0.514 +files: 0.439 +graphic: 0.431 +permissions: 0.423 +semantic: 0.401 +assembly: 0.340 +peripherals: 0.313 +user-level: 0.286 +socket: 0.267 +register: 0.259 +debug: 0.228 +virtual: 0.209 +ppc: 0.207 +boot: 0.191 +mistranslation: 0.178 +risc-v: 0.166 +vnc: 0.064 +PID: 0.040 +kernel: 0.025 +TCG: 0.022 +VMM: 0.014 +x86: 0.005 +i386: 0.005 +KVM: 0.001 +-------------------- +virtual: 0.898 +hypervisor: 0.747 +device: 0.033 +files: 0.017 +user-level: 0.015 +semantic: 0.013 +architecture: 0.008 +PID: 0.006 +register: 0.006 +boot: 0.004 +kernel: 0.004 +debug: 0.003 +permissions: 0.003 +assembly: 0.003 +performance: 0.002 +x86: 0.002 +peripherals: 0.002 +socket: 0.001 +graphic: 0.001 +TCG: 0.001 +network: 0.001 +arm: 0.001 +mistranslation: 0.001 +VMM: 0.000 +risc-v: 0.000 +ppc: 0.000 +i386: 0.000 +vnc: 0.000 +KVM: 0.000 + +IBM AIX 73 not supported under QEMU diff --git a/results/classifier/118/review/1505062 b/results/classifier/118/review/1505062 new file mode 100644 index 000000000..7ad80085e --- /dev/null +++ b/results/classifier/118/review/1505062 @@ -0,0 +1,84 @@ +x86: 0.962 +architecture: 0.823 +kernel: 0.816 +boot: 0.801 +device: 0.798 +performance: 0.724 +graphic: 0.720 +i386: 0.636 +peripherals: 0.624 +user-level: 0.577 +mistranslation: 0.565 +semantic: 0.495 +hypervisor: 0.495 +KVM: 0.482 +risc-v: 0.460 +debug: 0.456 +ppc: 0.436 +socket: 0.434 +network: 0.426 +arm: 0.414 +files: 0.352 +virtual: 0.350 +register: 0.349 +permissions: 0.346 +TCG: 0.327 +vnc: 0.326 +PID: 0.317 +VMM: 0.268 +assembly: 0.175 +-------------------- +virtual: 0.959 +x86: 0.330 +hypervisor: 0.188 +kernel: 0.149 +register: 0.065 +files: 0.061 +KVM: 0.054 +boot: 0.051 +PID: 0.047 +debug: 0.041 +TCG: 0.039 +architecture: 0.030 +graphic: 0.029 +device: 0.018 +risc-v: 0.015 +VMM: 0.013 +semantic: 0.010 +socket: 0.009 +user-level: 0.008 +performance: 0.005 +permissions: 0.003 +assembly: 0.003 +vnc: 0.003 +ppc: 0.002 +peripherals: 0.002 +network: 0.002 +i386: 0.001 +mistranslation: 0.001 +arm: 0.000 + +Regression: QEMU 2.4 on Linux 4.2 fails to init display with SMM enabled + +QEMU version: 2.4, also tested b37686f (2015-10-09 12:18:13 +0100) not working. Requires KVM and SDL, possibly others. +Kernel version: 4.1 working, 4.2 not working. +Architecture: x86_64 +Target: x86_64, also tested i386 not working. + +Step 0: Install versions listed above. +Step 1: Run "qemu-system-$TARGET -enable-kvm" +Step 2: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.3" +Step 3: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.4" +Step 4: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.3,smm=on" +Step 5: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-i440fx-2.4,smm=off" +Step 6: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.3" +Step 7: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.4" +Step 8: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.3,smm=on" +Step 9: Run "qemu-system-$TARGET -enable-kvm -nodefaults -vga std -machine pc-q35-2.4,smm=off" + +Expected behavior: All 8 invocations result in an rectangular SDL window showing a framebuffer showing failure to locate a boot device. + +Actual behavior: Invocations corresponding to steps 2, 4, 5, 6, 8, and 9 (i.e. those using 2.4 and *not* smm=off) behave as expected, however those in steps 1, 3, and 7 result in a square black SDL window with no text. Note that step 1 is more or less the "default configuration" for QEMU with KVM. + +fixed in linux + diff --git a/results/classifier/118/review/1505759 b/results/classifier/118/review/1505759 new file mode 100644 index 000000000..5c49397cf --- /dev/null +++ b/results/classifier/118/review/1505759 @@ -0,0 +1,145 @@ +mistranslation: 0.833 +user-level: 0.819 +peripherals: 0.818 +semantic: 0.788 +vnc: 0.776 +KVM: 0.770 +virtual: 0.766 +architecture: 0.753 +performance: 0.750 +graphic: 0.750 +hypervisor: 0.750 +assembly: 0.744 +x86: 0.728 +VMM: 0.727 +debug: 0.727 +arm: 0.725 +register: 0.722 +socket: 0.722 +device: 0.719 +risc-v: 0.712 +TCG: 0.709 +PID: 0.708 +kernel: 0.703 +permissions: 0.694 +i386: 0.657 +ppc: 0.654 +boot: 0.629 +network: 0.608 +files: 0.575 +-------------------- +x86: 0.975 +kernel: 0.969 +virtual: 0.869 +hypervisor: 0.832 +debug: 0.684 +peripherals: 0.514 +KVM: 0.195 +device: 0.051 +files: 0.046 +TCG: 0.029 +boot: 0.027 +VMM: 0.026 +register: 0.024 +ppc: 0.019 +performance: 0.016 +PID: 0.015 +socket: 0.015 +assembly: 0.013 +user-level: 0.011 +risc-v: 0.011 +semantic: 0.009 +architecture: 0.009 +arm: 0.006 +permissions: 0.005 +vnc: 0.003 +graphic: 0.003 +i386: 0.002 +network: 0.001 +mistranslation: 0.001 + +Usb passthrough of devices plugged to AMD FCH USB OHCI Controller failing on q35. + +I'm trying to setup a q35 vm with windows 7 guest for vga passthrough. The machine works well for this purpose, but the usb devices passed to the vm does not. I receive the following errors on screen: + +qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] +libusb: error [_open_sysfs_attr} open +/sys/bus/usb/devices/3-5/bConfigurationValue failed ret=-1 errno=2 +qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] +libusb: error [_open_sysfs_attr} open +/sys/bus/usb/devices/4-1/bConfigurationValue failed ret=-1 errno=2 +Disabling IRQ #18 +Disabling IRQ #17 + +And from the system log I can see the following: + +Oct 13 20:13:25 koalita kernel: vfio-pci 0000:01:00.1: enabling device (0400 -> 0402) +Oct 13 20:13:29 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:30 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:30 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:31 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:31 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:31 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:31 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:32 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:32 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:32 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:33 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:33 koalita kernel: usb 4-1: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:34 koalita kernel: usb 3-5: reset low-speed USB device number 2 using ohci-pci +Oct 13 20:13:34 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: reset low-speed USB device number 2 using xhci_hcd +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes +Oct 13 20:13:35 koalita kernel: usb 10-2: ep 0x1 - rounding interval to 64 microframes, ep desc says 80 microframes + +I tried to any combination of usb devices, and even disabling the ICH9 usb devices to make the setup looks close to the 440fx machine that is working for me. + +Version of qemu is 2.2.1(all newer versions fails on usb passthrough, even in 440fx machines), and kernel is 4.1.8. + +The script to launch it is the following: + +qemu-system-x86_64 -enable-kvm -M q35 -vga none -cpu host -smp 3,cores=3,threads=1 -m 6144 \ + -L /usr/x86_64-pc-linux-gnu/usr/share/qemu \ + -nodefaults -nodefconfig \ + -device ioh3420,multifunction=on,id=pcie \ + -device vfio-pci,host=01:00.0,addr=1c.0,x-vga=on,multifunction=on,bus=pcie \ + -device vfio-pci,host=01:00.1,addr=1c.1,bus=pcie \ + -netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \ + -device usb-ehci,id=ehci -device nec-usb-xhci,id=xhci \ + -usb -usbdevice host:03f0:134a -usbdevice host:03f0:0024 -usbdevice host:0079:0006 \ + -drive file=q35_win7.img,format=raw,cache=none,aio=native,if=virtio + +Thanks! + +Narrowing this down, I launched the vm passing the usb devices one by one. I boot correctly with the game pad and the mouse. For any strange reason the keyboard is the faulty device with q35. The model is the following: + +Bus 004 Device 002: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard. + +It's a bit surprising because using this device using 440fx vm is totally functional, and I can happily play games with it. Any possible explanation on this? + +Thanks! + + + +Actually moving the device to some other port made it work, so then the suspicious is not the keyboard, but the controller where it's unplugged, which is the following one: + +00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11). + + + + +Finally, I tried several combination of ports for this, until I figure out and arrangement that worked for me. Seems like the problem is that 2 hp usb devices cannot share the same bus, so no matter if it's using an ohci controller, an ehci, controller, or even xhci, if the devices are in the same bus, some fancy error will come to the screen, and no keyboard and mouse turns up in the vm. + +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. + +I found a different arrangement that made it for me, so that particular case, +I don't know if it works for me, or if it still fails the same, and versions +has gone so far to check, I'd simply mark this invalid and forget of it. + +Best regards. + +José. + diff --git a/results/classifier/118/review/1506 b/results/classifier/118/review/1506 new file mode 100644 index 000000000..edb5d35f8 --- /dev/null +++ b/results/classifier/118/review/1506 @@ -0,0 +1,61 @@ +architecture: 0.976 +device: 0.825 +network: 0.640 +performance: 0.544 +arm: 0.410 +semantic: 0.395 +graphic: 0.385 +mistranslation: 0.378 +hypervisor: 0.320 +socket: 0.289 +PID: 0.279 +register: 0.243 +risc-v: 0.202 +virtual: 0.193 +permissions: 0.191 +files: 0.184 +ppc: 0.179 +vnc: 0.171 +boot: 0.143 +peripherals: 0.132 +debug: 0.124 +assembly: 0.121 +kernel: 0.120 +i386: 0.102 +TCG: 0.082 +x86: 0.072 +user-level: 0.072 +VMM: 0.030 +KVM: 0.000 +-------------------- +virtual: 0.833 +hypervisor: 0.717 +i386: 0.078 +x86: 0.050 +architecture: 0.034 +user-level: 0.028 +semantic: 0.015 +boot: 0.009 +files: 0.007 +assembly: 0.006 +kernel: 0.006 +device: 0.006 +TCG: 0.004 +PID: 0.003 +register: 0.003 +graphic: 0.002 +arm: 0.001 +performance: 0.001 +peripherals: 0.001 +debug: 0.001 +risc-v: 0.001 +ppc: 0.001 +socket: 0.001 +mistranslation: 0.000 +VMM: 0.000 +permissions: 0.000 +network: 0.000 +vnc: 0.000 +KVM: 0.000 + +QEMU not support 32-bit stack in unreal/flat/big 32-bit mode diff --git a/results/classifier/118/review/1511 b/results/classifier/118/review/1511 new file mode 100644 index 000000000..411275f81 --- /dev/null +++ b/results/classifier/118/review/1511 @@ -0,0 +1,61 @@ +i386: 0.997 +architecture: 0.968 +x86: 0.957 +performance: 0.304 +boot: 0.278 +graphic: 0.241 +semantic: 0.167 +register: 0.145 +debug: 0.138 +permissions: 0.087 +mistranslation: 0.085 +kernel: 0.074 +VMM: 0.068 +vnc: 0.056 +device: 0.049 +risc-v: 0.048 +TCG: 0.046 +KVM: 0.042 +ppc: 0.035 +virtual: 0.032 +socket: 0.031 +PID: 0.031 +arm: 0.027 +hypervisor: 0.009 +assembly: 0.008 +files: 0.007 +user-level: 0.004 +network: 0.003 +peripherals: 0.001 +-------------------- +i386: 0.817 +x86: 0.724 +semantic: 0.047 +socket: 0.022 +user-level: 0.015 +register: 0.014 +architecture: 0.012 +virtual: 0.010 +device: 0.008 +ppc: 0.008 +files: 0.007 +VMM: 0.006 +TCG: 0.004 +assembly: 0.004 +PID: 0.003 +kernel: 0.003 +risc-v: 0.003 +debug: 0.002 +boot: 0.002 +graphic: 0.001 +KVM: 0.001 +performance: 0.001 +permissions: 0.001 +network: 0.001 +hypervisor: 0.001 +mistranslation: 0.001 +vnc: 0.000 +peripherals: 0.000 +arm: 0.000 + +Please a CPU model for ABI version for x86_64 i386 according to x86-64 psABI diff --git a/results/classifier/118/review/152 b/results/classifier/118/review/152 new file mode 100644 index 000000000..696e7ce7a --- /dev/null +++ b/results/classifier/118/review/152 @@ -0,0 +1,61 @@ +mistranslation: 0.983 +graphic: 0.775 +performance: 0.657 +semantic: 0.551 +device: 0.442 +permissions: 0.371 +virtual: 0.354 +architecture: 0.342 +peripherals: 0.293 +kernel: 0.231 +files: 0.217 +user-level: 0.215 +network: 0.196 +hypervisor: 0.186 +arm: 0.167 +x86: 0.148 +socket: 0.147 +VMM: 0.136 +PID: 0.134 +i386: 0.130 +ppc: 0.114 +assembly: 0.105 +debug: 0.105 +boot: 0.101 +vnc: 0.096 +TCG: 0.077 +register: 0.065 +risc-v: 0.029 +KVM: 0.026 +-------------------- +virtual: 0.948 +hypervisor: 0.867 +user-level: 0.644 +debug: 0.029 +files: 0.021 +VMM: 0.017 +semantic: 0.016 +x86: 0.012 +KVM: 0.011 +device: 0.009 +performance: 0.007 +i386: 0.007 +TCG: 0.005 +ppc: 0.005 +peripherals: 0.004 +kernel: 0.004 +register: 0.003 +arm: 0.003 +boot: 0.002 +assembly: 0.002 +PID: 0.002 +graphic: 0.001 +socket: 0.001 +risc-v: 0.001 +network: 0.001 +permissions: 0.001 +vnc: 0.001 +architecture: 0.001 +mistranslation: 0.001 + +qemu-img compare -m option is missing diff --git a/results/classifier/118/review/1525676 b/results/classifier/118/review/1525676 new file mode 100644 index 000000000..813a10edd --- /dev/null +++ b/results/classifier/118/review/1525676 @@ -0,0 +1,109 @@ +semantic: 0.894 +debug: 0.886 +permissions: 0.884 +graphic: 0.876 +register: 0.833 +device: 0.824 +virtual: 0.823 +mistranslation: 0.816 +PID: 0.816 +assembly: 0.803 +socket: 0.782 +arm: 0.775 +user-level: 0.773 +kernel: 0.772 +architecture: 0.760 +performance: 0.756 +network: 0.752 +ppc: 0.735 +hypervisor: 0.735 +boot: 0.726 +peripherals: 0.723 +vnc: 0.720 +x86: 0.716 +risc-v: 0.713 +files: 0.708 +i386: 0.705 +TCG: 0.704 +VMM: 0.684 +KVM: 0.621 +-------------------- +PID: 0.504 +x86: 0.311 +virtual: 0.205 +hypervisor: 0.193 +TCG: 0.126 +kernel: 0.115 +debug: 0.089 +files: 0.038 +permissions: 0.030 +ppc: 0.027 +i386: 0.025 +register: 0.019 +network: 0.015 +assembly: 0.010 +user-level: 0.006 +arm: 0.004 +risc-v: 0.004 +socket: 0.004 +device: 0.003 +graphic: 0.002 +semantic: 0.002 +boot: 0.002 +performance: 0.001 +vnc: 0.001 +architecture: 0.001 +VMM: 0.001 +KVM: 0.001 +peripherals: 0.000 +mistranslation: 0.000 + +qemu runas and sandbox option incompatible, process will hang in futex after setgid + +With -runas [user] and -sandbox on, qemu process will fail in the process of dropping privileges. While setgid() is done (see below), setuid() is not attempted. Instead process blocks waiting for a futex never to come. + +[pid 21769] +++ killed by SIGSYS +++ +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] tgkill(21767, 21768, SIGRT_1 <unfinished ...> +[pid 21768] <... nanosleep resumed> {0, 7284187}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) +[pid 21768] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=21767, si_uid=0} --- +[pid 21768] setgid(100) = 0 +[pid 21768] futex(0x7f7f0f53fd1c, FUTEX_WAKE_PRIVATE, 1) = 0 +[pid 21768] rt_sigreturn() = -1 EINTR (Interrupted system call) +[pid 21768] nanosleep({0, 7284187}, <unfinished ...> +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] futex(0x7ffd5a9b6890, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...> +[pid 21768] <... nanosleep resumed> 0x7f7f0f53eb00) = 0 +[pid 21768] futex(0x55f52acd1f44, FUTEX_WAIT, 4294967295, NULL + +This bug might be addresses in the discussion/patchset http://qemu.11.n7.nabble.com/PATCH-Add-syscalls-for-runas-and-chroot-to-the-seccomp-sandbox-td359588.html + +# lsb_release -rd +Description: Ubuntu 15.10 +Release: 15.10 + +# apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.3+dfsg-5ubuntu9.1 + Candidate: 1:2.3+dfsg-5ubuntu9.1 + Version table: + *** 1:2.3+dfsg-5ubuntu9.1 0 + 500 http://archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages + 500 http://archive.ubuntu.com/ubuntu/ wily-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:2.3+dfsg-5ubuntu9 0 + 500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages + +Yes, it looks like that discussion is related. Though I also got the impression that there is currently still some decision going on how exactly to fix this. So it feels like we should wait with any fix until this decision is made (and a fix is committed into qemu's upstream repo)... + +hmm, the change still did not made it upstream. +I lost track on it and only see it now checking bugs that became dormant - was that fixed in another way? + +There is some overlap with LP: #1675114 so you might be interested to know that @otubo is working on refactoring seccomp for upstream. No firm ETA yet but he thinks that 18.04 would be doable. + +I haven't tried, but I think this should be fixed now with the new elevateprivileges parameter of the -sandbox option. Have you tried to reproduce the problem with the latest version of QEMU already? + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1525682 b/results/classifier/118/review/1525682 new file mode 100644 index 000000000..b628cf1b1 --- /dev/null +++ b/results/classifier/118/review/1525682 @@ -0,0 +1,188 @@ +user-level: 0.880 +peripherals: 0.848 +risc-v: 0.835 +mistranslation: 0.813 +semantic: 0.805 +register: 0.793 +debug: 0.780 +assembly: 0.780 +device: 0.775 +permissions: 0.773 +virtual: 0.762 +KVM: 0.761 +PID: 0.759 +ppc: 0.759 +hypervisor: 0.759 +vnc: 0.758 +graphic: 0.756 +performance: 0.754 +arm: 0.753 +VMM: 0.742 +TCG: 0.736 +architecture: 0.730 +x86: 0.725 +kernel: 0.721 +socket: 0.703 +files: 0.678 +network: 0.670 +boot: 0.645 +i386: 0.616 +-------------------- +user-level: 0.069 +files: 0.033 +TCG: 0.023 +virtual: 0.017 +hypervisor: 0.015 +PID: 0.009 +kernel: 0.007 +semantic: 0.007 +register: 0.005 +debug: 0.005 +network: 0.004 +VMM: 0.003 +ppc: 0.002 +device: 0.002 +vnc: 0.001 +socket: 0.001 +x86: 0.001 +risc-v: 0.001 +performance: 0.001 +architecture: 0.001 +graphic: 0.001 +boot: 0.001 +assembly: 0.001 +mistranslation: 0.001 +KVM: 0.001 +permissions: 0.001 +peripherals: 0.001 +arm: 0.000 +i386: 0.000 + +configure: fix POSIX compatibility issue + +When running configure script from 2.5.0-rc4 on OpenBSD-current (amd64), I get the following error: + + ./configure[4756]: ${nettle:+($nettle_version)}": bad substitution + *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2747 '/usr/ports/pobj/qemu-2.5.0rc4/.configure_done') + *** Error 1 in /usr/ports/openbsd-wip/emulators/qemu (/usr/ports/infrastructure/mk/bsd.port.mk:2491 'configure') + +Indeed, construct "${nettle:+($nettle_version)}" does not conform to POSIX Shell Command Language. The attached patch fixes the issue. + + + +Sorry, wrong patch. + +On Sun, Dec 13, 2015 at 06:39:22PM -0000, Dmitrij D. Czarkoff wrote: +> Sorry, wrong patch. +> +> ** Patch added: "0001-configure-fix-POSIX-compatibility-issue.patch" +> https://bugs.launchpad.net/qemu/+bug/1525682/+attachment/4534158/+files/0001-configure-fix-POSIX-compatibility-issue.patch +> +> ** Patch removed: "0001-configure-fix-POSIX-compatibility-issue.patch" +> https://bugs.launchpad.net/qemu/+bug/1525682/+attachment/4534156/+files/0001-configure-fix-POSIX-compatibility-issue.patch + +Please send patches to <email address hidden>. Guidelines on submitting +patches are here: +http://qemu-project.org/Contribute/SubmitAPatch + +Thanks! + + +In particular, the Signed-off-by: line is critically important -- we cannot apply a patch without one. + +git blame says this + syntax was originally introduced in commit becaeb726 in July (though at that point the variable name was slightly different: ${gnutls_nettle+($nettle_version)} ). That means we were using this construct in v2.4.0, so this is not a regression for 2.5.0. + +I'm also a bit confused by your patch and your original bug report. The error message you quote is complaining about a line with ":+" syntax, but upstream configure is not using ":+" syntax here. Indeed your patch is changing it from + to :+. + + -echo "nettle $nettle ${nettle+($nettle_version)}" + +echo "nettle $nettle ${nettle:+($nettle_version)}" + +It's not clear to me why this would help, because +http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 +(section "Parameter Expansion") which documents the syntax describes both ":+" and "+", so whatever the shell is complaining about it presumably isn't the + vs :+ distinction. + +Which shell is this? + + +OK, so I misidentified the issue and screwed up my bug report. + +The shell is pdksh on OpenBSD, and the real issue is with parentheses: + + $ a=1 + $ b=2 + $ echo "${a+($b)}" + ksh: ${a+($b)}": bad substitution + $ echo "${a+\($b\)}" + (2) + +Unfortunately in bash and dash backslash-escaping the brackets results in the backslashes being printed verbatim: +$ (a=1 b=2 ; echo "${a+\($b\)}") +\(2\) + +Can you try this syntax with extra quote characters? (It works in bash/dash): +(a=1 b=2 ; echo "${a+"($b)"}") +(2) + + +It works. + +Thanks. I'll send out a patch. + + +Actually it turns out we really shouldn't be using the ${} syntax anyway, because if nettle is not present we end up printing +"nettle: no ()" +because $nettle is set to "no", not null or unset. So we should just write this out like: +if test "$nettle" = "yes"; then + echo "nettle $nettle ($nettle_version)" +else + echo "nettle $nettle" +fi + + +FWIW this way it is also consistent with other check results reporting, eg. spice. + +The patch to fix this is at: http://patchwork.ozlabs.org/patch/556537/ + +Unfortunately it has just missed the cutoff to get into 2.5.0 (since it has been present since 2.4.0 and there is a workaround of running "/path/to/bash configure"). We'll put it into the next 2.5.x stable release, though. + + +[adding autoconf, which likes to document shell bugs] + +On 12/14/2015 04:34 AM, Dmitrij D. Czarkoff wrote: +> OK, so I misidentified the issue and screwed up my bug report. +> +> The shell is pdksh on OpenBSD, and the real issue is with parentheses: +> +> $ a=1 +> $ b=2 +> $ echo "${a+($b)}" +> ksh: ${a+($b)}": bad substitution + +That's a bug in pdksh; see the POSIX interpretation: + +http://austingroupbugs.net/view.php?id=221#c399 + + For parameter expansions other than the four varieties that provide + for substring processing, within the string of characters from an + enclosed "${" to the matching '}', the double-quotes within which + the expansion occurs shall preserve the literal value of all + characters, with the exception of the characters double-quote, + backquote, <dollar-sign>, and <backslash>. + +The fact that you are using "" outside the ${} means that all characters +between + and } should be used literally (the same as if you had done +'echo "($b)"'). According to POSIX, it should not be a syntax error, so +you should report this to the pdksh shell developers. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Note that mksh is virtually a superset of OpenBSD ksh and accepts this construct, for a quick fix. + +The patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=18f49881cf8359e89396aac +... which should be part of QEMU 2.6.0, so let's mark this bug report as fixed. + diff --git a/results/classifier/118/review/1526 b/results/classifier/118/review/1526 new file mode 100644 index 000000000..5081e6635 --- /dev/null +++ b/results/classifier/118/review/1526 @@ -0,0 +1,61 @@ +mistranslation: 0.988 +device: 0.827 +virtual: 0.752 +network: 0.724 +performance: 0.571 +arm: 0.568 +ppc: 0.558 +vnc: 0.488 +risc-v: 0.464 +register: 0.459 +socket: 0.451 +boot: 0.429 +semantic: 0.389 +debug: 0.388 +architecture: 0.364 +kernel: 0.356 +graphic: 0.311 +VMM: 0.300 +TCG: 0.299 +user-level: 0.273 +hypervisor: 0.269 +peripherals: 0.268 +files: 0.257 +KVM: 0.172 +permissions: 0.164 +PID: 0.102 +i386: 0.082 +assembly: 0.071 +x86: 0.057 +-------------------- +debug: 0.942 +device: 0.234 +semantic: 0.073 +files: 0.069 +hypervisor: 0.063 +virtual: 0.058 +performance: 0.039 +kernel: 0.036 +peripherals: 0.017 +user-level: 0.017 +TCG: 0.013 +architecture: 0.009 +assembly: 0.008 +x86: 0.007 +VMM: 0.007 +i386: 0.005 +register: 0.005 +PID: 0.005 +arm: 0.005 +permissions: 0.004 +ppc: 0.004 +graphic: 0.003 +KVM: 0.003 +mistranslation: 0.002 +risc-v: 0.002 +boot: 0.001 +socket: 0.001 +vnc: 0.001 +network: 0.000 + +hw/vfio/trace-events incorrect format diff --git a/results/classifier/118/review/1529 b/results/classifier/118/review/1529 new file mode 100644 index 000000000..7bfbaddd4 --- /dev/null +++ b/results/classifier/118/review/1529 @@ -0,0 +1,61 @@ +mistranslation: 0.994 +semantic: 0.726 +hypervisor: 0.564 +performance: 0.319 +architecture: 0.287 +virtual: 0.277 +graphic: 0.187 +permissions: 0.171 +i386: 0.039 +device: 0.028 +network: 0.019 +files: 0.012 +user-level: 0.010 +x86: 0.008 +peripherals: 0.008 +boot: 0.006 +KVM: 0.005 +debug: 0.005 +ppc: 0.004 +register: 0.004 +VMM: 0.004 +TCG: 0.004 +arm: 0.003 +risc-v: 0.002 +assembly: 0.002 +socket: 0.002 +vnc: 0.002 +PID: 0.002 +kernel: 0.001 +-------------------- +hypervisor: 0.981 +semantic: 0.793 +kernel: 0.404 +virtual: 0.394 +files: 0.298 +device: 0.064 +mistranslation: 0.046 +boot: 0.026 +x86: 0.022 +assembly: 0.018 +network: 0.017 +debug: 0.013 +PID: 0.009 +architecture: 0.009 +register: 0.008 +user-level: 0.006 +performance: 0.005 +TCG: 0.005 +arm: 0.004 +permissions: 0.004 +i386: 0.004 +socket: 0.003 +risc-v: 0.002 +VMM: 0.001 +graphic: 0.001 +peripherals: 0.001 +ppc: 0.001 +KVM: 0.000 +vnc: 0.000 + +Documentation refers to Windows Hypervisor Platform as wphx instead of whpx diff --git a/results/classifier/118/review/1533 b/results/classifier/118/review/1533 new file mode 100644 index 000000000..8a0593178 --- /dev/null +++ b/results/classifier/118/review/1533 @@ -0,0 +1,61 @@ +architecture: 0.890 +i386: 0.727 +mistranslation: 0.585 +device: 0.559 +semantic: 0.455 +permissions: 0.373 +performance: 0.360 +graphic: 0.357 +network: 0.331 +virtual: 0.206 +register: 0.187 +peripherals: 0.169 +boot: 0.166 +hypervisor: 0.163 +user-level: 0.136 +debug: 0.126 +x86: 0.118 +arm: 0.106 +kernel: 0.100 +socket: 0.073 +files: 0.064 +TCG: 0.062 +PID: 0.060 +vnc: 0.056 +ppc: 0.054 +assembly: 0.042 +VMM: 0.040 +risc-v: 0.037 +KVM: 0.025 +-------------------- +i386: 0.999 +x86: 0.998 +virtual: 0.957 +hypervisor: 0.890 +semantic: 0.095 +user-level: 0.073 +architecture: 0.048 +debug: 0.031 +assembly: 0.028 +KVM: 0.025 +register: 0.012 +permissions: 0.012 +files: 0.011 +device: 0.011 +kernel: 0.008 +socket: 0.007 +TCG: 0.004 +performance: 0.003 +boot: 0.003 +VMM: 0.002 +PID: 0.002 +graphic: 0.001 +peripherals: 0.001 +ppc: 0.001 +risc-v: 0.000 +mistranslation: 0.000 +network: 0.000 +vnc: 0.000 +arm: 0.000 + +qemu-i386 should not enable feature LM with named CPU models. diff --git a/results/classifier/118/review/1535497 b/results/classifier/118/review/1535497 new file mode 100644 index 000000000..3d114356e --- /dev/null +++ b/results/classifier/118/review/1535497 @@ -0,0 +1,89 @@ +x86: 0.896 +architecture: 0.817 +device: 0.774 +performance: 0.741 +network: 0.734 +KVM: 0.694 +graphic: 0.691 +permissions: 0.634 +boot: 0.605 +hypervisor: 0.576 +virtual: 0.543 +vnc: 0.524 +semantic: 0.481 +peripherals: 0.474 +socket: 0.438 +i386: 0.431 +register: 0.345 +files: 0.326 +kernel: 0.314 +user-level: 0.271 +PID: 0.230 +mistranslation: 0.205 +ppc: 0.131 +arm: 0.097 +debug: 0.076 +VMM: 0.071 +risc-v: 0.070 +assembly: 0.066 +TCG: 0.032 +-------------------- +virtual: 0.966 +KVM: 0.964 +hypervisor: 0.921 +TCG: 0.843 +boot: 0.745 +debug: 0.682 +register: 0.513 +x86: 0.501 +risc-v: 0.456 +socket: 0.403 +kernel: 0.230 +PID: 0.067 +device: 0.050 +vnc: 0.045 +files: 0.043 +semantic: 0.027 +VMM: 0.024 +assembly: 0.017 +network: 0.014 +performance: 0.012 +architecture: 0.006 +i386: 0.003 +permissions: 0.003 +peripherals: 0.002 +ppc: 0.002 +user-level: 0.002 +graphic: 0.001 +arm: 0.001 +mistranslation: 0.000 + +Guest can not boot up when assigned more than 20 vcpus with option "-no-acpi" + +Environment: + ------------------------------- + KVM commit/branch: da3f7ca3/next + Qemu commit/branch: 7b8a354d/master + Host OS: RHEL7.2 ia32e + Host Kernel: 4.4-rc2 + Guest OS: RHEL7.2 ia32e + +Description: + -------------------------------- +When assign more than 20 vpcus with option "-no-acpi", guest can not boot up. + +Reproduce: + ---------------- + 1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + + +Bisect show the bad commit is 9ee2e2625 of seabios. + + + + + +Can you still reproduce this issue with the latest version of QEMU? If this is a bug in seabios, have you tried to report this to seabios instead? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1536487 b/results/classifier/118/review/1536487 new file mode 100644 index 000000000..b9b0c3940 --- /dev/null +++ b/results/classifier/118/review/1536487 @@ -0,0 +1,146 @@ +mistranslation: 0.924 +device: 0.905 +risc-v: 0.888 +virtual: 0.884 +register: 0.857 +user-level: 0.848 +VMM: 0.833 +PID: 0.829 +KVM: 0.826 +arm: 0.818 +semantic: 0.812 +peripherals: 0.801 +graphic: 0.780 +ppc: 0.776 +assembly: 0.769 +performance: 0.758 +permissions: 0.739 +x86: 0.704 +hypervisor: 0.682 +architecture: 0.680 +boot: 0.679 +socket: 0.665 +debug: 0.664 +kernel: 0.663 +files: 0.650 +network: 0.629 +vnc: 0.621 +TCG: 0.615 +i386: 0.366 +-------------------- +x86: 0.917 +KVM: 0.826 +virtual: 0.697 +hypervisor: 0.604 +files: 0.034 +TCG: 0.024 +debug: 0.023 +device: 0.021 +user-level: 0.017 +PID: 0.015 +register: 0.010 +kernel: 0.008 +socket: 0.005 +architecture: 0.003 +semantic: 0.003 +ppc: 0.003 +VMM: 0.003 +vnc: 0.002 +assembly: 0.002 +i386: 0.002 +risc-v: 0.002 +network: 0.002 +performance: 0.002 +boot: 0.001 +peripherals: 0.001 +graphic: 0.001 +permissions: 0.001 +arm: 0.000 +mistranslation: 0.000 + +Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1 + +When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out: + + qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg' + +This appears to be related to the addition of a DMA interface to fw_cfg last October: + + http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04568.html + +"info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled: + + bus: main-system-bus + type System + ... + dev: fw_cfg_io, id "" + iobase = 1296 (0x510) + dma_iobase = 1300 (0x514) + dma_enabled = true + +Incidentally, this guest had just undergone a migration from QEMU 2.4.0 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration. + +It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher. + +Hi, +Proxmox users have reported same bug (qemu 2.5 with pc-i440fc-2.4 not migrating to qemu 2.4.1) + +https://forum.proxmox.com/threads/cant-live-migrate-after-dist-upgrade.26097/ + +I don't have verified yet, but it seem to be related. + + +http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042 + +sent a patch: http://thread.gmane.org/gmane.comp.emulators.qemu/395014 + +Fix committed in e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Note: Also affects Migration Xenial->Trusty (tested and ran into the same issue, that was how I found the bug) and very likely also Yakkety->Trusty. + + qemu | 2.0.0+dfsg-2ubuntu1.27 | trusty-security | source + qemu | 1:2.5+dfsg-5ubuntu10.4 | xenial-updates | source + +Subscribing server Team to look at this in the scope of the qemu packaging SRU work for Xenial. + +Migrating a VM from xenial -> trusty (or anything moving backward) is +not supported. + + +Hi Serge I agree to "created on xenial -> migrating to trusty" not being supported. +I already tended to even say "created on xenial with the Trusty machine type -> migrating to trusty" is not supported as well (at least it is failing for all combos I tried. + +But I wonder how far "anything moving backward" should go. + +Especially I found that the "created on Trusty, migrated to xenial (works), but later migrated back to trusty (fails)" seems affected by it as well. +I'd have thought that this would be supported. What is you opinion on this more specific case? + +You might ask on #virt for the opinion there, but I don't believe +migrating backward is supported in any case. t->x->t doesn't change +the fact that there is x->t. + + +> Especially I found that the "created on Trusty, migrated to xenial +> (works), but later migrated back to trusty (fails)" seems affected by +> it as well. + +The first migration of the t->x->t sequence does not really matter (if +anything it could introduce _more_ bugs!), so if x->t is not supported +then neither is t->x->t. + +The upstream QEMU project doesn't have the manpower to test and support +backwards migration. We try not to break it, and in this case there +was an easy fix and we suggest that Canonical backports it. However, +in general it's not guaranteed to work. + +The fix is commit e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Serge, Paulo - thank you both! + +I already had the patch but I think it was good to discuss and list the expected behavior not only for me, but for whoever else that comes by this or a similar case. + +I backported this and tried my tests again, but this alone isn't sufficient to get the T->X->T working (which is effectively 2.0->2.5->2.0). +Wily (2.4) is already out of service, so setting this to won't fix. + +Thanks for your guidance, but that now properly known I'll set the Xenial task to won't fix for now. + diff --git a/results/classifier/118/review/154 b/results/classifier/118/review/154 new file mode 100644 index 000000000..b7108aa75 --- /dev/null +++ b/results/classifier/118/review/154 @@ -0,0 +1,61 @@ +mistranslation: 0.953 +performance: 0.712 +device: 0.644 +network: 0.541 +socket: 0.499 +arm: 0.470 +boot: 0.395 +graphic: 0.362 +architecture: 0.328 +semantic: 0.315 +files: 0.294 +ppc: 0.265 +debug: 0.263 +peripherals: 0.263 +i386: 0.261 +permissions: 0.250 +user-level: 0.248 +x86: 0.227 +VMM: 0.224 +kernel: 0.198 +vnc: 0.196 +TCG: 0.156 +KVM: 0.150 +risc-v: 0.147 +register: 0.143 +virtual: 0.120 +PID: 0.114 +hypervisor: 0.089 +assembly: 0.045 +-------------------- +files: 0.537 +debug: 0.118 +kernel: 0.117 +ppc: 0.090 +PID: 0.070 +virtual: 0.046 +user-level: 0.036 +x86: 0.035 +performance: 0.028 +hypervisor: 0.020 +architecture: 0.019 +TCG: 0.016 +semantic: 0.013 +risc-v: 0.008 +i386: 0.006 +VMM: 0.006 +device: 0.004 +KVM: 0.004 +arm: 0.003 +boot: 0.002 +assembly: 0.002 +graphic: 0.001 +network: 0.001 +vnc: 0.001 +peripherals: 0.001 +socket: 0.001 +register: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +readlink(2) returns incorrect size for /proc/self/exe diff --git a/results/classifier/118/review/1541643 b/results/classifier/118/review/1541643 new file mode 100644 index 000000000..d886c970b --- /dev/null +++ b/results/classifier/118/review/1541643 @@ -0,0 +1,73 @@ +architecture: 0.844 +virtual: 0.794 +device: 0.765 +mistranslation: 0.756 +kernel: 0.733 +graphic: 0.586 +semantic: 0.577 +x86: 0.575 +network: 0.569 +i386: 0.543 +vnc: 0.533 +register: 0.509 +KVM: 0.499 +permissions: 0.479 +socket: 0.470 +performance: 0.463 +boot: 0.441 +risc-v: 0.372 +VMM: 0.369 +debug: 0.330 +PID: 0.313 +TCG: 0.310 +files: 0.310 +hypervisor: 0.293 +ppc: 0.284 +user-level: 0.256 +arm: 0.230 +peripherals: 0.193 +assembly: 0.102 +-------------------- +KVM: 0.832 +x86: 0.785 +hypervisor: 0.528 +kernel: 0.524 +virtual: 0.291 +debug: 0.141 +TCG: 0.097 +user-level: 0.064 +i386: 0.032 +files: 0.023 +register: 0.019 +PID: 0.015 +device: 0.014 +network: 0.012 +architecture: 0.012 +socket: 0.010 +ppc: 0.008 +performance: 0.005 +boot: 0.005 +assembly: 0.005 +VMM: 0.004 +semantic: 0.004 +risc-v: 0.003 +permissions: 0.002 +peripherals: 0.001 +arm: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +IA32_FEATURE_CONTROL MSR unset for nested virtualization + +I enabled nested virtualization for the kvm_intel module, and passed -enable-kvm and -cpu host to qemu. However, the qemu BIOS did not set IA32_FEATURE_CONTROL MSR (index 0x3a) to a non-zero value allow VMXON. According to the Intel manual Section 23.7 ENABLING AND ENTERING VMX OPERATION: "To enable VMX support in a platform, BIOS must set bit 1, bit 2, or both (see below), as well as the lock bit." + +I noticed an old mailing list thread on this (https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01372.html), but I wanted to point out that the Intel manual (and all the physical hardware I've tested) specifically contradicts this response. + +Tested on kernel 4.3.3 and qemu 2.4.1. + +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/review/1544524 b/results/classifier/118/review/1544524 new file mode 100644 index 000000000..67a5493cd --- /dev/null +++ b/results/classifier/118/review/1544524 @@ -0,0 +1,132 @@ +user-level: 0.915 +peripherals: 0.897 +hypervisor: 0.876 +KVM: 0.862 +vnc: 0.859 +semantic: 0.857 +graphic: 0.856 +ppc: 0.849 +performance: 0.847 +TCG: 0.842 +virtual: 0.838 +arm: 0.831 +register: 0.831 +assembly: 0.830 +risc-v: 0.830 +permissions: 0.826 +architecture: 0.826 +device: 0.808 +debug: 0.806 +network: 0.794 +files: 0.791 +socket: 0.785 +mistranslation: 0.781 +x86: 0.780 +kernel: 0.775 +PID: 0.769 +VMM: 0.762 +boot: 0.742 +i386: 0.659 +-------------------- +x86: 0.955 +virtual: 0.949 +hypervisor: 0.805 +KVM: 0.792 +user-level: 0.578 +debug: 0.527 +network: 0.257 +TCG: 0.169 +files: 0.144 +device: 0.116 +register: 0.065 +PID: 0.061 +semantic: 0.060 +performance: 0.048 +risc-v: 0.032 +socket: 0.020 +peripherals: 0.013 +permissions: 0.012 +architecture: 0.011 +VMM: 0.010 +boot: 0.010 +ppc: 0.006 +kernel: 0.005 +i386: 0.004 +graphic: 0.004 +mistranslation: 0.002 +assembly: 0.002 +vnc: 0.001 +arm: 0.000 + +"info chardev" not showing the real port in use + +With Qemu 2.1.2 +============== +pharidos@uks2:~/work/tplaf/☸ qemu-system-x86_64 -hda /space/pharidos/Disks/Blank_disk.qcow2 -serial telnet::0,server,nowait -nographic +QEMU 2.1.2 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=telnet:0.0.0.0:44189,server <====<<< serial console is using port 44189 +compat_monitor0: filename=stdio +(qemu) + + +With Qemu 2.5.0 +============== +pharidos@kvm:~/$ qemu-system-x86_64 -hda /space/pharidos/Disks/Blank_disk.qcow2 -serial telnet::0,server,nowait -nographic +QEMU 2.5.0 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=disconnected:telnet::0,server <====<<< serial console port not shown +compat_monitor0: filename=stdio +(qemu) + +Also on quickly connecting to the ports via the netcat tool (hoping that it would make qemu to change its state from disconnected) +I see the following error "Error in getpeername: Transport endpoint is not connected" + +pharidos@uks2:~/$ qemu-system-x86_64 --enable-kvm -hda Sisk.qcow2 -serial telnet::0,server,nowait -serial telnet::0,server,nowait -nographic +QEMU 2.5.0 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial1: filename=disconnected:telnet::0,server +serial0: filename=disconnected:telnet::0,server +compat_monitor0: filename=stdio +(qemu) + +# COnnect quickly to the serial ports via netcat +pharidos@kvm:~/$ netstat -tupan 2>/dev/null | grep "LISTEN.* $(pgrep -f qemu)/qemu" | cut -d: -f2 | cut -d' ' -f1 +45814 +42522 +pharidos@kvm:~/$ ports=$(netstat -tupan 2>/dev/null | grep "LISTEN.* $(pgrep -f qemu)/qemu" | cut -d: -f2 | cut -d' ' -f1) +pharidos@kvm:~/$ for p in $ports; do echo | nc -w0 kvm $p >/dev/null; done + +# Check the port status again. We see the the error "Error in getpeername: Transport endpoint is not connected" +(qemu) info chardev +parallel0: filename=null +serial1: filename=Error in getpeername: Transport endpoint is not connected + +serial0: filename=Error in getpeername: Transport endpoint is not connected + +compat_monitor0: filename=stdio +(qemu) + + +Seems like this has been fixed in recent versions of QEMU again: + +$ qemu-system-x86_64 -serial telnet::0,server,nowait -nographic +QEMU 3.1.93 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=null +serial0: filename=disconnected:telnet:0.0.0.0:41346,server +compat_monitor0: filename=stdio + + +Yes. This was fixed some time back and I can confirm it working with qemu 2.8 + +QEMU 2.8.1 monitor - type 'help' for more information +(qemu) info chardev +parallel0: filename=vc +serial0: filename=telnet:127.0.0.1:35293,server <-> 127.0.0.1:52820 +compat_monitor0: filename=stdio + + diff --git a/results/classifier/118/review/1545052 b/results/classifier/118/review/1545052 new file mode 100644 index 000000000..16deaa517 --- /dev/null +++ b/results/classifier/118/review/1545052 @@ -0,0 +1,148 @@ +user-level: 0.903 +debug: 0.840 +peripherals: 0.837 +risc-v: 0.832 +permissions: 0.824 +mistranslation: 0.822 +KVM: 0.818 +hypervisor: 0.805 +performance: 0.794 +TCG: 0.788 +graphic: 0.779 +x86: 0.778 +vnc: 0.769 +virtual: 0.762 +register: 0.758 +ppc: 0.740 +architecture: 0.740 +arm: 0.730 +device: 0.720 +semantic: 0.714 +VMM: 0.708 +socket: 0.704 +i386: 0.690 +assembly: 0.672 +network: 0.669 +kernel: 0.659 +PID: 0.631 +files: 0.626 +boot: 0.604 +-------------------- +debug: 0.965 +virtual: 0.518 +kernel: 0.204 +x86: 0.128 +hypervisor: 0.103 +TCG: 0.097 +vnc: 0.049 +PID: 0.039 +ppc: 0.035 +assembly: 0.023 +files: 0.022 +VMM: 0.010 +device: 0.009 +network: 0.008 +risc-v: 0.007 +semantic: 0.007 +performance: 0.007 +architecture: 0.006 +register: 0.006 +KVM: 0.004 +user-level: 0.003 +graphic: 0.002 +socket: 0.002 +boot: 0.001 +i386: 0.001 +peripherals: 0.001 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.001 + +RDMA migration will hang forever if target QEMU fails to load vmstate + +Get a pair of machines with infiniband support. On one host run + +$ qemu-system-x86_64 -monitor stdio -incoming rdma:ibme:4444 -vnc :1 -m 1000 + +To start an incoming migration. + + +Now on the other host, run QEMU with an intentionally different configuration (ie different RAM size) + +$ qemu-system-x86_64 -monitor stdio -vnc :1 -m 2000 + +Now trigger a migration on this source host + +(qemu) migrate rdma:ibpair:4444 + + +You will see on the target host, that it failed to load migration: + +dest_init RDMA Device opened: kernel name mlx4_0 uverbs device name uverbs0, infiniband_verbs class device path /sys/class/infiniband_verbs/uverbs0, infiniband class device path /sys/class/infiniband/mlx4_0, transport: (2) Ethernet +qemu-system-x86_64: Length mismatch: pc.ram: 0x7d000000 in != 0x3e800000: Invalid argument +qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' + +This is to be expected, however, at this point QEMU has hung and no longer responds to the monitor + +GDB shows the target host is stuck in this callpath + +#0 0x00007ffff39141cd in write () at ../sysdeps/unix/syscall-template.S:81 +#1 0x00007ffff27fe795 in rdma_get_cm_event.part.15 () from /lib64/librdmacm.so.1 +#2 0x000055555593e445 in qemu_rdma_cleanup (rdma=0x7fff9647e010) at migration/rdma.c:2210 +#3 0x000055555593ea45 in qemu_rdma_close (opaque=0x555557796770) at migration/rdma.c:2652 +#4 0x00005555559397cc in qemu_fclose (f=f@entry=0x5555564b1450) at migration/qemu-file.c:270 +#5 0x0000555555936b88 in process_incoming_migration_co (opaque=0x5555564b1450) at migration/migration.c:361 +#6 0x0000555555a25a1a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:79 +#7 0x00007fffef5b3110 in ?? () from /lib64/libc.so.6 + + + +Now, back on the source host again, you would expect to see that the migrate command failed. Instead, this QEMU is hung too. + +GDB shows the source host, migrate thread, is stuck in this callpath: + +#0 0x00007ffff391522d in read#1 0x00007ffff00efd93 in ibv_get_cq_event () at /lib64/libibverbs.so.1 +#2 0x00005555559403f2 in qemu_rdma_block_for_wrid (rdma=rdma@entry=0x7fff3d07e010, wrid_requested=wrid_requested@entry=4000, byte_len=byte_len@entry=0x7fff39de370c) at migration/rdma.c:1511 +#3 0x000055555594058a in qemu_rdma_exchange_get_response (rdma=0x7fff3d07e010, head=head@entry=0x7fff39de3780, expecting=expecting@entry=2, idx=idx@entry=0) + at migration/rdma.c:1648 +#4 0x0000555555941e71 in qemu_rdma_exchange_send (rdma=0x7fff3d07e010, head=0x7fff39de3840, data=0x0, resp=0x7fff39de3870, resp_idx=0x7fff39de3880, callback=0x0) at migration/rdma.c:1725 +#5 0x00005555559447e4 in qemu_rdma_registration_stop (f=<optimized out>, opaque=<optimized out>, flags=0, data=<optimized out>) at migration/rdma.c:3302 +#6 0x000055555593bc4b in ram_control_after_iterate (f=f@entry=0x5555564c20f0, flags=flags@entry=0) at migration/qemu-file.c:157 +#7 0x0000555555740b59 in ram_save_setup (f=0x5555564c20f0, opaque=<optimized out>) at /home/berrange/src/virt/qemu/migration/ram.c:1959 +#8 0x00005555557451c1 in qemu_savevm_state_begin (f=0x5555564c20f0, params=params@entry=0x555555f6f048 <current_migration.37991+72>) + at /home/berrange/src/virt/qemu/migration/savevm.c:919 +#9 0x00005555559381a5 in migration_thread (opaque=0x555555f6f000 <current_migration.37991>) at migration/migration.c:1633 +#10 0x00007ffff390edc5 in start_thread (arg=0x7fff39de4700) at pthread_create.c:308 + + +It should have aborted migrate and set the status to failed. + +FYI is is tested on current GIT master + +commit fc1ec1acffd29d54c0c4266d30d38b2399d42f4f +Merge: f163684 1834ed3 +Author: Peter Maydell <email address hidden> +Date: Thu Feb 11 15:09:33 2016 +0000 + + Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2016-02-11' into staging + + + +Fix series posted upstream: +0001-migration-rdma-Fix-race-on-source.patch +0002-migration-Close-file-on-failed-migration-load.patch +0003-migration-rdma-Allow-cancelling-while-waiting-for-wr.patch +0004-migration-rdma-Safely-convert-control-types.patch +0005-migration-rdma-Send-error-during-cancelling.patch + + +Patch series has apparently been merged in time for QEMU v2.10: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9cf2bab2edca1e651eef +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3a0f2ceaedcf70ff79b6 +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9c98cfbe72b21d9d84b9 +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=482a33c53cbc9d2b0c47 +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=32bce196344772df8d68 +So I assume we can close this ticket now? + +Yes, we probably can - I'd still not be that sure we've got all the races in the RDMA code, but we're probably a chunk better of than we were. + diff --git a/results/classifier/118/review/1549298 b/results/classifier/118/review/1549298 new file mode 100644 index 000000000..9b44a615e --- /dev/null +++ b/results/classifier/118/review/1549298 @@ -0,0 +1,79 @@ +register: 0.940 +graphic: 0.860 +device: 0.834 +peripherals: 0.779 +performance: 0.740 +ppc: 0.740 +architecture: 0.707 +PID: 0.694 +i386: 0.677 +semantic: 0.656 +x86: 0.636 +user-level: 0.634 +socket: 0.614 +permissions: 0.605 +vnc: 0.571 +debug: 0.565 +network: 0.563 +mistranslation: 0.555 +risc-v: 0.548 +VMM: 0.535 +hypervisor: 0.531 +files: 0.514 +arm: 0.504 +assembly: 0.496 +TCG: 0.475 +boot: 0.474 +kernel: 0.393 +virtual: 0.360 +KVM: 0.165 +-------------------- +x86: 0.834 +arm: 0.544 +hypervisor: 0.394 +debug: 0.220 +register: 0.181 +TCG: 0.108 +architecture: 0.066 +kernel: 0.049 +device: 0.046 +user-level: 0.043 +i386: 0.040 +virtual: 0.039 +semantic: 0.028 +files: 0.028 +ppc: 0.021 +assembly: 0.014 +performance: 0.013 +PID: 0.010 +network: 0.009 +boot: 0.006 +socket: 0.004 +peripherals: 0.003 +risc-v: 0.002 +graphic: 0.002 +permissions: 0.001 +vnc: 0.001 +VMM: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +Add missing MSRs for powertop + +I reported this same bug on the powertop bugtracker [1] because I think both projects need to change something here. + +When running powertop it crashes and prints: + + unknown op '{' + read_msr cpu0 0xe8 : Input/output error + +It seems that powertop is trying to access model specific registers and because qemu doesn't emulate them it crashes. +Clearly powertop shouldn't crash in such case but I think it would also be better if qemu could add support for these registers. + +1: https://app.devzing.com/powertopbugs/bugzilla/show_bug.cgi?id=4 + +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/review/1556044 b/results/classifier/118/review/1556044 new file mode 100644 index 000000000..6893a65c1 --- /dev/null +++ b/results/classifier/118/review/1556044 @@ -0,0 +1,73 @@ +i386: 0.940 +arm: 0.921 +architecture: 0.842 +graphic: 0.841 +boot: 0.717 +device: 0.697 +x86: 0.597 +performance: 0.552 +mistranslation: 0.551 +semantic: 0.490 +vnc: 0.361 +socket: 0.324 +ppc: 0.294 +register: 0.269 +files: 0.254 +risc-v: 0.245 +PID: 0.231 +network: 0.224 +permissions: 0.198 +user-level: 0.177 +VMM: 0.177 +debug: 0.162 +TCG: 0.129 +virtual: 0.096 +assembly: 0.079 +peripherals: 0.076 +kernel: 0.070 +hypervisor: 0.040 +KVM: 0.006 +-------------------- +arm: 0.998 +virtual: 0.798 +debug: 0.504 +user-level: 0.430 +files: 0.231 +TCG: 0.128 +hypervisor: 0.118 +boot: 0.076 +performance: 0.071 +register: 0.017 +device: 0.014 +PID: 0.012 +semantic: 0.010 +architecture: 0.008 +socket: 0.007 +graphic: 0.006 +kernel: 0.005 +network: 0.004 +i386: 0.003 +peripherals: 0.002 +vnc: 0.002 +x86: 0.001 +assembly: 0.001 +risc-v: 0.001 +VMM: 0.001 +permissions: 0.000 +KVM: 0.000 +mistranslation: 0.000 +ppc: 0.000 + +Redox GUI hangs with 100% CPU on ARM + +Booting into Redox OS cli on ARM with qemu-system-i386 works fine. However, starting the Redox GUI (orbital) brings up the graphical interface and then starts using 100% CPU. I'd guess it's related to mouse detection and handling. + +The OS image is fully usable on x86. + + +https://www.dropbox.com/s/u6v2k9wzcuiycfo/redox-disk.img.xz?dl=0 + +Which QEMU version have you been using here? Can you still reproduce the problem with the latest upstream version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/156 b/results/classifier/118/review/156 new file mode 100644 index 000000000..86d513b3c --- /dev/null +++ b/results/classifier/118/review/156 @@ -0,0 +1,61 @@ +mistranslation: 0.865 +semantic: 0.609 +risc-v: 0.383 +user-level: 0.318 +vnc: 0.300 +VMM: 0.261 +device: 0.247 +ppc: 0.237 +graphic: 0.195 +TCG: 0.179 +virtual: 0.171 +KVM: 0.166 +peripherals: 0.131 +PID: 0.121 +arm: 0.120 +performance: 0.109 +i386: 0.106 +architecture: 0.103 +files: 0.101 +boot: 0.086 +register: 0.083 +hypervisor: 0.070 +network: 0.063 +permissions: 0.060 +kernel: 0.047 +x86: 0.046 +socket: 0.032 +assembly: 0.029 +debug: 0.012 +-------------------- +user-level: 0.729 +semantic: 0.181 +permissions: 0.099 +virtual: 0.029 +files: 0.026 +kernel: 0.011 +debug: 0.009 +x86: 0.009 +network: 0.008 +KVM: 0.008 +device: 0.007 +assembly: 0.006 +VMM: 0.005 +ppc: 0.004 +boot: 0.004 +PID: 0.004 +socket: 0.003 +i386: 0.003 +peripherals: 0.002 +performance: 0.002 +mistranslation: 0.002 +TCG: 0.002 +risc-v: 0.002 +hypervisor: 0.001 +architecture: 0.001 +vnc: 0.001 +register: 0.001 +arm: 0.001 +graphic: 0.000 + +-nodefaults has unclear documentation diff --git a/results/classifier/118/review/1562653 b/results/classifier/118/review/1562653 new file mode 100644 index 000000000..bfaee7d4a --- /dev/null +++ b/results/classifier/118/review/1562653 @@ -0,0 +1,210 @@ +register: 0.920 +permissions: 0.913 +mistranslation: 0.912 +virtual: 0.909 +user-level: 0.896 +hypervisor: 0.870 +KVM: 0.861 +risc-v: 0.860 +architecture: 0.855 +TCG: 0.853 +VMM: 0.850 +performance: 0.850 +graphic: 0.837 +device: 0.836 +ppc: 0.825 +vnc: 0.819 +arm: 0.818 +PID: 0.800 +boot: 0.793 +x86: 0.788 +network: 0.777 +socket: 0.760 +peripherals: 0.757 +debug: 0.752 +assembly: 0.750 +kernel: 0.747 +files: 0.717 +semantic: 0.706 +i386: 0.606 +-------------------- +virtual: 0.989 +hypervisor: 0.985 +x86: 0.973 +KVM: 0.960 +debug: 0.666 +performance: 0.354 +device: 0.132 +PID: 0.095 +kernel: 0.077 +boot: 0.073 +files: 0.037 +socket: 0.025 +architecture: 0.023 +register: 0.013 +TCG: 0.012 +VMM: 0.012 +assembly: 0.008 +user-level: 0.007 +semantic: 0.006 +peripherals: 0.003 +ppc: 0.003 +permissions: 0.002 +graphic: 0.002 +network: 0.001 +vnc: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +Ubuntu 15.10: QEMU VM hang if memory >= 1T + +1. Ubuntu 15.10 x86_64 installed on HP SuperDome X with 8CPUs and 4T memory. + +2. Create a VM, install Ubuntu 15.10, if memory >= 1T , VM hang when start. If memory < 1T, it is good. +<domain type='kvm'> + <name>u1510-1</name> + <uuid>39eefe1e-4829-4843-b892-026d143f3ec7</uuid> + <memory unit='KiB'>1073741824</memory> + <currentMemory unit='KiB'>1073741824</currentMemory> + <vcpu placement='static'>16</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> + <boot dev='hd'/> + <boot dev='cdrom'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='directsync'/> + <source file='/vms/images/u1510-1.img'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='0c:da:41:1d:ae:f1'/> + <source bridge='vswitch0'/> + <model type='virtio'/> + <driver name='vhost'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </memballoon> + </devices> +</domain> + +3. The panic stack is + ... cannot show + async_page_fault+0x28 + ioread32_rep+0x38 + ata_sff_data_xfer32+0x8a + ata_pio_sector+0x93 + ata_pio_sectors+0x34 + ata_sff_hsm_move+0x226 + RIP: kthread_data+0x10 + CR2: FFFFFFFF_FFFFFFD8 + +4. Change the host os to Redhat 7.2 , the vm is good even memory >=3.8T. + +I delete cdrom and IDE controller, the vm start sucessfully. + +But when I increate memory to 1100G, vm hang at hpet_enable when start. + +The panic is page_fault when execute hpet_period = hpet_readl(HPET_PERIOD); + +It seems that ioremap_nocache does not works correctly. + +hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE); + +Hi, + +just to be sure, if you run + +kvm -vnc :1 -m 1.5G +kvm -vnc :1 -m 1.5G --no-hpet + +do those also crash? + +Can you please show the contents of + +/var/log/libvirt/qemu/u1510-1.log + +I mean vm hang when memory >= 1100G (1024G when enable ide cdrom) instead of 1.5G. + +If disable hpet, the vm will hang at acpi_ex_system_memory_space_handler when memory >= 1100G + +If disable kvm, vm is good when memory <= 1020G, but also hang when memory >= 1024G. + +There is no critical information in vm.log: + + +After I changed PHYS_ADDR_MASK, qemu vm can start when memory >=1024G , but kvm vm still hang. + +-# define PHYS_ADDR_MASK 0xffffffffffLL ++# define PHYS_ADDR_MASK 0xfffffffffffLL + + +The issue is sloved after change cpuid[80000008]; + +--- a/target-i386/cpu.c ++++ b/target-i386/cpu.c +@@ -2547,7 +2547,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, + if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) { + /* 64 bit processor */ + /* XXX: The physical address space is limited to 42 bits in exec.c. */ +- *eax = 0x00003028; /* 48 bits virtual, 40 bits physical */ ++ *eax = 0x00003029; /* 48 bits virtual, 41 bits physical */ + } else { + if (env->features[FEAT_1_EDX] & CPUID_PSE36) { + *eax = 0x00000024; /* 36 bits physical */ + + +For cpus which have not EPT feature, should change CR3_L_MODE_RESERVED_BITS in arch/x86/include/asm/kvm_host.h: + +-#define CR3_L_MODE_RESERVED_BITS 0xFFFFFF0000000000ULL ++#define CR3_L_MODE_RESERVED_BITS 0xFFFFFE0000000000ULL + + +Can you still reproduce this problem with the latest version of upstream QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +I only saw this because it expired now :-/ + +Anyone affected by this might want to take a look at bug 1776189 where Ubuntu added a special machine type to more easily set "host-phys-bits" which is the qemu flag to have more (usually the host has more) available (at the cost of migratability). That allows <1TB as the default bits in qemu are chosen on the base of TCG (to be able to emulate what is virtualized) and that is limited to 1TB. + diff --git a/results/classifier/118/review/1566 b/results/classifier/118/review/1566 new file mode 100644 index 000000000..294ec1f5b --- /dev/null +++ b/results/classifier/118/review/1566 @@ -0,0 +1,69 @@ +mistranslation: 0.809 +device: 0.793 +socket: 0.686 +vnc: 0.683 +register: 0.616 +network: 0.609 +graphic: 0.595 +debug: 0.592 +kernel: 0.557 +files: 0.481 +semantic: 0.452 +performance: 0.411 +boot: 0.376 +VMM: 0.347 +arm: 0.289 +TCG: 0.285 +architecture: 0.251 +ppc: 0.242 +PID: 0.197 +KVM: 0.149 +hypervisor: 0.129 +user-level: 0.113 +assembly: 0.109 +x86: 0.103 +peripherals: 0.075 +i386: 0.074 +risc-v: 0.068 +virtual: 0.060 +permissions: 0.052 +-------------------- +debug: 0.293 +kernel: 0.086 +virtual: 0.058 +files: 0.058 +TCG: 0.042 +semantic: 0.038 +x86: 0.036 +assembly: 0.027 +user-level: 0.021 +register: 0.017 +ppc: 0.016 +network: 0.014 +hypervisor: 0.013 +PID: 0.013 +i386: 0.013 +device: 0.012 +arm: 0.010 +boot: 0.007 +VMM: 0.007 +KVM: 0.006 +peripherals: 0.006 +performance: 0.004 +architecture: 0.003 +graphic: 0.002 +socket: 0.002 +permissions: 0.002 +vnc: 0.001 +risc-v: 0.001 +mistranslation: 0.000 + +qemo-8-0-0-rc2 error: redeclaration of 'enum fsconfig_command' +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/review/1568107 b/results/classifier/118/review/1568107 new file mode 100644 index 000000000..2fc42ae3f --- /dev/null +++ b/results/classifier/118/review/1568107 @@ -0,0 +1,76 @@ +arm: 0.988 +architecture: 0.971 +device: 0.896 +graphic: 0.894 +mistranslation: 0.710 +semantic: 0.675 +register: 0.675 +network: 0.658 +user-level: 0.629 +debug: 0.598 +x86: 0.556 +performance: 0.547 +permissions: 0.535 +files: 0.525 +TCG: 0.486 +PID: 0.483 +socket: 0.469 +boot: 0.457 +vnc: 0.424 +ppc: 0.423 +peripherals: 0.399 +VMM: 0.359 +risc-v: 0.289 +kernel: 0.236 +hypervisor: 0.153 +virtual: 0.144 +assembly: 0.076 +KVM: 0.025 +i386: 0.010 +-------------------- +x86: 0.907 +arm: 0.800 +virtual: 0.778 +debug: 0.628 +kernel: 0.503 +TCG: 0.041 +files: 0.038 +hypervisor: 0.029 +PID: 0.027 +performance: 0.016 +user-level: 0.013 +device: 0.012 +architecture: 0.007 +register: 0.007 +semantic: 0.007 +boot: 0.002 +VMM: 0.002 +assembly: 0.002 +peripherals: 0.002 +graphic: 0.002 +socket: 0.001 +network: 0.001 +KVM: 0.001 +ppc: 0.001 +risc-v: 0.001 +permissions: 0.001 +i386: 0.000 +mistranslation: 0.000 +vnc: 0.000 + +x86_64 linux-user: setup_rt_frame: not implemented + +Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this: + +$ qemu-x86_64 parity --pruning fast + +setup_rt_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +Yes, the x86-64 linux-user target does not have any implementation of signal handling. + + +This bug was fixed in 2.9 (we added x86-64 linux-user signal handling support.) + + diff --git a/results/classifier/118/review/1570 b/results/classifier/118/review/1570 new file mode 100644 index 000000000..2e21c746b --- /dev/null +++ b/results/classifier/118/review/1570 @@ -0,0 +1,123 @@ +TCG: 0.829 +ppc: 0.811 +debug: 0.807 +KVM: 0.794 +hypervisor: 0.793 +register: 0.788 +virtual: 0.783 +vnc: 0.758 +boot: 0.744 +permissions: 0.735 +peripherals: 0.734 +VMM: 0.723 +device: 0.718 +graphic: 0.716 +arm: 0.708 +mistranslation: 0.700 +user-level: 0.676 +assembly: 0.673 +PID: 0.662 +socket: 0.630 +network: 0.626 +risc-v: 0.620 +files: 0.607 +semantic: 0.593 +performance: 0.586 +kernel: 0.578 +x86: 0.554 +architecture: 0.545 +i386: 0.329 +-------------------- +boot: 0.980 +kernel: 0.967 +debug: 0.886 +x86: 0.631 +TCG: 0.172 +assembly: 0.106 +virtual: 0.086 +hypervisor: 0.073 +mistranslation: 0.055 +PID: 0.047 +files: 0.041 +ppc: 0.031 +i386: 0.028 +register: 0.026 +user-level: 0.022 +VMM: 0.018 +arm: 0.014 +socket: 0.011 +architecture: 0.010 +performance: 0.010 +device: 0.010 +semantic: 0.008 +risc-v: 0.008 +vnc: 0.007 +KVM: 0.007 +network: 0.003 +permissions: 0.002 +graphic: 0.002 +peripherals: 0.001 + +Incorrect memory handling when booting redox +Description of problem: +During the boot of redox, I regularly get one of two errors when reading the HPET at base address `0xfed00000`: +- Incorrect translation from virtual address `0xffff8000fed00108` to random physical addresses, e.g. `0xfec00108` +- Invalid read at addr 0x0, size 8, region 'hpet', reason: invalid size (min:4 max:4) +Steps to reproduce: +1. Build the server version of the redox OS as per [the instructions](https://doc.redox-os.org/book/ch02-05-building-redox.html). +2. Run the qemu command line with multiple CPUs. The more CPUs the easier it is to reproduce. +3. The problem will manifest itself as a divide by zero error. See the corresponding [redox bug report](https://gitlab.redox-os.org/redox-os/kernel/-/issues/116). +Additional information: +The best evidence I have is a debug line I added to qemu before [the memory_region_dispatch_read line](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L1375): + +``` +if ((mr_offset & 0x1ff) == 0x108) fprintf(stderr, "cputlb io_readx cpu %d addr=%llx mr_offset=%llx mr=%p mr->addr=%llx\n", current_cpu->cpu_index, addr, mr_offset, mr, mr->addr); +r = memory_region_dispatch_read(mr, mr_offset, &val, op, full->attrs); +``` + +That logs: + +``` +cputlb io_readx cpu 0 addr=ffff8000fed00108 mr_offset=108 mr=0x7fefb60d5720 mr->addr=fec00000 +``` + +The expected physical address is `0xfed00000` instead of `0xfec00000`. + +A more extensive log is this one: +``` +55027@1680283224.671665:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f0 value 0x949707cc size 4 name 'hpet' <- ok +55027@1680283224.671681:memory_region_ops_read cpu 5 mr 0x7f9950890130 addr 0xfed000f4 value 0x0 size 4 name 'hpet' <- ok +tlb_set_page_full: vaddr=0000000000474000 paddr=0x000000000536f000 prot=5 idx=1 +... +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +tlb_flush_by_mmuidx_async_work: mmu_idx:0xffff +... +55027@1680283224.671951:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00108 value 0x0 size 4 name 'ioapic' <- wrong +55027@1680283224.671958:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec0010c value 0x0 size 4 name 'ioapic' +55027@1680283224.671967:memory_region_ops_write cpu 2 mr 0x7f994d808d30 addr 0xcf8 value 0x8000fa80 size 4 name 'pci-conf-idx' +55027@1680283224.671986:memory_region_ops_read cpu 2 mr 0x7f994d808e40 addr 0xcfc value 0x80a805 size 4 name 'pci-conf-data' +55027@1680283224.672001:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00000 value 0x0 size 4 name 'ioapic' <- wrong +55027@1680283224.672010:memory_region_ops_read cpu 5 mr 0x7f9950882930 addr 0xfec00004 value 0x0 size 4 name 'ioapic' +``` + +Some observations +- ~I seem to be the only one having this issue. Perhaps because I am the only one developing on MacOS. Maybe it's because I'm running an older intel mac.~. I managed to reproduce this on a Asus vivobook running linux +- The redox OS [reads the HPET](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_64/time.rs#L11) at addresses `0xf4`, `0x108`, `0x00` in that order. If I change the order to `0x00`, `0xf4`, `0x108`, the problem goes away. +- Even if I work around the problem by changing the order of the reads, the OS still randomly crashes. This could be related, but I can only speculate on that right now. +- Increasing qemu debug logging tends to push the problem to the 4vs8 size problem instead of the incorrect address one. The more logging, the more difficult it is to reproduce. +- I tried to bisect the issue and found I could only reproduce it after qemu version 5.2. However, the mac build broke during this process so I could not find the causal commit. Between 5.1 and 5.2 the performance is greatly increased though and I suspect whatever changed there caused the issue. +- I can't reproduce the problem with -smp 1 +- I have seen qemu segfault occasionally, but I didn't look further into it and I don't know if it's related to this issue. +- I have attempted to rule out a bug in redox. I am fairly certain nothing strange is going on there, but I can't say for sure. +- When I trigger the incorrect address bug, I mostly get a base address of `0xfec00000` which is the IO APIC. However, I do occasionally see other addresses too +- `info tlb` at the time of the fault shows + ``` + ffff8000fd3e6000: 00000000fd3e6000 X--DA---W + ffff8000fd3e7000: 00000000fd3e7000 X--DA---W + ffff8000fed00000: 00000000fed00000 X--DAC--W + ffff8000fee00000: 00000000fee00000 X--DA---W + fffffd8000000000: 0000000001e32000 XG-DA---W + fffffd8000001000: 0000000001e36000 XG-DA---W + ``` diff --git a/results/classifier/118/review/1570134 b/results/classifier/118/review/1570134 new file mode 100644 index 000000000..cbcfcf887 --- /dev/null +++ b/results/classifier/118/review/1570134 @@ -0,0 +1,1233 @@ +register: 0.882 +hypervisor: 0.859 +TCG: 0.859 +KVM: 0.856 +virtual: 0.856 +VMM: 0.839 +graphic: 0.834 +performance: 0.832 +permissions: 0.825 +semantic: 0.823 +debug: 0.818 +mistranslation: 0.814 +vnc: 0.814 +peripherals: 0.802 +user-level: 0.798 +PID: 0.794 +risc-v: 0.790 +network: 0.788 +ppc: 0.786 +device: 0.784 +arm: 0.783 +assembly: 0.780 +files: 0.774 +socket: 0.769 +architecture: 0.757 +x86: 0.756 +kernel: 0.754 +boot: 0.696 +i386: 0.674 +-------------------- +x86: 0.934 +debug: 0.931 +KVM: 0.885 +hypervisor: 0.884 +virtual: 0.457 +kernel: 0.148 +register: 0.100 +socket: 0.079 +TCG: 0.065 +PID: 0.046 +VMM: 0.043 +performance: 0.037 +device: 0.030 +user-level: 0.026 +files: 0.011 +boot: 0.009 +architecture: 0.007 +semantic: 0.006 +graphic: 0.005 +ppc: 0.004 +permissions: 0.004 +assembly: 0.003 +peripherals: 0.003 +network: 0.002 +risc-v: 0.001 +i386: 0.001 +mistranslation: 0.001 +vnc: 0.000 +arm: 0.000 + +While committing snapshot qemu crashes with SIGABRT + +Information: + +OS: Slackware64-Current +Compiled with: gcc version 5.3.0 (GCC) / glibc 2.23 +Compiled using: + +CFLAGS="-O2 -fPIC" \ +CXXFLAGS="-O2 -fPIC" \ +LDFLAGS="-L/usr/lib64" \ +./configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libdir=/usr/lib64 \ + --enable-spice \ + --enable-kvm \ + --enable-glusterfs \ + --enable-libiscsi \ + --enable-libusb \ + --target-list=x86_64-softmmu,i386-softmmu \ + --enable-debug + +Source: qemu-2.5.1.tar.bz2 + +Running as: + +/usr/bin/qemu-system-x86_64 -name test1,debug-threads=on -S -machine pc-1.1,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 4b30ec13-6609-4a56-8731-d400c38189ef -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-test1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/datastore/vm/test1/test1.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net pci,netdev=hostnet0,id=net0,mac=52:54:00:66:2e:0f,bus=pci.0,addr=0x3 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + +File system: zfs v0.6.5.6 + +While running: +virsh blockcommit test1 vda --active --pivot --verbose + +VM running very heavy IO load + +GDB reporting: + +#0 0x00007fd80132c3f8 in raise () at /lib64/libc.so.6 +#1 0x00007fd80132dffa in abort () at /lib64/libc.so.6 +#2 0x00007fd801324c17 in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007fd801324cc2 in () at /lib64/libc.so.6 +#4 0x000055d9918d7572 in bdrv_replace_in_backing_chain (old=0x55d993ed9c10, new=0x55d9931ccc10) at block.c:2096 + __PRETTY_FUNCTION__ = "bdrv_replace_in_backing_chain" +#5 0x000055d991911869 in mirror_exit (job=0x55d993fef830, opaque=0x55d999bbefe0) at block/mirror.c:376 + to_replace = 0x55d993ed9c10 + s = 0x55d993fef830 + data = 0x55d999bbefe0 + replace_aio_context = <optimized out> + src = 0x55d993ed9c10 +#6 0x000055d9918da1dc in block_job_defer_to_main_loop_bh (opaque=0x55d9940ce850) at blockjob.c:481 + data = 0x55d9940ce850 + aio_context = 0x55d9931a2610 +#7 0x000055d9918d014b in aio_bh_poll (ctx=ctx@entry=0x55d9931a2610) at async.c:92 + bh = <optimized out> + bhp = <optimized out> + next = 0x55d99440f910 + ret = 1 +#8 0x000055d9918dc8c0 in aio_dispatch (ctx=0x55d9931a2610) at aio-posix.c:305 + node = <optimized out> + progress = false +#9 0x000055d9918d000e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at async.c:231 + ctx = <optimized out> +#10 0x00007fd8037cf787 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 +#11 0x000055d9918db03b in main_loop_wait () at main-loop.c:211 + context = 0x55d9931a3200 + pfds = <optimized out> + ret = 0 + spin_counter = 1 + ret = 0 + timeout = 4294967295 + timeout_ns = <optimized out> +#12 0x000055d9918db03b in main_loop_wait (timeout=<optimized out>) at main-loop.c:256 + ret = 0 + spin_counter = 1 + ret = 0 + timeout = 4294967295 + timeout_ns = <optimized out> +#13 0x000055d9918db03b in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:504 + ret = 0 + timeout = 4294967295 + timeout_ns = <optimized out> +#14 0x000055d991679cc4 in main () at vl.c:1923 + nonblocking = <optimized out> + last_io = 2 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = <optimized out> + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + hda_opts = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + olist = <optimized out> + optind = 49 + optarg = 0x7fffc6d27f43 "timestamp=on" + loadvm = <optimized out> + machine_class = 0x55d993194d10 + cpu_model = <optimized out> + vga_model = 0x0 + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = false + log_mask = <optimized out> + log_file = <optimized out> + trace_events = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + __func__ = "main" +#15 0x000055d991679cc4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4699 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = <optimized out> + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + hda_opts = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + icount_opts = <optimized out> + olist = <optimized out> + optind = 49 + optarg = 0x7fffc6d27f43 "timestamp=on" + loadvm = <optimized out> + machine_class = 0x55d993194d10 + cpu_model = <optimized out> + vga_model = 0x0 + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = false + log_mask = <optimized out> + log_file = <optimized out> + trace_events = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + __func__ = "main" + + + +I can reproduce this at will, and can provide more information per a dev's request. + +On Wed, 04/13 23:18, Matthew Schumacher wrote: +> I can reproduce this at will, and can provide more information per a +> dev's request. + +Could you please try v2.6.0-rc1? + +Fam + + +Sure, I did the same test and still got a SIGABRT, but the debug looks a little different: + +Backtrace: + +#0 0x00007f8f0d46a3f8 in raise () at /lib64/libc.so.6 +#1 0x00007f8f0d46bffa in abort () at /lib64/libc.so.6 +#2 0x00007f8f0d462c17 in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007f8f0d462cc2 in () at /lib64/libc.so.6 +#4 0x000055ff4ce33926 in mirror_run (s=0x55ff4fc00dd0) at block/mirror.c:335 + next_sector = 31174784 + next_chunk = 243553 + nb_chunks = 29 + end = 209715200 + sectors_per_chunk = 128 + source = 0x55ff4e1eb050 + sector_num = 31171072 + delay_ns = 0 + delay_ns = 0 + cnt = 157184 + should_complete = <optimized out> + s = 0x55ff4fc00dd0 + data = <optimized out> + bs = 0x55ff4e1eb050 + sector_num = <optimized out> + end = <optimized out> + length = <optimized out> + last_pause_ns = <optimized out> + bdi = {cluster_size = 65536, vm_state_offset = 107374182400, is_dirty = false, unallocated_blocks_are_zero = true, can_write_zeroes_with_unmap = true, needs_compressed_writes = false} + backing_filename = "\000\021" + ret = <optimized out> + n = 1048576 + target_cluster_size = <optimized out> + __PRETTY_FUNCTION__ = "mirror_run" +#5 0x000055ff4ce33926 in mirror_run (opaque=0x55ff4fc00dd0) at block/mirror.c:613 + delay_ns = 0 + cnt = 157184 + should_complete = <optimized out> + s = 0x55ff4fc00dd0 + data = <optimized out> + bs = 0x55ff4e1eb050 + sector_num = <optimized out> + end = <optimized out> + length = <optimized out> + last_pause_ns = <optimized out> + bdi = {cluster_size = 65536, vm_state_offset = 107374182400, is_dirty = false, unallocated_blocks_are_zero = true, can_write_zeroes_with_unmap = true, needs_compressed_writes = false} + backing_filename = "\000\021" + ret = <optimized out> + n = 1048576 + target_cluster_size = <optimized out> + __PRETTY_FUNCTION__ = "mirror_run" +#6 0x000055ff4ce9968a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78 + self = 0x55ff4f6c2c80 + co = 0x55ff4f6c2c80 +#7 0x00007f8f0d47f560 in __start_context () at /lib64/libc.so.6 +#8 0x00007ffc759cb060 in () +#9 0x0000000000000000 in () + +I get this in the log: + +qemu-system-x86_64: block/mirror.c:335: mirror_iteration: Assertion `hbitmap_next == next_sector' failed. + + +The system was compiled like this: + +Install prefix /usr +BIOS directory /usr/share/qemu +binary directory /usr/bin +library directory /usr/lib64 +module directory /usr/lib64/qemu +libexec directory /usr/libexec +include directory /usr/include +config directory /etc +local state directory /var +Manual directory /usr/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /tmp/qemu-2.6.0-rc1 +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler clang +ARFLAGS rv +CFLAGS -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -O2 -fPIC +QEMU_CFLAGS -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt -DHAS_LIBSSH2_SFTP_FSYNC -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/spice-1 -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -L/usr/lib64 +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU x86_64 +host big endian no +target list x86_64-softmmu i386-softmmu +tcg debug enabled yes +gprof enabled no +sparse enabled no +strip binaries no +profiler no +static build no +pixman system +SDL support yes +GTK support yes +GTK GL support no +GNUTLS support yes +GNUTLS hash yes +GNUTLS rnd yes +libgcrypt no +libgcrypt kdf no +nettle yes (3.2) +nettle kdf yes +libtasn1 yes +VTE support yes +curses support yes +virgl support no +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support no +Documentation yes +PIE yes +vde support no +netmap support no +Linux AIO support yes +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support yes +libcap-ng support yes +vhost-net support yes +vhost-scsi support yes +Trace backends log +spice support yes (0.12.10/0.12.6) +rbd support no +xfsctl support yes +smartcard support yes +libusb yes +usb net redir no +OpenGL support yes +OpenGL dmabufs yes +libiscsi support yes +libnfs support no +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support yes +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support yes +TPM passthrough yes +QOM debugging yes +vhdx yes +lzo support yes +snappy support no +bzip2 support yes +NUMA host support no +tcmalloc support no +jemalloc support no +avx2 optimization yes + +I'm going to try and put the VM on an EXT4 partition and see if I can duplicate the issue. It might be related to ZFS. + +It still fails with ext4: + +#0 0x00007fbaa12b33f8 in raise () at /lib64/libc.so.6 +#1 0x00007fbaa12b4ffa in abort () at /lib64/libc.so.6 +#2 0x00007fbaa12abc17 in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007fbaa12abcc2 in () at /lib64/libc.so.6 +#4 0x00005646b990f926 in mirror_run (s=0x5646bc50f480) at block/mirror.c:335 + next_sector = 36659200 + next_chunk = 286400 + nb_chunks = 80 + end = 209715200 + sectors_per_chunk = 128 + source = 0x5646bcb70000 + sector_num = 36648960 + delay_ns = 0 + delay_ns = 0 + cnt = 15360 + should_complete = <optimized out> + s = 0x5646bc50f480 + data = <optimized out> + bs = 0x5646bcb70000 + sector_num = <optimized out> + end = <optimized out> + length = <optimized out> + last_pause_ns = <optimized out> + bdi = {cluster_size = 65536, vm_state_offset = 107374182400, is_dirty = false, unallocated_blocks_are_zero = true, can_write_zeroes_with_unmap = true, needs_compressed_writes = false} + backing_filename = "\000" + ret = <optimized out> + n = 1048576 + target_cluster_size = <optimized out> + __PRETTY_FUNCTION__ = "mirror_run" +#5 0x00005646b990f926 in mirror_run (opaque=0x5646bc50f480) at block/mirror.c:613 + delay_ns = 0 + cnt = 15360 + should_complete = <optimized out> + s = 0x5646bc50f480 + data = <optimized out> + bs = 0x5646bcb70000 + sector_num = <optimized out> + end = <optimized out> + length = <optimized out> + last_pause_ns = <optimized out> + bdi = {cluster_size = 65536, vm_state_offset = 107374182400, is_dirty = false, unallocated_blocks_are_zero = true, can_write_zeroes_with_unmap = true, needs_compressed_writes = false} + backing_filename = "\000" + ret = <optimized out> + n = 1048576 + target_cluster_size = <optimized out> + __PRETTY_FUNCTION__ = "mirror_run" +#6 0x00005646b997568a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78 + self = 0x5646bc5115b0 + co = 0x5646bc5115b0 +#7 0x00007fbaa12c8560 in __start_context () at /lib64/libc.so.6 +#8 0x00005646bd2b98b0 in () +#9 0x0000000000000000 in () + +qemu-system-x86_64: block/mirror.c:335: mirror_iteration: Assertion `hbitmap_next == next_sector' failed. + + +I can't seem to get stable snapshotting and blockpull with a loaded VM. + +Interestingly enough, the last command libvirt passes to qemu is: + +2016-04-14 20:47:58.196+0000: 18932: debug : qemuMonitorJSONCommandWithFd:294 : Send command '{"execute":"query-block-jobs","id":"libvirt-69"}' for write with FD -1 +2016-04-14 20:47:58.196+0000: 18932: info : qemuMonitorSend:1005 : QEMU_MONITOR_SEND_MSG: mon=0x7f1874001a30 msg={"execute":"query-block-jobs","id":"libvirt-69"} +2016-04-14 20:47:58.197+0000: 18929: info : qemuMonitorIOWrite:529 : QEMU_MONITOR_IO_WRITE: mon=0x7f1874001a30 buf={"execute":"query-block-jobs","id":"libvirt-69"} + + +Odd that it would SIGABRT on a smile query-block-jobs. + +Even more interesting is that it crashes on the first or second or third snapshot/block-commit cycle when using EXT4, but would sometimes go for 30-40 cycles on ZFS. + +Any ideas? I'm certainly willing to test and help in any way I can. + +Thanks! + +I just tested master, and it does the same as 2.6.0-rc.... + +The 2.6.0 branch crashes much faster than 2.5.x + +Hi Matthew, + +Thank you for your report! Could you try again with these two patches applied? Alternatively, you may fetch the resulting tree from https://github.com/XanClic/qemu.git, branch lp-1570134-pl (https://github.com/XanClic/qemu/archive/lp-1570134-pl.zip). + +Max + +And the second patch, because I'm either too stupid to make Launchpad attach two files to a single comment, or because Launchpad actually doesn't want me to for some reason. + +Thank you for working on this. Super helpful to have someone looking at this issue! + +With those two patches applied to 2.6.0-rc2 I still get the following: + +qemu-system-x86_64: block/mirror.c:342: mirror_iteration: Assertion `hbitmap_next == next_sector' failed. + +The line number confirms that qemu was patched before it was compiled. Here is the full backtrace: + +#0 0x00007f4e5aa213f8 in raise () at /lib64/libc.so.6 +#1 0x00007f4e5aa22ffa in abort () at /lib64/libc.so.6 +#2 0x00007f4e5aa19c17 in __assert_fail_base () at /lib64/libc.so.6 +#3 0x00007f4e5aa19cc2 in () at /lib64/libc.so.6 +#4 0x0000564d5afc1dab in mirror_run (s=0x564d5eb9c2d0) at block/mirror.c:342 + hbitmap_next = <optimized out> + next_sector = 29561984 + next_chunk = 230953 + nb_chunks = 4 + end = 209715200 + sectors_per_chunk = 128 + source = 0x564d5d273b00 + sector_num = 29561472 + delay_ns = 0 + delay_ns = 0 + cnt = <optimized out> + should_complete = <optimized out> + s = 0x564d5eb9c2d0 + data = <optimized out> + bs = 0x564d5d273b00 + sector_num = <optimized out> + end = <optimized out> + length = <optimized out> + last_pause_ns = <optimized out> + bdi = + {cluster_size = 65536, vm_state_offset = 107374182400, is_dirty = false, unallocated_blocks_are_zero = true, can_write_zeroes_with_unmap = true, needs_compressed_writes = false} + backing_filename = "\000\060" + ret = <optimized out> + n = 1048576 + target_cluster_size = <optimized out> + __PRETTY_FUNCTION__ = "mirror_run" +#5 0x0000564d5afc1dab in mirror_run (opaque=0x564d5eb9c2d0) at block/mirror.c:619 + delay_ns = 0 + cnt = <optimized out> + should_complete = <optimized out> + s = 0x564d5eb9c2d0 + data = <optimized out> + bs = 0x564d5d273b00 + sector_num = <optimized out> + end = <optimized out> + length = <optimized out> + last_pause_ns = <optimized out> + bdi = + {cluster_size = 65536, vm_state_offset = 107374182400, is_dirty = false, unallocated_blocks_are_zero = true, can_write_zeroes_with_unmap = true, needs_compressed_writes = false} + backing_filename = "\000\060" + ret = <optimized out> + n = 1048576 + target_cluster_size = <optimized out> + __PRETTY_FUNCTION__ = "mirror_run" +#6 0x0000564d5b027e4a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78 + self = 0x564d5eacc520 + co = 0x564d5eacc520 +#7 0x00007f4e5aa36560 in __start_context () at /lib64/libc.so.6 +#8 0x00007ffc151258c0 in () +#9 0x0000000000000000 in () + + +Hi Matthew, + +I now reproduced the issue myself, and it appears the second patch just missed one little thing. The attached patch (together with patch 1 from above) fixes the problem for me. + +(Also available from https://github.com/XanClic/qemu.git, branch lp-1570134-pl2; archive: https://github.com/XanClic/qemu/archive/lp-1570134-pl2.zip) + +While it was probably more or less noticed by chance (this is most likely a different issue than the one in 2.5.1), thank you for bringing this up. 2.6.0 is close to release, so it's good that this issue was still found. + +Max + +Max, + +Qemu still crashes for me, but the debug is again very different. When I attach to the qemu process from gdb, it is unable to provide a backtrace when it crashes. The log file is different too. Any ideas? + +qemu-system-x86_64: block.c:2307: bdrv_replace_in_backing_chain: Assertion `!bdrv_requests_pending(old)' failed. + +(gdb) attach 5563 +Attaching to process 5563 +Reading symbols from /usr/bin/qemu-system-x86_64...cdone. +oReading symbols from /usr/lib64/libepoxy.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libdrm.so.2...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgbm.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libX11.so.6...n(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libz.so.1...(no debugging symbols found)...done. +Reading symbols from /lib64/libaio.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libiscsi.so.4...done. +Reading symbols from /usr/lib64/libcurl.so.4...(no debugging symbols found)...done. +Reading symbols from /lib64/libacl.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgfapi.so.0...done. +Reading symbols from /usr/lib64/libglusterfs.so.0...done. +Reading symbols from /usr/lib64/libgfrpc.so.0...done. +Reading symbols from /usr/lib64/libgfxdr.so.0...done. +Reading symbols from /lib64/libuuid.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libssh2.so.1...done. +Reading symbols from /lib64/libbz2.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libpixman-1.so.0...(no debugging symbols found)...done. +Reading symbols from /lib64/libutil.so.1...(no debugging symbols found)...done. +Reading symbols from /lib64/libncurses.so.5...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libpng16.so.16...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libjpeg.so.62...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libsasl2.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libSDL-1.2.so.0...(no debugging symbols found)...done. +Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. +[New LWP 5588] +[New LWP 5587] +[New LWP 5586] +[New LWP 5585] +[New LWP 5584] +[New LWP 5583] +[New LWP 5582] +[New LWP 5581] +[New LWP 5580] +[New LWP 5579] +[New LWP 5578] +[New LWP 5577] +[New LWP 5576] +[New LWP 5575] +[New LWP 5574] +[New LWP 5573] +[New LWP 5572] +[New LWP 5571] +[New LWP 5570] +[New LWP 5568] +[New LWP 5567] +[New LWP 5566] +[New LWP 5564] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Reading symbols from /usr/lib64/libvte.so.9...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgtk-x11-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgdk-x11-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libpangocairo-1.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libatk-1.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgdk_pixbuf-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libpangoft2-1.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libpango-1.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libfontconfig.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libfreetype.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgio-2.0.so.0...t(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgobject-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libglib-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libcairo.so.2...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libXext.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libnettle.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgnutls.so.30...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/liblzo2.so.2...done. +Reading symbols from /usr/lib64/libspice-server.so.1...done. +Reading symbols from /usr/lib64/libcacard.so.0...done. +Reading symbols from /usr/lib64/libusb-1.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgthread-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libstdc++.so.6...(no debugging symbols found)...done. +Reading symbols from /lib64/libm.so.6...i(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgcc_s.so.1...(no debugging symbols found)...done. +Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. +Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. +Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libexpat.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libxcb.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libXau.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libXdmcp.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgcrypt.so.20...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgpg-error.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libidn.so.11...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libssl.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libcrypto.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/liblber-2.4.so.2...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libldap-2.4.so.2...(no debugging symbols found)...done. +Reading symbols from /lib64/libattr.so.1...(no debugging symbols found)...done. +Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libXrandr.so.2...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libXrender.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libvga.so.1...done. +Reading symbols from /usr/lib64/../lib64/libgmodule-2.0.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libffi.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libharfbuzz.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libEGL.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-shm.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libGL.so.1...n(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libglapi.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXdamage.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXfixes.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libX11-xcb.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-glx.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-dri2.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-dri3.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-present.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-randr.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-xfixes.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-render.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-shape.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxcb-sync.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libxshmfence.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXxf86vm.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXinerama.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXi.so.6...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXcursor.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/../lib64/libXcomposite.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libp11-kit.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libhogweed.so.4...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgmp.so.10...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libnss3.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libsmime3.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libssl3.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libsoftokn3.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libnssutil3.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libplds4.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libplc4.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libnspr4.so...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libsqlite3.so.0...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libicui18n.so.56...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libicuuc.so.56...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libicudata.so.56...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libcelt051.so.0...done. +Reading symbols from /usr/lib64/liblz4.so.1...(no debugging symbols found)...done. +Reading symbols from /lib64/libudev.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/libsasldb.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/libgdbm.so.4...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/libotp.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/libdigestmd5.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/libcrammd5.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/liblogin.so.3...(no debugging symbols found)...done. +Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/libplain.so.3...(no debugging symbols found)...done. +Reading symbols from /usr/lib64/sasl2/libscram.so.3...(no debugging symbols found)...done. +0x00007f12852f83d1 in ppoll () from /lib64/libc.so.6 +(gdb) continue +Continuing. + + +[Thread 0x7f115b7fe700 (LWP 5576) exited] +[Thread 0x7f127aa76700 (LWP 5566) exited] +[Thread 0x7f1159ffb700 (LWP 5579) exited] +[Thread 0x7f115affd700 (LWP 5577) exited] +[Thread 0x7f116a0e2700 (LWP 5571) exited] +[Thread 0x7f1158ff9700 (LWP 5581) exited] +[Thread 0x7f11690e0700 (LWP 5573) exited] +[Thread 0x7f11597fa700 (LWP 5580) exited] +[Thread 0x7f115bfff700 (LWP 5575) exited] +[Thread 0x7f11688df700 (LWP 5574) exited] +[Thread 0x7f115a7fc700 (LWP 5578) exited] +[Thread 0x7f11698e1700 (LWP 5572) exited] + + + +[New Thread 0x7f11698e1700 (LWP 5631)] +[New Thread 0x7f115a7fc700 (LWP 5632)] +[New Thread 0x7f11688df700 (LWP 5633)] +[New Thread 0x7f115bfff700 (LWP 5634)] +[New Thread 0x7f127aa76700 (LWP 5635)] +[New Thread 0x7f116a0e2700 (LWP 5636)] +[New Thread 0x7f11690e0700 (LWP 5637)] +[New Thread 0x7f115b7fe700 (LWP 5638)] +[New Thread 0x7f115affd700 (LWP 5639)] +[New Thread 0x7f1159ffb700 (LWP 5640)] +[New Thread 0x7f11597fa700 (LWP 5641)] +[New Thread 0x7f1158ff9700 (LWP 5642)] +[New Thread 0x7f1117fff700 (LWP 5643)] +[New Thread 0x7f11177fe700 (LWP 5644)] +[New Thread 0x7f1116ffd700 (LWP 5645)] +[New Thread 0x7f11167fc700 (LWP 5646)] +[New Thread 0x7f1115ffb700 (LWP 5647)] +[New Thread 0x7f11157fa700 (LWP 5648)] +[New Thread 0x7f1114ff9700 (LWP 5649)] +[New Thread 0x7f11147f8700 (LWP 5650)] +[New Thread 0x7f1113ff7700 (LWP 5651)] +[New Thread 0x7f11137f6700 (LWP 5652)] +[New Thread 0x7f1112ff5700 (LWP 5653)] + +Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted. +0x00007f12852323f8 in raise () from /lib64/libc.so.6 +(gdb) +Continuing. +Couldn't get registers: No such process. +Couldn't get registers: No such process. +Couldn't get registers: No such process. +(gdb) +Continuing. +Couldn't get registers: No such process. +(gdb) [Thread 0x7f1112ff5700 (LWP 5653) exited] +[Thread 0x7f11137f6700 (LWP 5652) exited] +[Thread 0x7f1113ff7700 (LWP 5651) exited] +[Thread 0x7f11147f8700 (LWP 5650) exited] +[Thread 0x7f1114ff9700 (LWP 5649) exited] +[Thread 0x7f11157fa700 (LWP 5648) exited] +[Thread 0x7f1115ffb700 (LWP 5647) exited] +[Thread 0x7f1116ffd700 (LWP 5645) exited] +[Thread 0x7f11177fe700 (LWP 5644) exited] +[Thread 0x7f1117fff700 (LWP 5643) exited] +[Thread 0x7f1158ff9700 (LWP 5642) exited] +[Thread 0x7f11597fa700 (LWP 5641) exited] +[Thread 0x7f1159ffb700 (LWP 5640) exited] +[Thread 0x7f115affd700 (LWP 5639) exited] +[Thread 0x7f115b7fe700 (LWP 5638) exited] +[Thread 0x7f11690e0700 (LWP 5637) exited] +[Thread 0x7f116a0e2700 (LWP 5636) exited] +[Thread 0x7f127aa76700 (LWP 5635) exited] +[Thread 0x7f115bfff700 (LWP 5634) exited] +[Thread 0x7f11688df700 (LWP 5633) exited] +[Thread 0x7f115a7fc700 (LWP 5632) exited] +[Thread 0x7f11698e1700 (LWP 5631) exited] +[Thread 0x7f1134ff9700 (LWP 5588) exited] +[Thread 0x7f11357fa700 (LWP 5587) exited] +[Thread 0x7f1135ffb700 (LWP 5586) exited] +[Thread 0x7f11367fc700 (LWP 5585) exited] +[Thread 0x7f1136ffd700 (LWP 5584) exited] +[Thread 0x7f11377fe700 (LWP 5583) exited] +[Thread 0x7f1137fff700 (LWP 5582) exited] +[Thread 0x7f1272dff700 (LWP 5570) exited] +[Thread 0x7f1278961700 (LWP 5568) exited] +[Thread 0x7f1279162700 (LWP 5567) exited] +[Thread 0x7f127b277700 (LWP 5564) exited] +[Thread 0x7f128d35cb00 (LWP 5563) exited] + +Continuing. +Cannot execute this command without a live selected thread. +(gdb) +Continuing. +Cannot execute this command without a live selected thread. +(gdb) +Continuing. +Cannot execute this command without a live selected thread. +(gdb) + +On Wed, 04/20 22:03, Max Reitz wrote: +> On 20.04.2016 20:09, Max Reitz wrote: +> > On 20.04.2016 02:03, Matthew Schumacher wrote: +> >> Max, +> >> +> >> Qemu still crashes for me, but the debug is again very different. When +> >> I attach to the qemu process from gdb, it is unable to provide a +> >> backtrace when it crashes. The log file is different too. Any ideas? +> >> +> >> qemu-system-x86_64: block.c:2307: bdrv_replace_in_backing_chain: +> >> Assertion `!bdrv_requests_pending(old)' failed. +> > +> > This message is exactly the same as you saw in 2.5.1, so I guess we've +> > at least averted a regression in 2.6.0. +> +> I get the same message in 2.5.0, in 2.4.0 it's "Co-routine re-entered +> recursively". 2.3.0 works fine. +> +> Bisecting the regression between 2.3.0 and 2.4.0 interestingly yields +> 48ac0a4df84662f as the problematic commit, but I can't imagine that this +> is the root issue. The effective change it brings is that for active +> commits, the buf_size is no longer the same as the granularity, but the +> default mirror buf_size instead. +> +> When forcing buf_size to the granularity, the issue first appears with +> commit 3f09bfbc7bee812 (after 2.4.0, before 2.5.0), which is much less +> surprising, because this is the one that introduced the assertion in the +> first place. +> +> However, I still don't think the assertion is the problem but the fact +> that the guest device can still send requests after bdrv_drained_begin(). + +Thanks for debugging this. + +bdrv_drained_begin isn't effective because the guest notifier handler is not +registered as "external": + + virtio_queue_set_host_notifier_fd_handler + event_notifier_set_handler + qemu_set_fd_handler + aio_set_fd_handler(ctx, fd, + is_external, /* false */ + ...) + + +is_external SHOULD be true here. + + +On Thu, 04/21 08:34, Fam Zheng wrote: +> On Wed, 04/20 22:03, Max Reitz wrote: +> > On 20.04.2016 20:09, Max Reitz wrote: +> > > On 20.04.2016 02:03, Matthew Schumacher wrote: +> > >> Max, +> > >> +> > >> Qemu still crashes for me, but the debug is again very different. When +> > >> I attach to the qemu process from gdb, it is unable to provide a +> > >> backtrace when it crashes. The log file is different too. Any ideas? +> > >> +> > >> qemu-system-x86_64: block.c:2307: bdrv_replace_in_backing_chain: +> > >> Assertion `!bdrv_requests_pending(old)' failed. +> > > +> > > This message is exactly the same as you saw in 2.5.1, so I guess we've +> > > at least averted a regression in 2.6.0. +> > +> > I get the same message in 2.5.0, in 2.4.0 it's "Co-routine re-entered +> > recursively". 2.3.0 works fine. +> > +> > Bisecting the regression between 2.3.0 and 2.4.0 interestingly yields +> > 48ac0a4df84662f as the problematic commit, but I can't imagine that this +> > is the root issue. The effective change it brings is that for active +> > commits, the buf_size is no longer the same as the granularity, but the +> > default mirror buf_size instead. +> > +> > When forcing buf_size to the granularity, the issue first appears with +> > commit 3f09bfbc7bee812 (after 2.4.0, before 2.5.0), which is much less +> > surprising, because this is the one that introduced the assertion in the +> > first place. +> > +> > However, I still don't think the assertion is the problem but the fact +> > that the guest device can still send requests after bdrv_drained_begin(). +> +> Thanks for debugging this. +> +> bdrv_drained_begin isn't effective because the guest notifier handler is not +> registered as "external": +> +> virtio_queue_set_host_notifier_fd_handler +> event_notifier_set_handler +> qemu_set_fd_handler +> aio_set_fd_handler(ctx, fd, +> is_external, /* false */ +> ...) +> +> +> is_external SHOULD be true here. +> + +This patch survives the reproducer I have on top of master (also submitted to +qemu-devel for 2.6): + +--- + +diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c +index f745c4a..002c2c6 100644 +--- a/hw/virtio/virtio.c ++++ b/hw/virtio/virtio.c +@@ -1829,10 +1829,11 @@ void virtio_queue_set_host_notifier_fd_handler(VirtQueue *vq, bool assign, + bool set_handler) + { + if (assign && set_handler) { +- event_notifier_set_handler(&vq->host_notifier, +- virtio_queue_host_notifier_read); ++ aio_set_event_notifier(qemu_get_aio_context(), &vq->host_notifier, ++ true, virtio_queue_host_notifier_read); + } else { +- event_notifier_set_handler(&vq->host_notifier, NULL); ++ aio_set_event_notifier(qemu_get_aio_context(), &vq->host_notifier, ++ true, NULL); + } + if (!assign) { + /* Test and clear notifier before after disabling event, + + + +On 20 April 2016 at 19:09, Max Reitz <email address hidden> wrote: +> On 20.04.2016 02:03, Matthew Schumacher wrote: +>> Qemu still crashes for me, but the debug is again very different. When +>> I attach to the qemu process from gdb, it is unable to provide a +>> backtrace when it crashes. The log file is different too. Any ideas? +>> +>> qemu-system-x86_64: block.c:2307: bdrv_replace_in_backing_chain: +>> Assertion `!bdrv_requests_pending(old)' failed. +> +> This message is exactly the same as you saw in 2.5.1, so I guess we've +> at least averted a regression in 2.6.0. + +Could somebody summarize for me the state of this bug w.r.t. the +upcoming release? In particular: + * are there any patches on-list for it which should go into rc3? + * are there any further problems which we plan to fix for 2.6 but + which there aren't patches for yet? + +thanks +-- PMM + + +Am 21.04.2016 um 13:35 hat Peter Maydell geschrieben: +> On 20 April 2016 at 19:09, Max Reitz <email address hidden> wrote: +> > On 20.04.2016 02:03, Matthew Schumacher wrote: +> >> Qemu still crashes for me, but the debug is again very different. When +> >> I attach to the qemu process from gdb, it is unable to provide a +> >> backtrace when it crashes. The log file is different too. Any ideas? +> >> +> >> qemu-system-x86_64: block.c:2307: bdrv_replace_in_backing_chain: +> >> Assertion `!bdrv_requests_pending(old)' failed. +> > +> > This message is exactly the same as you saw in 2.5.1, so I guess we've +> > at least averted a regression in 2.6.0. +> +> Could somebody summarize for me the state of this bug w.r.t. the +> upcoming release? In particular: +> * are there any patches on-list for it which should go into rc3? +> * are there any further problems which we plan to fix for 2.6 but +> which there aren't patches for yet? + +The first part of the bug (the regression since 2.5) was fixed with the +pull request that I sent you yesterday. For the remaining part, Fam sent +this patch, which hasn't been applied yet: + +[PATCH for-2.6] virtio: Register host notifier handler as external + +Kevin + + +Running master as of this morning 4/22 and I'm not getting any more crashes, and I'm flat beating on it. RC3 still crashes on me, so whatever the fix is, came after rc3. + +On Fri, 04/22 18:55, Matthew Schumacher wrote: +> Running master as of this morning 4/22 and I'm not getting any more +> crashes, and I'm flat beating on it. RC3 still crashes on me, so +> whatever the fix is, came after rc3. + +Matthew, It was bcd82a9..ab27c3b from last Friday (yes, after -rc3). + +Thank you so much for your reporting and testing. + +Fam + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1570134 +> +> Title: +> While committing snapshot qemu crashes with SIGABRT +> +> Status in QEMU: +> New +> +> Bug description: +> Information: +> +> OS: Slackware64-Current +> Compiled with: gcc version 5.3.0 (GCC) / glibc 2.23 +> Compiled using: +> +> CFLAGS="-O2 -fPIC" \ +> CXXFLAGS="-O2 -fPIC" \ +> LDFLAGS="-L/usr/lib64" \ +> ./configure \ +> --prefix=/usr \ +> --sysconfdir=/etc \ +> --localstatedir=/var \ +> --libdir=/usr/lib64 \ +> --enable-spice \ +> --enable-kvm \ +> --enable-glusterfs \ +> --enable-libiscsi \ +> --enable-libusb \ +> --target-list=x86_64-softmmu,i386-softmmu \ +> --enable-debug +> +> Source: qemu-2.5.1.tar.bz2 +> +> Running as: +> +> /usr/bin/qemu-system-x86_64 -name test1,debug-threads=on -S -machine +> pc-1.1,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp +> 2,sockets=2,cores=1,threads=1 -uuid +> 4b30ec13-6609-4a56-8731-d400c38189ef -no-user-config -nodefaults +> -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-test1/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc +> base=localtime,clock=vm,driftfix=slew -global kvm- +> pit.lost_tick_policy=discard -no-shutdown -boot strict=on -device +> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive +> file=/datastore/vm/test1/test1.img,format=qcow2,if=none,id=drive- +> virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive +> =drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id +> =drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive +> =drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev +> tap,fd=23,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net +> pci,netdev=hostnet0,id=net0,mac=52:54:00:66:2e:0f,bus=pci.0,addr=0x3 +> -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device +> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on +> +> File system: zfs v0.6.5.6 +> +> While running: +> virsh blockcommit test1 vda --active --pivot --verbose +> +> VM running very heavy IO load +> +> GDB reporting: +> +> #0 0x00007fd80132c3f8 in raise () at /lib64/libc.so.6 +> #1 0x00007fd80132dffa in abort () at /lib64/libc.so.6 +> #2 0x00007fd801324c17 in __assert_fail_base () at /lib64/libc.so.6 +> #3 0x00007fd801324cc2 in () at /lib64/libc.so.6 +> #4 0x000055d9918d7572 in bdrv_replace_in_backing_chain (old=0x55d993ed9c10, new=0x55d9931ccc10) at block.c:2096 +> __PRETTY_FUNCTION__ = "bdrv_replace_in_backing_chain" +> #5 0x000055d991911869 in mirror_exit (job=0x55d993fef830, opaque=0x55d999bbefe0) at block/mirror.c:376 +> to_replace = 0x55d993ed9c10 +> s = 0x55d993fef830 +> data = 0x55d999bbefe0 +> replace_aio_context = <optimized out> +> src = 0x55d993ed9c10 +> #6 0x000055d9918da1dc in block_job_defer_to_main_loop_bh (opaque=0x55d9940ce850) at blockjob.c:481 +> data = 0x55d9940ce850 +> aio_context = 0x55d9931a2610 +> #7 0x000055d9918d014b in aio_bh_poll (ctx=ctx@entry=0x55d9931a2610) at async.c:92 +> bh = <optimized out> +> bhp = <optimized out> +> next = 0x55d99440f910 +> ret = 1 +> #8 0x000055d9918dc8c0 in aio_dispatch (ctx=0x55d9931a2610) at aio-posix.c:305 +> node = <optimized out> +> progress = false +> #9 0x000055d9918d000e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at async.c:231 +> ctx = <optimized out> +> #10 0x00007fd8037cf787 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 +> #11 0x000055d9918db03b in main_loop_wait () at main-loop.c:211 +> context = 0x55d9931a3200 +> pfds = <optimized out> +> ret = 0 +> spin_counter = 1 +> ret = 0 +> timeout = 4294967295 +> timeout_ns = <optimized out> +> #12 0x000055d9918db03b in main_loop_wait (timeout=<optimized out>) at main-loop.c:256 +> ret = 0 +> spin_counter = 1 +> ret = 0 +> timeout = 4294967295 +> timeout_ns = <optimized out> +> #13 0x000055d9918db03b in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:504 +> ret = 0 +> timeout = 4294967295 +> timeout_ns = <optimized out> +> #14 0x000055d991679cc4 in main () at vl.c:1923 +> nonblocking = <optimized out> +> last_io = 2 +> i = <optimized out> +> snapshot = <optimized out> +> linux_boot = <optimized out> +> initrd_filename = <optimized out> +> kernel_filename = <optimized out> +> kernel_cmdline = <optimized out> +> boot_order = <optimized out> +> boot_once = <optimized out> +> ds = <optimized out> +> cyls = <optimized out> +> heads = <optimized out> +> secs = <optimized out> +> translation = <optimized out> +> hda_opts = <optimized out> +> opts = <optimized out> +> machine_opts = <optimized out> +> icount_opts = <optimized out> +> olist = <optimized out> +> optind = 49 +> optarg = 0x7fffc6d27f43 "timestamp=on" +> loadvm = <optimized out> +> machine_class = 0x55d993194d10 +> cpu_model = <optimized out> +> vga_model = 0x0 +> qtest_chrdev = <optimized out> +> qtest_log = <optimized out> +> pid_file = <optimized out> +> incoming = <optimized out> +> defconfig = <optimized out> +> userconfig = false +> log_mask = <optimized out> +> log_file = <optimized out> +> trace_events = <optimized out> +> trace_file = <optimized out> +> maxram_size = <optimized out> +> ram_slots = <optimized out> +> vmstate_dump_file = <optimized out> +> main_loop_err = 0x0 +> err = 0x0 +> __func__ = "main" +> #15 0x000055d991679cc4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4699 +> i = <optimized out> +> snapshot = <optimized out> +> linux_boot = <optimized out> +> initrd_filename = <optimized out> +> kernel_filename = <optimized out> +> kernel_cmdline = <optimized out> +> boot_order = <optimized out> +> boot_once = <optimized out> +> ds = <optimized out> +> cyls = <optimized out> +> heads = <optimized out> +> secs = <optimized out> +> translation = <optimized out> +> hda_opts = <optimized out> +> opts = <optimized out> +> machine_opts = <optimized out> +> icount_opts = <optimized out> +> olist = <optimized out> +> optind = 49 +> optarg = 0x7fffc6d27f43 "timestamp=on" +> loadvm = <optimized out> +> machine_class = 0x55d993194d10 +> cpu_model = <optimized out> +> vga_model = 0x0 +> qtest_chrdev = <optimized out> +> qtest_log = <optimized out> +> pid_file = <optimized out> +> incoming = <optimized out> +> defconfig = <optimized out> +> userconfig = false +> log_mask = <optimized out> +> log_file = <optimized out> +> trace_events = <optimized out> +> trace_file = <optimized out> +> maxram_size = <optimized out> +> ram_slots = <optimized out> +> vmstate_dump_file = <optimized out> +> main_loop_err = 0x0 +> err = 0x0 +> __func__ = "main" +> +> +> I can reproduce this at will, and can provide more information per a +> dev's request. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1570134/+subscriptions +> + + diff --git a/results/classifier/118/review/1571 b/results/classifier/118/review/1571 new file mode 100644 index 000000000..be6fb06f3 --- /dev/null +++ b/results/classifier/118/review/1571 @@ -0,0 +1,72 @@ +architecture: 0.929 +performance: 0.905 +graphic: 0.891 +hypervisor: 0.872 +PID: 0.866 +device: 0.863 +ppc: 0.821 +files: 0.805 +register: 0.801 +TCG: 0.795 +virtual: 0.771 +debug: 0.745 +kernel: 0.684 +socket: 0.675 +risc-v: 0.619 +permissions: 0.597 +vnc: 0.587 +network: 0.582 +semantic: 0.556 +mistranslation: 0.533 +arm: 0.514 +assembly: 0.491 +boot: 0.476 +peripherals: 0.441 +VMM: 0.267 +i386: 0.209 +x86: 0.178 +user-level: 0.154 +KVM: 0.108 +-------------------- +hypervisor: 0.960 +virtual: 0.866 +debug: 0.569 +kernel: 0.513 +files: 0.157 +x86: 0.034 +TCG: 0.033 +register: 0.024 +semantic: 0.022 +architecture: 0.016 +KVM: 0.009 +PID: 0.008 +performance: 0.008 +i386: 0.007 +assembly: 0.006 +VMM: 0.005 +boot: 0.005 +arm: 0.005 +device: 0.004 +ppc: 0.003 +peripherals: 0.003 +user-level: 0.003 +risc-v: 0.002 +permissions: 0.001 +network: 0.001 +graphic: 0.001 +vnc: 0.001 +socket: 0.000 +mistranslation: 0.000 + +accel/hvf: Instance size not properly declared +Description of problem: +In [`include/sysemu/hvf.h`](https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/hvf.h#L36), `HVFState` is declared to have the QOM type `TYPE_HVF_ACCEL`; +However, when the type is registered, proper `instance_size` for it was [not declared](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L351). + +As a result, a bad workaround was introduced. That is, when [`hvf_accel_init`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/hvf/hvf-accel-ops.c#L329) is called from [`accel_init_machine`](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/accel-softmmu.c#L33), an new instance of `HVFState` is allocated while we should have used the pre-allocated instance in `ms->accelerator` similar to [what KVM does](https://gitlab.com/qemu-project/qemu/-/blob/master/accel/kvm/kvm-all.c#L2381) (the code didn't do so since the allocated ([using `object_new_with_class`](https://gitlab.com/qemu-project/qemu/-/blob/master/softmmu/vl.c#L2218)) instance didn't allocate enough memory for `HVFState`). + +Eventhough the code wouldn't crash nor have any serious implication, this would leak an `AccelState` and attempts to manually manage accelerators would cause a buffer-overflow. +Steps to reproduce: +1. Run a HVF-accelerated VM +Additional information: + diff --git a/results/classifier/118/review/1573 b/results/classifier/118/review/1573 new file mode 100644 index 000000000..7335f28fa --- /dev/null +++ b/results/classifier/118/review/1573 @@ -0,0 +1,61 @@ +mistranslation: 0.808 +network: 0.380 +peripherals: 0.333 +device: 0.256 +virtual: 0.200 +semantic: 0.192 +performance: 0.176 +debug: 0.173 +user-level: 0.162 +permissions: 0.144 +arm: 0.101 +boot: 0.096 +architecture: 0.090 +vnc: 0.089 +graphic: 0.088 +risc-v: 0.088 +i386: 0.085 +ppc: 0.083 +register: 0.072 +files: 0.065 +hypervisor: 0.057 +socket: 0.038 +assembly: 0.033 +kernel: 0.033 +PID: 0.017 +x86: 0.014 +KVM: 0.006 +TCG: 0.005 +VMM: 0.004 +-------------------- +network: 0.991 +socket: 0.241 +performance: 0.049 +virtual: 0.047 +debug: 0.043 +user-level: 0.010 +semantic: 0.008 +device: 0.003 +boot: 0.003 +TCG: 0.003 +assembly: 0.003 +files: 0.002 +peripherals: 0.002 +ppc: 0.002 +risc-v: 0.002 +kernel: 0.001 +PID: 0.001 +register: 0.001 +x86: 0.001 +i386: 0.001 +arm: 0.001 +permissions: 0.001 +hypervisor: 0.001 +graphic: 0.000 +mistranslation: 0.000 +vnc: 0.000 +VMM: 0.000 +architecture: 0.000 +KVM: 0.000 + +TCP Previous segment not captured diff --git a/results/classifier/118/review/1577841 b/results/classifier/118/review/1577841 new file mode 100644 index 000000000..f4ca305db --- /dev/null +++ b/results/classifier/118/review/1577841 @@ -0,0 +1,77 @@ +mistranslation: 0.980 +device: 0.850 +files: 0.800 +socket: 0.788 +ppc: 0.781 +semantic: 0.752 +network: 0.711 +TCG: 0.674 +vnc: 0.656 +architecture: 0.624 +PID: 0.622 +peripherals: 0.601 +performance: 0.572 +debug: 0.556 +kernel: 0.548 +graphic: 0.523 +VMM: 0.519 +permissions: 0.510 +arm: 0.504 +assembly: 0.493 +register: 0.487 +boot: 0.441 +i386: 0.422 +x86: 0.396 +hypervisor: 0.360 +user-level: 0.357 +risc-v: 0.353 +KVM: 0.288 +virtual: 0.246 +-------------------- +x86: 0.949 +files: 0.380 +debug: 0.230 +TCG: 0.146 +i386: 0.107 +arm: 0.040 +hypervisor: 0.033 +kernel: 0.021 +register: 0.020 +virtual: 0.019 +ppc: 0.015 +VMM: 0.013 +semantic: 0.012 +device: 0.010 +PID: 0.009 +KVM: 0.007 +performance: 0.006 +boot: 0.005 +risc-v: 0.004 +architecture: 0.004 +user-level: 0.004 +network: 0.003 +peripherals: 0.002 +graphic: 0.002 +socket: 0.001 +assembly: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +target-mips/helper.c:542: bad sizeof ? + +Recent versions of gcc say this: + +qemu/target-mips/helper.c:542:9: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] + +Source code is + + memset(env->CP0_WatchLo, 0, sizeof(*env->CP0_WatchLo)); + +Maybe better code + + memset(env->CP0_WatchLo, 0, 8 * sizeof(target_ulong)); + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=9d989c732b153fe15 + diff --git a/results/classifier/118/review/1579306 b/results/classifier/118/review/1579306 new file mode 100644 index 000000000..dd2fcb91c --- /dev/null +++ b/results/classifier/118/review/1579306 @@ -0,0 +1,132 @@ +mistranslation: 0.887 +semantic: 0.868 +graphic: 0.849 +register: 0.849 +assembly: 0.848 +debug: 0.845 +device: 0.827 +virtual: 0.811 +performance: 0.808 +user-level: 0.805 +permissions: 0.803 +PID: 0.800 +arm: 0.797 +hypervisor: 0.771 +architecture: 0.770 +vnc: 0.765 +socket: 0.762 +x86: 0.745 +KVM: 0.736 +risc-v: 0.722 +peripherals: 0.722 +kernel: 0.708 +network: 0.707 +ppc: 0.705 +boot: 0.702 +files: 0.667 +TCG: 0.658 +VMM: 0.611 +i386: 0.559 +-------------------- +virtual: 0.985 +x86: 0.947 +hypervisor: 0.934 +KVM: 0.917 +user-level: 0.102 +peripherals: 0.091 +device: 0.049 +boot: 0.030 +kernel: 0.024 +files: 0.023 +register: 0.017 +PID: 0.016 +TCG: 0.016 +debug: 0.010 +VMM: 0.009 +socket: 0.008 +semantic: 0.005 +network: 0.004 +architecture: 0.003 +assembly: 0.003 +performance: 0.002 +permissions: 0.002 +risc-v: 0.002 +graphic: 0.001 +ppc: 0.001 +arm: 0.001 +vnc: 0.001 +mistranslation: 0.000 +i386: 0.000 + +usb-uas does not work in Windows (10) guest + +When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest: + +"The device cannot start. (Code 10) + +{Operation Failed} +The requested operation was unsuccessful" + +If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well: + +"qemu-system-x86_64: usb_uas_handle_control: unhandled control request" + +If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side. + + + +usb-bot works fine + +Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either. + +Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well). + +I am using qemu-2.5.1. Here are the commands I used in the test cases: + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-hd,drive=test + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-bot -device scsi-hd,drive=test + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdc,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-block,drive=test + +qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -device nec-usb-xhci -device usb-host,hostbus=2,hostport=6 + +Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either. + +Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well). + +I am also facing this issue. + +On further probing, I found out that usb-uas in Qemu doesn't support "SET_SEL" control command due to which windows driver "uaspstor.sys" couldn't complete the enumeration. + +It is clearly mentioned in USB 3.1 specs that uasp devices should handle two new control commands - SET_SEL and SET_ISOCH_DELAY. + + + +Just echoing Tom Yan's comment; I've tried passing through what appears to be the very same device (if not, at least the same UAS-SATA bridge) to a VM in its entirety. + +I can confirm the same result - with an otherwise identical domain configuration, Linux guests correctly use the UAS driver: + +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + + +Whereas Windows guests fall back to BOT/MSC: + +<see attached image> + + +In both cases, QEMU is being run via libvirt, which is generating the following command line: + +/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on + +I think they are two separate issues in usb-uas and usb-host respectively. I probably should not have bring in the usb-host case here but create another report for it. + +Noted, I've created https://bugs.launchpad.net/qemu/+bug/1648726 to track the issue with passing through physical UAS devices. + +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/review/1579327 b/results/classifier/118/review/1579327 new file mode 100644 index 000000000..ee186c207 --- /dev/null +++ b/results/classifier/118/review/1579327 @@ -0,0 +1,342 @@ +risc-v: 0.817 +mistranslation: 0.815 +user-level: 0.761 +permissions: 0.758 +register: 0.732 +peripherals: 0.730 +hypervisor: 0.723 +x86: 0.719 +debug: 0.714 +ppc: 0.712 +VMM: 0.708 +vnc: 0.706 +assembly: 0.706 +KVM: 0.704 +TCG: 0.700 +device: 0.695 +arm: 0.680 +architecture: 0.669 +graphic: 0.668 +performance: 0.667 +virtual: 0.662 +semantic: 0.644 +boot: 0.626 +PID: 0.619 +kernel: 0.584 +files: 0.578 +socket: 0.566 +i386: 0.542 +network: 0.504 +-------------------- +x86: 0.668 +virtual: 0.434 +boot: 0.222 +i386: 0.187 +arm: 0.178 +debug: 0.155 +TCG: 0.056 +kernel: 0.049 +register: 0.029 +network: 0.022 +assembly: 0.018 +device: 0.016 +files: 0.016 +PID: 0.016 +hypervisor: 0.013 +user-level: 0.011 +semantic: 0.010 +socket: 0.010 +vnc: 0.006 +risc-v: 0.005 +performance: 0.004 +peripherals: 0.004 +VMM: 0.003 +architecture: 0.003 +permissions: 0.002 +ppc: 0.001 +graphic: 0.001 +KVM: 0.001 +mistranslation: 0.001 + +emulation of vexpress-a9 vexpress-a15 in multicore mode seems to be broken + +Report based on: +https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under + +I don't see any bug reports about vexpress boards emulation here, so I decided to let you know: + +version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux + +There are issues with running u-boot on qemu vexpress-a9 ( it was reported to work ok at physical multicore board ) and vexpress-a15 with parameters -smp cores=2 r 3 or 4. +So far those are two tested. I dont know ATM if any other board emulation works in multiprocessor mode + +Original post at stackoverflow: +--------------------------------------------------------------------------------------------------- +I have tried numerous releases of u-boot since vexpress-a9 was introduced in u-bot stable release. Under qemu with multicore emulation its behaving unstable - mostly crashes instantly after loading. Sometimes it loads without issues but its rare. My version of qemu is 2.0.0 on x86 32bit Debian. I would be interested to hear if you succeeded in runing it under qemu with multicore emulation ( if yes which version of qemu and u-boot ) or physical versatile express board with multiple cores. + +Example outputs are + +$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2 +U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19) + +DRAM: 128 MiB +WARNING: Caches not enabled +undefined instruction +pc : [<00000000>] lr : [<00000000>] +sp : 60000ef0 ip : 67eedfd8 fp : 00000000 +r10: 00000000 r9 : 00000000 r8 : 60000f00 +r7 : 00000000 r6 : 608146ac r5 : 60828365 r4 : 0000004d +r3 : 00000000 r2 : 00000000 r1 : 60000f80 r0 : 47cc9e10 +Flags: nzcv IRQs on FIQs on Mode USER_26 +Resetting CPU ... +resetting ... +Flash: 256 MiB +MMC: MMC: 0 +*** Warning - bad CRC, using default environment + +In: serial +Out: serial +Err: serial +Net: smc911x-0 +Warning: smc911x-0 using MAC address from net device + +Hit any key to stop autoboot: 0 +Wrong Image Format for bootm command +ERROR: can't get kernel image! +VExpress# + +This time it was loaded + +Other time it was not... + +$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2 + + +U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19) + +DRAM: 128 MiB +WARNING: Caches not enabled + + +U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19) + +DRAM: 128 MiB +WARNING: Caches not enabled +Flash: 256 MiB +MMC: MMC: 0 +*** Warning - bad CRC, using default environment + +In: serial +Out: serial +Err: serial +Net: smc911x-0 +Warning: smc911x-0 using MAC address from net device + +Hit any key to stop autoboot: 2 qemu: fatal: Trying to execute code outside RAM or ROM at 0x6f71c004 + +R00=00418937 R01=000003e8 R02=00418937 R03=00000000 +R04=00000000 R05=67eedf58 R06=67f8e000 R07=00000002 +R08=00418937 R09=0778e000 R10=6082f688 R11=00000000 +R12=67eedfd8 R13=00000000 R14=67fb82c0 R15=6f71c004 +PSR=200001db --C- A und32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +vs12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +------------------------------------------------------------------------------------------------- +end of post + +Original discussion at ( includes comments of head custodian of Das U-boot about u-boot working on physical board versatile express a9 and him having issues with runing Linux distro at qemu vexpress-a9 board emulation ): +https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under + +On 7 May 2016 at 09:08, embedded0n3 <email address hidden> wrote: +> Public bug reported: +> +> Report based on: +> https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under +> +> I don't see any bug reports about vexpress boards emulation here, so I +> decided to let you know: +> +> version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux + +This version of QEMU is now five major releases old. Please can +you retry with the most recent the QEMU 2.6.0 release candidate, +or with QEMU master from git and see if your problems are still +present? + +thanks +-- PMM + + +Yes, there are still problems on qemu 2.6.0 release candidate and 2.5.1 with same version of u-boot as mentioned and with latest stable u-boot release. When qemu has parameter -smp cores=2 or 3 or 4. + +errors are: +qemu: fatal: Trying to execute code outside RAM or ROM at 0x31306c70 +That adress changes but is mostly close to that example value ("8 digits" adress) +as mentioned in previous posted bugreport + +Sometimes runing U-boot(?) hangs but I can exit qemu using keys Ctrl-a x +And that seems to be new behaviour. + +- - - - - - - - - - - - +If someone is interested how to build u-boot for further testing of this issue on his own box + + $ git clone git://git.denx.de/u-boot.git + $ cd u-boot + $ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi + $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi + + +Sorry, missed '-' character at the end of command obviously. It shaould be: + + $ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- + $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- + + +And if this is not clear - in all cases everything was OK when emulation was started without -smp cors=2 or 3 or 4. By OK i mean there was no + qemu: fatal: Trying to execute code outside RAM or ROM at 0xXXXXXXXX +errors and I was able to execute some comands like help and printenv and nothing happened when qemu was left open for time of 15 minutes ( sometimes in multicoe mulation mode error appeaed after about one and half minute if that time it loaded without almost instant eror message ). + +Does the u-boot binary you're running expect to work with SMP? Usually "Trying to execute code outside RAM or ROM" means "the guest binary did something badly wrong and jumped off to an invalid address", rather than being a QEMU bug. + + +Does -smp cores=4 means qemu is emulaing versatile espress a9 with 4 cores ( this is how versatile express board is designed - i mean it's a board with 4 cores cotex a9 ) and qemu without -smp parameter emalates jus single core ( unicore )? + +In case of versatile express a9 u-boot binary: + +U-boot was compilled from cofig file vexpress_ca9x4 - versatile express cortex a9 4cores + +U-boot configuration file is created to run on physical versatile a9 board. And this was confirmed by Tom Rini ( the head custodian of Das U-boot project as I see on his stackoverflow page ) to run without problems on physical 4 core versatile express a9 board ( see stackoverflow disscussion link in 1st message of this bug report ): + +Here is citation of his comment: + +>I have recently gotten confirmation that the real HW does work on current mainline U-Boot, +> but I can also replicate your failures. Interestingly, the real board is 4 cores, +> and I can (with the kernelci.org Linux kernel / device tree) run with -smp cores=2 +> but 3 and 4 result in soft lockups once userland starts. – Tom Rini 2 days ago + +So he even had more erors as he get further in linux boot process ( I stopped tests so far on just loading u-boot and waiting few minutes if it will fail suddenly, what happend ). As I said errors were quiet random, and sometimes appeard just after more than minute of inactivity, other times almost instantly after boot ). + +On 9 May 2016 at 13:47, embedded0n3 <email address hidden> wrote: +> Does -smp cores=4 means qemu is emulaing versatile espress a9 with 4 +> cores ( this is how versatile express board is designed - i mean it's a +> board with 4 cores cotex a9 ) and qemu without -smp parameter emalates +> jus single core ( unicore )? + +Yes. + +> U-boot configuration file is created to run on physical versatile a9 +> board. And this was confirmed by Tom Rini ( the head custodian of Das +> U-boot project as I see on his stackoverflow page ) to run without +> problems on physical 4 core versatile express a9 board ( see +> stackoverflow disscussion link in 1st message of this bug report ): +> +> Here is citation of his comment: +> +>>I have recently gotten confirmation that the real HW does work on current mainline U-Boot, +>> but I can also replicate your failures. Interestingly, the real board is 4 cores, +>> and I can (with the kernelci.org Linux kernel / device tree) run with -smp cores=2 +>> but 3 and 4 result in soft lockups once userland starts. – Tom Rini 2 days ago +> +> So he even had more erors as he get further in linux boot process ( I +> stopped tests so far on just loading u-boot and waiting few minutes if +> it will fail suddenly, what happend ). As I said errors were quiet +> random, and sometimes appeard just after more than minute of inactivity, +> other times almost instantly after boot ). + +The next phase is that somebody needs to debug what the u-boot code is +doing that causes it to crash (this is largely working with the guest +code, not trying to debug QEMU itself). + +thanks +-- PMM + + +I see. +I can take a look. +Could this procedure be helpfull in this case? Error message was similar but it was related to loading coreboot +http://blog.3mdeb.com/2014/08/07/debugging-coreboot-for-qemu-armv7-vexpress-a9-emulated-mainboard/ +Or there are better tools to do this job? + + +I found another typo In comment from last night about compilling u-boot. +This line + $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- +should look: + $ make all ARCH=arm CROSS_COMPILE=arm-none-eabi- + + +I can confirm this bug with vexpress-a9. +I have tested with the following versions: +QEMU emulator version 2.4.1 (qemu-2.4.1-11.fc23), Copyright (c) 2003-2008 Fabrice Bellard +QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +Here are the reproducing steps: +Get an ARM cross-compiler, and latest u-boot. +$ cd u-boot +$ make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} vexpress_ca9x4_defconfig +$ make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} + +# avoid audio errors +$ export QEMU_AUDIO_DRV=none +$ qemu-system-arm -M vexpress-a9 -m 1024 -smp 4 -nographic -kernel u-boot +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: + +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: + +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: + +U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300) + +DRAM: 1 GiB +WARNING: Caches not enabled +Flash: Bad ram pointer (nil) +Aborted (core dumped) + + +I believe this is not a qemu boot since booting the kernel with -smp 4 works just fine, sorry for the noise + +Sounds like a U-Boot bug. Closing according to comment #11. + diff --git a/results/classifier/118/review/1584 b/results/classifier/118/review/1584 new file mode 100644 index 000000000..7335f28fa --- /dev/null +++ b/results/classifier/118/review/1584 @@ -0,0 +1,61 @@ +mistranslation: 0.808 +network: 0.380 +peripherals: 0.333 +device: 0.256 +virtual: 0.200 +semantic: 0.192 +performance: 0.176 +debug: 0.173 +user-level: 0.162 +permissions: 0.144 +arm: 0.101 +boot: 0.096 +architecture: 0.090 +vnc: 0.089 +graphic: 0.088 +risc-v: 0.088 +i386: 0.085 +ppc: 0.083 +register: 0.072 +files: 0.065 +hypervisor: 0.057 +socket: 0.038 +assembly: 0.033 +kernel: 0.033 +PID: 0.017 +x86: 0.014 +KVM: 0.006 +TCG: 0.005 +VMM: 0.004 +-------------------- +network: 0.991 +socket: 0.241 +performance: 0.049 +virtual: 0.047 +debug: 0.043 +user-level: 0.010 +semantic: 0.008 +device: 0.003 +boot: 0.003 +TCG: 0.003 +assembly: 0.003 +files: 0.002 +peripherals: 0.002 +ppc: 0.002 +risc-v: 0.002 +kernel: 0.001 +PID: 0.001 +register: 0.001 +x86: 0.001 +i386: 0.001 +arm: 0.001 +permissions: 0.001 +hypervisor: 0.001 +graphic: 0.000 +mistranslation: 0.000 +vnc: 0.000 +VMM: 0.000 +architecture: 0.000 +KVM: 0.000 + +TCP Previous segment not captured diff --git a/results/classifier/118/review/1586756 b/results/classifier/118/review/1586756 new file mode 100644 index 000000000..46392ee1c --- /dev/null +++ b/results/classifier/118/review/1586756 @@ -0,0 +1,188 @@ +user-level: 0.841 +hypervisor: 0.801 +risc-v: 0.792 +socket: 0.788 +ppc: 0.787 +mistranslation: 0.784 +vnc: 0.782 +peripherals: 0.776 +permissions: 0.768 +performance: 0.761 +device: 0.761 +network: 0.759 +files: 0.745 +register: 0.729 +architecture: 0.721 +debug: 0.721 +arm: 0.719 +KVM: 0.714 +TCG: 0.712 +graphic: 0.697 +virtual: 0.675 +semantic: 0.671 +PID: 0.670 +assembly: 0.651 +x86: 0.635 +VMM: 0.628 +boot: 0.623 +kernel: 0.614 +i386: 0.382 +-------------------- +arm: 0.835 +debug: 0.567 +user-level: 0.385 +hypervisor: 0.107 +kernel: 0.051 +virtual: 0.046 +files: 0.038 +TCG: 0.038 +socket: 0.035 +network: 0.027 +register: 0.018 +semantic: 0.017 +performance: 0.016 +assembly: 0.013 +device: 0.012 +i386: 0.012 +PID: 0.011 +x86: 0.010 +ppc: 0.009 +architecture: 0.009 +VMM: 0.008 +risc-v: 0.008 +boot: 0.007 +peripherals: 0.004 +KVM: 0.004 +vnc: 0.003 +graphic: 0.002 +permissions: 0.002 +mistranslation: 0.001 + +"-serial unix:" option of qemu-system-arm is broken in qemu 2.6.0 + +I found a bug of "-serial unix:PATH_TO_SOCKET" in qemu 2.6.0 (qemu 2.5.1 works fine). +Occasionally, a part of the output of qemu disappears in the bug. + +It looks like following commit is the cause: + +char: ensure all clients are in non-blocking mode (Author: Daniel P. Berrange <email address hidden>) +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=64c800f808748522727847b9cdc73412f22dffb9 + +In this commit, UNIX socket is set to non-blocking mode, but qemu_chr_fe_write function doesn't handle EAGAIN. +You should fix code like that: + +--- +diff --git a/qemu-char.c b/qemu-char.c +index b597ee1..0361d78 100644 +--- a/qemu-char.c ++++ b/qemu-char.c +@@ -270,6 +270,7 @@ static int qemu_chr_fe_write_buffer(CharDriverState *s, const uint8_t *buf, int + int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len) + { + int ret; ++ int offset = 0; + + if (s->replay && replay_mode == REPLAY_MODE_PLAY) { + int offset; +@@ -280,7 +281,21 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len) + } + + qemu_mutex_lock(&s->chr_write_lock); +- ret = s->chr_write(s, buf, len); ++ ++ while (offset < len) { ++ retry: ++ ret = s->chr_write(s, buf, len); ++ if (ret < 0 && errno == EAGAIN) { ++ g_usleep(100); ++ goto retry; ++ } ++ ++ if (ret <= 0) { ++ break; ++ } ++ ++ offset += ret; ++ } + + if (ret > 0) { + qemu_chr_fe_write_log(s, buf, ret); +--- + +Or please do "git revert 64c800f808748522727847b9cdc73412f22dffb9". + +I'm unable to reproduce the problem mentioned myself, and code inspection shows no problem for x86_64 at least. + +Specifically hw/char/serial.c has a serial_xmit() method which calls qemu_chr_fe_write(), and if it sees EAGAIN, it sets up a event notification to re-try the write later. + +Can you provide the full QEMU command line you are using, include the emulator binary. + +Looking at the code in 2.5.0, the qemu_chr_fe_write method would see EAGAIN too, because the tcp_chr_accept() method would always set the newly connected client to non-blocking mode. So thre's no obvious change in behaviour between 2.5 and 2.6 wrt to blocking sockets. + +Sorry, this issue only occur in qemu-system-arm (vexpress-a9). +In hw/char/pl011.c, qemu_chr_fe_write function is called directly and EAGAIN isn't handled. + +http://git.qemu.org/?p=qemu.git;a=blob;f=hw/char/pl011.c;h=210c87b4c2bd000d80c359ca5c05d43c64210677;hb=bfc766d38e1fae5767d43845c15c79ac8fa6d6af#l148 + +So I use following a patch. + +---- +diff --git a/hw/char/pl011.c b/hw/char/pl011.c +index c0fbf8a..6e29db8 100644 +--- a/hw/char/pl011.c ++++ b/hw/char/pl011.c +@@ -146,7 +146,7 @@ static void pl011_write(void *opaque, hwaddr offset, + /* ??? Check if transmitter is enabled. */ + ch = value; + if (s->chr) +- qemu_chr_fe_write(s->chr, &ch, 1); ++ qemu_chr_fe_write_all(s->chr, &ch, 1); + s->int_level |= PL011_INT_TX; + pl011_update(s); + break; +---- + +qemu_chr_fe_write_all function handles EAGAIN. + +I wrote small code which reproduces this issue. + +https://bitbucket.org/redcap97/puts-hello-x80000-armv7-kernel/downloads/puts-HELLO-x80000 + +Above binary outputs "HELLO!" 80000 times to UART. + +# Please execute in terminal +socat unix-listen:a.sock stdout | tee actual + +# Please execute in another terminal +qemu-system-arm -M vexpress-a9 -nographic -kernel puts-HELLO-x80000 -serial unix:a.sock + +# Check results +yes 'HELLO!' | head -n 80000 > expected +diff -u expected actual + +Occasionally, a part of the output of qemu disappears. + + +Source code of the binary +https://bitbucket.org/redcap97/puts-hello-x80000-armv7-kernel/src + + +> Looking at the code in 2.5.0, the qemu_chr_fe_write method would see EAGAIN too, because the tcp_chr_accept() method would always set the newly connected client to non-blocking mode. So thre's no obvious change in behaviour between 2.5 and 2.6 wrt to blocking sockets. + +It looks like tcp_chr_accept function isn't called in above command. +tcp_chr_wait_connected function is called instead. + +So the socket is blocking mode and doesn't return EAGAIN in Qemu 2.5.0. + +Ok, now it makes more sense. You are using the socket chardev in TCP outgoing client mode, which used to be blocking by default. In 2.6 this switched to match TCP server mode, in wich the incoming client was always in non-blocking mode. + +IOW, this arm code was already broken in 2.5 just depending on which chardev config was used. + +So, we'll need to put a fix in pl011_write. I'm unsure whether use writeall() is the correct behaviour - I'll come to other serial backends. + +Fix posted https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg00684.html + +Fix has been committed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=6ab3fc32ea640026726b +... and been released with QEMU version 2.8 + diff --git a/results/classifier/118/review/1588328 b/results/classifier/118/review/1588328 new file mode 100644 index 000000000..7cfdc906d --- /dev/null +++ b/results/classifier/118/review/1588328 @@ -0,0 +1,917 @@ +semantic: 0.875 +graphic: 0.844 +permissions: 0.840 +debug: 0.830 +network: 0.818 +user-level: 0.803 +boot: 0.803 +risc-v: 0.786 +architecture: 0.784 +mistranslation: 0.782 +register: 0.777 +device: 0.776 +hypervisor: 0.769 +peripherals: 0.759 +arm: 0.759 +virtual: 0.758 +PID: 0.757 +performance: 0.756 +socket: 0.742 +assembly: 0.735 +ppc: 0.714 +vnc: 0.708 +TCG: 0.687 +files: 0.659 +VMM: 0.621 +kernel: 0.612 +KVM: 0.586 +x86: 0.555 +i386: 0.522 +-------------------- +virtual: 0.872 +debug: 0.862 +boot: 0.723 +user-level: 0.248 +kernel: 0.042 +performance: 0.035 +PID: 0.021 +hypervisor: 0.015 +files: 0.011 +device: 0.007 +register: 0.006 +semantic: 0.006 +assembly: 0.005 +graphic: 0.004 +socket: 0.004 +TCG: 0.003 +network: 0.003 +architecture: 0.003 +peripherals: 0.002 +permissions: 0.001 +vnc: 0.001 +x86: 0.001 +VMM: 0.001 +KVM: 0.001 +mistranslation: 0.000 +risc-v: 0.000 +i386: 0.000 +arm: 0.000 +ppc: 0.000 + +Qemu 2.6 Solaris 9 Sparc Segmentation Fault + +Hi, +I tried the following command to boot Solaris 9 sparc: +qemu-system-sparc -nographic -boot d -hda ./Spark9.disk -m 256 -cdrom sol-9-905hw-ga-sparc-dvd.iso -serial telnet:0.0.0.0:3000,server + +It seems there are a few Segmentation Faults, one from the starting of the boot. Another at the beginning of the commandline installation. + +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d + +Jumping to entry point 00004000 for type 00000005... +switching to new context: +SunOS Release 5.9 Version Generic_118558-34 32-bit +Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): + Corrupt label; wrong magic number + +Segmentation Fault +Configuring /dev and /devices +NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) +audio may not work correctly until it is stopped and restarted +Segmentation Fault +Using RPC Bootparams for network configuration information. +Skipping interface le0 +Searching for configuration file(s)... +Search complete. + +.... + +What type of terminal are you using? + 1) ANSI Standard CRT + 2) DEC VT52 + 3) DEC VT100 + 4) Heathkit 19 + 5) Lear Siegler ADM31 + 6) PC Console + 7) Sun Command Tool + 8) Sun Workstation + 9) Televideo 910 + 10) Televideo 925 + 11) Wyse Model 50 + 12) X Terminal Emulator (xterms) + 13) CDE Terminal Emulator (dtterm) + 14) Other +Type the number of your choice and press Return: 3 +syslog service starting. +savecore: no dump device configured +Running in command line mode +/sbin/disk0_install[109]: 143 Segmentation Fault +/sbin/run_install[130]: 155 Segmentation Fault + +That basically looks like it should work. The only time I've seen random segfaults similar to this is with a corrupted disk, so the first question to ask is whether you've verified the ISO image you are using? Unfortunately this isn't an image I currently have access to, but I can report my Solaris 8 32-bit ISO boots and installs fine with no issues here. Does it make any difference if you remove the -hda part of the command line? + +Hi Mark, + +I compared the cksum provided and the dvd cksum that i did, seems to match. I did try out Solaris 8 too. It seems to work fine with sun formatted hda disk. I did try removing the -hda for solaris 9, the problem still persist. I shall find if i can get another solaris 9 image source to try out. + +If you can verify that the media is correct and you still see problems, I'd be interested to take a look if you are able to provide me a copy of the media for debugging. + + +Hi Mark, + +I have uploaded a copy of it to mega.nz + +https://mega.nz/#!94ZVXBra + + +Hi Mark, + +Attached is the new link: https://mega.nz/#!94ZVXBra!8QMsQ2d9eKKkMuawg_0YelfyWTy47CyyD1f6tvSv1bQ + + +Thanks for the test case. It appears that this is a regression that occurred somewhere between 2.5 and 2.6 - bisecting now. + +Can you guys check if the problem persists when qemu is launched with +the -singlestep option? +I think it's in general a good idea always check TCG-related problems +with -singlestep , because it helps to find out whether a bug is in +the optimizer or generator module of TCG. + +Artyom + +On Tue, Jun 14, 2016 at 11:44 PM, Mark Cave-Ayland +<email address hidden> wrote: +> Thanks for the test case. It appears that this is a regression that +> occurred somewhere between 2.5 and 2.6 - bisecting now. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1588328 +> +> Title: +> Qemu 2.6 Solaris 9 Sparc Segmentation Fault +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> I tried the following command to boot Solaris 9 sparc: +> qemu-system-sparc -nographic -boot d -hda ./Spark9.disk -m 256 -cdrom sol-9-905hw-ga-sparc-dvd.iso -serial telnet:0.0.0.0:3000,server +> +> It seems there are a few Segmentation Faults, one from the starting of +> the boot. Another at the beginning of the commandline installation. +> +> Trying 127.0.0.1... +> Connected to localhost. +> Escape character is '^]'. +> Configuration device id QEMU version 1 machine id 32 +> Probing SBus slot 0 offset 0 +> Probing SBus slot 1 offset 0 +> Probing SBus slot 2 offset 0 +> Probing SBus slot 3 offset 0 +> Probing SBus slot 4 offset 0 +> Probing SBus slot 5 offset 0 +> Invalid FCode start byte +> CPUs: 1 x FMI,MB86904 +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 +> Type 'help' for detailed information +> Trying cdrom:d... +> Not a bootable ELF image +> Loading a.out image... +> Loaded 7680 bytes +> entry point is 0x4000 +> bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d +> +> Jumping to entry point 00004000 for type 00000005... +> switching to new context: +> SunOS Release 5.9 Version Generic_118558-34 32-bit +> Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +> Use is subject to license terms. +> WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): +> Corrupt label; wrong magic number +> +> Segmentation Fault +> Configuring /dev and /devices +> NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) +> audio may not work correctly until it is stopped and restarted +> Segmentation Fault +> Using RPC Bootparams for network configuration information. +> Skipping interface le0 +> Searching for configuration file(s)... +> Search complete. +> +> .... +> +> What type of terminal are you using? +> 1) ANSI Standard CRT +> 2) DEC VT52 +> 3) DEC VT100 +> 4) Heathkit 19 +> 5) Lear Siegler ADM31 +> 6) PC Console +> 7) Sun Command Tool +> 8) Sun Workstation +> 9) Televideo 910 +> 10) Televideo 925 +> 11) Wyse Model 50 +> 12) X Terminal Emulator (xterms) +> 13) CDE Terminal Emulator (dtterm) +> 14) Other +> Type the number of your choice and press Return: 3 +> syslog service starting. +> savecore: no dump device configured +> Running in command line mode +> /sbin/disk0_install[109]: 143 Segmentation Fault +> /sbin/run_install[130]: 155 Segmentation Fault +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1588328/+subscriptions +> + + + +-- +Regards, +Artyom Tarasenko + +SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu + + +On 17/06/16 12:42, Artyom Tarasenko wrote: + +> Can you guys check if the problem persists when qemu is launched with +> the -singlestep option? +> I think it's in general a good idea always check TCG-related problems +> with -singlestep , because it helps to find out whether a bug is in +> the optimizer or generator module of TCG. +> +> Artyom + +Hi Artyom, + +I did manage to bisect this down to a single commit in the end: see +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg04039.html +for the commit in question. + + +ATB, + +Mark. + + + +Artyom has located the regression and posted a patch here: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07226.html. + +Hi all, + +Thanks for the patch. I just tried, it seems to be not able to find the disk when it try to start the installation. :( + +... + +Please specify the media from which you will install the Solaris Operating +Environment. + +Media: + +1. CD/DVD +2. Network File System +3. HTTP (Flash archive only) +4. FTP (Flash archive only) +5. Local Tape (Flash archive only) + + Media [1]: 1 +Reading disc for Solaris Operating Environment... + +The system is being initialized, please wait... / +No Disks found. +Check to make sure disks are cabled and powered up. + + + +I ran all the way through the installer in order to test the patch, so it should be working for you. Is your Spark9.disk labelled? See http://virtuallyfun.superglobalmegacorp.com/2010/10/03/formatting-disks-for-solaris/ for more information on how to do this. + +Hmm.. strange. I did make a new disk went into the setup, then format the disk. After that, i rebooted and start that installation. But, it seems still there is no disk detected. + + Media [1]: 1 +Reading disc for Solaris Operating Environment... + +The system is being initialized, please wait... | +No Disks found. +Check to make sure disks are cabled and powered up. + + Press OK to Exit. + + <Press ENTER to continue/ + +-# format -e +Searching for disks...done + + +AVAILABLE DISK SELECTIONS: + 0. c0t0d0 <drive type unknown> + /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 +Specify disk (enter its number): 0 + + + +AVAILABLE DRIVE TYPES: + 0. Auto configure + 1. Quantum ProDrive 80S + 2. Quantum ProDrive 105S + 3. CDC Wren IV 94171-344 + 4. SUN0104 + 5. SUN0207 + 6. SUN0327 + 7. SUN0340 + 8. SUN0424 + 9. SUN0535 + 10. SUN0669 + 11. SUN1.0G + 12. SUN1.05 + 13. SUN1.3G + 14. SUN2.1G + 15. SUN2.9G + 16. Zip 100 + 17. Zip 250 + 18. other +Specify disk type (enter its number): 18 +Enter number of data cylinders: 24620 +Enter number of alternate cylinders[2]: +Enter number of physical cylinders[24622]: +Enter number of heads: 27 +Enter physical number of heads[default]: 107 +Enter number of data sectors/track: 107 +Enter number of physical sectors/track[default]: +Enter rpm of drive[3600]: +Enter format time[default]: +Enter cylinder skew[default]: +Enter track skew[default]: +Enter tracks per zone[default]: +Enter alternate tracks[default]: +Enter alternate sectors[default]: +Enter cache control[default]: +Enter prefetch threshold[default]: +Enter minimum prefetch[default]: +Enter maximum prefetch[default]: +Enter disk type name (remember quotes): Sparc9 +selecting c0t0d0 +[disk formatted] + + +FORMAT MENU: + disk - select a disk + type - select (define) a disk type + partition - select (define) a partition table + current - describe the current disk + format - format and analyze the disk + repair - repair a defective sector + label - write label to the disk + analyze - surface analysis + defect - defect list management + backup - search for backup labels + verify - read and display labels + save - save new disk/partition definitions + inquiry - show vendor, product and revision + scsi - independent SCSI mode selects + cache - enable, disable or query SCSI disk cache + volname - set 8-character volume name + !<cmd> - execute <cmd>, then return + quit +format> label +[0] SMI Label +[1] EFI Label +Specify Label type[0]: 1 +Ready to label disk, continue?y + +format> q + +#reboot +Jun 28 23:37:16 rpcbind: rpcbind terminating on signal. +syncing file systems... done +rebooting... +rebooting () +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d + +Jumping to entry point 00004000 for type 00000005... +switching to new context: +SunOS Release 5.9 Version Generic_118558-34 32-bit +Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Configuring /dev and /devices +NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) +audio may not work correctly until it is stopped and restarted + +Please specify the media from which you will install the Solaris Operating +Environment. + +Media: + +1. CD/DVD +2. Network File System +3. HTTP (Flash archive only) +4. FTP (Flash archive only) +5. Local Tape (Flash archive only) + + Media [1]: 1 +Reading disc for Solaris Operating Environment... + +The system is being initialized, please wait... -^[[6|^R +^[[/ +No Disks found. +Check to make sure disks are cabled and powered up. + + Press OK to Exit. + + + +Okay. Can you confirm which version (or git revision) you've used to apply the patch so I can try and reproduce locally? + + +May 11 2016. qemu-2.6.0 from http://wiki.qemu.org/Download + +I've just tried v2.6.0 with the recent ldstub patch applied and it looks from the output above that you're using an incorrect format to put down the disk label. I see the following: + +$ ./qemu-system-sparc -cdrom sol-9-905hw-ga-sparc-dvd.iso -hda /home/build/src/qemu/image/sparc32/sol9.qcow2 -boot d -nographic -prom-env 'auto-boot?=false' +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 + Type 'help' for detailed information + +0 > boot cdrom:d -vs Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d + +Jumping to entry point 00004000 for type 00000005... +switching to new context: +Size: 0x4624f+0xdaf5+0x1d6a3 Bytes +SunOS Release 5.9 Version Generic_118558-34 32-bit +Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +... +... +INIT: SINGLE USER MODE +# format +Searching for disks...WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): + Corrupt label; wrong magic number + +WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): + Corrupt label; wrong magic number + +done + + +AVAILABLE DISK SELECTIONS: + 0. c0t0d0 <drive type unknown> + /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 +Specify disk (enter its number): 0 + + + +AVAILABLE DRIVE TYPES: + 0. Auto configure + 1. Quantum ProDrive 80S + 2. Quantum ProDrive 105S + 3. CDC Wren IV 94171-344 + 4. SUN0104 + 5. SUN0207 + 6. SUN0327 + 7. SUN0340 + 8. SUN0424 + 9. SUN0535 + 10. SUN0669 + 11. SUN1.0G + 12. SUN1.05 + 13. SUN1.3G + 14. SUN2.1G + 15. SUN2.9G + 16. Zip 100 + 17. Zip 250 + 18. other +Specify disk type (enter its number): 18 +Enter number of data cylinders: 24620 +Enter number of alternate cylinders[2]: +Enter number of physical cylinders[24622]: +Enter number of heads: 27 +Enter physical number of heads[default]: +Enter number of data sectors/track: 107 +Enter number of physical sectors/track[default]: 107 +Enter rpm of drive[3600]: +Enter format time[default]: +Enter cylinder skew[default]: +Enter track skew[default]: +Enter tracks per zone[default]: +Enter alternate tracks[default]: +Enter alternate sectors[default]: +Enter cache control[default]: +Enter prefetch threshold[default]: +Enter minimum prefetch[default]: +Enter maximum prefetch[default]: +Enter disk type name (remember quotes): Sparc9 +selecting c0t0d0 +[disk formatted] + + +FORMAT MENU: + disk - select a disk + type - select (define) a disk type + partition - select (define) a partition table + current - describe the current disk + format - format and analyze the disk + repair - repair a defective sector + label - write label to the disk + analyze - surface analysis + defect - defect list management + backup - search for backup labels + verify - read and display labels + save - save new disk/partition definitions + inquiry - show vendor, product and revision + volname - set 8-character volume name + !<cmd> - execute <cmd>, then return + quit +format> label +Ready to label disk, continue? y + +WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): + Corrupt label; wrong magic number + +format> label +Ready to label disk, continue? y + +format> q + +And then after the reboot: + +$ ./qemu-system-sparc -cdrom sol-9-905hw-ga-sparc-dvd.iso -hda /home/build/src/qemu/image/sparc32/sol9.qcow2 -boot d -nographic +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d + +Jumping to entry point 00004000 for type 00000005... +switching to new context: +SunOS Release 5.9 Version Generic_118558-34 32-bit +Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +Configuring /dev and /devices +NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) +audio may not work correctly until it is stopped and restarted +Using RPC Bootparams for network configuration information. +Skipping interface le0 +Searching for configuration file(s)... +Search complete. + +Select a Language + + 0. English + 1. French + 2. German + 3. Italian + 4. Japanese + 5. Korean + 6. Simplified Chinese + 7. Spanish + 8. Swedish + 9. Traditional Chinese + +Please make a choice (0 - 9), or press h or ? for help: 0 + +Select a Locale + + 0. English (C - 7-bit ASCII) + 1. Albania (ISO8859-2) + 2. Australia (ISO8859-1) + 3. Belgium-Flemish (ISO8859-1) + 4. Belgium-Flemish (ISO8859-15 - Euro) + 5. Bosnia (ISO8859-2) + 6. Brazil (ISO8859-1) + 7. Brazil (UTF-8) + 8. Bulgaria (ISO8859-5) + 9. Canada-English (ISO8859-1) + 10. Catalan, Spain (ISO8859-1) + 11. Catalan, Spain (ISO8859-15 - Euro) + 12. Croatia (ISO8859-2) + 13. Czech Republic (ISO8859-2) + 14. Denmark (ISO8859-1) + 15. Denmark (ISO8859-15 - Euro) + 16. Egypt (ISO8859-6) + 17. Egypt (UTF-8) + 18. Estonia (ISO8859-15) + +Press Return to show more choices. +Please make a choice (0 - 59), or press h or ? for help: 0 + +What type of terminal are you using? + 1) ANSI Standard CRT + 2) DEC VT52 + 3) DEC VT100 + 4) Heathkit 19 + 5) Lear Siegler ADM31 + 6) PC Console + 7) Sun Command Tool + 8) Sun Workstation + 9) Televideo 910 + 10) Televideo 925 + 11) Wyse Model 50 + 12) X Terminal Emulator (xterms) + 13) CDE Terminal Emulator (dtterm) + 14) Other +Type the number of your choice and press Return: 3 +syslog service starting. +savecore: no dump device configured +Running in command line mode + +Please wait while the system information is loaded... | + +... +... + +Please wait while the system is configured with your settings... + +Scanning system disk information... + +Searching disks for upgradable Solaris root devices... +No Upgradable Solaris root devices were found. + + +Searching for locations to accommodate a temporary copy of the Solaris +installation software. Swap slices are usually erased at reboot, so it is +preferable to place the Solaris installation software on slice labeled swap. + +No swap slices that begin at the first usable cylinder have enough space +to accommodate a temporary copy of the Solaris installation software. + +Using a slice that begins at the first usable cylinder allows the most +flexibility during filesystem layout. If you are doing an initial install and +you are not preserving any filesystems, you can re-partition a disk with the +swap slice starting at the first usable cylinder. + +Would you like to re-partition a disk? [y,n,?,q] y + +The default root disk is /dev/dsk/c0t0d0. +The selected disk will be re-partitioned before the Solaris installation +software is copied to the disk. + +WARNING: ALL INFORMATION ON THE DISK WILL BE ERASED! + + +Do you want to re-partition /dev/dsk/c0t0d0 [y,n,?,q] y + +NOTE: The swap size cannot be changed during file system layout. + + +Enter a swap slice size between 158MB and 34729MB, default = 512MB [?] + +Placing the swap slice at the beginning of the disk will allow the most flexible file system partitioning later in the installation. + +Can the swap slice start at the beginning of the disk [y,n,?,q] y +Confirm Information: + + Disk Slice : /dev/dsk/c0t0d0s1 + Size : 512 MB + Start Cyl. : 0 + +WARNING: ALL INFORMATION ON THE DISK WILL BE ERASED! + + +Is this OK [y,n,?,q] y + +etc. + +Please specify the media from which you will install the Solaris Operating +Environment. + +Media: + +1. CD/DVD +2. Network File System +3. HTTP (Flash archive only) +4. FTP (Flash archive only) +5. Local Tape (Flash archive only) + + Media [1]: +Reading disc for Solaris Operating Environment... + +The system is being initialized, please wait... / + +Sun Microsystems, Inc. +Binary Code License Agreement + +etc. + +Comparing your output with mine I can see two obvious differences: + +1) You are using a different version of Solaris to label the disk in a way that can't be understood by Solaris 9 + +2) You've mistyped the "Physical number of heads" as 27 rather than accepting the default + + +ATB, + +Mark. + + +Hi Mark, + +Thanks a lot. Got it working now. When formatting the label, there are 2 options, SMI and EFI. Once I format it with SMI, it seems to be able to find the disk. + +Great news! FWIW with newer versions of QEMU, including 2.6.0, the framebuffer emulation is good enough to install and run Solaris (including X) without the -nographic/-serial options if you need it. I've also CCd the relevant patch to qemu-stable so it should appear in 2.6.1 also. + +Many thanks for the report! + + +Hi Mark, + +Thanks for the update. I would definitely be nice to have other than the black screen. Still got a problem though. I managed to install sparc9 but after i removed the cdrom, it fails to boot. + +qemu-system-sparc -nographic -monitor null -serial mon:telnet:0.0.0.0:3000,server -hda ./Sparc9.disk -m 256 -net nic,macaddr=52:54:0:12:34:56 -net tap,ifname=tap0,script=no,downscript=no + +From an article written by Artyom, i did add + +# cat >> /a/etc/system + +set scsi_options=0x58 + +^d + +to solaris 2.6. + +However, i think i didnt do this with solaris 8, it works fine. + +For the solaris 9, it will allow you to either set it to not reboot but once you reached the end of the installation, it will reboot when you press enter. And the Sparc9.disk cannot be booted :( + + + +telnet 0.0.0.0 3000 +Trying 0.0.0.0... +Connected to 0.0.0.0. +Escape character is '^]'. +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 + Type 'help' for detailed information +Trying disk... +Not a bootable ELF image +Not a bootable a.out image +No valid state has been set by load or init-program + +0 > + + + +If you use OpenBIOS then you don't explicitly have to set scsi-options since the value can be overridden via the device tree which is exactly what OpenBIOS does. + +Interestingly enough it seems that the default bootloader for Solaris 9 is installed in the slice rather than the root of the disk as per my Solaris 8 installation. Fortunately you can manually boot Solaris 9 from the slice by entering "boot disk:d" at the Forth prompt. + +Based upon this it probably makes sense to add "disk:d" to the bootpath used by OpenBIOS - I'll send a patch through to the OpenBIOS mailing list shortly. + + +Hi Mark, + +I have tried boot diisk:d. After this + +Not a bootable ELF image +Not a bootable a.out image +No valid state has been set by load or init-program + +0 > boot disk:d No valid state has been set by load or init-program + ok +0 > + + +Somehow I am getting invalid boot + +It works here as per my post above, so I think the problem is still with the disk label. With the above ISO image, I don't get asked for the type of label which makes me think you are using a newer version of Solaris for labelling than you are for installation. + +Can you re-label the disk using the exact same image used for the installation and see if that makes a difference? + +Hmmm I've just tried a second installation of Solaris 9 with a completely blank disk image and now it appears that "boot disk:a" is correct, i.e. boot from slice a. Not sure yet if this is the correct convention for HDs. + +Hi Mark, + +We are finally in:) + +By the way, how do you figure out which slice its in? + +From solaris 8 dvd onwards, i seems to see 2 disk label options: SMI and EFI. Not sure why you didnt see those. + +0 > boot disk:a Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0:a + +Jumping to entry point 00004000 for type 00000005... +switching to new context: +SunOS Release 5.9 Version Generic_118558-34 32-bit +Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +configuring IPv4 interfaces: le0. +starting DHCP on primary interface le0 +Hostname: unknown +The system is coming up. Please wait. +checking ufs filesystems +/dev/rdsk/c0t0d0s7: is logging. +starting rpc services: rpcbind done. +syslog service starting. +syslogd: line 24: WARNING: loghost could not be resolved +Jul 3 14:06:40 unknown sendmail[239]: My unqualified host name (unknown) unknown; sleeping for retry +Jul 3 14:06:40 unknown sendmail[240]: My unqualified host name (unknown) unknown; sleeping for retry +volume management starting. +Creating new rsa public/private host key pair +Creating new dsa public/private host key pair +Jul 3 14:06:54 unknown snmpXdmid: Error in Adding Row for Subscription Table Entry +Jul 3 14:06:55 unknown snmpXdmid: Failed to add filter to SP for Event delivery +The system is ready. + +unknown console login: root +Password: +Jul 3 14:07:09 unknown login: ROOT LOGIN /dev/console +Sun Microsystems Inc. SunOS 5.9 Generic May 2002 +# ls +bin etc lib opt tmp xfn +cdrom export lost+found platform usr +dev home mnt proc var +devices kernel net sbin vol +# Jul 3 14:07:41 unknown sendmail[240]: unable to qualify my own domain name (unknown) -- using short name +Jul 3 14:07:41 unknown sendmail[240]: [ID 702911 mail.alert] unable to qualify my own domain name (unknown) -- using short name +Jul 3 14:07:46 unknown sendmail[239]: unable to qualify my own domain name (unknown) -- using short name +Jul 3 14:07:46 unknown sendmail[239]: [ID 702911 mail.alert] unable to qualify my own domain name (unknown) -- using short name + + + +Great news! AFAICT it's just convention that the first disk slice is used, and I've also proposed a patch for OpenBIOS to include this in the boot search path in future, hopefully in time for 2.7. + diff --git a/results/classifier/118/review/159 b/results/classifier/118/review/159 new file mode 100644 index 000000000..e87c5125f --- /dev/null +++ b/results/classifier/118/review/159 @@ -0,0 +1,61 @@ +mistranslation: 0.985 +graphic: 0.546 +device: 0.500 +performance: 0.496 +semantic: 0.409 +permissions: 0.258 +peripherals: 0.237 +architecture: 0.222 +user-level: 0.210 +network: 0.158 +arm: 0.137 +kernel: 0.135 +hypervisor: 0.131 +debug: 0.126 +virtual: 0.122 +VMM: 0.107 +ppc: 0.097 +files: 0.084 +assembly: 0.080 +socket: 0.062 +vnc: 0.060 +register: 0.058 +TCG: 0.047 +boot: 0.047 +i386: 0.046 +risc-v: 0.043 +x86: 0.030 +KVM: 0.029 +PID: 0.018 +-------------------- +hypervisor: 0.934 +virtual: 0.917 +user-level: 0.385 +debug: 0.035 +semantic: 0.019 +x86: 0.014 +files: 0.013 +device: 0.012 +network: 0.007 +KVM: 0.006 +TCG: 0.005 +PID: 0.005 +socket: 0.004 +i386: 0.004 +arm: 0.004 +assembly: 0.004 +peripherals: 0.003 +register: 0.003 +ppc: 0.002 +VMM: 0.002 +permissions: 0.002 +kernel: 0.002 +performance: 0.002 +graphic: 0.002 +boot: 0.001 +architecture: 0.001 +mistranslation: 0.001 +vnc: 0.000 +risc-v: 0.000 + +qemu-nbd -l and -s options don't work together diff --git a/results/classifier/118/review/1591611 b/results/classifier/118/review/1591611 new file mode 100644 index 000000000..0335a9b2d --- /dev/null +++ b/results/classifier/118/review/1591611 @@ -0,0 +1,155 @@ +semantic: 0.913 +graphic: 0.905 +ppc: 0.893 +arm: 0.892 +peripherals: 0.890 +debug: 0.874 +hypervisor: 0.873 +vnc: 0.871 +assembly: 0.869 +architecture: 0.867 +virtual: 0.865 +risc-v: 0.865 +user-level: 0.864 +mistranslation: 0.860 +register: 0.856 +permissions: 0.854 +VMM: 0.852 +TCG: 0.840 +KVM: 0.840 +x86: 0.837 +performance: 0.837 +PID: 0.836 +device: 0.832 +kernel: 0.821 +socket: 0.788 +network: 0.779 +files: 0.770 +boot: 0.763 +i386: 0.600 +-------------------- +x86: 0.467 +ppc: 0.229 +user-level: 0.151 +debug: 0.064 +files: 0.060 +virtual: 0.053 +TCG: 0.033 +assembly: 0.030 +PID: 0.017 +semantic: 0.011 +kernel: 0.009 +hypervisor: 0.006 +architecture: 0.005 +register: 0.005 +device: 0.003 +VMM: 0.003 +performance: 0.003 +graphic: 0.002 +network: 0.001 +boot: 0.001 +KVM: 0.001 +socket: 0.001 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected. + +We don't have an implementation of the target-specific signal handling code for the x86-64 guest. Anything that cares about signals therefore won't work with this target. + +In general the x86-64 guest support for linux-user isn't very good; ARM or AArch64 guest should behave rather better. + + +Are there any plans to implement these signal handlers? + +I don't know of any plans to do so. They would not be difficult to implement (500 lines of code or so at most I guess), but on the other hand they've been unimplemented for some years. They fall into the category of "nobody who wants them has cared enough to write the code yet", I'm afraid. + + +Can you point me to the correct location in the codebase / any available resources on these handlers? I might be able to tackle this at a later date, but am not currently familiar with qemu's codebase. + +linux-user/signal.c has a collection of functions for creating a signal frame on the stack before taking a signal, and then reading the data out of it on return from a signal. The four entry points from the rest of QEMU are setup_frame(), setup_rt_frame(), do_sigreturn() and do_rt_sigreturn(). We have implementations for a lot of target architectures, but for TARGET_I386 we only have the case of TARGET_ABI_BITS==32 (ie i386), not the x86-64 case. + +What these functions have to do is architecture dependent and generally not documented -- you'll need to look in the corresponding Linux kernel source code to identify the structures and data layouts. + + +By the way there is probably a bug in what we're doing with fork/clone that's causing the initial assertion, as well as the missing signal handling problem. + + +Yes, I saw that -- implementing the signal handlers fixed the hang and a few other problems, but the assertion and subsequent SIGABORT/SIGSEGV are still present. Currently attempting to track down the fork() issues. + +If you've got working code for the signal handlers you can submit those as patches now if you like. (http://wiki.qemu.org/Contribute/SubmitAPatch has info on the formatting hoops.) We have a feature freeze for QEMU 2.7 coming up on the 28th June, so before then would be ideal. + +Judging by the assertion, something is going wrong with libc's attempt to set the child tidptr via the ctid argument to clone and the CLONE_CHILD_SETTID flag. + + +OK, the fundamental problem is that do_fork() uses put_user_u32() on child_tidptr, but child_tidptr appears to be a host pointer. Treating it as a host pointer (direct assignment) allows fork to proceed, but this seems a bit odd to say the least. + +Still investigating. + +On closer inspection maybe it's not that odd...the parent and child tid pointers are in abi, not target, space. I'm going to assume direct assignment is correct (using __put_user()) and proceed from there. + +No, put_user_u32() is correct and __put_user() would be wrong. child_tidptr is a value passed directly from the guest in a register, so it is a guest pointer, not a host pointer. + + +qemu can locate the guest page with that address but it has a flags field of all zero (no access, invalid). Any ideas? + +So after some further debugging effort it turns out while the page allocator is unaware of the mapping (looks like the x86_64 NPTL implementation never maps the thread ID memory?), g2h() does work on the address, and in this case they map to the same value. I'll probably submit a patch using g2h in case anyone else might have a better idea on how to handle this. + +Finally figured it out! + +It's the page size. qemu user mode does NOT support a host page that is greater than 4k on x86/x86_64 systems, despite some claims to the contrary on older documentation pages. + +I'll be updating the patch to print a clear warning on failure instead of allowing corrupt data and the resultant cryptic target messages. + +Patch series sent to mailing list here: +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05334.html + +In particular, this patch handles the original signal handler problem: +http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg05335.html + +I tried QEMU with these patches [qemu-x86_64 version 2.6.94 (v2.7.0-rc4-dirty)] but found the same errors as before: + +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +setup_frame: not implemented +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +So does this patch set form a complete solution or if some more fixes expected? + +Thanks, +Atul. + +This bug has been moved to "Fix committed" before v2.9.0 has been release ... so could we move this to "Fix released" now? Or is there still something left to do here? + +Nope, looks good here. As a note to other commenters, this won't work unless you are using a kernel compiled with the 4k page size -- default for PPC64 is 64k. + diff --git a/results/classifier/118/review/1592 b/results/classifier/118/review/1592 new file mode 100644 index 000000000..15f47be48 --- /dev/null +++ b/results/classifier/118/review/1592 @@ -0,0 +1,76 @@ +TCG: 0.934 +graphic: 0.864 +vnc: 0.757 +device: 0.698 +ppc: 0.656 +semantic: 0.606 +boot: 0.586 +performance: 0.557 +architecture: 0.557 +network: 0.550 +socket: 0.544 +PID: 0.490 +risc-v: 0.484 +register: 0.484 +debug: 0.467 +VMM: 0.440 +permissions: 0.412 +files: 0.349 +arm: 0.315 +user-level: 0.293 +peripherals: 0.270 +kernel: 0.264 +virtual: 0.233 +hypervisor: 0.216 +assembly: 0.205 +mistranslation: 0.188 +i386: 0.176 +KVM: 0.070 +x86: 0.045 +-------------------- +TCG: 0.785 +x86: 0.573 +debug: 0.452 +hypervisor: 0.363 +boot: 0.243 +register: 0.071 +virtual: 0.059 +files: 0.034 +performance: 0.025 +PID: 0.013 +user-level: 0.012 +kernel: 0.011 +device: 0.008 +semantic: 0.008 +risc-v: 0.006 +i386: 0.006 +assembly: 0.006 +arm: 0.005 +network: 0.003 +ppc: 0.003 +VMM: 0.002 +vnc: 0.002 +architecture: 0.002 +socket: 0.002 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +QEMU v8.0.0 crashes when running in TCG mode on windows OS +Description of problem: +This bug is a follow-up to issue #1581. +After the patch 7d9e1ee424b06a43708be02474e6714962cfee92 is merged, QEMU segfaults at startup. +And the location where the segfault occurs here(from coredump): +``` +atomic_common.c.inc:60 +CMPXCHG_HELPER(cmpxchgo_le, Int128) +``` +Steps to reproduce: +NA +Additional information: +1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux. +2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur. +3. This problem does not exist in the QEMU version 7.2. +4. What is even more confusing is that if you use gdb to load qemu and run it, this issue cannot be reproduced. diff --git a/results/classifier/118/review/1594861 b/results/classifier/118/review/1594861 new file mode 100644 index 000000000..20a0ed93d --- /dev/null +++ b/results/classifier/118/review/1594861 @@ -0,0 +1,404 @@ +register: 0.926 +risc-v: 0.899 +device: 0.891 +user-level: 0.876 +virtual: 0.870 +debug: 0.866 +permissions: 0.839 +peripherals: 0.821 +assembly: 0.815 +performance: 0.808 +graphic: 0.806 +architecture: 0.800 +mistranslation: 0.796 +arm: 0.795 +network: 0.790 +vnc: 0.787 +hypervisor: 0.786 +x86: 0.785 +socket: 0.775 +PID: 0.769 +ppc: 0.764 +boot: 0.761 +VMM: 0.753 +semantic: 0.748 +TCG: 0.741 +KVM: 0.734 +files: 0.720 +i386: 0.706 +kernel: 0.630 +-------------------- +debug: 0.993 +x86: 0.964 +virtual: 0.793 +hypervisor: 0.750 +PID: 0.085 +performance: 0.050 +TCG: 0.025 +graphic: 0.022 +files: 0.021 +user-level: 0.019 +register: 0.015 +device: 0.008 +network: 0.007 +assembly: 0.007 +semantic: 0.006 +boot: 0.005 +vnc: 0.005 +permissions: 0.004 +KVM: 0.004 +architecture: 0.004 +kernel: 0.003 +ppc: 0.003 +peripherals: 0.002 +socket: 0.002 +VMM: 0.001 +mistranslation: 0.001 +risc-v: 0.000 +i386: 0.000 +arm: 0.000 + +QEMU crashes when slow VNC client disconnects + +QEMU (at least 2.6.0 and today's git origin/master 6f1d2d1c5ad20d464705b17318cb7ca495f8078a) crashes when a slow VNC client disconnects during a time of busy VNC updates, with: +qemu_mutex_lock: Invalid argument + +This is easily repeatable: + - Start up a QEMU with the Finnix 1.10 CD-ROM, as below + - vnclient host:0 -shared (remote X11-based vnc client, to make it "slow") + - On the Finnix command line, run: "while :; do ls -laRC /; done" to generate screen updates + - Close the vncclient + - QEMU crashes on locking an already free'd mutex (note that the VNC state's share_mode is DISCONNECTED) + + + +# gdb qemu-system-x86_64 +GNU gdb (GDB) 7.11.1 +Copyright (C) 2016 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-pc-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-system-x86_64...done. +(gdb) run -cdrom finnix-110.iso -m 1G -vga cirrus -usbdevice tablet -net nic,model=e1000 -net user -rtc base=localtime,clock=host -enable-kvm -vnc :0,share=ignore -monitor stdio +Starting program: qemu-system-x86_64 -cdrom finnix-110.iso -m 1G -vga cirrus -usbdevice tablet -net nic,model=e1000 -net user -rtc base=localtime,clock=host -enable-kvm -vnc :0,share=ignore -monitor stdio +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib/libthread_db.so.1". +[New Thread 0x7ffff1ca2700 (LWP 25717)] +Failed to initialize module: /usr/lib/qemu/block-dmg.so +Note: only modules from the same build can be loaded. +[New Thread 0x7ffff129d700 (LWP 25718)] +QEMU 2.6.50 monitor - type 'help' for more information +(qemu) [New Thread 0x7ffff08ba700 (LWP 25719)] +[New Thread 0x7fffaabff700 (LWP 25721)] +[Thread 0x7ffff129d700 (LWP 25718) exited] +[New Thread 0x7ffff129d700 (LWP 25724)] +[Thread 0x7ffff129d700 (LWP 25724) exited] +[New Thread 0x7ffff129d700 (LWP 25728)] +qemu: qemu_mutex_lock: Invalid argument + +Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted. +0x00007ffff48cc2a8 in raise () from /usr/lib/libc.so.6 +(gdb) thread apply all backtrace + +Thread 7 (Thread 0x7ffff129d700 (LWP 25728)): +#0 0x00007ffff634b5f5 in do_futex_wait () from /usr/lib/libpthread.so.0 +#1 0x00007ffff634b6bf in __new_sem_wait_slow () from /usr/lib/libpthread.so.0 +#2 0x00007ffff634b772 in sem_timedwait () from /usr/lib/libpthread.so.0 +#3 0x0000555555a7fcb7 in qemu_sem_timedwait (sem=sem@entry=0x555556518c38, ms=ms@entry=10000) + at util/qemu-thread-posix.c:245 +#4 0x00005555559f281c in worker_thread (opaque=0x555556518bd0) at thread-pool.c:92 +#5 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#6 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 5 (Thread 0x7fffaabff700 (LWP 25721)): +#0 0x00007ffff634903f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a7fb69 in qemu_cond_wait (cond=cond@entry=0x555556541790, mutex=mutex@entry=0x5555565417c0) + at util/qemu-thread-posix.c:123 +#2 0x00005555559ecb4b in vnc_worker_thread_loop (queue=queue@entry=0x555556541790) at ui/vnc-jobs.c:228 +#3 0x00005555559ed088 in vnc_worker_thread (arg=0x555556541790) at ui/vnc-jobs.c:335 +#4 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 4 (Thread 0x7ffff08ba700 (LWP 25719)): +#0 0x00007ffff4979277 in ioctl () from /usr/lib/libc.so.6 +#1 0x00005555557d3484 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55555651f2d0, type=type@entry=44672) + at kvm-all.c:2057 +#2 0x00005555557d353d in kvm_cpu_exec (cpu=cpu@entry=0x55555651f2d0) + at kvm-all.c:1907 +#3 0x00005555557c1ea4 in qemu_kvm_cpu_thread_fn (arg=0x55555651f2d0) + at cpus.c:1078 +#4 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7ffff1ca2700 (LWP 25717)): +#0 0x00007ffff497c7f9 in syscall () from /usr/lib/libc.so.6 +#1 0x0000555555a7fe75 in futex_wait (val=<optimized out>, ev=<optimized out>) at util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=ev@entry=0x55555646bb64 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399 +#3 0x0000555555a8e26e in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:250 +#4 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7ffff7f94a80 (LWP 25713)): +#0 0x00007ffff48cc2a8 in raise () from /usr/lib/libc.so.6 +#1 0x00007ffff48cd72a in abort () from /usr/lib/libc.so.6 +#2 0x000055555579290b in error_exit (err=<optimized out>, + msg=msg@entry=0x555555b59d30 <__func__.14707> "qemu_mutex_lock") at util/qemu-thread-posix.c:39 +#3 0x0000555555a7faa0 in qemu_mutex_lock (mutex=mutex@entry=0x555556566568) at util/qemu-thread-posix.c:66 +#4 0x00005555559da91f in vnc_lock_output (vs=0x55555655a320) at ui/vnc-jobs.h:62 +#5 vnc_client_write (vs=0x55555655a320) at ui/vnc.c:1361 +#6 vnc_client_io (ioc=<optimized out>, condition=<optimized out>, opaque=0x55555655a320) at ui/vnc.c:1483 +#7 0x00007ffff53a6dba in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#8 0x00005555559fa6eb in glib_pollfds_poll () at main-loop.c:213 +#9 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258 +#10 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506 +#11 0x00005555557974a4 in main_loop () at vl.c:1925 +#12 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4628 +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff7f94a80 (LWP 25713))] +#0 0x00007ffff48cc2a8 in raise () from /usr/lib/libc.so.6 +(gdb) frame 5 +#5 vnc_client_write (vs=0x55555655a320) at ui/vnc.c:1361 +1361 vnc_lock_output(vs); +(gdb) set max-value-size 80000 +(gdb) print *vs +$1 = {sioc = 0x555557b1da40, ioc = 0x555557998790, ioc_tag = 0, disconnecting = 0, dirty = {{0, 0, 0}, {0, 0, 0}, { + 1055221925019647, 0, 0}, {1055221925019647, 0, 0}, {773781307523071, 0, 0}, {1125899906842623, 0, 0}, { + 1125899906842623, 0, 0}, {1125899906842623, 0, 0}, {1125899906842623, 0, 0}, {1125899906842623, 0, 0}, { + 1125899906842623, 0, 0}, {1125899906842623, 0, 0}, {71193947300417, 0, 0}, {71193947300433, 0, 0}, { + 71193947300417, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {1319379593592831, 0, 0}, {1319379593592831, 0, 0}, { + 1319379593592831, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, { + 2251799813685247, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, { + 106275268473665, 0, 0}, {115071496237889, 0, 0}, {106275268473665, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 381680068419649535, 0, 0}, {381680068419649535, 0, 0}, {309622474381721599, 0, 0}, {576460752303423487, 0, 0}, { + 576460752303423487, 0, 0}, {576460752303423487, 0, 0}, {576460752303423487, 0, 0}, {576460752303423487, 0, 0}, { + 576460752303423487, 0, 0}, {576460752303423487, 0, 0}, {106194469454161, 0, 0}, {36285762154894705, 0, 0}, { + 106194469454161, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {307370399690129407, 0, 0}, {307370399690129407, 0, 0}, + {307370399690129407, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, { + 569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, { + 55615324492583, 0, 0}, {36225287405246247, 0, 0}, {55615324492583, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 451468244688044031, 0, 0}, {451468244688044031, 0, 0}, {451468244688044031, 0, 0}, {569705352862367743, 0, 0}, { + 569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, { + 569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {55546325181303, 0, 0}, {36154780942280567, 0, 0}, { + 55546325181303, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {3406691643129069567, 0, 0}, {3406691643129069567, 0, + 0}, {3406691643129069567, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, + 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, { + 4607182418800017407, 0, 0}, {432929977792532287, 0, 0}, {541438925046353727, 0, 0}, {432929977792532287, 0, 0}, { + 0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {2831620673523154943, 0, 0}, {2831620673523154943, 0, 0}, {2831620673523154943, + 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, { + 4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, + 0}, {721827755353776959, 0, 0}, {830336702607599423, 0, 0}, {721827755353776959, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 0, 0, 0}, {1543608686381891327, 0, 0}, {1543608686381891327, 0, 0}, {1543045736428470271, 0, 0}, { + 4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, + 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {721970826084188599, + 0, 0}, {253878283546232247, 0, 0}, {145510073780765111, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 1517695344798859263, 0, 0}, {1517695344798859263, 0, 0}, {1515461137171218431, 0, 0}, {4580160821035794431, 0, + 0}, {4580160821035794431, 0, 0}, {4580160821035794431, 0, 0}, {4580160821035794431, 0, 0}, {4580160821035794431, + 0, 0}, {4580160821035794431, 0, 0}, {4580160821035794431, 0, 0}, {226043368113417, 0, 0}, {72565387932009739, 0, + 0}, {226043368113417, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {1522216674051227647, 0, 0}, {1522216674051227647, + 0, 0}, {1517713074423857151, 0, 0}, {2278821411449470975, 0, 0}, {2278821411449470975, 0, 0}, { + 2278821411449470975, 0, 0}, {2278821411449470975, 0, 0}, {2278821411449470975, 0, 0}, {2278821411449470975, 0, + 0}, {2278821411449470975, 0, 0}, {638357209941807, 0, 0}, {73127235220875119, 0, 0}, {638357209941807, 0, 0}, { + 0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {1873497444986126335, 0, 0}, {1873497444986126335, 0, 0}, {1873497376266649599, + 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, { + 4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, + 0}, {36244873060242763, 0, 0}, {115366073929258319, 0, 0}, {36244873060242763, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, + 0, 0}, {1125899872482361343, 0, 0}, {1125899872482361343, 0, 0}, {1125899735043407871, 0, 0}, { + 2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, + 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {325521969941073283, + 0, 0}, {397861314371603915, 0, 0}, {325521969941073283, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 1121396238495776767, 0, 0}, {1121396238495776767, 0, 0}, {1121396307215253503, 0, 0}, {1143914305352105983, 0, + 0}, {1143914305352105983, 0, 0}, {1143914305352105983, 0, 0}...}, lossy_rect = 0x555557b1da50, + vd = 0x5555585000a0, need_update = 1, force_update = 0, has_dirty = 192431, features = 723, absolute = 1, + last_x = 512, last_y = 384, last_bmask = 0, client_width = 1024, client_height = 768, + share_mode = VNC_SHARE_MODE_DISCONNECTED, vnc_encoding = 7, major = 3, minor = 8, auth = 1, subauth = 0, + challenge = '\000' <repeats 15 times>, tls = 0x0, encode_ws = false, websocket = false, info = 0x555557976a30, + output = {name = 0x0, capacity = 0, offset = 0, avg_size = 4194304, buffer = 0x0}, input = {name = 0x0, + capacity = 0, offset = 0, avg_size = 524288, buffer = 0x0}, write_pixels = 0x5555559daae0 <vnc_write_pixels_copy>, + client_pf = {bits_per_pixel = 32 ' ', bytes_per_pixel = 4 '\004', depth = 24 '\030', rmask = 16711680, + gmask = 65280, bmask = 255, amask = 0, rshift = 16 '\020', gshift = 8 '\b', bshift = 0 '\000', ashift = 24 '\030', + rmax = 255 '\377', gmax = 255 '\377', bmax = 255 '\377', amax = 0 '\000', rbits = 8 '\b', gbits = 8 '\b', + bbits = 8 '\b', abits = 0 '\000'}, client_format = 0, client_be = false, audio_cap = 0x0, as = {freq = 44100, + nchannels = 2, fmt = AUD_FMT_S16, endianness = 0}, read_handler = 0x5555559dbdc0 <protocol_client_msg>, + read_handler_expect = 1, modifiers_state = '\000' <repeats 255 times>, led = 0x5555572f5c40, abort = false, + initialized = true, output_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, + __kind = -1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 16 times>, "\377\377\377\377", '\000' <repeats 19 times>, __align = 0}}, + bh = 0x555557929d00, jobs_buffer = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, tight = { + type = 7, quality = 255 '\377', compression = 9 '\t', pixel24 = 1 '\001', tight = {name = 0x0, capacity = 0, + offset = 0, avg_size = 1890052, buffer = 0x0}, tmp = {name = 0x7fff9c0d3830 "vnc-worker-output", + capacity = 32768, offset = 26162, avg_size = 4194304, buffer = 0x555557786540 "\330R\303\364\377\177"}, zlib = { + name = 0x0, capacity = 0, offset = 0, avg_size = 524288, buffer = 0x0}, gradient = {name = 0x0, capacity = 0, + offset = 0, avg_size = 0, buffer = 0x0}, jpeg = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, + buffer = 0x0}, png = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, levels = {9, 9, 9, 0}, + stream = {{next_in = 0x7fff9c1341f0 "", avail_in = 0, total_in = 282144, + next_out = 0x7fff9c0640fd "\256\022\352]\002\210n\021rg\b\271\v\204\334\361\001", avail_out = 4083, + total_out = 40323, msg = 0x0, state = 0x0, zalloc = 0x5555559deb40 <vnc_zlib_zalloc>, + zfree = 0x5555559deb50 <vnc_zlib_zfree>, opaque = 0x7fffaabec3f0, data_type = 0, adler = 1422910222, + reserved = 0}, {next_in = 0x7fff9c134210 "", avail_in = 0, total_in = 3212411, + next_out = 0x7fff9c0640f9 "\377\235&\344\256\022\352]\002\210n\021rg\b\271\v\204\334\361\001", + avail_out = 4087, total_out = 1563572, msg = 0x0, state = 0x0, zalloc = 0x5555559deb40 <vnc_zlib_zalloc>, + zfree = 0x5555559deb50 <vnc_zlib_zfree>, opaque = 0x7fffaabec3f0, data_type = 0, adler = 2665424950, + reserved = 0}, {next_in = 0x7fff9c134440 "", avail_in = 0, total_in = 1057759, + next_out = 0x7fff9c064148 ">E\025\322fI \220\262\320\322\024", avail_out = 4008, total_out = 83411, msg = 0x0, + state = 0x0, zalloc = 0x5555559deb40 <vnc_zlib_zalloc>, zfree = 0x5555559deb50 <vnc_zlib_zfree>, + opaque = 0x7fffaabec3f0, data_type = 0, adler = 3032660148, reserved = 0}, {next_in = 0x0, avail_in = 0, + total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0x0, zfree = 0x0, + opaque = 0x0, data_type = 0, adler = 0, reserved = 0}}}, zlib = {zlib = {name = 0x0, capacity = 0, offset = 0, + avg_size = 0, buffer = 0x0}, tmp = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, stream = { + next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, + zalloc = 0x0, zfree = 0x0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, level = 0}, hextile = { + send_tile = 0x5555559df670 <send_hextile_tile_32>}, zrle = {type = 0, fb = {name = 0x0, capacity = 0, offset = 0, + avg_size = 0, buffer = 0x0}, zrle = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, tmp = { + name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, zlib = {name = 0x0, capacity = 0, offset = 0, + avg_size = 0, buffer = 0x0}, stream = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, + total_out = 0, msg = 0x0, state = 0x0, zalloc = 0x0, zfree = 0x0, opaque = 0x0, data_type = 0, adler = 0, + reserved = 0}, palette = {pool = {{idx = 0, color = 0, next = {le_next = 0x0, + le_prev = 0x0}} <repeats 256 times>}, size = 0, max = 0, bpp = 0, table = {{ + lh_first = 0x0} <repeats 256 times>}}}, zywrle = {buf = {0 <repeats 4096 times>}}, mouse_mode_notifier = { + notify = 0x5555559db450 <check_pointer_type_change>, node = {le_next = 0x0, + le_prev = 0x5555560586f8 <mouse_mode_notifiers>}}, next = {tqe_next = 0x0, tqe_prev = 0x5555585000a0}} + + + +QEMU build config: + +Install prefix /usr +BIOS directory /usr/share/qemu +binary directory /usr/bin +library directory /usr/lib +module directory /usr/lib/qemu +libexec directory /usr/lib/qemu +include directory /usr/include +config directory /etc +local state directory /var +Manual directory /usr/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/me/build/qemu/src/qemu-git +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fPIC +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/spice-1 -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -Wl,-O1,--sort-common,--as-needed,-z,relro +make make +install install +python /usr/bin/python2 -B +smbd /usr/sbin/smbd +module support yes +host CPU x86_64 +host big endian no +target list x86_64-softmmu i386-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (1.2.15) +GTK support no +GTK GL support no +VTE support no +GNUTLS support no +GNUTLS hash no +GNUTLS rnd no +libgcrypt no +libgcrypt kdf no +nettle no +nettle kdf no +libtasn1 yes +curses support yes +virgl support no +curl support no +mingw32 support no +Audio drivers sdl +Block whitelist (rw) +Block whitelist (ro) +VirtFS support no +VNC support yes +VNC SASL support no +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support no +Documentation yes +PIE yes +vde support yes +netmap support no +Linux AIO support yes +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support no +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +uuid support yes +libcap-ng support yes +vhost-net support yes +vhost-scsi support yes +Trace backends nop +spice support yes (0.12.10/0.12.6) +rbd support no +xfsctl support yes +smartcard support no +libusb yes +usb net redir no +OpenGL support no +OpenGL dmabufs no +libiscsi support no +libnfs support no +build guest agent no +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support yes +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support no +TPM passthrough yes +QOM debugging yes +vhdx no +lzo support no +snappy support no +bzip2 support no +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization yes + +The only place we free the mutex is in vnc_disconnect_finish() which is only ever called from vnc_client_read(), in turn called from vnc_client_io(). + +We're crashing in vnc_client_write() which is called from vnc_client_io(). + +The stack trace has optimized out the "condition" param in vnc_client_io(), but what I'm guessing is that vnc_client_io() is invoked with both G_IO_OUT and G_IO_IN set. We process G_IO_IN, calling vnc_disconnect_finish, and then carry on to process G_IO_OUT. It looks like we need to skip the G_IO_OUT processing if we called vnc_disconnect_finish during G_IO_IN handling + +Potential fix posted + +https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07693.html + +If you are able to test with this patch any feedback would be welcome. + +Fix has been included in QEMU v2.7.0: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ea697449884d83b83fefb + diff --git a/results/classifier/118/review/1596870 b/results/classifier/118/review/1596870 new file mode 100644 index 000000000..186270ad3 --- /dev/null +++ b/results/classifier/118/review/1596870 @@ -0,0 +1,73 @@ +mistranslation: 0.902 +device: 0.873 +network: 0.609 +graphic: 0.561 +files: 0.488 +semantic: 0.425 +ppc: 0.393 +boot: 0.392 +architecture: 0.361 +register: 0.309 +vnc: 0.306 +i386: 0.281 +performance: 0.248 +debug: 0.218 +PID: 0.204 +risc-v: 0.191 +arm: 0.167 +user-level: 0.167 +x86: 0.132 +kernel: 0.125 +socket: 0.121 +TCG: 0.116 +hypervisor: 0.104 +virtual: 0.081 +assembly: 0.079 +permissions: 0.072 +VMM: 0.071 +peripherals: 0.055 +KVM: 0.018 +-------------------- +hypervisor: 0.320 +network: 0.244 +files: 0.203 +debug: 0.150 +virtual: 0.126 +user-level: 0.055 +register: 0.032 +x86: 0.020 +TCG: 0.019 +semantic: 0.018 +device: 0.008 +ppc: 0.004 +socket: 0.004 +i386: 0.002 +assembly: 0.002 +performance: 0.002 +kernel: 0.002 +PID: 0.002 +arm: 0.002 +boot: 0.001 +graphic: 0.001 +architecture: 0.001 +risc-v: 0.001 +permissions: 0.001 +KVM: 0.001 +peripherals: 0.001 +VMM: 0.001 +vnc: 0.000 +mistranslation: 0.000 + +qemu-img backed over https fails on zero-length file + +When creating new disk with qemu-img backed by file accessed over HTTPS and the backing file has zero length, qemu-img fails with uninformative error: + + qemu-img: disk.qcow2: CURL: Error opening file: + +The error message should either be improved, or the operation on zero-length file should be allowed. Some other backends, as e.g. raw backend for regular files, seem to allow empty files. + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a41c457881b5463b18901a849 + +Released with QEMU v2.8 + diff --git a/results/classifier/118/review/1600112 b/results/classifier/118/review/1600112 new file mode 100644 index 000000000..5a809e9fa --- /dev/null +++ b/results/classifier/118/review/1600112 @@ -0,0 +1,84 @@ +mistranslation: 0.943 +graphic: 0.824 +device: 0.664 +network: 0.614 +vnc: 0.592 +performance: 0.538 +semantic: 0.502 +socket: 0.491 +architecture: 0.441 +PID: 0.430 +register: 0.425 +ppc: 0.421 +risc-v: 0.411 +kernel: 0.392 +permissions: 0.384 +debug: 0.361 +TCG: 0.349 +boot: 0.346 +VMM: 0.345 +x86: 0.341 +hypervisor: 0.337 +peripherals: 0.330 +i386: 0.320 +files: 0.303 +arm: 0.297 +user-level: 0.257 +virtual: 0.222 +KVM: 0.178 +assembly: 0.149 +-------------------- +hypervisor: 0.171 +TCG: 0.127 +user-level: 0.103 +graphic: 0.100 +x86: 0.042 +semantic: 0.041 +debug: 0.034 +virtual: 0.034 +files: 0.028 +device: 0.014 +arm: 0.010 +network: 0.008 +risc-v: 0.006 +performance: 0.006 +i386: 0.005 +ppc: 0.005 +PID: 0.004 +mistranslation: 0.004 +register: 0.002 +socket: 0.002 +kernel: 0.002 +boot: 0.001 +architecture: 0.001 +permissions: 0.001 +vnc: 0.001 +peripherals: 0.001 +assembly: 0.001 +VMM: 0.000 +KVM: 0.000 + +Qemu GTK interface showing question marks instead of correct strings + +Qemu version: 2.6.0 + +When running Qemu system emulation (configured with GTK interface), all interface strings shows up as question marks instead of the correct translated strings. Tested on locale zh_CN.UTF-8. + +I have attached a screenshot below for better understanding. + + + +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/review/1603636 b/results/classifier/118/review/1603636 new file mode 100644 index 000000000..18c7a57e9 --- /dev/null +++ b/results/classifier/118/review/1603636 @@ -0,0 +1,537 @@ +risc-v: 0.827 +permissions: 0.819 +user-level: 0.805 +register: 0.789 +virtual: 0.787 +performance: 0.787 +graphic: 0.779 +architecture: 0.758 +debug: 0.750 +TCG: 0.737 +semantic: 0.733 +arm: 0.732 +KVM: 0.729 +ppc: 0.727 +network: 0.721 +device: 0.715 +socket: 0.708 +PID: 0.705 +files: 0.695 +kernel: 0.676 +x86: 0.639 +boot: 0.638 +vnc: 0.636 +assembly: 0.631 +i386: 0.628 +hypervisor: 0.595 +VMM: 0.594 +peripherals: 0.545 +mistranslation: 0.504 +-------------------- +debug: 0.995 +i386: 0.994 +ppc: 0.974 +virtual: 0.828 +x86: 0.814 +boot: 0.473 +hypervisor: 0.226 +kernel: 0.173 +user-level: 0.069 +PID: 0.068 +TCG: 0.044 +performance: 0.025 +register: 0.020 +semantic: 0.014 +files: 0.013 +assembly: 0.009 +architecture: 0.009 +device: 0.006 +risc-v: 0.005 +graphic: 0.004 +KVM: 0.004 +VMM: 0.003 +socket: 0.003 +network: 0.003 +peripherals: 0.002 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.001 + +Guest has not initialized the display yet on ubuntu 16.10 PPC + +Hi +tested with all kind of configure, with all kind of machine types but i have the same issue ... +on lastest quemo 2.6 "Guest has not initialized the display yet" +note with lastest git repository the situation become worst because on i386-softmmu i have the message but qemu exit alone because looklike there is not a bios + +this is gdb of i386-softmmu + +(gdb) run +Starting program: /home/amigaone/src/qemu/i386-softmmu/qemu-system-i386 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". +[New Thread 0xf7f78b70 (LWP 25074)] +[New Thread 0xf770bb70 (LWP 25075)] +[New Thread 0xf6dfdb70 (LWP 25076)] +[New Thread 0xf65fdb70 (LWP 25077)] +[New Thread 0xf3337b70 (LWP 25078)] +[New Thread 0xe4146b70 (LWP 25087)] +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +[Thread 0xe4146b70 (LWP 25087) exited] +[Thread 0xf65fdb70 (LWP 25077) exited] +[Thread 0xf6dfdb70 (LWP 25076) exited] +[Thread 0xf770bb70 (LWP 25075) exited] +[Thread 0xf7f78b70 (LWP 25074) exited] +[Thread 0xf7f7c000 (LWP 25070) exited] +[Inferior 1 (process 25070) exited with code 01] + + +this is my ldd +ldd ./qemu-system-i386 + linux-vdso32.so.1 => (0x00100000) + libvirglrenderer.so.0 => /usr/local/lib/libvirglrenderer.so.0 (0x0ff8a000) + libepoxy.so.0 => /usr/lib/powerpc-linux-gnu/libepoxy.so.0 (0x0fe86000) + libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x0fe55000) + libX11.so.6 => /usr/lib/powerpc-linux-gnu/libX11.so.6 (0x0fcf2000) + libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0fcb1000) + libcurl-gnutls.so.4 => /usr/lib/powerpc-linux-gnu/libcurl-gnutls.so.4 (0x0fc10000) + libssh2.so.1 => /usr/lib/powerpc-linux-gnu/libssh2.so.1 (0x0fbbf000) + libbz2.so.1.0 => /lib/powerpc-linux-gnu/libbz2.so.1.0 (0x0fb7e000) + libpixman-1.so.0 => /usr/lib/powerpc-linux-gnu/libpixman-1.so.0 (0x0fadd000) + libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0faac000) + libnuma.so.1 => /usr/lib/powerpc-linux-gnu/libnuma.so.1 (0x0fa79000) + libncurses.so.5 => /lib/powerpc-linux-gnu/libncurses.so.5 (0x0fa28000) + libtinfo.so.5 => /lib/powerpc-linux-gnu/libtinfo.so.5 (0x0f9d7000) + libuuid.so.1 => /lib/powerpc-linux-gnu/libuuid.so.1 (0x0f9a6000) + libpng16.so.16 => /usr/lib/powerpc-linux-gnu/libpng16.so.16 (0x0f945000) + libjpeg.so.8 => /usr/lib/powerpc-linux-gnu/libjpeg.so.8 (0x0f8d4000) + libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x0f77d000) + libnettle.so.6 => /usr/lib/powerpc-linux-gnu/libnettle.so.6 (0x0f71c000) + libgnutls.so.30 => /usr/lib/powerpc-linux-gnu/libgnutls.so.30 (0x0f5ca000) + libgtk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgtk-x11-2.0.so.0 (0x0f0e6000) + libgdk-x11-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk-x11-2.0.so.0 (0x0f005000) + libcairo.so.2 => /usr/lib/powerpc-linux-gnu/libcairo.so.2 (0x0eec3000) + libgdk_pixbuf-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x0ee72000) + libgobject-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgobject-2.0.so.0 (0x0edf1000) + libglib-2.0.so.0 => /lib/powerpc-linux-gnu/libglib-2.0.so.0 (0x0eca0000) + libsnappy.so.1 => /usr/lib/powerpc-linux-gnu/libsnappy.so.1 (0x0ec6f000) + libusb-1.0.so.0 => /lib/powerpc-linux-gnu/libusb-1.0.so.0 (0x0ec2e000) + librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ebfd000) + libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0eb0c000) + libgcc_s.so.1 => /lib/powerpc-linux-gnu/libgcc_s.so.1 (0x0eacb000) + libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0ea88000) + libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0e8d4000) + libdrm.so.2 => /usr/lib/powerpc-linux-gnu/libdrm.so.2 (0x0e8a3000) + libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0e872000) + libexpat.so.1 => /lib/powerpc-linux-gnu/libexpat.so.1 (0x0e821000) + libxcb.so.1 => /usr/lib/powerpc-linux-gnu/libxcb.so.1 (0x0e7e0000) + libidn.so.11 => /lib/powerpc-linux-gnu/libidn.so.11 (0x0e77f000) + librtmp.so.1 => /usr/lib/powerpc-linux-gnu/librtmp.so.1 (0x0e73e000) + libgssapi_krb5.so.2 => /usr/lib/powerpc-linux-gnu/libgssapi_krb5.so.2 (0x0e6cd000) + liblber-2.4.so.2 => /usr/lib/powerpc-linux-gnu/liblber-2.4.so.2 (0x0e69c000) + libldap_r-2.4.so.2 => /usr/lib/powerpc-linux-gnu/libldap_r-2.4.so.2 (0x0e61a000) + libgcrypt.so.20 => /lib/powerpc-linux-gnu/libgcrypt.so.20 (0x0e527000) + /lib/ld.so.1 (0x200a9000) + libsndio.so.6.1 => /usr/lib/powerpc-linux-gnu/libsndio.so.6.1 (0x0e4f4000) + libp11-kit.so.0 => /usr/lib/powerpc-linux-gnu/libp11-kit.so.0 (0x0e473000) + libtasn1.so.6 => /usr/lib/powerpc-linux-gnu/libtasn1.so.6 (0x0e432000) + libhogweed.so.4 => /usr/lib/powerpc-linux-gnu/libhogweed.so.4 (0x0e3d1000) + libgmp.so.10 => /usr/lib/powerpc-linux-gnu/libgmp.so.10 (0x0e330000) + libgmodule-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgmodule-2.0.so.0 (0x0e2ff000) + libpangocairo-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpangocairo-1.0.so.0 (0x0e2ce000) + libXfixes.so.3 => /usr/lib/powerpc-linux-gnu/libXfixes.so.3 (0x0e29d000) + libatk-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libatk-1.0.so.0 (0x0e24c000) + libgio-2.0.so.0 => /usr/lib/powerpc-linux-gnu/libgio-2.0.so.0 (0x0e05a000) + libpangoft2-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpangoft2-1.0.so.0 (0x0e019000) + libpango-1.0.so.0 => /usr/lib/powerpc-linux-gnu/libpango-1.0.so.0 (0x0dfa8000) + libfontconfig.so.1 => /usr/lib/powerpc-linux-gnu/libfontconfig.so.1 (0x0df33000) + libXrender.so.1 => /usr/lib/powerpc-linux-gnu/libXrender.so.1 (0x0df02000) + libXinerama.so.1 => /usr/lib/powerpc-linux-gnu/libXinerama.so.1 (0x0dedf000) + libXi.so.6 => /usr/lib/powerpc-linux-gnu/libXi.so.6 (0x0de9e000) + libXrandr.so.2 => /usr/lib/powerpc-linux-gnu/libXrandr.so.2 (0x0de6d000) + libXcursor.so.1 => /usr/lib/powerpc-linux-gnu/libXcursor.so.1 (0x0de42000) + libXcomposite.so.1 => /usr/lib/powerpc-linux-gnu/libXcomposite.so.1 (0x0de1f000) + libXdamage.so.1 => /usr/lib/powerpc-linux-gnu/libXdamage.so.1 (0x0ddfc000) + libXext.so.6 => /usr/lib/powerpc-linux-gnu/libXext.so.6 (0x0ddc8000) + libfreetype.so.6 => /usr/lib/powerpc-linux-gnu/libfreetype.so.6 (0x0dcf7000) + libxcb-shm.so.0 => /usr/lib/powerpc-linux-gnu/libxcb-shm.so.0 (0x0dcc6000) + libxcb-render.so.0 => /usr/lib/powerpc-linux-gnu/libxcb-render.so.0 (0x0dc95000) + libffi.so.6 => /usr/lib/powerpc-linux-gnu/libffi.so.6 (0x0dc64000) + libpcre.so.3 => /lib/powerpc-linux-gnu/libpcre.so.3 (0x0dbd3000) + libstdc++.so.6 => /usr/lib/powerpc-linux-gnu/libstdc++.so.6 (0x0d9df000) + libudev.so.1 => /lib/powerpc-linux-gnu/libudev.so.1 (0x0d99d000) + libXau.so.6 => /usr/lib/powerpc-linux-gnu/libXau.so.6 (0x0d979000) + libXdmcp.so.6 => /usr/lib/powerpc-linux-gnu/libXdmcp.so.6 (0x0d948000) + libkrb5.so.3 => /usr/lib/powerpc-linux-gnu/libkrb5.so.3 (0x0d857000) + libk5crypto.so.3 => /usr/lib/powerpc-linux-gnu/libk5crypto.so.3 (0x0d806000) + libcom_err.so.2 => /lib/powerpc-linux-gnu/libcom_err.so.2 (0x0d7d5000) + libkrb5support.so.0 => /usr/lib/powerpc-linux-gnu/libkrb5support.so.0 (0x0d7a4000) + libresolv.so.2 => /lib/powerpc-linux-gnu/libresolv.so.2 (0x0d761000) + libsasl2.so.2 => /usr/lib/powerpc-linux-gnu/libsasl2.so.2 (0x0d720000) + libgssapi.so.3 => /usr/lib/powerpc-linux-gnu/libgssapi.so.3 (0x0d6be000) + libgpg-error.so.0 => /lib/powerpc-linux-gnu/libgpg-error.so.0 (0x0d67d000) + libasound.so.2 => /usr/lib/powerpc-linux-gnu/libasound.so.2 (0x0d54c000) + libbsd.so.0 => /lib/powerpc-linux-gnu/libbsd.so.0 (0x0d50b000) + libselinux.so.1 => /lib/powerpc-linux-gnu/libselinux.so.1 (0x0d4b9000) + libharfbuzz.so.0 => /usr/lib/powerpc-linux-gnu/libharfbuzz.so.0 (0x0d408000) + libthai.so.0 => /usr/lib/powerpc-linux-gnu/libthai.so.0 (0x0d3d7000) + libkeyutils.so.1 => /lib/powerpc-linux-gnu/libkeyutils.so.1 (0x0d3a6000) + libheimntlm.so.0 => /usr/lib/powerpc-linux-gnu/libheimntlm.so.0 (0x0d375000) + libkrb5.so.26 => /usr/lib/powerpc-linux-gnu/libkrb5.so.26 (0x0d2c3000) + libasn1.so.8 => /usr/lib/powerpc-linux-gnu/libasn1.so.8 (0x0d201000) + libhcrypto.so.4 => /usr/lib/powerpc-linux-gnu/libhcrypto.so.4 (0x0d19f000) + libroken.so.18 => /usr/lib/powerpc-linux-gnu/libroken.so.18 (0x0d15e000) + libgraphite2.so.3 => /usr/lib/powerpc-linux-gnu/libgraphite2.so.3 (0x0d10d000) + libdatrie.so.1 => /usr/lib/powerpc-linux-gnu/libdatrie.so.1 (0x0d0dc000) + libwind.so.0 => /usr/lib/powerpc-linux-gnu/libwind.so.0 (0x0d08b000) + libheimbase.so.1 => /usr/lib/powerpc-linux-gnu/libheimbase.so.1 (0x0d05a000) + libhx509.so.5 => /usr/lib/powerpc-linux-gnu/libhx509.so.5 (0x0cfe8000) + libsqlite3.so.0 => /usr/lib/powerpc-linux-gnu/libsqlite3.so.0 (0x0ceb6000) + libcrypt.so.1 => /lib/powerpc-linux-gnu/libcrypt.so.1 (0x0ce5e000) + + +Thanks + +In the title, you talk about PPC, but in the bug description, you talk about i386 ... quite confusing, please try to be consistent. But since you say that you run into this problem with all machine types, this sounds like a configuration problem to me. +Can you please specify how you run the configure script and what output you get there? Also, did you do a "make install" or are you trying to run QEMU from the folder where you compiled it? What output do you get if you run qemu-system-ppc64 with "-nographic" option? + +Hi T, +yes it is the emulated i386 machine qemu-system-i386 and it was working since something change in 2.6. +but issue is present in ppc machine too. dint try the kvm because on ppcemb there is not vga output. + +I had try the 2.5.1 and build and work and confirmed the issue is present only in 2.6 + + +ususally i build it with this : +./configure --with-sdlabi=2.0 --audio-drv-list=pa,sdl --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu + +i had been try with sdlabi=1.2 and without audio and without target list but have the same issue. +after work i will write my configure output probably can help? + + +Luigi + +Ah, you mean your *host* is running Ubuntu 16.10 PPC (i.e. not your guest)? Only looking at the title of this bug, I was assuming you were talking about the guest running Ubuntu 16.10 PPC (i.e. the host could also be a x86 machine)... +So yes, please provide also the output of "./configure ..." and specify the exact command line parameter that you use to run the emulator. + +Hi tony this are my configurations command i use for run the qemu-system-i386 +note it is working on 2.5.1 and 2.6 old release attached a shot you can see all is working in previous versions of 2.6 + +Aros: +qemu-system-i386 -m 2047 -drive file=/mnt/c7a1331a-6bfe-436e-b43d-fe2afead48e9/Aros.img,id=disk0,format=raw -net nic,model=rtl8139 -net user,smb=/home/amigaone/shared/ -vga vmware -balloon none -display sdl -cpu athlon -mem-prealloc -device virtio-scsi-pci,id=scsi -soundhw es1370 -cdrom /home/amigaone/emulators.iso + +Win98: +qemu-system-i386 -m 256 -drive file=/media/amigaone/mame/vhd/win98.img,id=disk0,format=raw -vga cirrus -display sdl -balloon none -mem-prealloc -device virtio-scsi-pci,id=scsi -rtc clock=host,base=localtime -serial none -parallel none + +winXP: + +qemu-system-i386 -m 2047 -drive file=/media/amigaone/mame/vhd/xp_black,id=disk0,format=raw -net nic,model=rtl8139 -net user,smb=/home/amigaone/shared/ -vga virtio -balloon virtio -display sdl -cpu athlon -mem-prealloc + + + +but qemu is working if only i open it thru qemu-system-i386 ... i have default setting with 128mb and bios running ... + +with lastest git not only "Guest has not initialized the display yet " or quitting like i described before... + +This is my complete configure from beginning + +./configure --with-sdlabi=2.0 --audio-drv-list=pa,sdl --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu,ppcemb-softmmu + +ERROR: DTC (libfdt) version >= 1.4.0 not present. Your options: + (1) Preferred: Install the DTC (libfdt) devel package + (2) Fetch the DTC submodule, using: + git submodule update --init dtc + +amigaone@Amigaone:~/src/qemu$ git submodule update --init dtc +Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' +Cloning into 'dtc'... +remote: Counting objects: 2778, done. +remote: Compressing objects: 100% (1692/1692), done. +remote: Total 2778 (delta 2058), reused 1415 (delta 1056) +Receiving objects: 100% (2778/2778), 654.26 KiB | 376.00 KiB/s, done. +Resolving deltas: 100% (2058/2058), done. +Checking connectivity... done. +Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf' +amigaone@Amigaone:~/src/qemu$ ./configure --with-sdlabi=2.0 --audio-drv-list=pa,sdl --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu,ppcemb-softmmu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/amigaone/src/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler clang +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -g +QEMU_CFLAGS -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt -Werror -DHAS_LIBSSH2_SFTP_FSYNC -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/local/include -I/usr/include/libpng16 -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -m32 -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU ppc +host big endian yes +target list i386-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (2.0.4) +GTK support yes (2.24.30) +GTK GL support no +VTE support no +TLS priority NORMAL +GNUTLS support yes +GNUTLS rnd yes +libgcrypt no +libgcrypt kdf no +nettle yes (3.2) +nettle kdf yes +libtasn1 yes +curses support yes +virgl support yes +curl support yes +mingw32 support no +Audio drivers pa sdl +Block whitelist (rw) +Block whitelist (ro) +VirtFS support no +VNC support yes +VNC SASL support no +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support no +Documentation yes +PIE no +vde support no +netmap support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backends log +spice support no +rbd support no +xfsctl support no +smartcard support no +libusb yes +usb net redir no +OpenGL support yes +OpenGL dmabufs yes +libiscsi support no +libnfs support no +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support yes +TPM passthrough no +QOM debugging yes +vhdx yes +lzo support no +snappy support yes +bzip2 support yes +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization no + + + + +one shot +of qemu-system-i386 2.6 old version, oldest was working + + + +Hi T, +i just make a test on My Quad G5 and Mate 15.10 and here i have the same issue ... no video on last 2.6. I think this issue is present on all ppc world + +Can you use "git bisect" to determine the exact commit that causes this problem to appear? + +Hi T, +i can gave a try ... i never used "git bisect" +i have to use it with the executable? with "git bisect log" or somthing else? + +You initially have to specify a commit that is known to fail, and one that is known to work, so in this case it's likely: + git bisect start master v2.6.0 +It then checks out a revision inbetween. Compile it with "make" and run the built QEMU to check whether it is working or not. +If it is not working, use this command to continue: + git bisect bad +If it was working, use this command instead: + git bisect good +Then continue to compile and test the next revision. git bisect should guide you this way to the commit that introduced the bug. + +Hi T, +thanks for the infos i will report ASAP + +Hi T, found! + +this was last bad a select + +git bisect bad +Bisecting: 101 revisions left to test after this (roughly 7 steps) +[f68419eee9a966f5a915314c43cda6778f976a77] Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging + +this is the good + + +git bisect good +Bisecting: 58 revisions left to test after this (roughly 6 steps) +[14fccfa91ecac7af36ac03dc1c2bb9a1d7fbca26] Merge remote-tracking branch 'remotes/lalrae/tags/mips-20160513' into staging + + +Ciao +Luigi + + +but what i see in this working there isnt your sdl2 patch. + + +If git bisect says something about "XX revisions left to test after this" then you're not done yet, you have to continue the git bisecting process until it is finished. +And if you need the sdl2 patch additionally, you have to apply it manually after each step if necessary. I'm sorry, it's quite cumbersome, but likely still the best solution to determine where your problem comes from. + +Hi T, +Ok. I m sorry i was thinking only this was needed i will made the other git bisect and report + +Luigi + +Hi t, + +this is what you need? +70f87e0f0aa04f764dabaeb3ed71ff195748076a is the first bad commit + + +Hi t, +just to notice the 2.7 is effected too :-( + +./qemu-system-i386 +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +amigaone@Amigaone:~/src/pippo/qemu/i386-softmmu$ ./qemu-system-i386 -m 1024 +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + +amigaone@Amigaone:~/src/pippo/qemu/i386-softmmu$ ./qemu-system-i386 --version +QEMU emulator version 2.6.90 (v2.7.0-rc0-10-gf49ee63-dirty), Copyright (c) 2003-2008 Fabrice Bellard + + +Hi T, +im checking and testing the lastest qemu and i understand +the issue is present only with all softmmu system . +if i open eg qemu-system-ppc64 i have the issue +if i open qemu-system-ppc64 with kvm enabled the issue isnt present and all run like have to be. + +It means all the emulated machine not work , virtualized only run. +in my case on g5 quad i cant emulate an X86 or a old world mac +but i can virtualize my g5 quad with a debian. +same is on p5020 machine. + +Hope it help + + Hi Luigi, + +70f87e0f0aa04f764dabaeb3ed71ff195748076a is a merge commit ... that should not have shown up as a result from bisecting. +Anyway, since it is pointing to a ui merge ... could you please: + +1) check whether it is still working fine with the first patch of that ui series, i.e.: + git checkout 4fd811a6bd0b8f24f4761fc281454494c336d310 + and then compile and test that version + +2) check whether it is really hanging / not working withe the last patch of that ui series, i.e.: + git checkout 6978dc4adcdf27722aa6f9e13f88a903b30a3f8d + and then compile and test that version + +Thanks! + +Hi T, +bad news i had to format my partition with 16.10 and dont have the 2.6.0 src any more if there is a way to git clone it please letme know. +note : 2.6.1 have the issue , 2.7.x is effected too. + +Luigi + +Alll revisions are available in the git repository, so please simply do: + + git clone git://git.qemu-project.org/qemu.git + cd qemu + git checkout 4fd811a6bd0b8f24f4761fc281454494c336d310 + ./configure ... + make -j4 + +And then check whether it is working or not. +Once you're done, switch to the other revision and compile again: + + git checkout 6978dc4adcdf27722aa6f9e13f88a903b30a3f8d + make -j4 + +and check whether that one is working or not. + +Hi T, +good news the 2.6.2 is working without the issue reported, but it not include your previous patches . +Ciao +Luigi + diff --git a/results/classifier/118/review/1614521 b/results/classifier/118/review/1614521 new file mode 100644 index 000000000..832d8a01d --- /dev/null +++ b/results/classifier/118/review/1614521 @@ -0,0 +1,68 @@ +mistranslation: 0.959 +device: 0.784 +socket: 0.684 +performance: 0.676 +semantic: 0.670 +network: 0.651 +architecture: 0.608 +peripherals: 0.556 +kernel: 0.535 +ppc: 0.523 +files: 0.463 +register: 0.458 +vnc: 0.455 +boot: 0.376 +graphic: 0.352 +debug: 0.317 +hypervisor: 0.298 +arm: 0.257 +x86: 0.219 +user-level: 0.212 +virtual: 0.200 +risc-v: 0.196 +assembly: 0.185 +TCG: 0.176 +i386: 0.147 +permissions: 0.125 +VMM: 0.050 +PID: 0.044 +KVM: 0.031 +-------------------- +hypervisor: 0.632 +KVM: 0.150 +user-level: 0.102 +TCG: 0.069 +debug: 0.062 +virtual: 0.062 +register: 0.058 +files: 0.053 +x86: 0.029 +VMM: 0.026 +kernel: 0.023 +semantic: 0.017 +device: 0.014 +network: 0.008 +assembly: 0.008 +arm: 0.007 +PID: 0.007 +risc-v: 0.005 +i386: 0.005 +ppc: 0.005 +peripherals: 0.004 +socket: 0.003 +graphic: 0.003 +architecture: 0.002 +boot: 0.002 +vnc: 0.002 +permissions: 0.002 +performance: 0.001 +mistranslation: 0.000 + +-display accepts "none[a-z,0-9]*" instead of 'none' + +When using the '-display' option the parameter 'none' is not the only string that causes the behaviour of 'none'. I can use '-display noneMICKEYMOUSE' and still have the none behaviour. + +Fixed in: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c9498c3e44cd5574 + diff --git a/results/classifier/118/review/1614609 b/results/classifier/118/review/1614609 new file mode 100644 index 000000000..f9ef9dda0 --- /dev/null +++ b/results/classifier/118/review/1614609 @@ -0,0 +1,112 @@ +mistranslation: 0.915 +device: 0.871 +boot: 0.842 +ppc: 0.781 +peripherals: 0.752 +kernel: 0.749 +risc-v: 0.718 +vnc: 0.715 +files: 0.697 +VMM: 0.691 +network: 0.688 +socket: 0.685 +permissions: 0.683 +TCG: 0.680 +PID: 0.679 +architecture: 0.675 +arm: 0.655 +hypervisor: 0.643 +KVM: 0.637 +performance: 0.632 +register: 0.623 +x86: 0.573 +i386: 0.556 +assembly: 0.531 +graphic: 0.528 +user-level: 0.501 +virtual: 0.384 +debug: 0.358 +semantic: 0.270 +-------------------- +boot: 0.893 +user-level: 0.497 +hypervisor: 0.235 +KVM: 0.179 +VMM: 0.164 +kernel: 0.149 +debug: 0.144 +virtual: 0.140 +files: 0.091 +x86: 0.043 +semantic: 0.039 +TCG: 0.038 +device: 0.037 +register: 0.011 +risc-v: 0.007 +i386: 0.006 +PID: 0.005 +assembly: 0.004 +performance: 0.003 +ppc: 0.003 +network: 0.003 +socket: 0.003 +graphic: 0.003 +architecture: 0.002 +vnc: 0.001 +arm: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 + +alphabetical order of monitor options + +Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. +It had me overlook the 'cont' option at glance. Which is just a little impractical. + +... +boot_set bootdevice -- define new values for the boot device list +change device filename [format [read-only-mode]] -- change a removable medium, optional format +chardev-add args -- add chardev +chardev-remove id -- remove chardev +client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display +closefd closefd name -- close a file descriptor previously passed via SCM rights +commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files +cpu index -- set the default CPU +cpu-add id -- add cpu +c|cont -- resume emulation +delvm tag|id -- delete a VM snapshot from its tag or id +... + +I tested this list with 'sort' just to make sure and make a point: + +$ cat Desktop/order-orig.txt +boot_set +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +c|cont +delvm +$ cat Desktop/order-orig.txt | sort +boot_set +c|cont +change +chardev-add +chardev-remove +client_migrate_info +closefd +commit +cpu +cpu-add +delvm +$ + +Should be fixed by this patch: https://<email address hidden>/ + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/ff688cd2c7c3a677b71e + diff --git a/results/classifier/118/review/1618265 b/results/classifier/118/review/1618265 new file mode 100644 index 000000000..04d9375ab --- /dev/null +++ b/results/classifier/118/review/1618265 @@ -0,0 +1,66 @@ +user-level: 0.925 +peripherals: 0.904 +device: 0.825 +mistranslation: 0.815 +kernel: 0.763 +architecture: 0.758 +graphic: 0.751 +ppc: 0.745 +performance: 0.723 +semantic: 0.658 +boot: 0.639 +socket: 0.596 +register: 0.578 +risc-v: 0.557 +VMM: 0.543 +vnc: 0.538 +permissions: 0.505 +PID: 0.471 +arm: 0.436 +network: 0.421 +x86: 0.407 +i386: 0.391 +TCG: 0.370 +files: 0.301 +debug: 0.243 +KVM: 0.231 +virtual: 0.221 +assembly: 0.217 +hypervisor: 0.086 +-------------------- +virtual: 0.952 +hypervisor: 0.635 +kernel: 0.613 +x86: 0.334 +user-level: 0.301 +peripherals: 0.185 +boot: 0.160 +TCG: 0.062 +debug: 0.050 +files: 0.046 +device: 0.023 +i386: 0.017 +VMM: 0.014 +semantic: 0.013 +KVM: 0.012 +register: 0.011 +ppc: 0.010 +socket: 0.010 +architecture: 0.008 +PID: 0.006 +risc-v: 0.004 +assembly: 0.004 +permissions: 0.003 +arm: 0.003 +performance: 0.003 +network: 0.002 +graphic: 0.002 +vnc: 0.001 +mistranslation: 0.000 + +Loading virtio-input-host-pci drivers before boot? To allow using passthrough devices in grub and other preboot menus? + +Currently virtio-input devices cannot be used before the kernel loads. This is not really a full bug but it would be much more useful if you can use the keyboard+mouse this way. + +This can not be fixed on the QEMU side. If you want to have virtio-input support in seabios or grub for example, you've got to ask the seabios or grub project to add it. + diff --git a/results/classifier/118/review/1618431 b/results/classifier/118/review/1618431 new file mode 100644 index 000000000..23fbd57b6 --- /dev/null +++ b/results/classifier/118/review/1618431 @@ -0,0 +1,320 @@ +user-level: 0.819 +vnc: 0.748 +KVM: 0.742 +TCG: 0.733 +ppc: 0.710 +peripherals: 0.692 +graphic: 0.681 +hypervisor: 0.663 +virtual: 0.653 +risc-v: 0.638 +mistranslation: 0.637 +x86: 0.622 +performance: 0.611 +device: 0.603 +architecture: 0.592 +VMM: 0.588 +permissions: 0.580 +register: 0.579 +network: 0.575 +boot: 0.561 +arm: 0.557 +debug: 0.547 +socket: 0.545 +semantic: 0.535 +assembly: 0.532 +kernel: 0.523 +PID: 0.515 +files: 0.491 +i386: 0.429 +-------------------- +virtual: 0.961 +hypervisor: 0.875 +KVM: 0.682 +debug: 0.455 +x86: 0.214 +PID: 0.132 +socket: 0.033 +TCG: 0.016 +kernel: 0.012 +files: 0.008 +performance: 0.007 +VMM: 0.006 +graphic: 0.005 +device: 0.005 +register: 0.005 +user-level: 0.004 +architecture: 0.003 +semantic: 0.003 +i386: 0.002 +assembly: 0.002 +peripherals: 0.002 +network: 0.001 +boot: 0.001 +ppc: 0.001 +vnc: 0.001 +permissions: 0.000 +risc-v: 0.000 +mistranslation: 0.000 +arm: 0.000 + +windows hangs after live migration with virtio + +Several of our users reported problems with windows machines hanging +after live migrations. The common denominator _seems_ to be virtio +devices. +I've managed to reproduce this reliably on a windows 10 (+ +virtio-win-0.1.118) guest, always within 1 to 5 migrations, with a +virtio-scsi hard drive and a virtio-net network device. (When I +replace the virtio-net device with an e1000 it takes 10 or more +migrations, and without virtio devices I have not (yet) been able to +reproduce this problem. I also could not reproduce this with a linux +guest. Also spice seems to improve the situation, but doesn't solve +it completely). + +I've tested quite a few tags from qemu-git (v2.2.0 through v2.6.1, +and 2.6.1 with the patches mentioned on qemu-stable by Peter Lieven) +and the behavior is the same everywhere. + +The reproducibility seems to be somewhat dependent on the host +hardware, which makes investigating this issue that much harder. + +Symptoms: +After the migration the windows graphics stack just hangs. +Background processes are still running (eg. after installing an ssh +server I could still login and get a command prompt after the hang was +triggered... not that I'd know what to do with that on a windows +machine...) - commands which need no GUI access work, the rest just +hangs there on the command line, too. +It's also capable of responding to an NMI sent via the qemu monitor: +it then seems to "recover" and manages to show the blue sad-face +screen that something happened, reboots successfully and is usable +again without restarting the qemu process in between. +From there whole the process can be repeated. + +Here's what our command line usually looks like: + +/usr/bin/qemu -daemonize \ + -enable-kvm \ + -chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait -mon chardev=qmp,mode=control \ + -pidfile /var/run/qemu-server/101.pid \ + -smbios type=1,uuid=07fc916e-24c2-4eef-9827-4ab4026501d4 \ + -name win10 \ + -smp 6,sockets=1,cores=6,maxcpus=6 \ + -nodefaults \ + -boot menu=on,strict=on,reboot-timeout=1000 \ + -vga std \ + -vnc unix:/var/run/qemu-server/101.vnc \ + -no-hpet \ + -cpu kvm64,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce \ + -m 2048 \ + -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f \ + -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e \ + -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 \ + -device usb-tablet,id=tablet,bus=uhci.0,port=1 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ + -iscsi initiator-name=iqn.1993-08.org.debian:01:1ba48d46fb8 \ + -drive if=none,id=drive-ide0,media=cdrom,aio=threads \ + -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=200 \ + -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 \ + -drive file=/mnt/pve/data1/images/101/vm-101-disk-1.qcow2,if=none,id=drive-scsi0,cache=writeback,discard=on,format=qcow2,aio=threads,detect-zeroes=unmap \ + -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100 \ + -netdev type=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on \ + -device virtio-net-pci,mac=F2:2B:20:37:E6:D7,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 \ + -rtc driftfix=slew,base=localtime \ + -global kvm-pit.lost_tick_policy=discard + +I'm not sure it's virtio - I've got similar cases which happen even without any virtio; for me it goes away if you enable hpet or switch you kvm-put.lost_tick_policy=delay. + +Dave + +As the virtio related parts aren't the ones hanging (network and disks +still work...) it's unlikely, but it makes a night and day difference. + +Removing -no-hpet as suggested does seem to make a difference, too. +(Changing the tick policy doesn't, for me.) +However, I've found that there are various options which when changed +can massively influence the likelihood of hangs - but it's not always +the same options for all VMs. +With the difference being hangups after 1 to at most 2 migrations with +one setting, or the VMs still being alive and kicking after 20 and +more migrations with the other. +However the options I've tested appear to be unrelated. Eq. in my test +setups this happened with VNC settings, CPU types, toggling our +backend's ssh tunnel for encryption (which should cause nothing but +changes in timing from the perspective of qemu); and of course +replacing virtio devices always had this effect in my tests. +All this might point to some kind of race condition or time keeping +problem, but I can't seem to pinpoint it. + +Enabling hpet isn't a good option btw., since #599958 [Timedrift +problems with Win7: hpet missing time drift fixups] appears to +still be an open issue. => https://bugs.launchpad.net/qemu/+bug/599958 +(This entry is from 2010 :-( ) + +I can reproduce this bug also on Ubuntu 16.04 with libvirt. +The interesting thing is that this bug triggers faster, +if I use tunneled migration instead direct. +Using the virt-manager for migration. + +The test VM is a Win10 with virtio driver from fedora 0.1.118. + +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit win10-1 +or other application using the libvirt API. +--> + +<domain type='kvm'> + <name>win10-1</name> + <uuid>4b3533c1-20d4-4556-9d99-4fb3d04b19dc</uuid> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>6</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-wily'>hvm</type> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + </hyperv> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>Haswell-noTSX</model> + <topology sockets='1' cores='6' threads='1'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/kvm-spice</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none' io='threads'/> + <source file='/mnt/traini3/vm-win10-1.qcow2'/> + <target dev='sda' bus='scsi'/> + <boot order='1'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/mnt/nasi/template/iso/Win10_EnglishInternational_x64.iso'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <boot order='2'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/mnt/nasi/template/iso/virtio-win-0.1.118.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <boot order='3'/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </controller> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='bridge'> + <mac address='52:54:00:2e:4f:ea'/> + <source bridge='vmbr0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> +</domain> + + +When I set -rtc clock=vm the mig problem is solved, but what does this flag exactly? + +In the docu there is only + +" If you want to isolate the guest time from the host, you can set clock to "rt" instead. + To even prevent it from progressing during suspension, you can set it to "vm"." + +what does this means? + +Will the VM never be synced with the HW clock and so it will run slower on cpu load on normal running? + +Hmm, I'd not tried that one; I don't think that should change the behaviour during normal running, but the behaviour on pause and interactions with things like host ntp clock syncing is probably different - how different I'd have to dig in a bit more. + +However, we've done two patches this week that help windows migration - I'd be interested if either of them help your case; + +https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg02658.html is a qemu fix (now in current head qemu) that I wrote that helps one windows migration test case. + +https://lkml.org/lkml/2016/9/14/857 is a kernel fix that fixes some related problems. + +If one or both of these fixes together help I'd love to know either way! + +Dave + +Thank I test the 2 patches and they worked for me. +It works also if you apply only the qemu patch, +in combination the ubuntu kernel 4.4.0-38.57 and qemu 2.6.1. + +Excellent news; thanks for testing! + +Hi WOLI, + Note, if you pick up a new (4.8 ish) kernel you'll probably find you'll need to also pick up two patches that we've just posted to the qemu list: + + target-i386: introduce kvm_put_one_msr + kvm: apic: set APIC base as part of kvm_apic_put + +otherwise you get weird reboot hangs with Linux guests. + +Dave + +The patches should be part of QEMU v2.8 ==> Fix released + diff --git a/results/classifier/118/review/1623020 b/results/classifier/118/review/1623020 new file mode 100644 index 000000000..2a190848d --- /dev/null +++ b/results/classifier/118/review/1623020 @@ -0,0 +1,134 @@ +arm: 0.899 +graphic: 0.882 +permissions: 0.876 +x86: 0.870 +architecture: 0.865 +performance: 0.865 +semantic: 0.862 +hypervisor: 0.858 +peripherals: 0.856 +TCG: 0.846 +PID: 0.827 +device: 0.822 +VMM: 0.818 +register: 0.814 +user-level: 0.811 +socket: 0.810 +kernel: 0.795 +risc-v: 0.778 +vnc: 0.777 +network: 0.777 +files: 0.776 +mistranslation: 0.771 +ppc: 0.768 +KVM: 0.757 +debug: 0.750 +assembly: 0.737 +virtual: 0.722 +boot: 0.691 +i386: 0.657 +-------------------- +debug: 0.944 +user-level: 0.574 +PID: 0.147 +virtual: 0.100 +arm: 0.088 +performance: 0.069 +files: 0.045 +x86: 0.035 +TCG: 0.029 +risc-v: 0.028 +kernel: 0.022 +architecture: 0.012 +hypervisor: 0.009 +VMM: 0.009 +device: 0.009 +semantic: 0.007 +assembly: 0.006 +register: 0.005 +boot: 0.003 +peripherals: 0.003 +KVM: 0.003 +graphic: 0.002 +network: 0.002 +permissions: 0.001 +socket: 0.001 +ppc: 0.001 +vnc: 0.000 +mistranslation: 0.000 +i386: 0.000 + +emulate amd64 binary on arm7 host + +I'm trying to run a Go program compiled for amd64 on a Raspberry Pi. Here is an example : + +=== +// main.go +package main + +func main() { + println("hello world") +} +=== + +Then here is the output I'm getting : + +=== +> GOARCH=amd64 go build main.go +> ../qemu/build/x86_64-linux-user/qemu-x86_64 -strace ./main +29213 arch_prctl(4098,4823880,0,0,0,0) = 0 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4622132)bad timediv = 11 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address) +29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address) +29213 write(2,0,4623731) +runtime stack: + = 16 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 write(2,0,4624923)panic during panic + = 19 +29213 write(2,0,4623731) +runtime stack: + = 16 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 write(2,0,4627441)stack trace unavailable + = 24 +29213 exit_group(4) +=== + +I'm running the latest qemu (commit 7263da78045dc91cc207f350911efe4259e99b3c), which was compiled with "../configure --target-list=x86_64-linux-user --static". + +The go version is 1.7.1, and the system "Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux". + +Unfortunately trying to emulate a 64-bit binary on a 32-bit host with QEMU's linux-user emulator will in general not work. (This is because we don't really emulate the guest CPU's MMU in linux-user mode, so we effectively require the guest page size and the host page size to be the same, which they aren't in this case.) + + +I see, I'll close the ticket then. + +Do you have any recommandation on how I could achieve this? It is actually a 64-bit CPU (armv8 from Raspberry Pi 3) but it's running on a 32-bit OS / kernel. + +On 13 September 2016 at 15:56, Bilal Amarni <email address hidden> wrote: +> I see, I'll close the ticket then. +> +> Do you have any recommandation on how I could achieve this? It is +> actually a 64-bit CPU (armv8 from Raspberry Pi 3) but it's running on a +> 32-bit OS / kernel. + +Your choices are to run a 64-bit kernel (which can still support +a mostly 32-bit userspace), or run a 32-bit guest binary, I'm afraid. + + diff --git a/results/classifier/118/review/1623276 b/results/classifier/118/review/1623276 new file mode 100644 index 000000000..bf0cf6fb9 --- /dev/null +++ b/results/classifier/118/review/1623276 @@ -0,0 +1,359 @@ +user-level: 0.857 +peripherals: 0.839 +TCG: 0.816 +vnc: 0.813 +KVM: 0.810 +risc-v: 0.809 +VMM: 0.808 +hypervisor: 0.803 +ppc: 0.803 +virtual: 0.792 +x86: 0.788 +permissions: 0.773 +device: 0.763 +arm: 0.735 +i386: 0.734 +debug: 0.732 +boot: 0.730 +performance: 0.726 +mistranslation: 0.726 +network: 0.724 +register: 0.716 +socket: 0.704 +architecture: 0.701 +assembly: 0.700 +graphic: 0.692 +files: 0.684 +semantic: 0.682 +kernel: 0.675 +PID: 0.654 +-------------------- +hypervisor: 0.902 +x86: 0.881 +debug: 0.827 +virtual: 0.825 +user-level: 0.400 +boot: 0.249 +kernel: 0.191 +files: 0.063 +PID: 0.043 +socket: 0.019 +register: 0.019 +KVM: 0.017 +TCG: 0.006 +semantic: 0.005 +performance: 0.005 +VMM: 0.004 +device: 0.004 +architecture: 0.003 +assembly: 0.003 +i386: 0.003 +network: 0.002 +ppc: 0.002 +graphic: 0.002 +peripherals: 0.001 +permissions: 0.001 +risc-v: 0.001 +vnc: 0.001 +arm: 0.000 +mistranslation: 0.000 + +qemu 2.7 / iPXE crash + +I am running Arch linux + +vanilla 4.7.2 kernel +qemu 2.7 +libvirt 2.2.0 +virt-manager 1.4.0 + + +Since the upgrade from qemu 2.6.1 to 2.7 a few days ago. I'm no longer +able to PXE boot at all. Everything else appears to function normally. +Non PXE booting and everything else is perfect. Obviously have +restarted everying etc. Have tried the various network drivers also. + +This occurs on domains created with 2.6.1 or with 2.7 + +When I choose PXE boot, the machine moves to a paused state (crashed) +immediately after the 'starting PXE rom execution...' message appears. + +Reverting to qemu 2.6.1 package corrects the issue. + +The qemu.log snippet follows below. + +I'm not sure how to troubleshoot this problem to determine if it's a +packaging error by the distribution or a problem with qemu/kvm/kernel? + +Any help would be much appreciated - Thanks, +Greg + +--- qemu.log: + + +2016-09-12 16:36:33.867+0000: starting up libvirt version: 2.2.0, qemu +version: 2.7.0, hostname: seneca +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +QEMU_AUDIO_DRV=spice /usr/sbin/qemu-system-x86_64 -name guest=c,debug- +threads=on -S -object +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6- +c/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,vmport=off +-cpu Nehalem -m 2048 -realtime mlock=off -smp +1,sockets=1,cores=1,threads=1 -uuid 348009be-26d5-4dc7-b515- +e8b45f5117ac -no-user-config -nodefaults -chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6- +c/monitor.sock,server,nowait -mon +chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew +-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global +PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot +menu=on,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 +-device ich9-usb- +uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 +-device ich9-usb- +uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9- +usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device +virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive +file=/var/lib/libvirt/images/c.qcow2,format=qcow2,if=none,id=drive- +virtio-disk0 -device virtio-blk- +pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio- +disk0,bootindex=1 -netdev tap,fd=28,id=hostnet0 -device +rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:a0:95:7c,bus=pci.0,addr=0x +3 -chardev pty,id=charserial0 -device isa- +serial,chardev=charserial0,id=serial0 -chardev +socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain +-6-c/org.qemu.guest_agent.0,server,nowait -device +virtserialport,bus=virtio- +serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_age +nt.0 -chardev spicevmc,id=charchannel1,name=vdagent -device +virtserialport,bus=virtio- +serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 +-device usb-tablet,id=input0,bus=usb.0,port=1 -spice +port=5901,addr=127.0.0.1,disable-ticketing,image- +compression=off,seamless-migration=on -device qxl- +vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vga +mem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel- +hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0- +codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir +-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 +-chardev spicevmc,id=charredir1,name=usbredir -device usb- +redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio- +balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on +char device redirected to /dev/pts/0 (label charserial0) +main_channel_link: add main channel client +red_dispatcher_set_cursor_peer: +inputs_connect: inputs channel client create +KVM internal error. Suberror: 1 +emulation failure +EAX=801a8d00 EBX=000000a0 ECX=00002e20 EDX=0009d5e8 +ESI=7ffa3c00 EDI=7fef4000 EBP=ffffffff ESP=00007b92 +EIP=000006ab EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00c09300 +CS =9c4c 0009c4c0 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =9cd0 0009cd00 ffffffff 00c09300 +FS =0000 00000000 ffffffff 00c09300 +GS =0000 00000000 ffffffff 00c09300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 00000000 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 +DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 16 66 9c 66 60 0f a8 0f a0 06 1e 16 0e fa 2e 8e 1e 90 06 <0f> +ae 06 d0 1c 0f 01 0e c6 1c 0f 01 06 c0 1c fc 66 b9 38 00 00 00 66 ba 10 +02 00 00 66 68 + + +--- /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 26 +model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz +stepping : 5 +microcode : 0x11 +cpu MHz : 3066.648 +cache size : 8192 KB +physical id : 0 +siblings : 8 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr +pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe +syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl +xtopology nonstop_tsc aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx +est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow +vnmi flexpriority ept vpid dtherm +bugs : +bogomips : 6135.85 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +sudo qemu-system-x86_64 -boot n -net nic,model=virtio,vlan=0 -net bridge,vlan=0,br=br1 -drive file=/tmp/qc2.img,format=qcow2,index=0,media=disk -m 1024 + +Without -enable-kvm, the above command work perfectly. I can PXE boot from the tftp server on my LAN just fine. + +When KVM is enabled, qemu crashes immediately displaying only this: + +Booting from ROM... +iPXE (PCI 00:03.0) starting execution + +I can confirm the issue, I stumbled upon it on a Proxmox system using the pve-qemu-kvm package versions 2.7.0-3 + 2.7.0-4 and have reported the bug in Proxmox bug tracker as https://bugzilla.proxmox.com/show_bug.cgi?id=1182 with further details. + +I was able to reproduce the problem also with latest git of qemu: + + % ./qemu-system-x86_64 -version + QEMU emulator version 2.7.50 (v2.7.0-1343-g4429532-dirty) + +When disabling the KVM feature QEMU loads fine with iPXE/PXE boot. +I'd be happy to provide further information if needed. + +Can you post the host dmesg that is written at the time of the guest crash? + +Please add the output of the following command too: + +tail /sys/module/kvm/holders/kvm_intel/parameters/* + +Thanks. + +(I should have given the pattern /sys/module/kvm_intel/parameters/*, but the result is the same.) + +Laszlo, I'll grab that info for you soon. In the meantime here's the bug tracker for Arch. Someone has completed a git bisect which may be helpful: + +https://bugs.archlinux.org/task/50778 + + +The ipxe bisection is extremely helpful; can you please thank Peter Pickford in the arch tracker on our behalf? + +So, the culprit iPXE commit is + +commit 71560d185475117b10994d839afe059577e7768c +Author: Michael Brown <email address hidden> +Date: Wed Apr 27 11:03:18 2016 +0100 + + [librm] Preserve FPU, MMX and SSE state across calls to virt_call() + +We have actually seen this, in https://bugzilla.redhat.com/show_bug.cgi?id=1356762 + +This is a feature gap in KVM's instruction *emulation*. + +In one of the previous comments, I asked for the KVM module parameters / settings -- I'm pretty sure that once you upload them, they will match Paolo's RHBZ comment in <https://bugzilla.redhat.com/show_bug.cgi?id=1356762#c12>. + +Namely, I expect that the affected host does not support "unrestricted_guest"; i.e., it cannot natively virtualize the FXSAVE instruction (in big real mode that iPXE runs in). Given that "emulate_invalid_guest_state" is set to "yes" on your host (well, I expect that at least; I think it's the default if unrestricted_guest is missing), KVM "manually" emulates 16-bit big real mode for iPXE. However, FXSAVE emulation is missing from KVM. + +RHBZ#1356762 is the bug that tracks the Request for Enhancement. + +(In retrospect, the QEMU code dump "<0f> ae 06 d0 1c" is also a match.) + +Gerd, do you think we should rebuild the iPXE binaries bundled with QEMU with the offending iPXE commit (71560d185475) reverted, at least until KVM gets FXSAVE emulation in big real mode? I think this would be reasonable, as that iPXE commit works around a bug in the IBM Tivoli Provisioning Manager VMM. + +(In other words, the iPXE commit that breaks QEMU's bundled binaries, for a number of KVM users, targets a hypervisor that's different from QEMU/KVM/Xen -- thus normally we wouldn't care about that commit at all.) + +Thanks. + +(--> the rebuilt binaries should go into v2.7.1, if we agree) + +We could also try changing upstream iPXE so that the FXSAVE trick is not active for CONFIG=qemu. + +BTW, this bug can be easily reproduced on hosts that do feature unrestricted_guest, just reload the kvm_intel module with unrestricted_guest=N. + +(In other news, Launchpad continues to suck incredibly. Did you see how it broke up "unrestricted_guest" in my previous comment?) + +Some more reports on ipxe-devel: + +http://lists.ipxe.org/pipermail/ipxe-devel/2016-October/005203.html +http://lists.ipxe.org/pipermail/ipxe-devel/2016-October/005210.html + +Radim just posted the KVM feature patches: + +[PATCH 0/2] KVM: x86: emulate fxsave and fxrstor +https://www.spinics.net/lists/kernel/msg2370327.html + +I thought suppressing the regression within iPXE proper could be helpful in the interim: + +[ipxe-devel] [PATCH 0/2] mask lack of KVM's FXSAVE/FXRSTOR emulation in the QEMU build +http://lists.ipxe.org/pipermail/ipxe-devel/2016-October/005221.html + +Laszlo, as requested: + +[gregory@seneca ~]$ tail /sys/module/kvm/holders/kvm_intel/parameters/* +==> /sys/module/kvm/holders/kvm_intel/parameters/emulate_invalid_guest_state <== +Y + +==> /sys/module/kvm/holders/kvm_intel/parameters/enable_apicv <== +N + +==> /sys/module/kvm/holders/kvm_intel/parameters/enable_shadow_vmcs <== +N + +==> /sys/module/kvm/holders/kvm_intel/parameters/ept <== +Y + +==> /sys/module/kvm/holders/kvm_intel/parameters/eptad <== +N + +==> /sys/module/kvm/holders/kvm_intel/parameters/fasteoi <== +Y + +==> /sys/module/kvm/holders/kvm_intel/parameters/flexpriority <== +Y + +==> /sys/module/kvm/holders/kvm_intel/parameters/nested <== +N + +==> /sys/module/kvm/holders/kvm_intel/parameters/ple_gap <== +0 + +==> /sys/module/kvm/holders/kvm_intel/parameters/ple_window <== +4096 + +==> /sys/module/kvm/holders/kvm_intel/parameters/ple_window_grow <== +2 + +==> /sys/module/kvm/holders/kvm_intel/parameters/ple_window_max <== +1073741823 + +==> /sys/module/kvm/holders/kvm_intel/parameters/ple_window_shrink <== +0 + +==> /sys/module/kvm/holders/kvm_intel/parameters/pml <== +N + +==> /sys/module/kvm/holders/kvm_intel/parameters/unrestricted_guest <== +N + +==> /sys/module/kvm/holders/kvm_intel/parameters/vmm_exclusive <== +Y + +==> /sys/module/kvm/holders/kvm_intel/parameters/vpid <== +Y + + +Thanks. It's indeed the same issue, you have unrestricted_guest=N and emulate_invalid_guest_state=Y. + +The iPXE patches are now upstream (a big "thank you" to the iPXE maintainer!); QEMU 2.8 -- with Gerd willing -- should bundle iPXE binaries containing that fix. + +http://lists.ipxe.org/pipermail/ipxe-devel/2016-November/005244.html + +Fixed in: + +commit 423f7cf233fe262c777db7f87db3e9fac29e02d1 +Author: Gerd Hoffmann <email address hidden> +Date: Wed Nov 9 09:48:44 2016 +0100 + + ipxe: update to 20161108 snapshot + + +Commit 423f7cf233fe262 has been released with QEMU v2.8 + diff --git a/results/classifier/118/review/1625295 b/results/classifier/118/review/1625295 new file mode 100644 index 000000000..364d2d7a4 --- /dev/null +++ b/results/classifier/118/review/1625295 @@ -0,0 +1,346 @@ +user-level: 0.829 +arm: 0.783 +assembly: 0.783 +register: 0.768 +semantic: 0.758 +virtual: 0.754 +PID: 0.750 +debug: 0.742 +hypervisor: 0.737 +architecture: 0.728 +peripherals: 0.726 +risc-v: 0.725 +permissions: 0.725 +network: 0.715 +KVM: 0.713 +kernel: 0.703 +device: 0.701 +performance: 0.696 +socket: 0.693 +graphic: 0.678 +vnc: 0.677 +ppc: 0.668 +TCG: 0.658 +VMM: 0.651 +mistranslation: 0.639 +boot: 0.612 +x86: 0.581 +files: 0.575 +i386: 0.513 +-------------------- +arm: 0.755 +user-level: 0.296 +network: 0.180 +PID: 0.147 +files: 0.135 +socket: 0.095 +virtual: 0.091 +TCG: 0.084 +hypervisor: 0.069 +kernel: 0.069 +debug: 0.060 +register: 0.055 +VMM: 0.054 +device: 0.043 +semantic: 0.024 +boot: 0.022 +permissions: 0.016 +ppc: 0.014 +performance: 0.014 +peripherals: 0.012 +vnc: 0.010 +architecture: 0.009 +risc-v: 0.006 +assembly: 0.006 +x86: 0.003 +graphic: 0.002 +i386: 0.002 +KVM: 0.001 +mistranslation: 0.001 + +qemu-arm dies with libarmmem inside ld.so.preload + +When running raspbian inside qemu,the user has to first comment out the following line from /etc/ld.so.conf: + +/usr/lib/arm-linux-gnueabihf/libarmmem.so + + +Will future qemus will be able to work without changine /etc/ld.so.conf ? + +Which version of QEMU are you using? This is I think due to SETEND emulation, which I thought we had implemented now. + +If this still doesn't work on QEMU 2.7, please can you provide full instructions to reproduce the problem (assume I know nothing about how to get raspbian or run it on QEMU). + + +- I'm on Ubuntu 16.04, and it looks like it's 2.6.1 + +qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c) +2003-2008 Fabrice Bellard + +Is there a PPA for qemu 2.7 somewhere ? + + +On 19 September 2016 at 21:27, Peter Maydell <email address hidden> +wrote: + +> Which version of QEMU are you using? This is I think due to SETEND +> emulation, which I thought we had implemented now. +> +> If this still doesn't work on QEMU 2.7, please can you provide full +> instructions to reproduce the problem (assume I know nothing about how +> to get raspbian or run it on QEMU). +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +On 20 September 2016 at 00:02, Stu <email address hidden> wrote: +> - I'm on Ubuntu 16.04, and it looks like it's 2.6.1 +> +> qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c) +> 2003-2008 Fabrice Bellard +> +> Is there a PPA for qemu 2.7 somewhere ? + +You'd need to ask the Ubuntu folks about that. Upstream +we provide source code distributions only. + +thanks +-- PMM + + +Cheers :) + +May as well close this, I'll re-open it if I try 2.7 and find the same bug. + +Testing involves trying stock raspbian in qemu. + + +On 20 September 2016 at 10:26, Peter Maydell <email address hidden> +wrote: + +> On 20 September 2016 at 00:02, Stu <email address hidden> wrote: +> > - I'm on Ubuntu 16.04, and it looks like it's 2.6.1 +> > +> > qemu-arm version 2.6.1 (Debian 1:2.6.1+dfsg-0~16.04), Copyright (c) +> > 2003-2008 Fabrice Bellard +> > +> > Is there a PPA for qemu 2.7 somewhere ? +> +> You'd need to ask the Ubuntu folks about that. Upstream +> we provide source code distributions only. +> +> thanks +> -- PMM +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +As I say, for providing reproduction instructions you have to assume I know nothing about raspbian, so "trying stock raspbian in qemu" is not detailed enough. I was looking for details more like "download this particular image from this website and then run this specific QEMU commandline, and then in the guest do <this thing> and it fails in <this way>". + + +Are bash scripts OK ? + + +I put everything into some scripts - I'm on ubuntu, debian should be +similar - not sure about other platforms. + + +# Grab scripts +$ git clone https://github.com/stuaxo/raspbian-qemu-scripts +$ cd raspbian-qemu-scripts + +# Download current raspbian lite to /tmp/raspbian: +$ ./download-raspbian.sh + + + + +# Test that may fail - run +/tmp/raspbian/2016-05-27-raspbian-jessie-lite.img in qemu: +$ ./run_qemu.sh + + + +# If the above fails, then it's you can edit /etc/ld.so.preload --- +$ ./mount-raspbian.sh + +^ mounts the image to /tmp/raspbian/ + +Now edit the file /tmp/raspbian/etc/ld.so.preload and comment any lines, +e.g + +$ sudo nano -w /tmp/raspbian/mnt/etc/ld.so.preload + +$ umount /tmp/raspbian + +## Test again in qemu + +$ ./run_qemu.sh + + + +One I get do the edit, qemu works for me. +To get chroot working, one has to mount the image and copy the file + +$ ./mount-raspbian.sh +$ sudo cp /usr/bin/qemu-arm-static /tmp/raspbian/mnt/usr/bin + +# After that chroot works... +$ sudo chroot /tmp/raspbian/mnt + +-- Remember to umount the image before using qemu + but mount for chroot :) + + + + + + + + + + + +On 20 September 2016 at 11:22, Peter Maydell <email address hidden> +wrote: + +> As I say, for providing reproduction instructions you have to assume I +> know nothing about raspbian, so "trying stock raspbian in qemu" is not +> detailed enough. I was looking for details more like "download this +> particular image from this website and then run this specific QEMU +> commandline, and then in the guest do <this thing> and it fails in <this +> way>". +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +Thanks. I can reproduce this with the current QEMU, so there is still a problem of some kind here. + + +Awesome, cheers :) + +On 20 September 2016 at 14:29, Peter Maydell <email address hidden> +wrote: + +> Thanks. I can reproduce this with the current QEMU, so there is still a +> problem of some kind here. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +This turns out to be nothing to do with setend. We're doing something wrong emulating the following nasty hack: +https://github.com/bavison/arm-mem/blob/master/architecture.S + +.arm +architecture: + sub pc, pc, #1 @ is an interworking branch on ARMv7, not ARMv6 + and a1, a4, a1 @ second word interpreted as 'B .+0xA' if Thumb + mov a1, #6 + bx lr +.thumb + mov a1, #7 + bx lr + +so after the 'sub pc, pc, #1' (which in my debug trace is at address 0xb6f086dc) QEMU next tries to execute from 0xb6f086e2 in ARM mode, which is neither of the two expected outcomes. As it happens we hit an undefined instruction pretty much immediately afterwards: + +0xb6f086e2: 0006e003 andeq lr, r6, r3 +0xb6f086e6: ff1ee3a0 undefined instruction 0xff1ee3a0 + + + +Patch which fixes this: http://patchwork.ozlabs.org/patch/672288/ + + +Now fixed in QEMU master, commit 9b6a3ea7a69959416. + + +Awesome, thanks :) + +On 4 October 2016 at 15:55, Peter Maydell <email address hidden> wrote: + +> Now fixed in QEMU master, commit 9b6a3ea7a69959416. +> +> +> ** 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/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +Quick followup on this, finally got the time to build this + can confirming I can boot raspbian with the default /etc/ld.so.conf to the command prompt (both raspbian jessie lite and the default distro). + +NB that commit 9b6a3ea7a69959416 had a bug (it broke exception return to Thumb code), so you should also make sure you have commit fb0e8e79a9d77 which fixes that bug. + + +Yup, got it - cheers :) + +On 20 October 2016 at 08:41, Peter Maydell <email address hidden> wrote: + +> NB that commit 9b6a3ea7a69959416 had a bug (it broke exception return to +> Thumb code), so you should also make sure you have commit fb0e8e79a9d77 +> which fixes that bug. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1625295 +> +> Title: +> qemu-arm dies with libarmmem inside ld.so.preload +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1625295/+subscriptions +> + + +Released with version 2.8 + diff --git a/results/classifier/118/review/1625987 b/results/classifier/118/review/1625987 new file mode 100644 index 000000000..8ae10100a --- /dev/null +++ b/results/classifier/118/review/1625987 @@ -0,0 +1,128 @@ +mistranslation: 0.928 +arm: 0.781 +semantic: 0.627 +ppc: 0.598 +device: 0.580 +PID: 0.567 +performance: 0.557 +socket: 0.484 +hypervisor: 0.446 +register: 0.443 +architecture: 0.419 +graphic: 0.418 +user-level: 0.405 +network: 0.397 +kernel: 0.394 +permissions: 0.387 +VMM: 0.355 +assembly: 0.342 +i386: 0.342 +boot: 0.340 +KVM: 0.333 +vnc: 0.319 +risc-v: 0.310 +TCG: 0.309 +x86: 0.301 +peripherals: 0.269 +virtual: 0.268 +files: 0.244 +debug: 0.159 +-------------------- +arm: 0.973 +debug: 0.860 +architecture: 0.497 +kernel: 0.383 +device: 0.265 +files: 0.261 +peripherals: 0.255 +register: 0.202 +boot: 0.179 +KVM: 0.156 +TCG: 0.112 +virtual: 0.109 +PID: 0.109 +semantic: 0.093 +ppc: 0.079 +hypervisor: 0.072 +vnc: 0.062 +socket: 0.062 +assembly: 0.042 +network: 0.040 +performance: 0.032 +VMM: 0.026 +risc-v: 0.021 +permissions: 0.011 +user-level: 0.005 +graphic: 0.005 +mistranslation: 0.004 +i386: 0.001 +x86: 0.001 + +target-arm/translate-a64.c:2028: possible coding error ? + +target-arm/translate-a64.c:2028:37: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] + +Source code is + + bool iss_sf = opc == 0 ? 32 : 64; + +Maybe better code + + bool iss_sf = (opc == 0) ? 32 : 64; + +This is clearly a bug, but your suggested change won't deal with the problem, which is that we're trying to set a bool so the ? 32 : 64 construct is just wrong. + + +On 22 September 2016 at 02:53, Peter Maydell <email address hidden> wrote: +> This is clearly a bug, but your suggested change won't deal with the +> problem, which is that we're trying to set a bool so the ? 32 : 64 +> construct is just wrong. + +> Bug description: +> target-arm/translate-a64.c:2028:37: warning: ?: using integer +> constants in boolean context [-Wint-in-bool-context] +> +> Source code is +> +> bool iss_sf = opc == 0 ? 32 : 64; + +Edgar, did you want to look at a fix for this? It was introduced +in your commit aaa1f954d4 adding syndrome info for loads and stores. + +thanks +-- PMM + + +On Thu, Sep 29, 2016 at 06:40:53PM -0700, Peter Maydell wrote: +> On 22 September 2016 at 02:53, Peter Maydell <email address hidden> wrote: +> > This is clearly a bug, but your suggested change won't deal with the +> > problem, which is that we're trying to set a bool so the ? 32 : 64 +> > construct is just wrong. +> +> > Bug description: +> > target-arm/translate-a64.c:2028:37: warning: ?: using integer +> > constants in boolean context [-Wint-in-bool-context] +> > +> > Source code is +> > +> > bool iss_sf = opc == 0 ? 32 : 64; +> +> Edgar, did you want to look at a fix for this? It was introduced +> in your commit aaa1f954d4 adding syndrome info for loads and stores. + +Hi Peter, + +Yes, I've just posted a fix to the list. +It should have been: + +bool iss_sf = opc == 0 ? false : true; + +Cheers, +Edgar + + +Now fixed in master, commit 173ff58580b383a7841. + + +Released with v2.8 + diff --git a/results/classifier/118/review/1631773 b/results/classifier/118/review/1631773 new file mode 100644 index 000000000..79f1f1504 --- /dev/null +++ b/results/classifier/118/review/1631773 @@ -0,0 +1,77 @@ +mistranslation: 0.928 +device: 0.831 +ppc: 0.793 +socket: 0.662 +network: 0.539 +kernel: 0.527 +register: 0.495 +architecture: 0.480 +vnc: 0.472 +files: 0.455 +semantic: 0.412 +graphic: 0.406 +hypervisor: 0.341 +peripherals: 0.323 +risc-v: 0.295 +debug: 0.288 +PID: 0.261 +x86: 0.251 +assembly: 0.248 +boot: 0.222 +i386: 0.213 +KVM: 0.213 +arm: 0.198 +VMM: 0.182 +TCG: 0.172 +performance: 0.163 +user-level: 0.161 +virtual: 0.158 +permissions: 0.150 +-------------------- +debug: 0.559 +hypervisor: 0.535 +x86: 0.535 +kernel: 0.403 +i386: 0.185 +files: 0.160 +KVM: 0.138 +ppc: 0.122 +arm: 0.120 +TCG: 0.110 +device: 0.101 +assembly: 0.047 +VMM: 0.047 +architecture: 0.037 +register: 0.034 +boot: 0.032 +virtual: 0.031 +peripherals: 0.029 +risc-v: 0.025 +user-level: 0.019 +PID: 0.018 +socket: 0.010 +semantic: 0.009 +performance: 0.006 +network: 0.005 +graphic: 0.003 +vnc: 0.002 +permissions: 0.002 +mistranslation: 0.000 + +hw/dma/pl080.c:354: possible typo ? + +hw/dma/pl080.c:354:1: warning: V578 An odd bitwise operation detected: s->conf & (0x2 | 0x2). Consider verifying it. + +Source code is + + if (s->conf & (PL080_CONF_M1 | PL080_CONF_M1)) { + +Maybe better code + + if (s->conf & (PL080_CONF_M1 | PL080_CONF_M2)) { + +Thanks for reporting the issue, patch has now been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=04bb79d1f519ae190a + +Released with version 2.8. + diff --git a/results/classifier/118/review/1634 b/results/classifier/118/review/1634 new file mode 100644 index 000000000..e4616a088 --- /dev/null +++ b/results/classifier/118/review/1634 @@ -0,0 +1,78 @@ +architecture: 0.836 +ppc: 0.757 +graphic: 0.561 +device: 0.370 +kernel: 0.238 +semantic: 0.234 +mistranslation: 0.137 +permissions: 0.130 +user-level: 0.121 +PID: 0.108 +performance: 0.103 +files: 0.091 +debug: 0.088 +network: 0.087 +peripherals: 0.077 +boot: 0.066 +TCG: 0.060 +hypervisor: 0.060 +vnc: 0.060 +risc-v: 0.052 +VMM: 0.047 +socket: 0.046 +register: 0.040 +virtual: 0.040 +assembly: 0.019 +KVM: 0.019 +x86: 0.013 +arm: 0.007 +i386: 0.002 +-------------------- +debug: 0.714 +kernel: 0.628 +ppc: 0.351 +architecture: 0.297 +user-level: 0.167 +PID: 0.033 +files: 0.028 +hypervisor: 0.025 +virtual: 0.024 +register: 0.024 +TCG: 0.020 +device: 0.012 +semantic: 0.006 +assembly: 0.005 +performance: 0.004 +peripherals: 0.004 +permissions: 0.004 +socket: 0.004 +network: 0.003 +boot: 0.003 +graphic: 0.002 +VMM: 0.001 +mistranslation: 0.001 +KVM: 0.000 +risc-v: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 +arm: 0.000 + +[8.0.0] Broken snapshot replay support on PowerPC +Description of problem: +QEMU 8.0.0 can no longer replay snapshots on PowerPC e500mc (Book-E) architecture. The issue is caused by https://gitlab.com/qemu-project/qemu/-/commit/c4b075318eb1e87de5fc942e6b987694a0e677e1, reverting this commit solves the issue. +Steps to reproduce: +1. Run bare metal example from the attachment with the first command-line to create snapshot. +2. Run bare metal example from the attachment with the second command-line to replay snapshot. +Additional information: +Any e500mc example would do really. I was unable to find a prebuilt Linux distribution, thus just wrote a minimal sample that prints hello world to UART: [ppc-e500.zip](/uploads/f9328c4b8355a92877d784661aa69fa4/ppc-e500.zip) + +Log output: + +``` +% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio +Hello world +qemu-system-ppc: terminating on signal 2 from pid 4505 (<unknown process>) +% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio +qemu-system-ppc: Missing random event in the replay log +``` diff --git a/results/classifier/118/review/1637 b/results/classifier/118/review/1637 new file mode 100644 index 000000000..1acb6e691 --- /dev/null +++ b/results/classifier/118/review/1637 @@ -0,0 +1,61 @@ +architecture: 0.950 +x86: 0.892 +device: 0.840 +performance: 0.660 +graphic: 0.655 +debug: 0.579 +arm: 0.389 +risc-v: 0.282 +TCG: 0.245 +permissions: 0.220 +boot: 0.219 +kernel: 0.202 +VMM: 0.202 +ppc: 0.201 +vnc: 0.201 +semantic: 0.196 +PID: 0.184 +virtual: 0.177 +network: 0.164 +assembly: 0.162 +register: 0.142 +user-level: 0.106 +hypervisor: 0.103 +socket: 0.081 +mistranslation: 0.070 +files: 0.054 +KVM: 0.044 +peripherals: 0.020 +i386: 0.003 +-------------------- +virtual: 0.960 +assembly: 0.823 +x86: 0.692 +debug: 0.354 +KVM: 0.214 +hypervisor: 0.124 +kernel: 0.045 +VMM: 0.037 +architecture: 0.037 +arm: 0.027 +TCG: 0.015 +performance: 0.009 +device: 0.008 +semantic: 0.007 +PID: 0.005 +register: 0.004 +files: 0.004 +user-level: 0.004 +socket: 0.003 +risc-v: 0.002 +graphic: 0.001 +mistranslation: 0.001 +boot: 0.000 +ppc: 0.000 +peripherals: 0.000 +vnc: 0.000 +network: 0.000 +i386: 0.000 +permissions: 0.000 + +Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/118/review/1639322 b/results/classifier/118/review/1639322 new file mode 100644 index 000000000..99d352ff6 --- /dev/null +++ b/results/classifier/118/review/1639322 @@ -0,0 +1,91 @@ +user-level: 0.930 +graphic: 0.864 +performance: 0.667 +mistranslation: 0.657 +ppc: 0.636 +debug: 0.610 +semantic: 0.572 +device: 0.552 +register: 0.521 +permissions: 0.515 +PID: 0.487 +architecture: 0.463 +network: 0.456 +virtual: 0.431 +peripherals: 0.427 +files: 0.425 +vnc: 0.398 +socket: 0.369 +TCG: 0.346 +x86: 0.309 +arm: 0.305 +risc-v: 0.302 +VMM: 0.255 +hypervisor: 0.232 +kernel: 0.220 +boot: 0.211 +i386: 0.206 +assembly: 0.150 +KVM: 0.102 +-------------------- +ppc: 0.984 +debug: 0.732 +user-level: 0.657 +TCG: 0.076 +files: 0.033 +virtual: 0.017 +PID: 0.015 +device: 0.014 +hypervisor: 0.007 +performance: 0.005 +kernel: 0.005 +network: 0.003 +peripherals: 0.003 +graphic: 0.003 +architecture: 0.002 +socket: 0.002 +semantic: 0.002 +boot: 0.002 +register: 0.002 +x86: 0.001 +VMM: 0.001 +assembly: 0.001 +risc-v: 0.000 +permissions: 0.000 +arm: 0.000 +vnc: 0.000 +mistranslation: 0.000 +KVM: 0.000 +i386: 0.000 + +pasting into ppc64 serial console kills qemu + +- run qemu-system-ppc64 +- when X window appears press Ctrl+Alt+3 +- paste any text longer than 16 characters + + +qemu-system-ppc64: /home/abuild/rpmbuild/BUILD/qemu-2.6.1/hw/char/spapr_vty.c:40: vty_receive: Assertion `(dev->in - dev->out) < 16' failed. +Aborted (core dumped) + +Broken in SUSE Leap 42.2 and git 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414 + +What user interface are you using? VNC? SDL? GTK? + +This is gtk interface. + +However, the function on line 40 os spapr_vty.c looks really insane. + +It asserts that it is not given more data to input in a ring buffer than is size of the buffer and then stuffs all the data in regardless of the amount of data already present. + +It should probably loop or one of its callers but I did not find a decent comparable piece of code to cut and paste whatever callbacks are needed for the other side to consume the bytes. + +OK, seems like you need to compile QEMU with CONFIG_VTE enabled (i.e. with the vte-devel packages installed before running configure) to get copy-n-paste support in the GTK interface, that's why I was initially not able to reproduce this issue. +Anyway, now I can trigger the assert(), too, and I've suggested a patch here: + +http://marc.info/?<email address hidden> + +FWIW, the crash should be fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7bacfd7f7289192c83330 +(but we still need to fix the gtk side, too, to only send as much characters at once as the receiving side can take) + diff --git a/results/classifier/118/review/1643619 b/results/classifier/118/review/1643619 new file mode 100644 index 000000000..0d37ec8b3 --- /dev/null +++ b/results/classifier/118/review/1643619 @@ -0,0 +1,114 @@ +user-level: 0.920 +risc-v: 0.859 +debug: 0.827 +register: 0.812 +socket: 0.784 +performance: 0.783 +architecture: 0.777 +device: 0.776 +network: 0.775 +graphic: 0.773 +semantic: 0.762 +permissions: 0.762 +virtual: 0.762 +arm: 0.749 +PID: 0.747 +ppc: 0.747 +assembly: 0.740 +peripherals: 0.737 +boot: 0.706 +kernel: 0.706 +mistranslation: 0.680 +vnc: 0.668 +files: 0.662 +i386: 0.641 +hypervisor: 0.582 +KVM: 0.568 +x86: 0.533 +VMM: 0.524 +TCG: 0.494 +-------------------- +network: 0.990 +socket: 0.967 +debug: 0.944 +PID: 0.864 +kernel: 0.795 +virtual: 0.201 +user-level: 0.015 +TCG: 0.014 +assembly: 0.013 +files: 0.013 +hypervisor: 0.008 +x86: 0.006 +architecture: 0.004 +device: 0.003 +semantic: 0.002 +performance: 0.002 +register: 0.002 +boot: 0.001 +ppc: 0.001 +graphic: 0.001 +risc-v: 0.001 +peripherals: 0.001 +VMM: 0.001 +i386: 0.000 +mistranslation: 0.000 +permissions: 0.000 +vnc: 0.000 +arm: 0.000 +KVM: 0.000 + +netlink broken on big-endian mips + +Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159) + +As the summary says, netlink is completely broken on big-endian mips running qemu-user. + +Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes. + +[...] +[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3 +[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 +[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0 +[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 +[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0 +[pid 11249] time([1479745823]) = 1479745823 +[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40 +[pid 11249] recvmsg(3, + +Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped. + +Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason. + +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, + #ifdef TARGET_NR_socket + case TARGET_NR_socket: + ret = do_socket(arg1, arg2, arg3); +- fd_trans_unregister(ret); + break; + #endif + #ifdef TARGET_NR_socketpair + +I also notice fd_trans_unregister does not appear in the socketcall implementation which seems like an oversight. + +Same here. While running qemu-debootstrap using Debian qemu 2.7, debootstrap hangs on groupadd calls. Reproduction on amd64 host, running jessie, on a failed qemu-debootstrap but sufficiently working jessie mips chroot. See attached strace of groupadd. Problem reproduces with compiled qemu from git master, commit 00227fefd2059464cd2f59aed29944874c630e2f. + +... +[pid 31008] socket(PF_NETLINK, SOCK_RAW, NETLINK_AUDIT) = 3 +[pid 31008] fcntl(3, F_SETFD, FD_CLOEXEC) = 0 +... +[pid 31008] sendto(3, "\0\0\0x\4\\\0\5\0\0\0\1\0\0\0\0op=adding group "..., 120, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 120 +[pid 31008] ppoll([{fd=3, events=POLLIN}], 1, {0, 500000000}, NULL, 0) = 0 (Timeout) +[pid 31008] recvfrom(3, 0x7facef9e1504, 8988, 66, 0x7fff0138c9b0, 0x7fff0138c9f4) = -1 EAGAIN (Resource temporarily unavailable) +[pid 31008] ppoll([{fd=3, events=POLLIN}], 1, {0, 500000000}, NULL, 0) = 0 (Timeout) +[pid 31008] recvfrom(3, 0x7facef9e1504, 8988, 66, 0x7fff0138c9b0, 0x7fff0138c9f4) = -1 EAGAIN (Resource temporarily unavailable) +...etc ... etc... + +Strace jessie mips groupadd. + +Patch applied by James works for me as well. Dropping a qemu-user static binary from Debian qemu 2.1 into the mips chroot can also be used as workaround. + +This has been fixed by 40493c5f2b0f124c9b2581e539bba14522e51269, which is exactly the same diff as given here. + diff --git a/results/classifier/118/review/1652011 b/results/classifier/118/review/1652011 new file mode 100644 index 000000000..46bda3320 --- /dev/null +++ b/results/classifier/118/review/1652011 @@ -0,0 +1,202 @@ +user-level: 0.838 +peripherals: 0.818 +graphic: 0.816 +KVM: 0.811 +hypervisor: 0.807 +TCG: 0.799 +VMM: 0.799 +ppc: 0.789 +risc-v: 0.788 +mistranslation: 0.783 +vnc: 0.777 +x86: 0.763 +debug: 0.752 +semantic: 0.749 +virtual: 0.734 +socket: 0.725 +device: 0.724 +register: 0.723 +PID: 0.713 +architecture: 0.710 +arm: 0.693 +i386: 0.686 +permissions: 0.684 +performance: 0.664 +boot: 0.663 +network: 0.659 +assembly: 0.658 +kernel: 0.630 +files: 0.613 +-------------------- +KVM: 0.990 +hypervisor: 0.897 +virtual: 0.791 +debug: 0.781 +files: 0.212 +TCG: 0.185 +x86: 0.102 +PID: 0.033 +VMM: 0.022 +register: 0.022 +architecture: 0.021 +semantic: 0.019 +performance: 0.008 +device: 0.008 +kernel: 0.008 +ppc: 0.007 +socket: 0.005 +assembly: 0.005 +boot: 0.004 +risc-v: 0.003 +permissions: 0.003 +i386: 0.002 +graphic: 0.002 +network: 0.001 +user-level: 0.001 +peripherals: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +VM shuts down due to error in qemu block.c + +On a Trusty KVM host one of the guest VMs shut down without any user interaction. The system is running: + +$ cat /etc/lsb-release +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=14.04 +DISTRIB_CODENAME=trusty +DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS" + +$ dpkg -l libvirt0 qemu-kvm qemu-system-common qemu-system-x86 +Desired=Unknown/Install/Remove/Purge/Hold +| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend +|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) +||/ Name Version Architecture Description ++++-============================================================-===================================-===================================-============================================================================================================================== +ii libvirt0 1.2.2-0ubuntu13.1.17 amd64 library for interfacing with different virtualization systems +ii qemu-kvm 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU Full virtualization +ii qemu-system-common 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU full system emulation binaries (x86) + +In the VMs log in /var/lib/libvirt/qemu/hostname we see: + +2016-11-17 09:18:42.603+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name hostname,process=qemu:hostname -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 12697 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 51766564-ed8e-41aa-91b5-574220af4ac3 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hostname.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk1/hostname,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk2/hostname_mnt_data,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/dev/disk1/hostname_tmp,if=none,id=drive-virtio-disk2,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,tx=bh,netdev=hostnet0,id=net0,mac=52:54:00:45:e7:d9,bus=pci.0,addr=0x6 -netdev tap,fd=31,id=hostnet1,vhost=on,vhostfd=32 -device virtio-net-pci,tx=bh,netdev=hostnet1,id=net1,mac=52:54:00:f6:6c:77,bus=pci.0,addr=0x7 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:5 -device VGA,id=video0,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 +char device redirected to /dev/pts/6 (label charserial0) +qemu-system-x86_64: /build/qemu-PVxDqC/qemu-2.0.0+dfsg/block.c:3491: bdrv_error_action: Assertion `error >= 0' failed. +2016-12-22 09:49:49.392+0000: shutting down + +In /var/lib/libvirt/libvirtd.log we see: + +2016-12-22 09:49:49.298+0000: 6946: error : qemuMonitorIO:656 : internal error: End of file from monitor + +We investigated to see if this is a known issue and came across a bug report for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1147398), but nothing references changes upstream that fix this. + +The guest OS is Ubuntu Precise (12.04.5) running kernel linux-image-3.2.0-101-virtual 3.2.0-101.141. There wasn't any significant load (CPU or IO) on the guest at the time that it shut down and there wasn't any appreciable disk IO on the KVM host either. The disks for the guest are on the KVM host box. + +Please do not report distribution specific bugs (since you're using qemu-kvm 2.0.0+dfsg-2ubuntu1.27) against the QEMU project bugtracker - use the distribution's bugtracker instead. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Description of problem: +VM Guests occasionally hard shutdown unexpectedly with error: + +"qemu-system-x86_64: block.c:2806: bdrv_error_action: Assertion `error >= 0' failed." + +In my environment it only appears to be my Windows 2008R2 guests that are affected, although I know of another environment with SLES guests that are affected. As per email here: http://lists.gnu.org/archive/html/qemu-discuss/2014-06/msg00094.html + + +Version-Release number of selected component (if applicable): + + * qemu-system-x86-1.6.2-5.fc20.x86_64 + +How reproducible: + +It is difficult to reproduce, it occurs roughly once a week each Guest VM for me. + + +Additional info: + * I am running Openstack Icehouse on Fedora 20 (via packstack) + * Kernels: kernel-3.14.4-200.fc20.x86_64 / kernel-3.14.8-200.fc20.x86_64 + * libvirt-1.1.3.5-2.fc20.x86_64 + * Guest OS: Windows 2008R2 + * Guest VirtIO driver version 0.1-81 + * Guest Storage is via NFS export from a Netapp FAS 6220 cluster. + * These unexpected shutdowns do not occur for me at busy times for either the guests or the hosts. + +*** Bug 1147398 has been marked as a duplicate of this bug. *** + +bdrv_error_action is called from 3 places. What is going to +help most of all here is a stack trace. Easiest thing is +to enable core dumps and make sure the core dump is captured when +qemu fails. + +Thanks for the idea. Sounds better than mine to recompile qemu with debug messages. Can you give a hint how to achieve it in an OVirt/libvirt environment. + +I met this problem with qemu-1.6.1 too, while my problem is found at debian7 guests. + +This message is a reminder that Fedora 20 is nearing its end of life. +Approximately 4 (four) weeks from now Fedora will stop maintaining +and issuing updates for Fedora 20. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as EOL if it remains open with a Fedora 'version' +of '20'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version. + +Thank you for reporting this issue and we are sorry that we were not +able to fix it before Fedora 20 is end of life. If you would still like +to see this bug fixed and are able to reproduce it against a later version +of Fedora, you are encouraged change the 'version' to a later Fedora +version prior this bug is closed as described in the policy above. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +Since F20 is EOL soon, closing this. If anyone can still reproduce with F21+, please reopen and I'll take a look + +We see this in upstream openstack CI testing, viewable here: + +http://logs.openstack.org/07/251407/2/check/gate-tempest-dsvm-full/144f7fc/logs/libvirt/libvirtd.txt.gz#_2015-11-30_18_20_18_168 + +2015-11-30 18:20:18.168+0000: 31539: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-11-30 18:20:18.168+0000: 31539: debug : qemuMonitorIO:710 : Error on monitor internal error: End of file from monitor +2015-11-30 18:20:18.168+0000: 31539: debug : qemuMonitorIO:731 : Triggering EOF callback +2015-11-30 18:20:18.168+0000: 31539: debug : qemuProcessHandleMonitorEOF:300 : Received EOF on 0x7fa310011240 'instance-00000066' +2015-11-30 18:20:18.168+0000: 31539: debug : qemuProcessHandleMonitorEOF:318 : Monitor connection to 'instance-00000066' closed without SHUTDOWN event; assuming the domain crashed +2015-11-30 18:20:18.168+0000: 31539: debug : virObjectEventNew:643 : obj=0x7fa340aab850 +2015-11-30 18:20:18.168+0000: 31539: debug : qemuProcessStop:4235 : Shutting down vm=0x7fa310011240 name=instance-00000066 id=150 pid=17830 flags=0 + +This was the domain log: + +http://logs.openstack.org/07/251407/2/check/gate-tempest-dsvm-full/144f7fc/logs/libvirt/qemu/instance-00000066.txt.gz + +I noticed this: + +char device redirected to /dev/pts/1 (label charserial1) +qemu-system-x86_64: /build/qemu-5LgLIn/qemu-2.0.0+dfsg/block.c:3491: bdrv_error_action: Assertion `error >= 0' failed. +2015-11-30 18:20:18.168+0000: shutting down + +This is a volume-backed VM. I think around the time that this fails, we should be trying to plug a virtual interface. + +Possibly also helpful: + +http://logs.openstack.org/07/251407/2/check/gate-tempest-dsvm-full/144f7fc/logs/screen-n-net.txt.gz#_2015-11-30_18_19_45_252 + +2015-11-30 18:19:45.251 DEBUG oslo_concurrency.processutils [req-8911e8c7-2466-408f-832e-af4b78e9adec tempest-TestVolumeBootPattern-2142876884 tempest-TestVolumeBootPattern-1970238908] CMD "sudo nova-rootwrap /etc/nova/rootwrap.conf ebtables --concurrent -t nat -D PREROUTING --logical-in br100 -p ipv4 --ip-src 10.1.0.3 ! --ip-dst 10.1.0.0/20 -j redirect --redirect-target ACCEPT" returned: 255 in 0.147s execute /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297 + +For comment 7, this is mitaka openstack. + +libvirt version: 1.2.2 + +QEMU 2.0.0 + +Ubuntu 14.04 for the compute host. + +If you are hitting this on ubuntu, you need to file an ubuntu bug. + diff --git a/results/classifier/118/review/1654 b/results/classifier/118/review/1654 new file mode 100644 index 000000000..346f56cf5 --- /dev/null +++ b/results/classifier/118/review/1654 @@ -0,0 +1,141 @@ +user-level: 0.853 +hypervisor: 0.841 +x86: 0.836 +mistranslation: 0.834 +vnc: 0.832 +peripherals: 0.819 +ppc: 0.819 +TCG: 0.817 +KVM: 0.803 +register: 0.787 +graphic: 0.785 +device: 0.784 +VMM: 0.781 +i386: 0.777 +architecture: 0.775 +socket: 0.761 +risc-v: 0.746 +performance: 0.740 +virtual: 0.732 +debug: 0.713 +arm: 0.708 +permissions: 0.706 +semantic: 0.703 +kernel: 0.684 +PID: 0.677 +files: 0.663 +assembly: 0.656 +network: 0.608 +boot: 0.600 +-------------------- +kernel: 0.964 +x86: 0.269 +hypervisor: 0.259 +debug: 0.175 +virtual: 0.150 +TCG: 0.064 +device: 0.044 +files: 0.025 +PID: 0.022 +assembly: 0.015 +peripherals: 0.011 +VMM: 0.010 +register: 0.010 +KVM: 0.009 +architecture: 0.008 +i386: 0.008 +semantic: 0.008 +user-level: 0.005 +ppc: 0.004 +performance: 0.004 +risc-v: 0.003 +boot: 0.003 +permissions: 0.002 +graphic: 0.002 +socket: 0.002 +vnc: 0.002 +network: 0.001 +arm: 0.001 +mistranslation: 0.000 + +Memory out of bounds access vulnerability when guest accesses Block Limits information of SCSI devices +Description of problem: +When a guest uses a Linux kernel version 5.19 or higher and uses an scsi device, there will be a memory access violation, which can be clearly seen when ASAN is turned on. + +**reason：** +Linux kernel 5.19 merge commit： + +https://github.com/torvalds/linux/commit/c92a6b5d63359dd6d2ce6ea88ecd8e31dd769f6b + +The Linux kernel will first issue a header request to obtain the VPD length before obtaining the VPD information. The BUF for obtaining the VPD length is less than 8 bytes. However, QEMU regards the header for obtaining the VPD length as obtaining all VPD information, and a memory access violation occurs when writing information to BUF. + +The specific memory out of bounds information is as follows: +==12430==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! + +==12430==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: +0x7fffebc1d000; bottom 0x7f61115ee000; size: 0x009eda62f000 (682268749824) + +False positive error reports may follow + +==12430==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200024d858 at pc 0x55767513791c bp 0x7f6111fcddc0 sp 0x7f6111fcddb0 + +WRITE of size 4 at 0x60200024d858 thread T0 + + #0 0x55767513791b in stl_he_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 + + #1 0x55767513791b in stl_be_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:464 + + #2 0x55767513791b in scsi_handle_inquiry_reply hw/scsi/scsi-generic.c:173 + + #3 0x55767513791b in scsi_read_complete hw/scsi/scsi-generic.c:318 + + #4 0x55767545d7c6 in blk_aio_complete block/block-backend.c:1425 + + #5 0x557675544d79 in coroutine_trampoline util/coroutine-ucontext.c:115 + + #6 0x7f611b9f14df (/lib/x86_64-linux-gnu/libc.so.6+0x5b4df) + +0x60200024d858 is located 4 bytes to the right of 4-byte region [0x60200024d850,0x60200024d854) + +allocated by thread T0 here: + + #0 0x557674a987f2 in malloc (/sf/bin/qemu-system-x86_64+0x7827f2) + + #1 0x7f6120141d41 in g_malloc (/usr/lib/libglib256-2.0.so.0+0x61d41) + + #2 0x557675137bb4 in scsi_send_command hw/scsi/scsi-generic.c:459 + + #3 0x55767513e902 in scsi_req_enqueue hw/scsi/scsi-bus.c:836 + + #4 0x557674c5f26e in virtio_scsi_handle_cmd_req_submit /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:589 + + #5 0x557674c5f26e in virtio_scsi_handle_cmd_vq /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:634 + + #6 0x557674c61089 in virtio_scsi_data_plane_handle_cmd /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi-dataplane.c:60 + + #7 0x557674c9a520 in virtio_queue_notify_aio_vq /root/hci/qemu/qemu-5.0.0/hw/virtio/virtio.c:2338 + + #8 0x55767552c7c4 in aio_dispatch_handler util/aio-posix.c:328 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 stl_he_p +Steps to reproduce: +1. QEMU Enable ASAN +2. Use a guest with a Linux kernel version greater than 5.19 and mount an scsi physical device +3. Upon startup, memory out of bounds access can be detected +Additional information: +At present, I have made some simple modifications, but I am not sure if this is the best solution and can serve as a reference. + +Make a judgment on buflen, ignore the header information issued by the Linux kernel, and write the VPD information when issuing the actual instruction to obtain VPD information. + +hw/scsi/scsi-generic.c:scsi_handle_inquiry_reply + +``` +if (r->buflen >= 12) { + stl_be_p(&r->buf[8], max_transfer); +} +if (r->buflen >= 16){ + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); +} +``` diff --git a/results/classifier/118/review/1657538 b/results/classifier/118/review/1657538 new file mode 100644 index 000000000..befac914c --- /dev/null +++ b/results/classifier/118/review/1657538 @@ -0,0 +1,261 @@ +user-level: 0.801 +mistranslation: 0.771 +register: 0.741 +risc-v: 0.728 +virtual: 0.713 +TCG: 0.710 +debug: 0.708 +graphic: 0.706 +VMM: 0.703 +permissions: 0.693 +ppc: 0.689 +architecture: 0.688 +vnc: 0.688 +hypervisor: 0.684 +device: 0.683 +KVM: 0.664 +network: 0.662 +PID: 0.651 +x86: 0.650 +assembly: 0.640 +peripherals: 0.635 +semantic: 0.633 +arm: 0.624 +performance: 0.623 +socket: 0.621 +i386: 0.618 +files: 0.617 +boot: 0.611 +kernel: 0.600 +-------------------- +virtual: 0.833 +i386: 0.782 +hypervisor: 0.689 +x86: 0.670 +TCG: 0.597 +kernel: 0.295 +user-level: 0.246 +debug: 0.092 +ppc: 0.067 +boot: 0.032 +files: 0.019 +register: 0.013 +architecture: 0.010 +KVM: 0.010 +PID: 0.010 +device: 0.006 +performance: 0.005 +arm: 0.005 +socket: 0.004 +semantic: 0.004 +network: 0.003 +VMM: 0.002 +risc-v: 0.002 +vnc: 0.002 +graphic: 0.002 +assembly: 0.001 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +qemu 2.7.x 2.8 softmmu dont work on BE machine + +Build on Be machine qemu 2.7.1 and 2.8 in pure softmmu (tgc) dont work on big endian hardware . +tested with ppc-softmmu,i386-softmmu,arm-softmmu same result: + +with : + ./qemu-system-i386 +Gtk-Message: Failed to load module "overlay-scrollbar" +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + + +I try to add the -L option with ../pc-bios/bios.bin +and have the same result. + +note the ppc-softmmu and ppc64-softmmu work in kvm mode only emulated mode have issue. + + +tested on my hardware a Qriq P5040 and G5 4x970MP with Ubuntu Mate 16.10 +thanks +Luigi + +I can not reproduce this issue. QEMU 2.8 works fine here on a POWER8 big endian host (running RHEL7). Can you still run older versions of QEMU that used to work for you in the past, to check whether it is QEMU or whether it is Ubuntu 16.10 that is causing the trouble here? Could you please also post the full output of the "configure" run on your system? + +Something else to try: Could you please check whether you get any output when you run "qemu-system-ppc -nographic" on your system? So we can make sure that it is not related to GTK or something similar... + +Hi Thomas, +here the configure .. i made a clean one just with the target for have fastest build +will report soon the result with the nographic just the time of build + +src/qemu$ ./configure --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/amigaone/src/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler clang +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -D_GNU_SOURCE -I/usr/include/ncursesw -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-shift-negative-value -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/local/include/libpng12 -I/usr/local/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -m32 -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU ppc +host big endian yes +target list i386-softmmu ppc-softmmu ppc64-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (1.2.15) +GTK support yes (2.24.30) +GTK GL support no +VTE support no +TLS priority NORMAL +GNUTLS support no +GNUTLS rnd no +libgcrypt yes +libgcrypt kdf yes +nettle no +nettle kdf no +libtasn1 no +curses support yes +virgl support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support yes +bluez support yes +Documentation yes +PIE no +vde support no +netmap support no +Linux AIO support yes +ATTR/XATTR support yes +Install blobs yes +KVM support yes +COLO support yes +RDMA support yes +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +libcap-ng support yes +vhost-net support yes +vhost-scsi support yes +vhost-vsock support yes +Trace backends log +spice support no +rbd support yes +xfsctl support yes +smartcard support yes +libusb yes +usb net redir yes +OpenGL support yes +OpenGL dmabufs yes +libiscsi support yes +libnfs support yes +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support yes +coroutine backend ucontext +coroutine pool yes +debug stack usage no +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support yes +TPM passthrough no +QOM debugging yes +lzo support yes +snappy support yes +bzip2 support yes +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization no +replication support yes + + + +i386-softmmu: +./qemu-system-i386 -nographic +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: and so and so + +./qemu-system-ppc -nographic +nothing happen ... no exit on console . + + +on 2.6.2 i have: + +qemu-system-ppc -nographic + +>> ============================================================= +>> OpenBIOS 1.1 [Apr 18 2016 08:20] +>> Configuration device id QEMU version 1 machine id 2 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,750 +milliseconds isn't unique. +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:20 +Trying hd:,\\:tbxi... +Trying hd:,\ppc\bootinfo.txt... +Trying hd:,%BOOT... + + +note the 2.6.2 work, before on 2.6.1 i had the same issue of 2.7 and 2.8 + +I can reproduce the same problem on 2.7.0 on a PowerPC G5 for the x86, x86_64 and ppc softmmu targets (minus the Gtk problem, since I use this ported to Cocoa). As with Luigi this seems to be a regression from 2.6.2. There is no change with -nographic. + +See also: https://bugzilla.redhat.com/show_bug.cgi?id=1332449 + +The commenter indicates several BE issues were detected. I have not yet heard from him regarding his patches or whether they were upstreamed here. + +Oh my gosh the great Cameron Kaiser :) + +Looking through old bug tickets ... can you still reproduce the issue with the latest version of QEMU (v4.2) and a more recent Linux distribution? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1658 b/results/classifier/118/review/1658 new file mode 100644 index 000000000..1f6cad994 --- /dev/null +++ b/results/classifier/118/review/1658 @@ -0,0 +1,120 @@ +register: 0.809 +virtual: 0.771 +permissions: 0.753 +user-level: 0.743 +graphic: 0.736 +files: 0.732 +device: 0.728 +architecture: 0.723 +assembly: 0.717 +peripherals: 0.716 +performance: 0.711 +network: 0.709 +vnc: 0.709 +semantic: 0.705 +debug: 0.685 +boot: 0.678 +arm: 0.676 +VMM: 0.675 +PID: 0.657 +socket: 0.640 +risc-v: 0.636 +ppc: 0.619 +kernel: 0.609 +mistranslation: 0.600 +TCG: 0.581 +hypervisor: 0.577 +KVM: 0.542 +x86: 0.491 +i386: 0.371 +-------------------- +arm: 0.998 +debug: 0.572 +boot: 0.191 +virtual: 0.042 +device: 0.039 +hypervisor: 0.020 +files: 0.020 +kernel: 0.015 +TCG: 0.015 +PID: 0.012 +register: 0.007 +performance: 0.005 +peripherals: 0.005 +VMM: 0.005 +semantic: 0.005 +assembly: 0.004 +user-level: 0.004 +architecture: 0.003 +permissions: 0.003 +socket: 0.002 +ppc: 0.002 +network: 0.001 +graphic: 0.001 +KVM: 0.001 +vnc: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +Zephyr TF-M IPC example triggers failed assertion !arm_feature(env, ARM_FEATURE_M) on recent Qemu +Description of problem: +I can't run the TrustedFirmware-M IPC example in the Zephyr repo with recent Qemu (in particular v8.0.0). + +By bisecting, I got the last commit OK : v7.2.0-351-gfaa1451e7b + +``` +$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio +[INF] Beginning TF-M provisioning +[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE +[Sec Thread] Secure image initializing! +Booting TF-M 8209cb2ed +Creating an empty ITS flash layout. +Creating an empty PS flash layout. +[INF][Crypto] Provisioning entropy seed... complete. +*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef *** +TF-M IPC on mps2_an521_ns +The version of the PSA Framework API is 257. +The PSA Crypto service minor version is 1. +Generating 256 bytes of random data: +71 03 DD 50 8E E5 00 C7 E0 61 7B EB 77 15 E9 38 +E9 A8 7D 0C 51 23 76 9F C3 61 E9 8B 8A 67 BD 14 +73 A3 2C 6E E5 8C E3 19 53 6B 50 55 A8 A7 F4 7B +56 03 60 AA 48 B6 DF 04 33 56 BE 84 43 FA 4E AC +D7 6E 2E 2E 1D 7E 46 69 D5 9B B0 42 5C 54 E4 09 +73 9E 4F 55 F8 3E 05 9E A3 DE 46 D3 E4 02 B0 9C +F3 21 9F 20 85 74 34 07 19 79 07 B8 02 B5 0E 90 +74 21 BE B5 09 4C D7 20 D8 43 F7 72 23 1C F0 3E +77 7B D3 70 29 72 69 D3 7F 1F 61 16 12 73 D5 89 +C5 8B D1 A3 7B 4B FD F5 11 C2 B1 9A C0 A5 F9 7B +16 3D 98 17 66 FE E9 F4 FE 37 76 62 E0 E6 83 99 +69 26 41 CD FF 0C 44 AC F9 F4 91 B8 CA 63 5E 1D +B9 C4 38 D6 0C 11 19 1B 94 BE C9 4F EC 2E 5A 05 +3F 72 5F 41 44 3C 91 39 AC 2D 50 75 DF FD D3 11 +39 F2 43 18 D7 69 B0 A3 99 0C C0 6E 83 84 1A A8 +B0 37 6C 8E 32 B2 8E 4F AA 12 97 09 09 87 D3 FD +qemu-system-arm: terminating on signal 2 +``` + +But after 452c67a427, for example v8.0.0-918-g6972ef1440, I get : + +``` +$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio +[INF] Beginning TF-M provisioning +[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE +[Sec Thread] Secure image initializing! +Booting TF-M 8209cb2ed +Creating an empty ITS flash layout. +Creating an empty PS flash layout. +[INF][Crypto] Provisioning entropy seed... complete. +*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef *** +TF-M IPC on mps2_an521_ns +qemu-system-arm: ../target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed. +Aborted +``` +Steps to reproduce: +1. Build the Zephyr tfm_merged.hex file from Zephyr 7ba5ecf451 https://github.com/zephyrproject-rtos/zephyr/commit/7ba5ecf451ef29f96b30dbe5f0e54c1865839093 : ``west -v build -p -b mps2_an521_ns ./samples/tfm_integration/tfm_ipc`` +2. Build qemu-system-arm and run : ``qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio`` +Additional information: +More info to build Zephyr TF-M IPC example on the official repo https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/tfm_integration/tfm_ipc diff --git a/results/classifier/118/review/1658634 b/results/classifier/118/review/1658634 new file mode 100644 index 000000000..d0ad1f57f --- /dev/null +++ b/results/classifier/118/review/1658634 @@ -0,0 +1,460 @@ +mistranslation: 0.887 +user-level: 0.877 +graphic: 0.851 +network: 0.832 +debug: 0.818 +virtual: 0.812 +semantic: 0.805 +register: 0.803 +PID: 0.798 +assembly: 0.796 +permissions: 0.795 +risc-v: 0.791 +arm: 0.786 +device: 0.783 +peripherals: 0.771 +performance: 0.770 +architecture: 0.759 +files: 0.756 +boot: 0.753 +kernel: 0.748 +hypervisor: 0.747 +socket: 0.746 +KVM: 0.734 +VMM: 0.732 +TCG: 0.717 +ppc: 0.681 +vnc: 0.669 +x86: 0.599 +i386: 0.498 +-------------------- +hypervisor: 0.696 +virtual: 0.683 +user-level: 0.526 +debug: 0.041 +x86: 0.036 +files: 0.032 +socket: 0.031 +graphic: 0.027 +TCG: 0.022 +register: 0.020 +device: 0.019 +risc-v: 0.019 +PID: 0.017 +kernel: 0.017 +VMM: 0.016 +boot: 0.016 +vnc: 0.010 +ppc: 0.008 +network: 0.007 +performance: 0.005 +arm: 0.004 +semantic: 0.004 +peripherals: 0.003 +architecture: 0.002 +assembly: 0.002 +mistranslation: 0.001 +KVM: 0.001 +i386: 0.001 +permissions: 0.001 + +Can't get correct display with latest QEMU and OVMF BIOS + +I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: +1. "-vga cirrus" + "-bios OVMF.fd": works +2. "-vga std" + non-UEFI bios: works + +The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. + +(1) What phase of the guest do you get invalid video output in? Do you see the TianoCore splash screen? Does the grub2 menu appear? + +(2) I cannot reproduce the issue (with a different guest OS anyway); I just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at 7cf59c854f35), with stdvga; this combo works fine. + +(3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF binary? + +(4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips instead. Libvirt (strongly recommended) will do this for you. + +Thanks. + +Splash screen and UEFI shell were displayed correctly. Grub2 menu and +Ubuntu login screen also appeared, however the display didn't seem right. I +got very blurry output. + +[image: Inline image 1] + +With QEMU 2.7.0 and the same OVMF.fd, everything works well. + +Please let me know if anything is not clear. + +Thanks, +Kai + +On Mon, Jan 23, 2017 at 4:50 AM, Laszlo Ersek (Red Hat) <email address hidden> +wrote: + +> (1) What phase of the guest do you get invalid video output in? Do you +> see the TianoCore splash screen? Does the grub2 menu appear? +> +> (2) I cannot reproduce the issue (with a different guest OS anyway); I +> just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at +> 7cf59c854f35), with stdvga; this combo works fine. +> +> (3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF +> binary? +> +> (4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips +> instead. Libvirt (strongly recommended) will do this for you. +> +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> Status in QEMU: +> New +> +> Bug description: +> I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and +> OVMF UEFI BIOS, however I can't get correct display output with default vga +> configuration (-vga std). However, qemu works with a couple of different +> configurations: +> 1. "-vga cirrus" + "-bios OVMF.fd": works +> 2. "-vga std" + non-UEFI bios: works +> +> The same error with QEMU 2.8.0 release. Everything works well on +> 2.7.0/1. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> + + +I downloaded "ubuntu-16.04.1-desktop-amd64.iso" (MD5: 17643c29e3c4609818f26becf76d29a3), and I can reproduce the issue -- the grub2 display is corrupt. (I didn't even look further than that.) I also confirm that it works fine with the same firmware, but using QEMU 2.7. + +Here's the result of the bisection: + +cd958edb1fae85d0c7d1e1acbff82d22724e8d64 is the first bad commit +commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Author: Marc-André Lureau <email address hidden> +Date: Fri Aug 26 13:47:11 2016 +0400 + + console: skip same-size resize + + virtio-gpu does a set-scanout at each frame (it might be a driver + regression). qemu_console_resize() recreate a surface even if the size + didn't change, and this shows up in profiling reports because the + surface is cleared. With this patch, I get a +15-20% glmark2 + improvement. + + Signed-off-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +If I revert this commit on top of current master -- it reverts cleanly -- then the grub2 screen displays fine again. + +For reference, this is my script: + +ISO=ubuntu-16.04.1-desktop-amd64.iso +CODE=OVMF_CODE.fd +TMPL=OVMF_VARS.fd + +cp $TMPL vars.fd + +qemu-system-x86_64 \ + -m 1024 \ + -M pc,accel=kvm \ + -device VGA \ + -drive if=pflash,readonly,format=raw,file=$CODE \ + -drive if=pflash,format=raw,file=vars.fd \ + -drive id=cdrom,if=none,readonly,format=raw,file=$ISO \ + -device virtio-scsi-pci,id=scsi0 \ + -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \ + -debugcon file:debug.log \ + -global isa-debugcon.iobase=0x402 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline,default \ + -serial chardev:char0 + + +Added Marc-André and Gerd to the CC list. + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Cc: Marc-André Lureau <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..67c65b7 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Hi + +On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +wrote: + +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Cc: Marc-André Lureau <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..67c65b7 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +> int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +You are missing the 's->' ! + +with that, +Reviewed-by: Marc-André Lureau <email address hidden> + + +-- +> 1.8.3.1 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> +-- +Marc-André Lureau + + +> > - if (s->surface && +> > + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> > pixman_image_get_width(s->surface->image) == width && +> > pixman_image_get_height(s->surface->image) == height) { +> > return; +> > +> +> You are missing the 's->' ! + +Good catch. /me wonders why gcc didn't throw a warning on that one. + +Fixed. + +thanks, + Gerd + + + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..d573351 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +On 01/24/17 11:37, elmarco wrote: +> Hi +> +> On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +> wrote: +> +>> Only skip surface reallocation in case the old surface was created using +>> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +>> might end up with a DisplaySurface with the wrong backing storage. +>> +>> Cc: <email address hidden> +>> Cc: Marc-André Lureau <email address hidden> +>> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +>> Signed-off-by: Gerd Hoffmann <email address hidden> +>> --- +>> ui/console.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/ui/console.c b/ui/console.c +>> index b9575f2..67c65b7 100644 +>> --- a/ui/console.c +>> +++ b/ui/console.c +>> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +>> int height) +>> +>> assert(s->console_type == GRAPHIC_CONSOLE); +>> +>> - if (s->surface && +>> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +>> pixman_image_get_width(s->surface->image) == width && +>> pixman_image_get_height(s->surface->image) == height) { +>> return; +>> +> +> You are missing the 's->' ! +> +> with that, +> Reviewed-by: Marc-André Lureau <email address hidden> + +With that change: + +Tested-by: Laszlo Ersek <email address hidden> + +Also, + +Cc: <email address hidden> + +Thanks +Laszlo + + +> -- +>> 1.8.3.1 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1658634 +>> +>> Title: +>> Can't get correct display with latest QEMU and OVMF BIOS +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +>> + + + +On 01/24/17 12:10, Gerd Hoffmann wrote: +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> Reviewed-by: Marc-André Lureau <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..d573351 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +Tested-by: Laszlo Ersek <email address hidden> +Cc: <email address hidden> + +Thanks +Laszlo + + +It works well on my side with the patch. Thanks! + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +Tested-by: Laszlo Ersek <email address hidden> +Message-id: <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index fe03a66..e353c85 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2116,7 +2116,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Fixed in commit 3ef0c573d37b ("console: fix console resize", 2017-01-31), released in v2.9.0. + + diff --git a/results/classifier/118/review/166 b/results/classifier/118/review/166 new file mode 100644 index 000000000..326b2ec1e --- /dev/null +++ b/results/classifier/118/review/166 @@ -0,0 +1,61 @@ +mistranslation: 0.996 +semantic: 0.899 +device: 0.600 +performance: 0.521 +graphic: 0.513 +i386: 0.310 +architecture: 0.291 +arm: 0.290 +network: 0.283 +virtual: 0.172 +TCG: 0.167 +VMM: 0.146 +peripherals: 0.129 +x86: 0.120 +ppc: 0.107 +user-level: 0.103 +debug: 0.085 +permissions: 0.078 +register: 0.069 +vnc: 0.068 +assembly: 0.060 +PID: 0.055 +hypervisor: 0.033 +risc-v: 0.022 +KVM: 0.016 +boot: 0.013 +files: 0.009 +socket: 0.008 +kernel: 0.002 +-------------------- +virtual: 0.966 +hypervisor: 0.845 +user-level: 0.262 +debug: 0.066 +network: 0.062 +x86: 0.038 +performance: 0.026 +semantic: 0.023 +peripherals: 0.023 +device: 0.019 +PID: 0.017 +TCG: 0.013 +i386: 0.012 +files: 0.010 +assembly: 0.008 +arm: 0.007 +VMM: 0.007 +KVM: 0.006 +ppc: 0.004 +mistranslation: 0.004 +register: 0.003 +boot: 0.003 +architecture: 0.003 +socket: 0.002 +risc-v: 0.002 +kernel: 0.002 +graphic: 0.002 +vnc: 0.001 +permissions: 0.000 + +qemu-bridge-helper failure but qemu not exit diff --git a/results/classifier/118/review/1660010 b/results/classifier/118/review/1660010 new file mode 100644 index 000000000..dfd9ac55e --- /dev/null +++ b/results/classifier/118/review/1660010 @@ -0,0 +1,103 @@ +architecture: 0.928 +kernel: 0.773 +TCG: 0.636 +mistranslation: 0.614 +user-level: 0.581 +semantic: 0.558 +files: 0.551 +device: 0.542 +PID: 0.541 +socket: 0.517 +ppc: 0.516 +register: 0.503 +network: 0.473 +performance: 0.443 +hypervisor: 0.421 +graphic: 0.418 +vnc: 0.394 +arm: 0.351 +risc-v: 0.336 +permissions: 0.328 +x86: 0.296 +boot: 0.264 +VMM: 0.262 +i386: 0.239 +debug: 0.208 +virtual: 0.199 +assembly: 0.174 +peripherals: 0.171 +KVM: 0.102 +-------------------- +kernel: 0.806 +TCG: 0.383 +debug: 0.252 +files: 0.210 +virtual: 0.187 +register: 0.064 +hypervisor: 0.036 +socket: 0.022 +network: 0.021 +PID: 0.019 +device: 0.014 +architecture: 0.010 +boot: 0.010 +arm: 0.010 +VMM: 0.007 +user-level: 0.006 +risc-v: 0.006 +semantic: 0.004 +assembly: 0.003 +vnc: 0.003 +x86: 0.002 +performance: 0.002 +graphic: 0.001 +permissions: 0.001 +ppc: 0.001 +peripherals: 0.001 +KVM: 0.001 +i386: 0.001 +mistranslation: 0.001 + +AArch64 system emulation cannot execute virt uefi in 2.7 or 2.8 + +The UEFI firmware file is retrieved from http://snapshots.linaro.org/components/kernel/linaro-edk2/latest/release/qemu64/QEMU_EFI.fd . + +The error is: +``` +TODO /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg_qemu_tb_exec() +/var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg fatal error +``` + +(both 2.7.0 and 2.8.0 are tested to fail, 2.6.1 works) + + +Icenowy Zheng <email address hidden> writes: + +> Public bug reported: +> +> The UEFI firmware file is retrieved from +> http://snapshots.linaro.org/components/kernel/linaro- +> edk2/latest/release/qemu64/QEMU_EFI.fd . +> +> The error is: +> ``` +> TODO /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg_qemu_tb_exec() +> /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg fatal error +> ``` + +What is your command line and why are you running with the TCI? + +> +> (both 2.7.0 and 2.8.0 are tested to fail, 2.6.1 works) +> +> ** Affects: qemu +> Importance: Undecided +> Status: New + + +-- +Alex Bennée + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1660599 b/results/classifier/118/review/1660599 new file mode 100644 index 000000000..eaa8ab73a --- /dev/null +++ b/results/classifier/118/review/1660599 @@ -0,0 +1,73 @@ +mistranslation: 0.814 +graphic: 0.789 +device: 0.705 +semantic: 0.624 +architecture: 0.539 +user-level: 0.534 +network: 0.414 +performance: 0.374 +x86: 0.313 +PID: 0.306 +vnc: 0.284 +socket: 0.272 +debug: 0.267 +register: 0.266 +i386: 0.261 +ppc: 0.232 +kernel: 0.203 +virtual: 0.200 +boot: 0.194 +files: 0.167 +permissions: 0.164 +TCG: 0.145 +risc-v: 0.143 +VMM: 0.121 +peripherals: 0.106 +arm: 0.100 +hypervisor: 0.084 +assembly: 0.061 +KVM: 0.019 +-------------------- +x86: 0.504 +hypervisor: 0.038 +TCG: 0.032 +i386: 0.023 +user-level: 0.014 +ppc: 0.014 +files: 0.011 +virtual: 0.011 +register: 0.009 +kernel: 0.008 +debug: 0.006 +semantic: 0.004 +arm: 0.004 +PID: 0.004 +device: 0.004 +network: 0.003 +peripherals: 0.002 +performance: 0.002 +VMM: 0.001 +socket: 0.001 +architecture: 0.001 +boot: 0.001 +vnc: 0.001 +assembly: 0.001 +risc-v: 0.001 +permissions: 0.000 +graphic: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +v2.8.0 won't compile if g++ compiler doesn't understand "-fstack-protector-strong" + +For example, Ubuntu Trusty (LTS 14.04) uses g++ v4.8.5. +Compilation fails with a syntax error saying that the ""-fstack-protector-strong" option in g++ is unrecognized. +Instead, under Ubuntu Xenial (LTS 16.04), the g++ compiler is v5.4.0 and the compilation goes on smoothly. + +Could you provide the command you've used? +I tried `CC=gcc-4.8 ./configure --enable-stack-protector && make` in Ubuntu 14.04 and qemu v2.8.0. It didn't set `-fstack-protector-strong` flag, only `-fstack-protector-all`. + +Which version of gcc (i.e. normal C-compiler, not g++) did you use here? Can you still reproduce this issue with the latest release of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1662050 b/results/classifier/118/review/1662050 new file mode 100644 index 000000000..c72ddb069 --- /dev/null +++ b/results/classifier/118/review/1662050 @@ -0,0 +1,420 @@ +assembly: 0.865 +virtual: 0.848 +arm: 0.846 +permissions: 0.846 +socket: 0.841 +peripherals: 0.838 +register: 0.824 +user-level: 0.808 +device: 0.806 +semantic: 0.800 +graphic: 0.800 +debug: 0.781 +PID: 0.777 +ppc: 0.775 +performance: 0.773 +hypervisor: 0.773 +risc-v: 0.769 +KVM: 0.739 +files: 0.739 +TCG: 0.732 +mistranslation: 0.732 +VMM: 0.724 +kernel: 0.718 +architecture: 0.717 +boot: 0.693 +network: 0.645 +x86: 0.589 +vnc: 0.587 +i386: 0.425 +-------------------- +virtual: 0.814 +user-level: 0.798 +VMM: 0.791 +risc-v: 0.791 +TCG: 0.773 +register: 0.747 +PID: 0.718 +vnc: 0.697 +device: 0.492 +boot: 0.427 +hypervisor: 0.361 +ppc: 0.332 +socket: 0.292 +files: 0.189 +x86: 0.167 +i386: 0.085 +network: 0.066 +semantic: 0.064 +arm: 0.058 +debug: 0.037 +permissions: 0.036 +peripherals: 0.031 +kernel: 0.014 +graphic: 0.012 +KVM: 0.010 +assembly: 0.006 +architecture: 0.006 +mistranslation: 0.003 +performance: 0.003 + +qemu-img convert a overlay qcow2 image into a entire image + +I have a base image file "base.qcow2" and a delta qcow2 image file "delta.qcow2" whose backing file is "base.qcow2". + +Now I use qemu-img to convert "delta.qcow2" and will get a new image file "new.qcow2" which is complete and equivalent to combination of "base.qcow2" and "delta.qcow2". + +In fact, i just want to convert the delta qcow2 image file and get a new delta overlay qcow2 image file. So the "new.qcow2" is not what i want. I have to admit that this is not bug. Could you please take this as a new feature and enable qemu-img to convert images in-place? + +On 02/05/2017 09:19 PM, wayen wrote: +> +> I have a base image file "base.qcow2" and a delta qcow2 image file +> "delta.qcow2" whose backing file is "base.qcow2". +> +> Now I use qemu-img to convert "delta.qcow2" and will get a new image +> + file "new.qcow2" which is entire and equivalent to combination of +> "base.qcow2" and "delta.qcow2". +> +> In fact, i just want to convert the delta qcow2 image file and get a new +> delta overlay qcow2 image file. So the "new.qcow2" is not what i want. I +> have to admit that this is not bug. Could you please take this as a new +> feature and enable qemu-img to convert images in-place? + +This feature already exists. Use: + +qemu-img rebase -F $backing_fmt -b '' -f qcow2 delta.qcow2 + +and now delta.qcow2 will be a complete image. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +@Eric Blake, Thanks very much for your help. In your way, I have verified that this feature already exists. + +@Eric Blake. Sorry, I didn't make it clear. In fact, I don't want to get a complete image. I just want to convert qcow2 overlay and get a new qcow2 overlay. Maybe you think my intention is meaningless， but this is what I want. + +Can't you simply do a "cp delta.qcow2 new.qcow2" ? + +@Thomas Huth, when we use qemu-img to convert a image "A" and will get a new image "B" which is equivalent to "A" . But "B" may be a lot different from "A",such as file size. The file size of "B" is usually less than "A" and this is very valuable to me. So I can't simply do a "cp delta.qcow2 new.qcow2" ? + +I meant to copy B, not A ... but I likely just haven't really understood what you're really trying to do here, so never mind. + +@Thomas Huth, I just want to reduce the file size of qcow2 overlay image by this conversion. + +On 02/08/2017 02:16 AM, wayen wrote: +> @Thomas Huth, I just want to reduce the file size of qcow2 overlay image +> by this conversion. + +Are you merely trying to sparsify the file (punch holes on the portion +of the file that is not mapped to disk), so that the apparent file size +is unchanged, but the actual disk usage is minimized? That's probably +already possible (virt-sparsify from libguestfs seems to be able to do +it; look at what steps it uses). + +Or are you asking for a way to defragment the file, so that the apparent +size shrinks because all occupied clusters are now contiguous, so that +there are no longer any need for holes? The end result is the same +amount of disk usage, but right now, the only way to defragment is to +convert from one image to a copy; we don't support in-place +defragmentation yet. So far, no one has come up with a compelling +reason why it is needed, or a patch to implement it, but there's no +technical reason why it can't be done. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +@Eric Blake, I used virt-sparsify to sparsify the qcow2 overlay image. As you said, the actual disk usage is minimized and the apparent file size is unchanged.It is very valuable for me, because it means that my disk can hold more files. + +But we need to be careful when transfer the sparse qcow2 overlays. Because some tools do not support sparse file and will convert it into a common file,for example, scp. And I doubt what will happen when transfer sparse files between different file systems. + +So I want to use qemu-img to convert the sparse qcow2 overlay into common file. If this was feasible, the holes in the sparse overlay will be removed and the above problems will disappear. + +On Thu, Feb 09, 2017 at 02:05:54AM -0000, wayen wrote: +> @Eric Blake, I used virt-sparsify to sparsify the qcow2 overlay image. +> As you said, the actual disk usage is minimized and the apparent file +> size is unchanged.It is very valuable for me, because it means that my +> disk can hold more files. +> +> But we need to be careful when transfer the sparse qcow2 overlays. +> Because some tools do not support sparse file and will convert it into a +> common file,for example, scp. And I doubt what will happen when transfer +> sparse files between different file systems. +> +> So I want to use qemu-img to convert the sparse qcow2 overlay into +> common file. If this was feasible, the holes in the sparse overlay will +> be removed and the above problems will disappear. + +You can use the drive_mirror HMP command or drive-mirror QMP command on +a running QEMU instance to copy the data to a new file and switch to the +new file. + +I'm curious what exactly is being optimized by copying out a fresh qcow2 +image. + +Please post the output of: + + $ stat delta.qcow2 + $ qemu-img map delta.qcow2 + $ stat new.qcow2 + $ qemu-img map new.qcow2 + +This will allow us to see the size and data layout differences. + +Maybe a new command should be added to QEMU to do the optimization +in-place. This would avoid the disk space overhead associated with +drive-mirror, cp, qemu-img convert, etc. + +Stefan + + + + + + + + + + +On Tue, Feb 14, 2017 at 02:17:16AM -0000, wayen wrote: +> ** Attachment added: "qemu-img map new.qcow2 output" +> https://bugs.launchpad.net/qemu/+bug/1662050/+attachment/4818564/+files/qemu_img_map_new_qcow2.txt + +Thanks for posting the attachments. + +I ran a script to find unallocated clusters in the delta.qcow2 host +file. Most are actually qcow2 metadata (L1/L2 tables, refcount blocks). + +This output shows that any image file size reduction you are hoping to +achieve can only come from zero clusters. + +There are no holes in the files that would result in significant image +file size reduction if a new image were written out. + +Just wanted to share this info in case anyone else is thinking about how +to optimize qcow2 files. I still think rewriting images sequentially +can be useful - if internal snapshots were used and deleted then COW can +result in holes. + +Hole at 0 size 5.0 clusters +Hole at 393216 size 1.0 clusters +Hole at 589824 size 1.0 clusters +Hole at 1114112 size 1.0 clusters +Hole at 1310720 size 1.0 clusters +Hole at 1507328 size 1.0 clusters +Hole at 1703936 size 1.0 clusters +Hole at 2293760 size 1.0 clusters +Hole at 2621440 size 1.0 clusters +Hole at 3080192 size 1.0 clusters +Hole at 5111808 size 1.0 clusters +Hole at 6291456 size 1.0 clusters +Hole at 30408704 size 1.0 clusters +Hole at 47906816 size 1.0 clusters +Hole at 142671872 size 1.0 clusters +Hole at 219545600 size 1.0 clusters +Hole at 667090944 size 1.0 clusters +Hole at 853868544 size 1.0 clusters +Hole at 1562640384 size 1.0 clusters +Hole at 2147483648 size 1.0 clusters +Hole at 2617180160 size 1.0 clusters +Hole at 3411148800 size 1.0 clusters +Hole at 4107075584 size 1.0 clusters +Hole at 4294967296 size 1.0 clusters +Hole at 4452646912 size 1.0 clusters +Hole at 4792057856 size 1.0 clusters +Hole at 5494865920 size 1.0 clusters +Hole at 5645271040 size 1.0 clusters +Hole at 5702483968 size 1.0 clusters +Hole at 6187188224 size 1.0 clusters +Hole at 6442450944 size 1.0 clusters +Hole at 6862995456 size 1.0 clusters +Hole at 6987317248 size 1.0 clusters +Hole at 7567245312 size 1.0 clusters +Hole at 8135245824 size 1.0 clusters +Hole at 8590589952 size 1.0 clusters +Hole at 8613462016 size 1.0 clusters +Hole at 9055436800 size 1.0 clusters +Hole at 9703522304 size 1.0 clusters +Hole at 10279321600 size 1.0 clusters +Hole at 10737418240 size 3.0 clusters +Hole at 10844372992 size 1.0 clusters +Hole at 11167858688 size 1.0 clusters +Hole at 11209605120 size 1.0 clusters +Hole at 11209801728 size 1.0 clusters +Hole at 11730944000 size 1.0 clusters +Hole at 12183207936 size 1.0 clusters +Hole at 12705464320 size 1.0 clusters +Hole at 12884901888 size 1.0 clusters +Hole at 13444120576 size 1.0 clusters +Hole at 13910016000 size 1.0 clusters +Hole at 14182711296 size 1.0 clusters +Hole at 15025635328 size 1.0 clusters +Hole at 15032385536 size 1.0 clusters + +The following script draws the allocated clusters and holes in the image +file. I took your qemu-img map output, filtered out any lines with +base.qcow2, and sorted using sort -k3 -g to sort on the "Mapped to" +field. Then I ran ./qcow2-map-svg.py <filtered.txt >output.svg. + +#!/usr/bin/python3 +import sys +import io + +COLOR_ALLOCATED = '#ffaaaa' +COLOR_HOLE = '#999999' + +def svg_percentage(value, total): + return '{0}%'.format(100.0 * value / total) + +def svg_rect(x, width, color): + print('<rect x="{0}" y="0" width="{1}" height="40" fill="{2}" stroke="none" />'.format(x, width, color), file=out) + +def svg_text(x, y, text): + print('<text x="{0}" y="{1}">{2}</text>'.format(x, y, text), file=out) + +out = io.StringIO() + +print('''<?xml version="1.0" encoding="UTF-8" ?> +<svg xmlns="http://www.w3.org/2000/svg" version="1.1">''', file=out) + +file_map = [] +header = True +for line in sys.stdin: + if header: + header = False + continue + + offset, length, mapped, filename = line.split() + offset = int(offset, 16) + length = int(length, 16) + mapped = int(mapped, 16) + + file_map.append((offset, length, mapped, filename)) + +file_size = file_map[-1][2] + file_map[-1][1] +last_mapped = 0 +for _, length, mapped, _ in file_map: + if mapped > last_mapped: +# if mapped - last_mapped: +# print('Hole at {0} size {1} clusters'.format(last_mapped, (mapped - last_mapped) / 65536)) + svg_rect(svg_percentage(last_mapped, file_size), + svg_percentage(mapped - last_mapped, file_size), + COLOR_HOLE) + + svg_rect(svg_percentage(mapped, file_size), + svg_percentage(length, file_size), + COLOR_ALLOCATED) + last_mapped = mapped + length +if last_mapped < file_size: + svg_rect(svg_percentage(last_mapped, file_size), + svg_percentage(file_size - last_mapped, file_size), + COLOR_HOLE) + +for i in range(10): + svg_text(svg_percentage(i, 10), 60, svg_percentage(i, 10)) + +print('</svg>', file=out) + +print(out.getvalue()) + + +Is there any way to remove holes from qcow2 overlay images? It's very important to me. I am looking forward to your reply. + +Is there any way to remove holes from sparse qcow2 overlay? It's very important to me. I am looking forward to your reply. + +Hi wayen: + Which version are you used? + I also find this problem on old version qemu, and i write a patch +for it. It works. + I'm not sure the mainline version have solve this problem. + what command are you used? + +On Mon, Apr 10, 2017 at 10:14 AM, wayen <email address hidden> wrote: +> Is there any way to remove holes from qcow2 overlay images? It's very +> important to me. I am looking forward to your reply. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1662050 +> +> Title: +> qemu-img convert a overlay qcow2 image into a entire image +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> I have a base image file "base.qcow2" and a delta qcow2 image file +> "delta.qcow2" whose backing file is "base.qcow2". +> +> Now I use qemu-img to convert "delta.qcow2" and will get a new image +> file "new.qcow2" which is entire and equivalent to combination of +> "base.qcow2" and "delta.qcow2". +> +> In fact,I don't want to get a complete image.I just want to convert +> delta qcow2 image file "A" to a New delta overlay qcow2 image "B" +> which is equivalent to "A". So the "new.qcow2" is not what i want. I +> have to admit that this is not bug. Could you please take this as a +> new feature and enable qemu-img to convert qcow2 overlay itself? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions +> + + +Hi Lidong Chen: + I used QEMU 2.0.0 on Ubuntu 14.04. + Do you mean your patch can make qemu-img convert qcow2 overlay into a new overlay? + + +On Mon, Apr 10, 2017 at 1:07 PM, wayen <email address hidden> wrote: +> Hi Lidong Chen: +> I used QEMU 2.0.0 on Ubuntu 14.04. +> Do you mean your patch can make qemu-img convert qcow2 overlay into a new overlay? + +yes. but i find it already fixed in 2.0.0. +do you add the -o backing_file= option in the command? + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1662050 +> +> Title: +> qemu-img convert a overlay qcow2 image into a entire image +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> I have a base image file "base.qcow2" and a delta qcow2 image file +> "delta.qcow2" whose backing file is "base.qcow2". +> +> Now I use qemu-img to convert "delta.qcow2" and will get a new image +> file "new.qcow2" which is entire and equivalent to combination of +> "base.qcow2" and "delta.qcow2". +> +> In fact,I don't want to get a complete image.I just want to convert +> delta qcow2 image file "A" to a New delta overlay qcow2 image "B" +> which is equivalent to "A". So the "new.qcow2" is not what i want. I +> have to admit that this is not bug. Could you please take this as a +> new feature and enable qemu-img to convert qcow2 overlay itself? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions +> + + +Hi Lidong Chen: + + I forgot to use this option.I think the way you said is effective.I will try it.Thank you very much for your help + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1665344 b/results/classifier/118/review/1665344 new file mode 100644 index 000000000..a37daa354 --- /dev/null +++ b/results/classifier/118/review/1665344 @@ -0,0 +1,73 @@ +mistranslation: 0.910 +device: 0.905 +graphic: 0.892 +arm: 0.814 +network: 0.803 +ppc: 0.790 +socket: 0.771 +files: 0.768 +risc-v: 0.752 +vnc: 0.741 +semantic: 0.661 +boot: 0.626 +register: 0.617 +kernel: 0.606 +performance: 0.557 +VMM: 0.546 +permissions: 0.537 +TCG: 0.513 +user-level: 0.495 +architecture: 0.450 +PID: 0.444 +peripherals: 0.439 +x86: 0.431 +hypervisor: 0.421 +KVM: 0.402 +i386: 0.373 +debug: 0.363 +assembly: 0.265 +virtual: 0.224 +-------------------- +network: 0.761 +hypervisor: 0.480 +x86: 0.085 +virtual: 0.074 +files: 0.073 +TCG: 0.068 +VMM: 0.059 +debug: 0.058 +user-level: 0.044 +KVM: 0.032 +i386: 0.025 +risc-v: 0.024 +arm: 0.013 +device: 0.013 +kernel: 0.012 +ppc: 0.009 +PID: 0.007 +semantic: 0.006 +peripherals: 0.006 +socket: 0.006 +vnc: 0.005 +performance: 0.004 +boot: 0.004 +architecture: 0.004 +graphic: 0.003 +assembly: 0.003 +permissions: 0.001 +register: 0.001 +mistranslation: 0.000 + +documentation error:404 not found + +In http://wiki.qemu-project.org/Outreachy_2017_MayAugust the urls + http://www.qemu-project.org/images/4/4e/Q35.pdf and http://www.qemu-project.org/images/f/f6/PCIvsPCIe.pdf on opening displays: + + + + Not Found + +The requested URL /images/4/4e/Q35.pdf was not found on this server. + +Thanks for letting us know. The links have been updated on the wiki page. + diff --git a/results/classifier/118/review/1667 b/results/classifier/118/review/1667 new file mode 100644 index 000000000..eec775a58 --- /dev/null +++ b/results/classifier/118/review/1667 @@ -0,0 +1,61 @@ +mistranslation: 0.808 +graphic: 0.798 +device: 0.638 +semantic: 0.417 +arm: 0.412 +performance: 0.394 +risc-v: 0.377 +permissions: 0.372 +register: 0.278 +vnc: 0.228 +debug: 0.181 +TCG: 0.177 +network: 0.172 +ppc: 0.160 +i386: 0.135 +architecture: 0.125 +boot: 0.117 +x86: 0.108 +VMM: 0.108 +virtual: 0.086 +socket: 0.061 +user-level: 0.061 +PID: 0.060 +KVM: 0.047 +files: 0.039 +hypervisor: 0.039 +assembly: 0.037 +peripherals: 0.012 +kernel: 0.006 +-------------------- +assembly: 0.829 +x86: 0.098 +debug: 0.055 +virtual: 0.052 +i386: 0.042 +device: 0.041 +files: 0.039 +user-level: 0.033 +peripherals: 0.018 +semantic: 0.017 +TCG: 0.015 +kernel: 0.013 +architecture: 0.012 +boot: 0.011 +performance: 0.009 +register: 0.002 +hypervisor: 0.002 +ppc: 0.002 +arm: 0.002 +mistranslation: 0.002 +graphic: 0.001 +network: 0.001 +KVM: 0.001 +socket: 0.001 +permissions: 0.001 +PID: 0.001 +VMM: 0.001 +vnc: 0.000 +risc-v: 0.000 + +Tricore: missing a few TC1.6.2 instruction set diff --git a/results/classifier/118/review/1668 b/results/classifier/118/review/1668 new file mode 100644 index 000000000..78dc87c6c --- /dev/null +++ b/results/classifier/118/review/1668 @@ -0,0 +1,105 @@ +mistranslation: 0.948 +architecture: 0.901 +files: 0.900 +x86: 0.899 +device: 0.850 +graphic: 0.825 +ppc: 0.819 +PID: 0.815 +vnc: 0.704 +user-level: 0.687 +network: 0.667 +socket: 0.655 +kernel: 0.649 +performance: 0.647 +semantic: 0.646 +TCG: 0.635 +risc-v: 0.613 +register: 0.612 +debug: 0.610 +permissions: 0.607 +VMM: 0.578 +i386: 0.560 +boot: 0.513 +arm: 0.504 +assembly: 0.450 +hypervisor: 0.419 +virtual: 0.405 +peripherals: 0.402 +KVM: 0.241 +-------------------- +virtual: 0.624 +debug: 0.400 +TCG: 0.049 +files: 0.020 +PID: 0.017 +hypervisor: 0.013 +register: 0.011 +kernel: 0.011 +x86: 0.010 +user-level: 0.010 +performance: 0.006 +semantic: 0.005 +network: 0.005 +architecture: 0.004 +VMM: 0.004 +device: 0.003 +boot: 0.002 +socket: 0.002 +KVM: 0.002 +peripherals: 0.002 +assembly: 0.001 +graphic: 0.001 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +ppc: 0.001 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +Fedora 38 build of clang 16 fails when run under s390x emulation (both system & linux-user) +Description of problem: +Spawn a Fedora 38 container using `s390x` linux-user based emulation + +``` +$ podman run -it --platform linux/s390x fedora:latest +``` + +Install clang inside it + +``` +sh-5.2# dnf -y install clang +``` + +Try to run clang + +``` +sh-5.2# clang --version +clang version 16.0.4 (Fedora 16.0.4-1.fc38) +Target: s390x-redhat-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +sh-5.2# clang --help +clang-16: error: unsupported option '--help'; did you mean '--help'? +clang-16: error: no input files +``` + +Notice the nonsense error message when requesting `--help`. With Fedora 37 build of clang 15 (compiled with gcc 12), under s390x emulation, `--help` will correctly print the help. In fact all options except for `--version` appear to be broken: + +``` +sh-5.2# echo "void foo(void) {}" > foo.c +sh-5.2# clang -c foo.c +clang-16: error: unknown argument: '-c' +``` + + +IOW, there appears to be something in the clang 16 (compiled with gcc 13) in Fedora 38 that is tripping up s390x emulation. + +It is unclear whether the trigger was from building clang 16 with a newer gcc 13, or whether something changed from clang 15 -> 16. + +Originally reported with qemu-user-static-7.2.1-1.fc38.x86_64, but I've reproduced with QEMU upstream 7.1.0 release and QEMU upstream git master (v8.0.0-394-gc2b7158455) + +This was originally reported in Fedora at + + https://bugzilla.redhat.com/show_bug.cgi?id=2209635 diff --git a/results/classifier/118/review/1668041 b/results/classifier/118/review/1668041 new file mode 100644 index 000000000..60f10a718 --- /dev/null +++ b/results/classifier/118/review/1668041 @@ -0,0 +1,149 @@ +risc-v: 0.925 +register: 0.858 +x86: 0.852 +PID: 0.848 +device: 0.847 +architecture: 0.841 +virtual: 0.834 +permissions: 0.823 +ppc: 0.817 +network: 0.812 +graphic: 0.802 +debug: 0.801 +arm: 0.797 +user-level: 0.797 +semantic: 0.777 +peripherals: 0.771 +performance: 0.765 +hypervisor: 0.757 +i386: 0.750 +files: 0.749 +mistranslation: 0.719 +boot: 0.712 +assembly: 0.711 +TCG: 0.711 +KVM: 0.675 +VMM: 0.674 +vnc: 0.620 +socket: 0.544 +kernel: 0.523 +-------------------- +x86: 0.987 +i386: 0.776 +virtual: 0.272 +debug: 0.084 +hypervisor: 0.051 +kernel: 0.030 +files: 0.022 +performance: 0.017 +user-level: 0.011 +network: 0.008 +PID: 0.008 +architecture: 0.007 +KVM: 0.005 +TCG: 0.004 +semantic: 0.004 +device: 0.004 +register: 0.003 +assembly: 0.003 +ppc: 0.002 +risc-v: 0.002 +socket: 0.001 +boot: 0.001 +vnc: 0.001 +peripherals: 0.001 +graphic: 0.001 +permissions: 0.001 +VMM: 0.001 +mistranslation: 0.000 +arm: 0.000 + +x86 Floating point exceptions - incorrect support? + +It seems that qemu does not correctly emulate the x86 support for optionally causing a floating-point exception (#FP) when, for example, dividing by zero. Reports such as: + +https://github.com/cloudius-systems/osv/issues/855 +http://stackoverflow.com/questions/15134189/qemu-div-by-zero-mxcsr-register + +suggest that setting the exception mask in the fpu cw or mxcsr (e.g., using a function like feenableexcept() in the guest OS) does not generate floating point exceptions on divide by zero. The problem only happens on pure QEMU - when a QEMU/KVM combination is used, the actual hardware does the floating point work, and does throw the exception on divide by zero if so requested. + +Looking at the qemu (2.8.0) source code, it seems to me it really lacks support for generating fpu exceptions: For example, helper_fdiv() in target-i386/fpu_helper.c, when it notices the divisor is zero, seems to set the divide-by-zero exception bit, but doesn't seem to check whether it needs to trigger an exception (when the right bits on the x87 or SSE control words are enabled). + +Hi, + +This problem still exists on QEMU 5.0.0 both for i386 and x86_64; +floating-point zero division is not trapped at all, while integer +one is trapped correctly. + +This seriously affects NetBSD project, which carries out periodic +regression tests on QEMU: + +https://releng.netbsd.org/test-results.html + +Tests including floating-point zero division are falling on QEMU, +while they are successfully passing on real hardwares. + +HOW TO REPEAT: + +Compile and run this program on Unix like operating systems: + +--- +#include <fenv.h> +#include <stdlib.h> +#include <unistd.h> + +int +main(void) +{ + volatile double a = getpid(); + volatile double b = atoi("0"); + + feenableexcept(FE_ALL_EXCEPT); + + usleep((int)(a / b)); + + return 0; +} +--- + +It crashes by SIGFPE on real hardware, but normally exits on QEMU. + +I ran this program on NetBSD 9.0 for x86_64 and i386 on QEMU 5.0.0: + +(1) Obtain NetBSD 9.0 release from here: + +For x86_64: +http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-amd64.iso + +For i386: +http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-i386.iso + +(2) Install it for disk image. + +(3) qemu-system-x86_64 NetBSD.qcow2 or qemu-system-i386 NetBSD.qcow2 + +(4) Compile and run the test program above: + +# cc fpe.c -lm -o fpe +# ./fpe + +(5) Then, it exits normally, while it should abort due to SIGFPE. + +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 all 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. + + +Bug still present as of commit 7fbd7e710323c8f4c (just before 5.2 release); tested with a Linux guest in system emulation and with Linux usermode. + +The underlying problem is that we don't properly implement trapping FP exceptions; see the final paragraph in the commit message for commit 418b0f93d12a1589d50. + + + +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/215 + + diff --git a/results/classifier/118/review/1668360 b/results/classifier/118/review/1668360 new file mode 100644 index 000000000..cf67b0404 --- /dev/null +++ b/results/classifier/118/review/1668360 @@ -0,0 +1,67 @@ +mistranslation: 0.972 +graphic: 0.786 +device: 0.768 +KVM: 0.718 +semantic: 0.677 +arm: 0.621 +risc-v: 0.571 +network: 0.568 +files: 0.555 +vnc: 0.544 +ppc: 0.527 +VMM: 0.473 +socket: 0.465 +assembly: 0.426 +kernel: 0.383 +x86: 0.358 +i386: 0.344 +hypervisor: 0.331 +PID: 0.321 +boot: 0.314 +architecture: 0.311 +peripherals: 0.228 +register: 0.217 +permissions: 0.202 +debug: 0.190 +TCG: 0.178 +performance: 0.170 +virtual: 0.140 +user-level: 0.077 +-------------------- +KVM: 0.832 +hypervisor: 0.751 +TCG: 0.135 +network: 0.096 +virtual: 0.092 +x86: 0.086 +files: 0.073 +debug: 0.052 +kernel: 0.051 +user-level: 0.046 +ppc: 0.036 +VMM: 0.016 +i386: 0.015 +arm: 0.011 +device: 0.009 +semantic: 0.008 +risc-v: 0.005 +socket: 0.005 +PID: 0.005 +peripherals: 0.003 +graphic: 0.003 +vnc: 0.002 +register: 0.002 +boot: 0.002 +performance: 0.002 +assembly: 0.002 +architecture: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +Documentation error :404 not found + +In http://wiki.qemu-project.org/Documentation/GettingStartedDevelopers the url http://www.linux-kvm.org/wiki/images/1/17/2010-forum-qmp-status-talk.pp.pdf displays a 404 NOt found error. + +Thanks for the report; the right URL is https://www.linux-kvm.org/images/1/17/2010-forum-qmp-status-talk.pp.pdf and I have updated the wiki page. + + diff --git a/results/classifier/118/review/1670 b/results/classifier/118/review/1670 new file mode 100644 index 000000000..d78c7355d --- /dev/null +++ b/results/classifier/118/review/1670 @@ -0,0 +1,69 @@ +x86: 0.906 +device: 0.883 +architecture: 0.878 +graphic: 0.856 +files: 0.833 +network: 0.794 +semantic: 0.704 +PID: 0.697 +TCG: 0.669 +ppc: 0.624 +vnc: 0.588 +permissions: 0.546 +register: 0.537 +user-level: 0.509 +boot: 0.480 +debug: 0.476 +kernel: 0.465 +socket: 0.455 +risc-v: 0.453 +performance: 0.449 +hypervisor: 0.385 +arm: 0.376 +mistranslation: 0.360 +VMM: 0.324 +peripherals: 0.255 +virtual: 0.229 +assembly: 0.163 +i386: 0.145 +KVM: 0.077 +-------------------- +x86: 0.770 +user-level: 0.747 +files: 0.130 +hypervisor: 0.113 +TCG: 0.110 +semantic: 0.078 +network: 0.064 +register: 0.051 +kernel: 0.025 +debug: 0.022 +virtual: 0.022 +PID: 0.017 +device: 0.011 +architecture: 0.009 +VMM: 0.008 +socket: 0.006 +risc-v: 0.004 +assembly: 0.004 +ppc: 0.003 +boot: 0.003 +arm: 0.003 +performance: 0.002 +vnc: 0.002 +graphic: 0.002 +peripherals: 0.001 +permissions: 0.001 +KVM: 0.001 +i386: 0.001 +mistranslation: 0.000 + +Cannot statically build x86_64-softmmu with Darwin(Intel) +Description of problem: +I am using `Podman` and currently,`Podman` uses qemu on macOS. The `Podman` team has adopted a scheme to dynamically compile `qemu` (https://github.com/containers/podman-machine-qemu). However, I am currently trying to use static compilation for both amd64 and arm64 targets. + +I have searched many articles online, most of which are about static compilation on Linux. Very few articles mention static compilation on macOS, and some mention that `softmmu` does not support static compilation. However, I have not found any concrete evidence to support this claim. + +I also want to ask another question: Does `qemu` support static compilation on macOS? +Additional information: +[meson-log.txt](/uploads/6e32691488533a06c64dc34ee4514135/meson-log.txt) diff --git a/results/classifier/118/review/1675108 b/results/classifier/118/review/1675108 new file mode 100644 index 000000000..cc2387606 --- /dev/null +++ b/results/classifier/118/review/1675108 @@ -0,0 +1,415 @@ +mistranslation: 0.838 +register: 0.789 +semantic: 0.788 +graphic: 0.768 +permissions: 0.759 +PID: 0.755 +assembly: 0.753 +performance: 0.753 +device: 0.739 +user-level: 0.735 +virtual: 0.735 +TCG: 0.733 +architecture: 0.729 +arm: 0.725 +boot: 0.718 +risc-v: 0.712 +files: 0.699 +debug: 0.695 +vnc: 0.687 +KVM: 0.673 +VMM: 0.672 +hypervisor: 0.669 +socket: 0.660 +peripherals: 0.656 +i386: 0.633 +ppc: 0.628 +network: 0.611 +kernel: 0.586 +x86: 0.518 +-------------------- +i386: 0.987 +x86: 0.964 +debug: 0.058 +files: 0.053 +PID: 0.052 +boot: 0.048 +assembly: 0.034 +virtual: 0.032 +TCG: 0.026 +graphic: 0.023 +register: 0.013 +performance: 0.012 +semantic: 0.012 +hypervisor: 0.009 +user-level: 0.008 +VMM: 0.007 +permissions: 0.005 +kernel: 0.005 +device: 0.004 +architecture: 0.004 +KVM: 0.003 +socket: 0.003 +network: 0.003 +risc-v: 0.003 +ppc: 0.002 +vnc: 0.002 +peripherals: 0.002 +mistranslation: 0.001 +arm: 0.000 + +Cocoa UI always crashes on startup + +Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure graphic updates don't race with TCG vCPUs") causes the graphic update to run on a non-main thread, which Cocoa is not happy with. It crashes immediately after startup. + +$ i386-softmmu/qemu-system-i386 +2017-03-22 10:09:25.113 qemu-system-i386[15968:9538245] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!' +*** First throw call stack: +( + 0 CoreFoundation 0x00007fff91e72e7b __exceptionPreprocess + 171 + 1 libobjc.A.dylib 0x00007fffa6a5ccad objc_exception_throw + 48 + 2 AppKit 0x00007fff900953fd -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 4471 + 3 qemu-system-i386 0x0000000104f75a49 cocoa_refresh + 233 + 4 qemu-system-i386 0x0000000104e0312c process_queued_cpu_work + 140 + 5 qemu-system-i386 0x0000000104d1a73c qemu_tcg_rr_cpu_thread_fn + 284 + 6 libsystem_pthread.dylib 0x00007fffa7557aab _pthread_body + 180 + 7 libsystem_pthread.dylib 0x00007fffa75579f7 _pthread_body + 0 + 8 libsystem_pthread.dylib 0x00007fffa75571fd thread_start + 13 +) +libc++abi.dylib: terminating with uncaught exception of type NSException +Abort trap: 6 + +System: macOS 10.12.3, Xcode 8.2.1 + +On 22 March 2017 at 17:26, Brendan Shanks <email address hidden> wrote: +> Public bug reported: +> +> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure +> graphic updates don't race with TCG vCPUs") causes the graphic update to +> run on a non-main thread, which Cocoa is not happy with. It crashes +> immediately after startup. + +Oops. Alex, we can't just run UI code on random threads like this. +Any ideas? + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On 22 March 2017 at 17:26, Brendan Shanks <email address hidden> wrote: +>> Public bug reported: +>> +>> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure +>> graphic updates don't race with TCG vCPUs") causes the graphic update to +>> run on a non-main thread, which Cocoa is not happy with. It crashes +>> immediately after startup. +> +> Oops. Alex, we can't just run UI code on random threads like this. + +Technically its not a random thread its the vCPU context (which ensures +the vCPU isn't updating while the display is being updated). But I guess +the Cocoa is limited to not being able to update from an arbitrary +thread? + +There was a patch posted yesterday to ensure the BQL is held during the +deferred work but this doesn't look like that. + +> Any ideas? + +Hmm a quick Google seems to imply Cocoa is inflexible in its +requirements. You can try this ugly but untested patch (I don't have any +Macs handy): + +modified ui/console.c +@@ -1598,8 +1598,16 @@ static void dpy_refresh(DisplayState *s) + QLIST_FOREACH(dcl, &s->listeners, next) { + if (dcl->ops->dpy_refresh) { + if (tcg_enabled()) { ++#ifdef CONFIG_COCOA ++ qemu_mutex_unlock_iothread(); ++ start_exclusive(); ++ do_safe_dpy_refresh(first_cpu, RUN_ON_CPU_HOST_PTR(dcl)); ++ end_exclusive(); ++ qemu_mutex_lock_iothread(); ++#else + async_safe_run_on_cpu(first_cpu, do_safe_dpy_refresh, + RUN_ON_CPU_HOST_PTR(dcl)); ++#endif + } else { + dcl->ops->dpy_refresh(dcl); + } + + +Other than that I guess we need to bring forward the plans to "fixed the dirty tracking +races in display adapters" + +> +> thanks +> -- PMM + + +-- +Alex Bennée + + +On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +> Technically its not a random thread its the vCPU context (which ensures +> the vCPU isn't updating while the display is being updated). But I guess +> the Cocoa is limited to not being able to update from an arbitrary +> thread? + +Yes. It's very common for windowing libraries to mandate that you +do all windowing operations from one specific thread. + +thanks +-- PMM + + + +Peter Maydell <email address hidden> writes: + +> On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +>> Technically its not a random thread its the vCPU context (which ensures +>> the vCPU isn't updating while the display is being updated). But I guess +>> the Cocoa is limited to not being able to update from an arbitrary +>> thread? +> +> Yes. It's very common for windowing libraries to mandate that you +> do all windowing operations from one specific thread. + +Fair enough. Well let me know if that works OK on MacOS and I'll fold it +in to the other console patches. In fact I might as well do the +start/end_exclusive dance for all OSes and it will achieve the same thing. + +-- +Alex Bennée + + + +On Mar 23, 2017, at 7:35 AM, <email address hidden> wrote: + +> Message: 15 +> Date: Thu, 23 Mar 2017 11:13:02 +0000 +> From: Alex Benn?e <email address hidden> +> To: Peter Maydell <email address hidden> +> Cc: Bug 1675108 <email address hidden>, QEMU Developers +> <email address hidden>, Gerd Hoffmann <email address hidden> +> Subject: Re: [Qemu-devel] [Bug 1675108] [NEW] Cocoa UI always crashes +> on startup +> Message-ID: <email address hidden> +> Content-Type: text/plain; charset=utf-8 +> +> +> Peter Maydell <email address hidden> writes: +> +>> On 22 March 2017 at 17:26, Brendan Shanks <email address hidden> wrote: +>>> Public bug reported: +>>> +>>> Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure +>>> graphic updates don't race with TCG vCPUs") causes the graphic update to +>>> run on a non-main thread, which Cocoa is not happy with. It crashes +>>> immediately after startup. +>> +>> Oops. Alex, we can't just run UI code on random threads like this. +> +> Technically its not a random thread its the vCPU context (which ensures +> the vCPU isn't updating while the display is being updated). But I guess +> the Cocoa is limited to not being able to update from an arbitrary +> thread? +> +> There was a patch posted yesterday to ensure the BQL is held during the +> deferred work but this doesn't look like that. +> +>> Any ideas? +> +> Hmm a quick Google seems to imply Cocoa is inflexible in its +> requirements. You can try this ugly but untested patch (I don't have any +> Macs handy): +> +> modified ui/console.c +> @@ -1598,8 +1598,16 @@ static void dpy_refresh(DisplayState *s) +> QLIST_FOREACH(dcl, &s->listeners, next) { +> if (dcl->ops->dpy_refresh) { +> if (tcg_enabled()) { +> +#ifdef CONFIG_COCOA +> + qemu_mutex_unlock_iothread(); +> + start_exclusive(); +> + do_safe_dpy_refresh(first_cpu, RUN_ON_CPU_HOST_PTR(dcl)); +> + end_exclusive(); +> + qemu_mutex_lock_iothread(); +> +#else +> async_safe_run_on_cpu(first_cpu, do_safe_dpy_refresh, +> RUN_ON_CPU_HOST_PTR(dcl)); +> +#endif +> } else { +> dcl->ops->dpy_refresh(dcl); +> } +> +> +> Other than that I guess we need to bring forward the plans to "fixed the dirty tracking +> races in display adapters" +> +>> +>> thanks +>> -- PMM +> +> +> -- +> Alex Benn?e + +Your patch does work. I tested it on Mac OS 10.6.8 using qemu-sytem-ppc. + +Has anyone checked on the GTK front-end yet to see if it is having similar problems? + +Tested on 10.12.3, it doesn't crash immediately (like before) but crashes reliably once I send some keyboard input to qemu: + +$ i386-softmmu/qemu-system-i386 +** +ERROR:/Users/pip/no_backup/qemu/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Abort trap: 6 + + + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 libsystem_kernel.dylib 0x00007fffa746edd6 __pthread_kill + 10 +1 libsystem_pthread.dylib 0x00007fffa755a787 pthread_kill + 90 +2 libsystem_c.dylib 0x00007fffa73d4420 abort + 129 +3 libglib-2.0.0.dylib 0x00000001076aec86 g_assertion_message + 388 +4 libglib-2.0.0.dylib 0x00000001076aece4 g_assertion_message_expr + 94 +5 qemu-system-i386 0x00000001066bb1ec tcg_handle_interrupt + 156 (translate-common.c:50) +6 qemu-system-i386 0x0000000106740dfc pic_irq_request + 156 (pc.c:187) +7 qemu-system-i386 0x000000010673e5e4 gsi_handler + 36 (pc.c:115) +8 qemu-system-i386 0x000000010685e97a kbd_update_kbd_irq + 138 (pckbd.c:180) +9 qemu-system-i386 0x000000010694164a qemu_input_event_send_impl + 938 (input.c:328) +10 qemu-system-i386 0x000000010694188f qemu_input_event_send_key + 239 (input.c:359) +11 qemu-system-i386 0x0000000106946a00 cocoa_refresh + 272 (cocoa.m:1402) +12 qemu-system-i386 0x000000010693f6a8 gui_update + 104 (console.c:1603) + + +The keyboard input issue looks the same as #1675549, and that's on Linux/SDL. So not specific to this fix or Cocoa. + + +Brendan Shanks <email address hidden> writes: + +> Tested on 10.12.3, it doesn't crash immediately (like before) but +> crashes reliably once I send some keyboard input to qemu: +> +> $ i386-softmmu/qemu-system-i386 +> ** +> ERROR:/Users/pip/no_backup/qemu/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +> Abort trap: 6 + +Can you test with the suggested patch I posted yesterday? If we keep the +update under BQL this shouldn't fail. + +> +> +> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +> 0 libsystem_kernel.dylib 0x00007fffa746edd6 __pthread_kill + 10 +> 1 libsystem_pthread.dylib 0x00007fffa755a787 pthread_kill + 90 +> 2 libsystem_c.dylib 0x00007fffa73d4420 abort + 129 +> 3 libglib-2.0.0.dylib 0x00000001076aec86 g_assertion_message + 388 +> 4 libglib-2.0.0.dylib 0x00000001076aece4 g_assertion_message_expr + 94 +> 5 qemu-system-i386 0x00000001066bb1ec tcg_handle_interrupt + 156 (translate-common.c:50) +> 6 qemu-system-i386 0x0000000106740dfc pic_irq_request + 156 (pc.c:187) +> 7 qemu-system-i386 0x000000010673e5e4 gsi_handler + 36 (pc.c:115) +> 8 qemu-system-i386 0x000000010685e97a kbd_update_kbd_irq + 138 (pckbd.c:180) +> 9 qemu-system-i386 0x000000010694164a qemu_input_event_send_impl + 938 (input.c:328) +> 10 qemu-system-i386 0x000000010694188f qemu_input_event_send_key + 239 (input.c:359) +> 11 qemu-system-i386 0x0000000106946a00 cocoa_refresh + 272 (cocoa.m:1402) +> 12 qemu-system-i386 0x000000010693f6a8 gui_update + 104 (console.c:1603) + + +-- +Alex Bennée + + +On Do, 2017-03-23 at 11:31 +0000, Alex Bennée wrote: +> Peter Maydell <email address hidden> writes: +> +> > On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +> >> Technically its not a random thread its the vCPU context (which ensures +> >> the vCPU isn't updating while the display is being updated). But I guess +> >> the Cocoa is limited to not being able to update from an arbitrary +> >> thread? +> > +> > Yes. It's very common for windowing libraries to mandate that you +> > do all windowing operations from one specific thread. +> +> Fair enough. Well let me know if that works OK on MacOS and I'll fold it +> in to the other console patches. In fact I might as well do the +> start/end_exclusive dance for all OSes and it will achieve the same thing. + +Where do we stand with this one? + +cheers, + Gerd + + + + +Gerd Hoffmann <email address hidden> writes: + +> On Do, 2017-03-23 at 11:31 +0000, Alex Bennée wrote: +>> Peter Maydell <email address hidden> writes: +>> +>> > On 23 March 2017 at 11:13, Alex Bennée <email address hidden> wrote: +>> >> Technically its not a random thread its the vCPU context (which ensures +>> >> the vCPU isn't updating while the display is being updated). But I guess +>> >> the Cocoa is limited to not being able to update from an arbitrary +>> >> thread? +>> > +>> > Yes. It's very common for windowing libraries to mandate that you +>> > do all windowing operations from one specific thread. +>> +>> Fair enough. Well let me know if that works OK on MacOS and I'll fold it +>> in to the other console patches. In fact I might as well do the +>> start/end_exclusive dance for all OSes and it will achieve the same thing. +> +> Where do we stand with this one? + +I've got two patches in my tree at the moment. I was holding off posting +the series to see if I could make more progress with the record/replay +bug. I'll post the series tomorrow morning but if you want to grab them +ahead of that see: + + https://github.com/stsquad/qemu/commit/6c0ddfc5752f311b4c5a2956de25821cc2cd3fd6 + https://github.com/stsquad/qemu/commit/15d2b05a20879017f20370b71d5d144947b693fe + +-- +Alex Bennée + + +On 27 March 2017 at 16:18, Alex Bennée <email address hidden> wrote: +> I've got two patches in my tree at the moment. I was holding off posting +> the series to see if I could make more progress with the record/replay +> bug. + +rc candidates are cut on Tuesdays, so it's better in general not +to sit on a fix for rc bugs if it causes them to miss going into +the next rc tag. + +thanks +-- PMM + + +I just did a quick test on 10.12.3 with those two patches and didn't get any crashes + + +Brendan Shanks <email address hidden> writes: + +> I just did a quick test on 10.12.3 with those two patches and didn't get +> any crashes + +Awesome. I'm rolling the series now. I assume will pickup the patches in +due course. + +-- +Alex Bennée + + +Fixed in -rc2, closing. + diff --git a/results/classifier/118/review/1678466 b/results/classifier/118/review/1678466 new file mode 100644 index 000000000..0debbc9a2 --- /dev/null +++ b/results/classifier/118/review/1678466 @@ -0,0 +1,190 @@ +user-level: 0.830 +mistranslation: 0.804 +risc-v: 0.769 +ppc: 0.762 +x86: 0.762 +KVM: 0.758 +hypervisor: 0.752 +graphic: 0.749 +vnc: 0.748 +VMM: 0.747 +permissions: 0.745 +peripherals: 0.745 +TCG: 0.737 +register: 0.723 +performance: 0.703 +debug: 0.696 +virtual: 0.681 +semantic: 0.678 +i386: 0.664 +assembly: 0.659 +architecture: 0.652 +device: 0.645 +network: 0.643 +arm: 0.638 +files: 0.627 +socket: 0.601 +PID: 0.587 +boot: 0.550 +kernel: 0.549 +-------------------- +i386: 0.981 +x86: 0.840 +debug: 0.776 +KVM: 0.578 +hypervisor: 0.253 +virtual: 0.167 +TCG: 0.083 +register: 0.071 +kernel: 0.070 +PID: 0.068 +device: 0.056 +files: 0.037 +VMM: 0.028 +assembly: 0.028 +performance: 0.010 +ppc: 0.009 +user-level: 0.007 +architecture: 0.007 +semantic: 0.005 +boot: 0.004 +peripherals: 0.004 +graphic: 0.003 +risc-v: 0.002 +socket: 0.002 +permissions: 0.002 +network: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.001 + +using x-vga=on with vfio-pci leads to segfault + +bug occures at least with qemu 2.8.0 and 2.8.1 in 64bit-system + +stripped cmd for minimal config: +qemu-system-i386 -m 2048 -M q35 -enable-kvm -nodefaults -nodefconfig -device ioh3420,bus=pcie.0,addr=0x9,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=01.0,x-vga=on + +Backtrace is: +#0 0x00005555557ca836 in memory_region_update_container_subregions (subregion=0x55555828f2f0) at qemu-2.8.1/memory.c:2030 +#1 0x00005555557ca9dc in memory_region_add_subregion_common (mr=0x0, offset=8, subregion=0x55555828f2f0) at qemu-2.8.1/memory.c:2049 +#2 0x00005555557caa9a in memory_region_add_subregion_overlap (mr=0x0, offset=8, subregion=0x55555828f2f0, priority=1) at qemu-2.8.1/memory.c:2066 +#3 0x0000555555832e48 in vfio_probe_nvidia_bar5_quirk (vdev=0x55555805aef0, nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:689 +#4 0x0000555555835433 in vfio_bar_quirk_setup (vdev=0x55555805aef0, nr=5) at qemu-2.8.1/hw/vfio/pci-quirks.c:1652 +#5 0x000055555582f122 in vfio_realize (pdev=0x55555805aef0, errp=0x7fffffffdc78) at qemu-2.8.1/hw/vfio/pci.c:2777 +#6 0x0000555555a86195 in pci_qdev_realize (qdev=0x55555805aef0, errp=0x7fffffffdcf0) at hw/pci/pci.c:1966 +#7 0x00005555559be7b7 in device_set_realized (obj=0x55555805aef0, value=true, errp=0x7fffffffdeb0) at hw/core/qdev.c:918 +#8 0x0000555555bb017f in property_set_bool (obj=0x55555805aef0, v=0x55555805ced0, name=0x555556071b56 "realized", opaque=0x555557f15860, errp=0x7fffffffdeb0) at qom/object.c:1854 +#9 0x0000555555bae2e6 in object_property_set (obj=0x55555805aef0, v=0x55555805ced0, name=0x555556071b56 "realized", errp=0x7fffffffdeb0) at qom/object.c:1088 +#10 0x0000555555bb184f in object_property_set_qobject (obj=0x55555805aef0, value=0x55555805cd70, name=0x555556071b56 "realized", errp=0x7fffffffdeb0) at qom/qom-qobject.c:27 +#11 0x0000555555bae637 in object_property_set_bool (obj=0x55555805aef0, value=true, name=0x555556071b56 "realized", errp=0x7fffffffdeb0) at qom/object.c:1157 +#12 0x00005555558fee4b in qdev_device_add (opts=0x555556b15160, errp=0x7fffffffdf28) at qdev-monitor.c:623 +#13 0x00005555559142c1 in device_init_func (opaque=0x0, opts=0x555556b15160, errp=0x0) at vl.c:2373 +#14 0x0000555555cc3bb7 in qemu_opts_foreach (list=0x555556548b80 <qemu_device_opts>, func=0x555555914283 <device_init_func>, opaque=0x0, errp=0x0) at util/qemu-option.c:1116 +#15 0x00005555559198aa in main (argc=12, argv=0x7fffffffe388, envp=0x7fffffffe3f0) at vl.c:4574 + +as I can see, it happens during initialization of the device-option. + +seems that the code tries to loop over a memory-region mr, which is null from at least three calls before it crashes. + +because there seems to be special handling for nvidia-cards, here're the pci-infos of the card: +01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 7300 GS] [10de:01df] (rev a1) (prog-if 00 [VGA controller]) + Subsystem: Gigabyte Technology Co., Ltd Device [1458:342a] + Flags: fast devsel, IRQ 16 + Memory at de000000 (32-bit, non-prefetchable) [disabled] [size=16M] + Memory at c0000000 (64-bit, prefetchable) [disabled] [size=256M] + Memory at dd000000 (64-bit, non-prefetchable) [disabled] [size=16M] + Expansion ROM at df000000 [disabled] [size=128K] + Capabilities: [60] Power Management version 2 + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [78] Express Endpoint, MSI 00 + Capabilities: [100] Virtual Channel + Capabilities: [128] Power Budgeting <?> + Kernel driver in use: vfio-pci + +at least with a similar card in another slot the crash does not occure. +(sorry, can't change the slots at the moment) + +It's highly likely that a 7-series GeForce has a different BAR layout than a modern card and should be considered unsupported. Is the "similar card in another slot" also a 7-series or older card? Out of curiosity, add another -v to the lspci output (lspci -vv) so that it identifies which BARs are which. A more modern card looks like this: + + Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M] + Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M] + Region 3: Memory at f0000000 (64-bit, prefetchable) [size=32M] + Region 5: I/O ports at e000 [size=128] + Expansion ROM at f7000000 [disabled] [size=512K] + +Thus the quirk should be triggered on the I/O port BAR, which your card doesn't seem to have. + +well but even if it's unsupported it shouldn't segfault... + +the other card is nearly the same +this one is a GeForce 7300 GS, the other a GeForce 7300 GT + +I think, the above output was done with "lspci -vv", but I've do it again: +lspci -vv for the "bad card" is: + +01:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300 GS] (rev a1) (prog-if 00 [VGA controller]) + Subsystem: Gigabyte Technology Co., Ltd Device 342a + Flags: fast devsel, IRQ 16 + Memory at de000000 (32-bit, non-prefetchable) [disabled] [size=16M] + Memory at c0000000 (64-bit, prefetchable) [disabled] [size=256M] + Memory at dd000000 (64-bit, non-prefetchable) [disabled] [size=16M] + Expansion ROM at df000000 [disabled] [size=128K] + Capabilities: [60] Power Management version 2 + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [78] Express Endpoint, MSI 00 + Capabilities: [100] Virtual Channel + Capabilities: [128] Power Budgeting <?> + Kernel driver in use: vfio-pci + + +and for the "good" card: +07:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7300 GT] (rev a1) (prog-if 00 [VGA controller]) + Subsystem: CardExpert Technology Device 1401 + Flags: fast devsel, IRQ 16 + Memory at db000000 (32-bit, non-prefetchable) [disabled] [size=16M] + Memory at b0000000 (64-bit, prefetchable) [disabled] [size=256M] + Memory at da000000 (64-bit, non-prefetchable) [disabled] [size=16M] + I/O ports at e000 [disabled] [size=128] + Expansion ROM at dc000000 [disabled] [size=128K] + Capabilities: [60] Power Management version 2 + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Capabilities: [78] Express Endpoint, MSI 00 + Capabilities: [100] Virtual Channel + Capabilities: [128] Power Budgeting <?> + Kernel driver in use: vfio-pci + +your're right that the I/O-Port is not shown for the "bad" card, even I don't know why. Maybe because the card's bios-routine saw the other or vice versa. + +nevertheless, segfaults are not nice... + + + +Does this resolve the segfault? + +diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c +index e9b493b939db..349085ea12bc 100644 +--- a/hw/vfio/pci-quirks.c ++++ b/hw/vfio/pci-quirks.c +@@ -660,7 +660,7 @@ static void vfio_probe_nvidia_bar5_quirk(VFIOPCIDevice *vdev + VFIOConfigWindowQuirk *window; + + if (!vfio_pci_is(vdev, PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID) || +- !vdev->vga || nr != 5) { ++ !vdev->vga || nr != 5 || !vdev->bars[5].ioport) { + return; + } + + + +after applying the patch no segfault occures any more. + +thanks for quick fix. + + +regarding my assumption the missing I/O may depend on bios/slot or similar: it doesn't. the card does not show the entry in either slot or even as only extra-card. + + + +This is now fixed in QEMU 2.9-rc + diff --git a/results/classifier/118/review/1680679 b/results/classifier/118/review/1680679 new file mode 100644 index 000000000..88d370660 --- /dev/null +++ b/results/classifier/118/review/1680679 @@ -0,0 +1,262 @@ +user-level: 0.938 +register: 0.892 +permissions: 0.888 +mistranslation: 0.884 +boot: 0.865 +risc-v: 0.864 +assembly: 0.862 +debug: 0.856 +socket: 0.855 +semantic: 0.850 +architecture: 0.849 +device: 0.847 +PID: 0.835 +files: 0.835 +arm: 0.830 +performance: 0.829 +TCG: 0.821 +virtual: 0.819 +graphic: 0.818 +kernel: 0.808 +network: 0.802 +x86: 0.795 +peripherals: 0.785 +VMM: 0.783 +KVM: 0.772 +vnc: 0.746 +ppc: 0.735 +i386: 0.723 +hypervisor: 0.708 +-------------------- +kernel: 0.523 +virtual: 0.335 +x86: 0.283 +debug: 0.249 +peripherals: 0.067 +device: 0.057 +semantic: 0.054 +user-level: 0.053 +boot: 0.052 +TCG: 0.022 +register: 0.022 +files: 0.017 +socket: 0.014 +hypervisor: 0.013 +graphic: 0.013 +PID: 0.012 +performance: 0.009 +architecture: 0.006 +assembly: 0.002 +VMM: 0.002 +KVM: 0.002 +permissions: 0.002 +network: 0.001 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.000 +vnc: 0.000 +i386: 0.000 +arm: 0.000 + +qemu cannot run twice + +After using qemu with gpu passthrough and then shutting down windows 7 properly I cannot boot windows 7 a second time. +Only a full reboot of linux fixes this issue. +Qemu appears to corrupt something in linux when exiting. +I get no error messages but windows 7 never finishes booting during the 2nd try. +Apparently I do try to run vfiobind each time the script is run. +Wondering if rerunning vfiobind can cause an issue? + + +My specs: +----------------------------------------------------------------------------------------- +System: Host: GT70-2PE Kernel: 4.5.4-040504-generic x86_64 (64 bit gcc: 5.3.1) + Desktop: Cinnamon 3.2.7 (Gtk 3.18.9) Distro: Linux Mint 18.1 Serena +Machine: Mobo: Micro-Star model: MS-1763 v: REV:0.C Bios: American Megatrends v: E1763IMS.51B date: 01/29/2015 +CPU: Quad core Intel Core i7-4810MQ (-HT-MCP-) cache: 6144 KB + flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 22347 + clock speeds: max: 2801 MHz 1: 2801 MHz 2: 2801 MHz 3: 2801 MHz 4: 2801 MHz 5: 2801 MHz 6: 2801 MHz + 7: 2801 MHz 8: 2801 MHz +Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0 + Card-2: NVIDIA GK104M [GeForce GTX 880M] bus-ID: 01:00.0 + Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) + Resolution: 1920x1080@60.02hz, 1920x1080@60.00hz + GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 12.0.6 Direct Rendering: Yes + + +My script: +------------------------------------------------------------------------------------------- +#!/bin/bash + +cd ~/qemu +sudo ./up.sh tap0 + +configfile=~/qemu/vfio-pci1.cfg + +vfiobind() { + dev="$1" + vendor=$(cat /sys/bus/pci/devices/$dev/vendor) + device=$(cat /sys/bus/pci/devices/$dev/device) + if [ -e /sys/bus/pci/devices/$dev/driver ]; then + echo $dev > /sys/bus/pci/devices/$dev/driver/unbind + fi + echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id + +} + +modprobe vfio-pci + +cat $configfile | while read line;do + echo $line | grep ^# >/dev/null 2>&1 && continue + vfiobind $line +done + +sudo qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host,kvm=off \ +-smp 8,sockets=1,cores=4,threads=2 \ +-bios /usr/share/seabios/bios.bin \ +-serial none \ +-parallel none \ +-vga none \ +-m 4G \ +-mem-path /run/hugepages/kvm \ +-mem-prealloc \ +-balloon none \ +-rtc clock=host,base=localtime \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=/home/dad/qemu/windows7.img \ +-drive file=/home/dad/1TB-Backup/Iso/SP1ForWin7.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ +-net nic -net tap,ifname=tap0,script=no,downscript=no \ +-usbdevice host:413c:a503 \ +-usbdevice host:13fe:3100 \ +-usbdevice host:0bc2:ab21 \ +-boot menu=on \ +-boot order=c + +sudo ./down.sh tap0 + +exit 0 + +If you get one boot where GPU assignment works with a mobile GeForce, you're doing better than most. + +I have been told that getting this to work with a laptop is rare. +I own an MSI GT70-2PE. + + +NOTE: I only get gpu passthrough to work when using seabios. UEFI will not work with modern nvidia drivers. You get the 'code 43' error because whatever standards nvidia expects when talking to uefi are not met by the OVMF firmware used by qemu. This issue happens to windows users also. They had to update their uefi firmware to get around the code 43 issue. + +NOTE: Article showing windows users updating their motherboard uefi firmware to get around code 43: +https://devtalk.nvidia.com/default/topic/861244/cuda-setup-and-installation/geforce-740m-asus-x550l-code-43-after-windows-10-update/3 + +Comments #3 & #4 are not relevant to this bug and inaccurate speculation. There is no known incompatibility between NVIDIA drivers and OVMF. Many users, including myself, use this combination daily. The issue is far more likely to be a VM configuration issue or lack of UEFI support in the GPU ROM. + +Perhaps you get Code 43 because mobile NVIDIA chips make use of Optimus which requires significant proprietary firmware support. QEMU/VFIO has never claimed to work with such devices. The further speculation in the original report that QEMU corrupted something in Linux seems unjustified, the device simply doesn't work a second time. This might be lack of proper reset support in the GPU itself or poor interaction with aforementioned proprietary firmware. + +GTX880M - uefi firmware built in, confirmed + +My uefi build script. If you see an error or issue that could cause error 43 please confirm it: + +#!/bin/bash + +cd /home/dad/qemu/qemu2 +sudo ./up.sh tap0 + +configfile=./vfio-pci1.cfg + +vfiobind() { + dev="$1" + vendor=$(cat /sys/bus/pci/devices/$dev/vendor) + device=$(cat /sys/bus/pci/devices/$dev/device) + if [ -e /sys/bus/pci/devices/$dev/driver ]; then + echo $dev > /sys/bus/pci/devices/$dev/driver/unbind + fi + echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id + +} + +modprobe vfio-pci + +cat $configfile | while read line;do + echo $line | grep ^# >/dev/null 2>&1 && continue + vfiobind $line +done + +vmname="windows10vm" + +if ps -A | grep -q $vmname; then + echo "$vmname is already running." & + exit 1 + +else + +# use pulseaudio +export QEMU_AUDIO_DRV=pa + +cp /usr/share/OVMF/OVMF_VARS.fd /tmp/my_vars.fd + +qemu-system-x86_64 \ + -name $vmname,process=$vmname \ + -machine type=pc-i440fx-2.6,accel=kvm \ + -cpu host,kvm=off \ + -smp 8,sockets=1,cores=4,threads=2 \ + -enable-kvm \ + -m 4G \ + -mem-path /run/hugepages/kvm \ + -mem-prealloc \ + -balloon none \ + -rtc clock=host,base=localtime \ + -serial none \ + -parallel none \ + -vga none \ + -device vfio-pci,host=01:00.0,multifunction=on \ + -device vfio-pci,host=01:00.1 \ + -drive if=pflash,format=raw,readonly,file=/home/dad/qemu/qemu2/OVMF-pure-efi.fd \ + -drive if=pflash,format=raw,file=/tmp/my_vars.fd \ + -boot order=dc -boot menu=on \ + -device virtio-scsi-pci,id=scsi \ + -drive id=disk0,if=virtio,cache=none,format=raw,file=/home/dad/qemu/qemu2/win7.img \ + -drive file=/home/dad/qemu/qemu2/virtio-win-0.1.126.iso,id=virtiocd,format=raw,if=none -device ide-cd,bus=ide.1,drive=virtiocd \ + -netdev type=tap,id=net0,ifname=tap0,vhost=on,script=no,downscript=no \ + -device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 \ + -usb -usbdevice host:413c:a503 -usbdevice host:13fe:3100 + +sudo ./down.sh tap0 + exit 0 +fi + + + +ok, so I will research qemu and nvidia optimus. I have a custom BIOS made by an MSI employee. I have hundreds of bios options to play with. + + +I suspect the 'M' in GTX880M is the biggest contributor to the Code 43. The fact you can get it to work once per host boot on SeaBIOS is a fluke. If you can get custom ROMs, you might try playing with the vfio-pci x-pci-device-id option to masquerade as a discrete card, maybe that would avoid mobile code in the NVIDIA driver that would expect Optimus. Obviously do so at your own risk. + +It works using seabios. I assume that the nvidia driver cannot see optimus, and expect an intel card also, unless I use OVMF. I do know that you cannot run off the intel card in windows. It's a no-no. Thanks for the bios tip. Maybe I can hide the optimus feature from OVMF and windows. + + +I meant to say you cannot run without the intel card in windows if you have optimus. I am glad seabios somehow hides optimus. + +Does your Subsystem ID and Subsystem Vendor ID (of your GPU) show correctly inside the WindowsVM? + +It should be the same ID shown in your host. Otherwise that will trigger the Code 43 error. + +I once have this problem but now solve this by some vfio-pci option. Now I have a laptop that passthrough my dGPU with OVMF working perfectly. + +Thanks. +I will look into this. + + +On 11/15/2017 10:56 AM, misairu wrote: +> Does your Subsystem ID and Subsystem Vendor ID (of your GPU) show +> correctly inside the WindowsVM? +> +> It should be the same ID shown in your host. Otherwise that will trigger +> the Code 43 error. +> +> I once have this problem but now solve this by some vfio-pci option. Now +> I have a laptop that passthrough my dGPU with OVMF working perfectly. +> + + + diff --git a/results/classifier/118/review/1680991 b/results/classifier/118/review/1680991 new file mode 100644 index 000000000..6e9d522df --- /dev/null +++ b/results/classifier/118/review/1680991 @@ -0,0 +1,222 @@ +user-level: 0.919 +debug: 0.915 +permissions: 0.908 +peripherals: 0.907 +device: 0.896 +mistranslation: 0.890 +graphic: 0.887 +ppc: 0.886 +assembly: 0.878 +VMM: 0.866 +register: 0.856 +TCG: 0.851 +arm: 0.849 +virtual: 0.848 +performance: 0.848 +PID: 0.844 +semantic: 0.834 +risc-v: 0.829 +hypervisor: 0.824 +x86: 0.816 +kernel: 0.808 +architecture: 0.805 +socket: 0.795 +vnc: 0.783 +files: 0.766 +network: 0.762 +boot: 0.752 +KVM: 0.748 +i386: 0.634 +-------------------- +kernel: 0.994 +arm: 0.987 +assembly: 0.738 +register: 0.478 +debug: 0.381 +virtual: 0.215 +device: 0.164 +peripherals: 0.110 +semantic: 0.072 +TCG: 0.043 +architecture: 0.025 +hypervisor: 0.022 +files: 0.021 +performance: 0.011 +VMM: 0.007 +boot: 0.004 +PID: 0.004 +x86: 0.004 +user-level: 0.003 +socket: 0.002 +network: 0.002 +i386: 0.002 +KVM: 0.002 +graphic: 0.002 +permissions: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +vnc: 0.001 +ppc: 0.000 + +raspi2: system timer device not implemented + +In a small hobby kernel for Raspberry Pi 2B, I am using the system timer to control wait durations. This timer is located at 0x3f003000 and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008 (CHI). Reading these memory locations returns 0 for both. + +The basic code for this function is: +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +@@ uint64_t ReadSysTimerCount() -- read the system time running count +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +ReadSysTimerCount: + ldr r0,=ST_CLO @ load the base address of the system timer + ldrd r0,r1,[r0] @ Get the 64-bit timer "count" into r1:r0 + mov pc,lr @ return + +Tracing back the definition of ST_CLO in my code: +#define ST_CLO (ST_BASE+4) // Counter Lower 32 bits +#define ST_BASE (HW_BASE+0x3000) // System Timer base address +#define HW_BASE (0x3f000000) // this is the base address for all hardware I/O addresses + +I have tested a similar program that I know to work on real hardware with qemu-system-arm reading the same mmio register and have the same issue, so I'm pretty sure the issue is not with my code. + +My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): +[adam@os-dev ~]$ uname -a +Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3 (git). + +adam@os-dev ~]$ qemu-system-arm --version +QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +[adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version +QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +A remote debugger for my kernel shows the following: +(gdb) info reg +r0 0x0 0 +r1 0x0 0 +r2 0x96 150 +r3 0x0 0 +r4 0xa000 40960 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0xa000 40960 +r10 0x0 0 +r11 0x7fdc 32732 +r12 0x0 0 +sp 0x7fc8 0x7fc8 +lr 0x8194 33172 +pc 0x80a4 0x80a4 +cpsr 0x800001d3 -2147483181 +(gdb) stepi +0x000080a8 in ?? () +(gdb) info reg +r0 0x3f003004 1056976900 +r1 0x0 0 +r2 0x96 150 +r3 0x0 0 +r4 0xa000 40960 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0xa000 40960 +r10 0x0 0 +r11 0x7fdc 32732 +r12 0x0 0 +sp 0x7fc8 0x7fc8 +lr 0x8194 33172 +pc 0x80a8 0x80a8 +cpsr 0x800001d3 -2147483181 +(gdb) stepi +0x000080ac in ?? () +(gdb) info reg +r0 0x0 0 +r1 0x0 0 +r2 0x96 150 +r3 0x0 0 +r4 0xa000 40960 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0xa000 40960 +r10 0x0 0 +r11 0x7fdc 32732 +r12 0x0 0 +sp 0x7fc8 0x7fc8 +lr 0x8194 33172 +pc 0x80ac 0x80ac +cpsr 0x800001d3 -2147483181 + +Notice r0 is loaded with the address for CLO and then cleared with 0 when read. + +I am writing my code against the documented specifications in "BCM2835 ARM Peripherals" (attached for convenience), section "12 System Timer". + + +Please let me know if you need anything else from me. + + + +The command lines are: + +[adam@os-dev ~]$ qemu-system-aarch64 -m 256 -M raspi2 -serial stdio -kernel bin/rpi2b/kernel.elf + +[adam@os-dev workspace]$ ./qemu/bin/debug/native/arm-softmmu/qemu-system-arm -m 256 -M raspi2 -serial stdio -kernel century/bin/rpi2b/kernel.elf + + +A sample kernel is also attached for your convenience. + +The raspi2 board model is only partial, and is missing various devices that weren't used by the test images that it was tested with (mostly Windows-for-Arm, I think). The "system timer" is one of the devices that hasn't been implemented, which is why the memory locations where it should be just read-as-zero. + + +Is anybody still working on the raspi2 model? If not, shall we close this as WontFix? + +The timer has been implemented, see commits: +d05be883fc9 ("hw/timer/bcm2835: Add the BCM2835 SYS_timer") +0e5bbd74064 ("hw/arm/bcm2835_peripherals: Use the SYS_timer") +722bde6789c ("hw/arm/bcm2835_peripherals: Correctly wire the SYS_timer IRQs") + +Running the attached test with "-trace bcm2835_systmr_read" produces: +1634226@1605697958.837194:bcm2835_systmr_read timer read: offset 0x4 data 0x7cfc +1634226@1605697958.837229:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837313:bcm2835_systmr_read timer read: offset 0x4 data 0x7d73 +1634226@1605697958.837323:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837439:bcm2835_systmr_read timer read: offset 0x4 data 0x7df1 +1634226@1605697958.837454:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837553:bcm2835_systmr_read timer read: offset 0x4 data 0x7e64 +1634226@1605697958.837561:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837568:bcm2835_systmr_read timer read: offset 0x4 data 0x7e73 +1634226@1605697958.837574:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837578:bcm2835_systmr_read timer read: offset 0x4 data 0x7e7d +1634226@1605697958.837582:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837586:bcm2835_systmr_read timer read: offset 0x4 data 0x7e85 +1634226@1605697958.837590:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837594:bcm2835_systmr_read timer read: offset 0x4 data 0x7e8d +1634226@1605697958.837598:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837602:bcm2835_systmr_read timer read: offset 0x4 data 0x7e95 +1634226@1605697958.837606:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837611:bcm2835_systmr_read timer read: offset 0x4 data 0x7e9e +1634226@1605697958.837616:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837621:bcm2835_systmr_read timer read: offset 0x4 data 0x7ea7 +1634226@1605697958.837625:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837629:bcm2835_systmr_read timer read: offset 0x4 data 0x7eaf +1634226@1605697958.837634:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837640:bcm2835_systmr_read timer read: offset 0x4 data 0x7ebb +1634226@1605697958.837646:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837653:bcm2835_systmr_read timer read: offset 0x4 data 0x7ec8 +1634226@1605697958.837666:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837673:bcm2835_systmr_read timer read: offset 0x4 data 0x7edc +1634226@1605697958.837679:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837685:bcm2835_systmr_read timer read: offset 0x4 data 0x7ee7 +1634226@1605697958.837690:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837696:bcm2835_systmr_read timer read: offset 0x4 data 0x7ef2 +1634226@1605697958.837707:bcm2835_systmr_read timer read: offset 0x8 data 0x0 +1634226@1605697958.837713:bcm2835_systmr_read timer read: offset 0x4 data 0x7f03 +1634226@1605697958.837717:bcm2835_systmr_read timer read: offset 0x8 data 0x0 + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/review/1685 b/results/classifier/118/review/1685 new file mode 100644 index 000000000..504e9d2d5 --- /dev/null +++ b/results/classifier/118/review/1685 @@ -0,0 +1,119 @@ +register: 0.892 +permissions: 0.872 +device: 0.856 +graphic: 0.836 +architecture: 0.831 +debug: 0.820 +performance: 0.814 +semantic: 0.788 +arm: 0.787 +PID: 0.785 +hypervisor: 0.781 +virtual: 0.766 +KVM: 0.754 +assembly: 0.752 +TCG: 0.750 +VMM: 0.729 +kernel: 0.725 +x86: 0.711 +files: 0.708 +user-level: 0.703 +boot: 0.702 +vnc: 0.701 +peripherals: 0.696 +socket: 0.680 +ppc: 0.678 +network: 0.613 +risc-v: 0.601 +i386: 0.580 +mistranslation: 0.493 +-------------------- +x86: 0.974 +virtual: 0.967 +debug: 0.941 +hypervisor: 0.550 +i386: 0.550 +user-level: 0.413 +PID: 0.107 +files: 0.092 +TCG: 0.088 +semantic: 0.078 +kernel: 0.061 +assembly: 0.053 +performance: 0.047 +register: 0.043 +device: 0.018 +peripherals: 0.011 +architecture: 0.010 +graphic: 0.009 +VMM: 0.009 +ppc: 0.006 +network: 0.006 +socket: 0.005 +KVM: 0.003 +boot: 0.003 +permissions: 0.002 +arm: 0.002 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +QEMU segfaults when I restart Windows 11 VM with virtio-vga-gl +Description of problem: +When I restart the Windows 11 VM with the virtio GPU DoD driver installed, QEMU crashes with a SIGSEGV. This also happens if I try to uninstall this driver in the Device Manager. I attached the backtrace. +Steps to reproduce: +1. Install Windows 11 into the VM; +2. Install virtio GPU DoD driver; +3. Click Start -> Power -> Restart. +Additional information: +virtio-win version: 0.1.229 + +Backtrace: +``` +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff64a3e80 (LWP 118206)] +_mesa_TexParameteri () at ../mesa-23.1.1/src/mesa/main/texparam.c:1248 +1248 texObj = _mesa_get_texobj_by_target_and_texunit(ctx, target, +(gdb) bt +#0 _mesa_TexParameteri() () at ../mesa-23.1.1/src/mesa/main/texparam.c:1248 +#1 0x00007ffece03cba2 in _mesa_unmarshal_TexParameteri () at src/mapi/glapi/gen/marshal_generated0.c:5332 +#2 0x00007ffecdf1bb30 in glthread_unmarshal_batch() () at ../mesa-23.1.1/src/mesa/main/glthread.c:122 +#3 0x00007ffecdf269c2 in _mesa_glthread_finish () at ../mesa-23.1.1/src/mesa/main/glthread.c:382 +#4 _mesa_glthread_finish() () at ../mesa-23.1.1/src/mesa/main/glthread.c:347 +#5 0x00007ffecdebd20f in dri_make_current () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_context.c:303 +#6 dri_make_current () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_context.c:287 +#7 driBindContext() () at ../mesa-23.1.1/src/gallium/frontends/dri/dri_util.c:701 +#8 0x00007ffee6e8693f in dri3_bind_context () at ../mesa-23.1.1/src/glx/dri3_glx.c:181 +#9 0x00007ffee6e78075 in MakeContextCurrent () at ../mesa-23.1.1/src/glx/glxcurrent.c:149 +#10 0x00007ffee7c84e73 in InternalMakeCurrentVendor + (dpy=dpy@entry=0x5555570fe3b0, draw=draw@entry=90177544, read=read@entry=90177544, ctxInfo=ctxInfo@entry=0x5555579418b0, callerOpcode=callerOpcode@entry=5 '\005', threadState=threadState@entry=0x55555702fbe0, vendor=0x55555707f520) at ../libglvnd-v1.6.0/src/GLX/libglx.c:871 +#11 0x00007ffee7c8bce1 in CommonMakeCurrent (dpy=0x5555570fe3b0, draw=90177544, read=90177544, context=0x55555780f760, callerOpcode=<optimized out>) + at ../libglvnd-v1.6.0/src/GLX/libglx.c:1053 +#12 0x00007ffff51f90b1 in X11_GL_MakeCurrent (_this=0x5555570c1aa0, window=<optimized out>, context=0x55555780f760) + at /usr/src/debug/sdl2/SDL2-2.26.5/src/video/x11/SDL_x11opengl.c:865 +#13 0x00007ffff51d0a3f in SDL_GL_MakeCurrent_REAL (window=0x5555570048b0, ctx=0x55555780f760) at /usr/src/debug/sdl2/SDL2-2.26.5/src/video/SDL_video.c:4120 +#14 0x00007ffff6492b86 in sdl2_gl_switch () at ../qemu-8.0.2/ui/sdl2-gl.c:83 +#15 0x000055555598efe2 in displaychangelistener_gfx_switch () at ../qemu-8.0.2/ui/console.c:1158 +#16 0x00005555559997aa in dpy_gfx_replace_surface () at ../qemu-8.0.2/ui/console.c:1815 +#17 0x0000555555d03398 in vga_draw_graphic () at ../qemu-8.0.2/hw/display/vga.c:1589 +#18 vga_update_display () at ../qemu-8.0.2/hw/display/vga.c:1789 +#19 vga_update_display () at ../qemu-8.0.2/hw/display/vga.c:1762 +#20 0x0000555555998acb in graphic_hw_update () at ../qemu-8.0.2/ui/console.c:234 +#21 0x00007ffff6493952 in sdl2_gl_refresh () at ../qemu-8.0.2/ui/sdl2-gl.c:113 +#22 0x000055555599d79a in dpy_refresh () at ../qemu-8.0.2/ui/console.c:1852 +#23 gui_update () at ../qemu-8.0.2/ui/console.c:169 +#24 0x0000555555fd9690 in timerlist_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:576 +#25 0x0000555555fd97b4 in timerlist_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:509 +#26 qemu_clock_run_timers () at ../qemu-8.0.2/util/qemu-timer.c:590 +#27 qemu_clock_run_all_timers () at ../qemu-8.0.2/util/qemu-timer.c:672 +#28 0x0000555555fd9a53 in main_loop_wait () at ../qemu-8.0.2/util/main-loop.c:603 +#29 0x0000555555e1ab17 in qemu_main_loop () at ../qemu-8.0.2/softmmu/runstate.c:731 +--Type <RET> for more, q to quit, c to continue without paging--c +#30 qemu_default_main () at ../qemu-8.0.2/softmmu/main.c:37 +#31 0x00007ffff6c15850 in __libc_start_call_main (main=main@entry=0x55555598baa0 <main>, argc=argc@entry=33, argv=argv@entry=0x7fffffffd338) + at ../sysdeps/nptl/libc_start_call_main.h:58 +#32 0x00007ffff6c1590a in __libc_start_main_impl + (main=0x55555598baa0 <main>, argc=33, argv=0x7fffffffd338, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd328) + at ../csu/libc-start.c:360 +#33 0x000055555598e6f5 in _start () +``` diff --git a/results/classifier/118/review/1685242 b/results/classifier/118/review/1685242 new file mode 100644 index 000000000..f9c79b9c3 --- /dev/null +++ b/results/classifier/118/review/1685242 @@ -0,0 +1,214 @@ +semantic: 0.810 +graphic: 0.789 +user-level: 0.734 +debug: 0.688 +PID: 0.612 +virtual: 0.595 +permissions: 0.595 +register: 0.582 +kernel: 0.581 +architecture: 0.581 +network: 0.569 +x86: 0.565 +assembly: 0.561 +VMM: 0.561 +hypervisor: 0.559 +arm: 0.554 +files: 0.544 +device: 0.536 +boot: 0.523 +performance: 0.512 +ppc: 0.493 +risc-v: 0.463 +TCG: 0.463 +mistranslation: 0.454 +peripherals: 0.452 +socket: 0.413 +KVM: 0.406 +vnc: 0.377 +i386: 0.182 +-------------------- +x86: 0.996 +virtual: 0.913 +hypervisor: 0.798 +TCG: 0.236 +debug: 0.134 +boot: 0.084 +device: 0.049 +kernel: 0.039 +files: 0.019 +semantic: 0.018 +PID: 0.017 +register: 0.011 +network: 0.010 +VMM: 0.010 +KVM: 0.007 +performance: 0.007 +socket: 0.006 +graphic: 0.005 +user-level: 0.005 +peripherals: 0.004 +assembly: 0.004 +architecture: 0.004 +risc-v: 0.003 +ppc: 0.002 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +ovmf hangs at efi with virtio-net memory hotplug + +with qemu 2.9 it hangs at the efi stage when memory-hotplug is enabled and it has a virtio-net devices + +the ovmf images where compiled from https://github.com/tianocore/edk2 (current master) + +reproducer: + +qemu-system-x86_64 -drive 'if=pflash,unit=0,format=raw,readonly,file=./OVMF_CODE.fd' -drive 'if=pflash,unit=1,format=raw,file=./my_OVMF_VARS.fd' -smp 1 -vga std -netdev 'type=tap,id=mynet' -device 'virtio-net-pci,netdev=mynet' -display sdl -nodefaults -m 'size=1G,slots=256,maxmem=1024G' + +interestingly, it works when you do the following: + +- omit the virtio-net-pci device +- use seabios +- use less maxmem, e.g. 512G + +qemu was compiled from source (v2.9.0) with following options: + +./configure --target-list=x86_64-softmmu --disable-xen --enable-gnutls --enable-sdl --enable-linux-aio --enable-rbd --enable-libiscsi --disable-smartcard --audio-drv-list="alsa" --enable +-spice --enable-usb-redir --enable-glusterfs --enable-libusb --disable-gtk --enable-xfsctl --enable-numa --disable-strip --enable-jemalloc --enable-virtfs --disable-libnfs --disable-fdt --disable-guest-agent --disable-guest-agent-msi + +i forgot: + +it also works with + +-machine pc-i440fx-2.6 + +Tested here with versions of pc-i440fx-XX and it didn't work here on qemu-server 5.0-46, qemu 2.12.1-1 + +Didn't work. + +OVMF places the 64-bit PCI MMIO aperture after the memory hotplug area. If you specify `-m maxmem=1024G`, then accessing 64-bit MMIO BARs of PCI(e) devices, allocated from the aperture, will require at least 41 address bits. If you use KVM, and nested paging (EPT on Intel, NPT on AMD) is enabled, and your /proc/cpuinfo on the host reports a smaller phys address width than 41, then 64-bit PCI MMIO accesses in the guest will silently fail. You can read more details in <https://bugzilla.redhat.com/show_bug.cgi?id=1353591#c8>. + +SeaBIOS uses an independent algorithm for aperture placement and BAR allocation. + +If you remove virtio-net-pci, then your command line ends up without any PCI(e) device that has a 64-bit MMIO BAR. So the issue is not triggered. + +If you use a maxmem of 512G, then 40 bits might suffice. It's possible that your physical CPU has precisely that many address bits, and so the behavior could change. + +If you attach the OVMF debug log (capture `-debugcon file:debug.log -global isa-debugcon.iobase=0x402`), I could say more. + +Thus far this ticket looks like "NOTABUG" -- use a smaller memory hotplug area, or disable nested paging (which will come with a performance penalty). + +i see, + +but is there a good reason why it did work with an older qemu version/machine type (<= 2.6) +also my cpuinfo says physical bits 39 but i cannot use more maxmem than 222G + +i attached the cpuinfo, cmdline, and debug logs for a nonworking invocation and +one for each working, with 222G, with machine type 2.6 and without a virtio-net respectively + + + + + + + + + + + + + + + +The reason why it behaves differently with machine types <= 2.4 is that +- up to and including qemu-2.4, the calculation of the DIMM hotplug area was incorrect, +- in 2.5, the calculation was fixed, +- but for the migration compatibility of machine types <= 2.4, the old calculation was preserved for those machine types (the DIMM hotplug area is guest-visible) + +See the following (adjacent) commits: +- 3385e8e2640e ("pc: memhotplug: fix incorrectly set reserved-memory-end", 2015-09-10) +- 2f8b50083b32 ("pc: memhotplug: keep reserved-memory-end broken on 2.4 and earlier machines", 2015-09-10) + +These commits were first released in v2.5.0. + +I'll look at your logs now. + +* From "debug-nonworking.log": + +> GetFirstNonAddress: Pci64Base=0x8800000000 Pci64Size=0x800000000 +> [...] +> PublishPeiMemory: mPhysMemAddressWidth=40 PeiMemoryCap=69644 KB +> [...] +> Type = Mem64; Base = 0x8800000000; Length = 0x100000; Alignment = 0xFFFFF +> Base = 0x8800000000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [00|12|00:20]; Type = PMem64 + +- The 64-bit MMIO aperture starts at (512+32)GB (see "Pci64Base"). +- 40 physical address bits are required (see "mPhysMemAddressWidth"). + Your PCPU has 39 (thanks for confirming that). +- The 64-bit MMIO BAR of the virtio-net-pci device is allocated at + (512+32)GB. Will not be accessible. + + +* From "debug-working-222G.log": + +> GetFirstNonAddress: Pci64Base=0x7800000000 Pci64Size=0x800000000 +> [...] +> PublishPeiMemory: mPhysMemAddressWidth=39 PeiMemoryCap=67592 KB +> [...] +> Type = Mem64; Base = 0x7800000000; Length = 0x100000; Alignment = 0xFFFFF +> Base = 0x7800000000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [00|12|00:20]; Type = PMem64 + +- Aperture at 480GB. +- 39 phys bits suffice. +- BAR allocated at 480GB. Will be accessible. + + +* From "debug-working-novirtio-net.log": + +- Identical to "debug-nonworking.log", except there is no PCI device + with a 64-bit BAR, hence no attempt is made to access the inaccessible + aperture. + + +* Regarding why 222GB seems to be the cutoff. The base of the 64-bit + aperture must be suitably aligned. I explained this in the + earlier-referenced + <https://bugzilla.redhat.com/show_bug.cgi?id=1353591#c8>, in + particular, bullet (6). If you decrease the aperture size, the + required alignment will shrink as well, and the DIMM hotplug cutoff + might increase. Please refer to + + -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=4096 + + in <https://bugzilla.redhat.com/show_bug.cgi?id=1353591#c10>. + +Right now everything appears to work by design. Closing this ticket. + + +Last night I remembered another tidbit: + +In OVMF, you can entirely disable the 64-bit MMIO aperture. + + -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=0 + +If you use the above switch, the firmware log should contain the following message: + +> GetFirstNonAddress: disabling 64-bit PCI host aperture + +This will force the BAR allocations into 32-bit address space. Obviously, that makes it a lot easier to run out of the (much smaller) 32-bit MMIO aperture, but if you don't have PCI(E) devices with large MMIO BARs, then it should work (e.g. it should totally work in your present use case). + +And then you should be able to increase the DIMM hotplug area significantly, without running out of the GPA range covered by 39 physical address bits: + + // + // There's nothing more to do; the amount of memory above 4GB fully + // determines the highest address plus one. The memory hotplug area (see + // below) plays no role for the firmware in this case. + // + +"This case" beeing (Pci64Size == 0). + +Hope this helps. + diff --git a/results/classifier/118/review/1689499 b/results/classifier/118/review/1689499 new file mode 100644 index 000000000..52544a6f5 --- /dev/null +++ b/results/classifier/118/review/1689499 @@ -0,0 +1,147 @@ +user-level: 0.851 +semantic: 0.802 +virtual: 0.783 +mistranslation: 0.773 +hypervisor: 0.771 +vnc: 0.770 +ppc: 0.767 +network: 0.750 +TCG: 0.733 +VMM: 0.727 +permissions: 0.722 +KVM: 0.713 +performance: 0.713 +peripherals: 0.709 +register: 0.697 +graphic: 0.696 +x86: 0.685 +kernel: 0.683 +debug: 0.671 +risc-v: 0.647 +PID: 0.638 +arm: 0.633 +device: 0.628 +socket: 0.627 +assembly: 0.620 +i386: 0.608 +architecture: 0.604 +boot: 0.601 +files: 0.567 +-------------------- +performance: 0.864 +virtual: 0.788 +debug: 0.597 +hypervisor: 0.503 +TCG: 0.399 +risc-v: 0.059 +VMM: 0.032 +x86: 0.029 +register: 0.027 +socket: 0.026 +PID: 0.019 +semantic: 0.016 +user-level: 0.012 +vnc: 0.012 +kernel: 0.012 +files: 0.010 +ppc: 0.008 +KVM: 0.006 +device: 0.006 +i386: 0.006 +arm: 0.005 +architecture: 0.005 +boot: 0.003 +network: 0.002 +assembly: 0.002 +graphic: 0.002 +peripherals: 0.002 +permissions: 0.001 +mistranslation: 0.000 + +copy-storage-all/inc does not easily converge with load going on + +Hi, +for now this is more a report to discuss than a "bug", but I wanted to be sure if there are things I might overlook. + +I'm regularly testing the qemu's we have in Ubuntu which currently are 2.0, 2.5, 2.6.1, 2.8 plus a bunch of patches. And for all sorts of verification upstream every now and then. + +I recently realized that the migration options around --copy-storage-[all/inc] seem to have got worse at converging on migration. Although it is not a hard commit that is to be found, it just seems more likely to occur the newer the qemu versions is. I assume that is partially due to guest performance optimization that keep it busy. +To a user it appears as a hanging migration being locked up. + +But let me outline what actually happens: +- Setup without shared storage +- Migration using --copy-storage-all/--copy-storage-inc +- Working fine with idle guests +- If the guests is busy the migration does take like forever (1 vCPU that are busy with 1 CPU, 1 memory and one disk hogging processes) +- statistically seems to trigger more likely on newer qemu's (might be a red herring) + +The background workloads are most trivial burners: +- cpu: md5sum /dev/urandom +- memory: stress-ng -m 1 --vm-keep --vm-bytes 256M +- disk: while /bin/true; do dd if=/dev/urandom of=/var/tmp/mjb.1 bs=4M count=100; done + +We are talking about ~1-2 minutes on qemu 2.5 (4 tries x 3 architectures) and 2-10+ hours on >=qemu 2.6.1. + +I say it is likely not a bug, but more a discussion as I can easily avoid hanging via either: +- timeouts (--timeout, ...) to abort or suspend to migrate it +- --auto-converge ( I had only one try, but it seemed to help by slowing down the load generators) + +So you might say "that is all as it should be, and the users can use the further options to mitigate" and I'm all fine with that. In that case the bug still serves as a "searchable" document of some kind for others triggering the same case. But if anything comes to your mind that need better handling around this case lets start to discuss more deeply about it. + +Interesting. +That's quite a big difference, so if you could bisect it down it would be interesting to figure out where the change occurred. + +What happens if you just make it a 'disk' workload without the memory stress? + +What network interface (1G/10G etc) are you migrating over and what bandwidth limit have you got set? + +Dave + +On Tue, May 9, 2017 at 12:41 PM, Dr. David Alan Gilbert <<email address hidden> +> wrote: + +> Interesting. +> That's quite a big difference, so if you could bisect it down it would be +> interesting to figure out where the change occurred. +> + +Hi David, +if it turns out to stay reproducible enough I can certainly try somewhen +next week. + +What happens if you just make it a 'disk' workload without the memory +> stress? +> + +Will do so along my checks if it triggers reliably enough for a bisect. + + +> What network interface (1G/10G etc) are you migrating over and what +> bandwidth limit have you got set? +> + +No explicit bandwith limit set, the connection itself is only virtual +(migrating two libvirt/qemu stacks in between lxd containers) so other than +networking overhead this is usually really fast. +I quickly sniffed with iperf on a few of the test hosts and speed was +around 30-120 GBit/s which should qualify as "fast enough". + +I'll get back to you once I found the time to verify reproducibility and +hopefully a bisect. +I beg your pardon as this might need a few days (to free up my tasks as +well a system capable to do so). + + +Ok, I found an hour to set up a test environment. +I already had all the bisect script written until the systems were ready, but unfortunately it is not reproducible enough with my build from git as of today's master - out of 8 tries it showed as less of a slowdown once, and never to the hours of wait that I saw when testing on a wider scope. + +If my regular testing triggers these issues again I'll try to sort out what the difference is between this and my bisect environment (I set the latter up with the scripts that do the former), but until then I'm kind of out of options for now :-/. + + + +I'm "incompleting" myself until I was able to provide more :-/ + +OK, it'll be interesting if you get something repeatable, but sometimes these type of bugs go and hide in a dark corner until someone trips over them in a more critical situation. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1691 b/results/classifier/118/review/1691 new file mode 100644 index 000000000..1ec520726 --- /dev/null +++ b/results/classifier/118/review/1691 @@ -0,0 +1,70 @@ +register: 0.861 +virtual: 0.828 +device: 0.751 +performance: 0.713 +vnc: 0.670 +graphic: 0.658 +ppc: 0.650 +architecture: 0.646 +permissions: 0.633 +files: 0.618 +kernel: 0.609 +socket: 0.607 +peripherals: 0.587 +VMM: 0.583 +network: 0.580 +hypervisor: 0.579 +risc-v: 0.548 +TCG: 0.476 +PID: 0.470 +user-level: 0.462 +mistranslation: 0.437 +semantic: 0.436 +debug: 0.423 +arm: 0.416 +x86: 0.401 +assembly: 0.379 +KVM: 0.357 +i386: 0.349 +boot: 0.329 +-------------------- +virtual: 0.853 +hypervisor: 0.314 +debug: 0.294 +register: 0.167 +semantic: 0.126 +x86: 0.092 +user-level: 0.086 +architecture: 0.077 +TCG: 0.054 +peripherals: 0.045 +device: 0.037 +kernel: 0.033 +files: 0.031 +boot: 0.029 +performance: 0.025 +PID: 0.023 +assembly: 0.020 +risc-v: 0.019 +i386: 0.016 +VMM: 0.015 +vnc: 0.009 +permissions: 0.007 +socket: 0.007 +arm: 0.007 +ppc: 0.006 +network: 0.006 +graphic: 0.003 +mistranslation: 0.001 +KVM: 0.001 + +QEMU's NVMe emulator behaving not standard compliant +Description of problem: +QEMU's NVMe emulator behaves slightly non-conformant to the standard. +For one, in the CAP.CSS register, bits 0, 6 and 7 are set. Bit 7 indicates that the NVMe Controller does not support any I/O Command Set, while bit 6 is set when the NVMe Controller supports one or more I/O Command Sets (see Figure 36 of the NVM Express® Base Specification, Revision 2.0c). This is obviously contradictory and only bit 6 (and 0) should be set. These bits are configured in hw/nvme/ctrl.c:8250. +The NVMe emulator also checks whether the values of CC.IOSQES and CC.IOCQES are within the allowed range when the controller is enabled by setting CC.EN to 1. However this check should not be performed yet, as the allowed range can only be discovered after the controller is enabled, by submitting the Identify Command. This command reports the valid range in the Identify Controller Data Structure, however it requires the controller to be enabled which in turn would, at least in the current version, require valid values in CC.IOSQES and CC.IOCQES. The NVMe emulator also uses the values configured in CC.IOSQES and IO.IOCQES for the Admin Queues which, from what I understand, should not be the case. Only the I/O Queues should use these values. These checks are done in hw/nvme/ctrl.c:7199f. In the same function the values are already used to initialize the controllers cqe_size and sqe_size which should also happen at a later time. +Steps to reproduce: +1. Start any virtual machine with a NVMe Controller attached. +2. Read the value of CAP.CSS (located in BAR0 of the PCIe NVMe Controller). This value will be contradictory. +3. Follow the initialization procedure as described in section 3.5.1 of the NVM Express® Base Specification, Revision 2.0c. Do not set the values of CC.IOSQES and CC.IOCQES. +4. The NVMe Controller will fail to enable when setting CC.EN to 1 by setting CC.CFS to 1 and reporting the respective trace event (pci_nvme_err_startfail_cqent_too_small and variations). diff --git a/results/classifier/118/review/1692 b/results/classifier/118/review/1692 new file mode 100644 index 000000000..d652eac5f --- /dev/null +++ b/results/classifier/118/review/1692 @@ -0,0 +1,162 @@ +mistranslation: 0.923 +user-level: 0.898 +permissions: 0.867 +register: 0.867 +graphic: 0.834 +debug: 0.814 +risc-v: 0.812 +performance: 0.803 +KVM: 0.792 +peripherals: 0.788 +hypervisor: 0.784 +device: 0.783 +semantic: 0.780 +virtual: 0.778 +PID: 0.769 +arm: 0.768 +files: 0.764 +boot: 0.756 +TCG: 0.748 +socket: 0.735 +x86: 0.731 +ppc: 0.720 +assembly: 0.706 +network: 0.706 +architecture: 0.705 +VMM: 0.674 +kernel: 0.665 +i386: 0.619 +vnc: 0.617 +-------------------- +x86: 0.991 +kernel: 0.259 +debug: 0.084 +performance: 0.042 +virtual: 0.040 +files: 0.026 +hypervisor: 0.025 +boot: 0.025 +PID: 0.021 +assembly: 0.021 +TCG: 0.018 +architecture: 0.016 +device: 0.014 +register: 0.012 +user-level: 0.009 +semantic: 0.008 +VMM: 0.006 +ppc: 0.003 +socket: 0.003 +permissions: 0.003 +risc-v: 0.003 +peripherals: 0.002 +KVM: 0.002 +network: 0.002 +graphic: 0.002 +mistranslation: 0.001 +vnc: 0.001 +arm: 0.000 +i386: 0.000 + +Got "Assertion `bus->irq_count[i] == 0` failed" when running fuzzing +Description of problem: +When running the fuzzer on ac97, it always stops with "Assertion `bus->irq_count[i] == 0` failed". +Steps to reproduce: +Run `./qemu-fuzz-x86_64 --fuzz-target=generic-fuzz-ac97` +Additional information: +The logs triggered by the crash report are: +``` +==2330108==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +[I 0.000000] OPENED +INFO: libFuzzer ignores flags that start with '--' +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1879893091 +INFO: Loaded 1 modules (358762 inline 8-bit counters): 358762 [0x55bec313a1a0, 0x55bec3191b0a), +INFO: Loaded 1 PC tables (358762 PCs): 358762 [0x55bec3191b10,0x55bec370b1b0), +./qemu-fuzz-x86_64: Running 1 inputs 1 time(s) each. +Running: ./crash-55e7a160b7c66d5b41718e22c7620a29e9f568f1 +Starting x86_64 with Arguments: -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -device ac97,audiodev=snd0 -audiodev none,id=snd0 -nodefaults -qtest /dev/null +Matching objects by name ac97* +This process will try to fuzz the following MemoryRegions: + * bus master[0] (size 0xffffffffffffffff) + * ac97-nabm[0] (size 0x100) + * bus master container[0] (size 0xffffffffffffffff) + * ac97-nam[0] (size 0x400) +[R +0.033680] outl 0xcf8 0x80000800 +[S +0.033714] [R +0.033729] inw 0xcfc +[S +0.033750] [R +0.033766] outl 0xcf8 0x80000810 +[S +0.033781] [R +0.033792] outl 0xcfc 0xffffffff +[S +0.033816] [R +0.033827] outl 0xcf8 0x80000810 +[S +0.033841] [R +0.033852] inl 0xcfc +[S +0.033866] [R +0.033879] outl 0xcf8 0x80000810 +[S +0.033894] [R +0.033904] outl 0xcfc 0xc001 +[S +0.033920] [R +0.033935] outl 0xcf8 0x80000814 +[S +0.033952] [R +0.033967] outl 0xcfc 0xffffffff +[S +0.033984] [R +0.033994] outl 0xcf8 0x80000814 +[S +0.034008] [R +0.034017] inl 0xcfc +[S +0.034031] [R +0.034043] outl 0xcf8 0x80000814 +[S +0.034057] [R +0.034067] outl 0xcfc 0xc401 +[S +0.034085] [R +0.034096] outl 0xcf8 0x80000804 +[S +0.034110] [R +0.034120] inw 0xcfc +[S +0.034133] [R +0.034145] outl 0xcf8 0x80000804 +[S +0.034159] [R +0.034170] outw 0xcfc 0x7 +[S +0.035259] [R +0.035272] outl 0xcf8 0x80000804 +[S +0.035285] [R +0.035291] inw 0xcfc +[S +0.035300] [I +0.035389] CLOSED +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x80000805 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcfc 0x5050505 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc40b 0x6f0d +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x0 0x8 0x2a256c5a2c008425 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x80000805 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcfc 0x8468920 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +qemu-fuzz-x86_64: ../../../../hw/pci/pci.c:435: void pcibus_reset(BusState *): Assertion `bus->irq_count[i] == 0' failed. +==2330108== ERROR: libFuzzer: deadly signal + #0 0x55bebf2624de in __sanitizer_print_stack_trace ../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55bebf1a4b31 in fuzzer::PrintStackTrace() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55bebf17f406 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18 + #3 0x55bebf17f4cd in fuzzer::Fuzzer::CrashCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1 + #4 0x55bebf17f4cd in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19 + #5 0x7fae9f8a441f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466) + #6 0x7fae9f69800a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fae9f69800a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fae9f677858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7fae9f677728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7fae9f688fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55bebfab33a7 in pcibus_reset ../hw/pci/pci.c:435:9 + #12 0x55bec0c75ae3 in resettable_phase_hold ../hw/core/resettable.c + #13 0x55bec0c6e543 in device_reset_child_foreach ../hw/core/qdev.c:276:9 + #14 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #15 0x55bec0c5c421 in bus_reset_child_foreach ../hw/core/bus.c:97:13 + #16 0x55bec0c757c5 in resettable_phase_hold ../hw/core/resettable.c:173:5 + #17 0x55bec0c73729 in resettable_assert_reset ../hw/core/resettable.c:60:5 + #18 0x55bec0c7336a in resettable_reset ../hw/core/resettable.c:45:5 + #19 0x55bec0c7309a in qemu_devices_reset ../hw/core/reset.c:84:9 + #20 0x55bec02d95bb in pc_machine_reset ../hw/i386/pc.c:1901:5 + #21 0x55bebff4ede6 in qemu_system_reset ../softmmu/runstate.c:451:9 + #22 0x55bec0c49684 in fuzz_reset ../tests/qtest/fuzz/fuzz.c:56:5 + #23 0x55bec0c55641 in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:676:5 + #24 0x55bec0c4a0f7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5 + #25 0x55bebf17fc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) .. /../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15 + #26 0x55bebf1630a4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21 + #27 0x55bebf16fa8a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19 + #28 0x55bebf15a856 in main ../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #29 0x7fae9f679082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #30 0x55bebf15a8dd in _start (../qemu-fuzz-x86_64+0x1e938dd) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal + +``` + +After some manual checks, I find out that the instruction `outl 0xcf8 0x80000805` and `outl 0xcfc 0x8468920` will set irq_count[5] to -1 while the pcibus_reset() doesn't set it back to 0 so it will fail the assertion. diff --git a/results/classifier/118/review/1693050 b/results/classifier/118/review/1693050 new file mode 100644 index 000000000..546999ab8 --- /dev/null +++ b/results/classifier/118/review/1693050 @@ -0,0 +1,94 @@ +register: 0.834 +user-level: 0.790 +graphic: 0.763 +peripherals: 0.720 +permissions: 0.706 +architecture: 0.701 +arm: 0.675 +assembly: 0.659 +debug: 0.659 +semantic: 0.651 +socket: 0.642 +PID: 0.642 +hypervisor: 0.636 +device: 0.634 +performance: 0.627 +ppc: 0.605 +files: 0.595 +risc-v: 0.585 +network: 0.578 +mistranslation: 0.550 +kernel: 0.528 +VMM: 0.528 +boot: 0.520 +virtual: 0.489 +TCG: 0.475 +vnc: 0.466 +x86: 0.464 +KVM: 0.414 +i386: 0.341 +-------------------- +debug: 0.754 +kernel: 0.405 +register: 0.335 +hypervisor: 0.116 +x86: 0.113 +device: 0.039 +TCG: 0.034 +files: 0.030 +virtual: 0.029 +peripherals: 0.028 +assembly: 0.019 +architecture: 0.012 +PID: 0.012 +semantic: 0.010 +user-level: 0.010 +i386: 0.006 +arm: 0.005 +performance: 0.005 +ppc: 0.003 +VMM: 0.003 +vnc: 0.002 +network: 0.002 +socket: 0.002 +permissions: 0.002 +boot: 0.002 +risc-v: 0.001 +graphic: 0.001 +KVM: 0.001 +mistranslation: 0.001 + +xhci HCIVERSION register read emulation incorrectly handled + +We had an illumos user trying to run illumos in QEMU 2.9.0 with the qemu-xhci device enabled. Note, that while this was discovered against QEMU 2.9.0, from my current read of the HEAD, it is still present. The illumos bug at https://www.illumos.org/issues/8173 has additional information on how the user invoked qemu. While investigating the problem we found that the illumos driver was reading a version of 0x0000 when reading the HCIVERSION register from qemu. + +In the illumos driver we're performing a 16-bit read of the version register at offset 0x2. From looking around at other OSes, while Linux performs a 4 byte read at offset 0x0 and masks out the version, others that care about the version are doing a two byte read, though not all actually act on the version and some just discard the information. + +The user who hit this was able to enable tracing (note the tracing file is attached to the illumos bug linked previously) and we hit the unimplemented register read with offset 0x2 at http://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l2960. The xhci register specifies today that its allowed for users to do 1-4 byte reads; however, that it implements only four byte reads in its implementation (http://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3333). Hence why when we read the HCIVERSION register at offset 0x2, it isn't handled in xhci_cap_read() which then returns zeros. + +From digging into this, I think that we're coming into memory_region_dispatch_read() and then memory_region_dispatch_read1(). However, I don't see anything in either the general memory region logic or in the xhci_cap_read() function that would deal with adjusting the offset that we're reading at and then masking it off again. While the access_with_adjusted_size() attempts to deal with this, it never adjusts the hardware address that's passed in to be a multiple of the implementation defined offset that I can see. I suspect that the FIXME at line 582 (http://git.qemu.org/?p=qemu.git;a=blob;f=memory.c;hb=HEAD#l582) and the implementation in the xhci code is the crux of the problem. + +For the time being we're working around this in the illumos driver, but I wanted to point this out such that it might be helpful for other systems which are assuming that they can do the two byte read like on hardware. + +According to [1], this is still an issue today. + +[1]: https://review.coreboot.org/c/coreboot/+/39838/ + +Odd, this should be fixed by commit 6ee021d41 and 36960b4d66..98f52cdbb5c. + +According to Duncan, it’s not, and the paragraph from the original issue still applies. + +> The xhci register specifies today that its allowed for users to do 1-4 byte reads; however, that +> it implements only four byte reads in its implementation +> (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3333). Hence why when we +> read the HCIVERSION register at offset 0x2, it isn't handled in xhci_cap_read() which then +> returns zeros. + + +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/143 + + diff --git a/results/classifier/118/review/1696180 b/results/classifier/118/review/1696180 new file mode 100644 index 000000000..406647f36 --- /dev/null +++ b/results/classifier/118/review/1696180 @@ -0,0 +1,115 @@ +semantic: 0.912 +files: 0.909 +debug: 0.901 +assembly: 0.898 +mistranslation: 0.895 +hypervisor: 0.885 +KVM: 0.884 +architecture: 0.883 +virtual: 0.882 +graphic: 0.876 +peripherals: 0.876 +user-level: 0.874 +arm: 0.873 +performance: 0.871 +TCG: 0.866 +PID: 0.862 +device: 0.852 +kernel: 0.850 +risc-v: 0.847 +permissions: 0.846 +vnc: 0.842 +ppc: 0.840 +register: 0.837 +boot: 0.815 +VMM: 0.806 +x86: 0.805 +socket: 0.805 +network: 0.775 +i386: 0.698 +-------------------- +user-level: 0.828 +virtual: 0.548 +x86: 0.312 +TCG: 0.238 +i386: 0.143 +hypervisor: 0.139 +debug: 0.130 +PID: 0.127 +files: 0.055 +VMM: 0.034 +kernel: 0.032 +risc-v: 0.026 +register: 0.025 +network: 0.015 +assembly: 0.010 +ppc: 0.010 +semantic: 0.006 +device: 0.006 +boot: 0.005 +performance: 0.005 +socket: 0.004 +arm: 0.004 +graphic: 0.003 +permissions: 0.003 +architecture: 0.002 +vnc: 0.001 +KVM: 0.001 +peripherals: 0.001 +mistranslation: 0.000 + +Issues with qemu-img, libgfapi, and encryption at rest + +Hi, + +Encryption-at-rest has been supported for some time now. The client is responsible for encrypting the files with a help of a master key file. I have a properly setup environment and everything appears to be working fine but when I use qemu-img to move a file to gluster I get the following: + + +# qemu-img convert -f raw -O raw linux.iso gluster://gluster01/virt0/linux.raw +[2017-06-06 16:52:25.489720] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.490778] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.492263] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.497226] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_create+0x44d) [0x7f30f7a3cf5d] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL + +On and on until I get this message: + +[2017-06-06 17:00:03.467361] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-0: All subvolumes are down. Going offline until atleast one of them comes back up. +[2017-06-06 17:00:03.467442] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-1: All subvolumes are down. Going offline until atleast one of them comes back up. + +I asked for help assuming it's a problem with glusterfs and was told it appears qemu-img's implementation of libgfapi doesn't call the xlator function correctly. + +I'm using Fedora 24 with version: + +qemu-img 2.6.2 +glusterfs-api-3.8.12 + +When reporting bugs to the QEMU project, please always try with the latest release first (distros are often not shipping the latest version). So can you please try with the latest release of QEMU (currently version 2.9.0)? + +Just upgraded to 2.9.0 and actually I see a different issue: + +# qemu-img convert -O raw fedora.iso gluster://dalpinfglt04/virt0/fedora6.raw +[2017-06-07 16:52:43.300902] C [rpc-clnt-ping.c:160:rpc_clnt_ping_timer_expired] 0-virt0-client-2: server 172.19.38.42:49152 has not responded in the last 42 seconds, disconnecting. +[2017-06-07 17:02:44.342745] E [rpc-clnt.c:365:saved_frames_unwind] (--> /lib64/libglusterfs.so.0(_gf_log_callingfn+0x17d)[0x7f78c3e4fe6d] (--> /lib64/libgfrpc.so.0(saved_frames_unwind+0x1d1)[0x7f78c3c169a1] (--> /lib64/libgfrpc.so.0(saved_frames_destroy+0xe)[0x7f78c3c16abe] (--> /lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x87)[0x7f78c3c18157] (--> /lib64/libgfrpc.so.0(rpc_clnt_notify+0x288)[0x7f78c3c18c28] ))))) 0-virt0-client-2: forced unwinding frame type(GlusterFS 3.3) op(WRITE(13)) called at 2017-06-07 16:52:00.618744 (xid=0x1c) +[2017-06-07 17:02:44.342952] E [rpc-clnt.c:365:saved_frames_unwind] (--> /lib64/libglusterfs.so.0(_gf_log_callingfn+0x17d)[0x7f78c3e4fe6d] (--> /lib64/libgfrpc.so.0(saved_frames_unwind+0x1d1)[0x7f78c3c169a1] (--> /lib64/libgfrpc.so.0(saved_frames_destroy+0xe)[0x7f78c3c16abe] (--> /lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x87)[0x7f78c3c18157] (--> /lib64/libgfrpc.so.0(rpc_clnt_notify+0x288)[0x7f78c3c18c28] ))))) 0-virt0-client-2: forced unwinding frame type(GF-DUMP) op(NULL(2)) called at 2017-06-07 16:52:00.618753 (xid=0x1d) +[2017-06-07 17:02:44.343415] E [MSGID: 114031] [client-rpc-fops.c:1593:client3_3_finodelk_cbk] 0-virt0-client-2: remote operation failed [Transport endpoint is not connected] +[2017-06-07 17:08:49.367264] C [rpc-clnt-ping.c:160:rpc_clnt_ping_timer_expired] 0-virt0-client-3: server 172.19.38.43:49152 has not responded in the last 42 seconds, disconnecting. +[2017-06-07 17:13:29.969206] E [rpc-clnt.c:365:saved_frames_unwind] (--> /lib64/libglusterfs.so.0(_gf_log_callingfn+0x17d)[0x7f78c3e4fe6d] (--> /lib64/libgfrpc.so.0(saved_frames_unwind+0x1d1)[0x7f78c3c169a1] (--> /lib64/libgfrpc.so.0(saved_frames_destroy+0xe)[0x7f78c3c16abe] (--> /lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x87)[0x7f78c3c18157] (--> /lib64/libgfrpc.so.0(rpc_clnt_notify+0x288)[0x7f78c3c18c28] ))))) 0-virt0-client-3: forced unwinding frame type(GlusterFS 3.3) op(WRITE(13)) called at 2017-06-07 17:08:06.371259 (xid=0x22) +[2017-06-07 17:13:29.969250] E [MSGID: 114031] [client-rpc-fops.c:1593:client3_3_finodelk_cbk] 0-virt0-client-3: remote operation failed [Transport endpoint is not connected] +[2017-06-07 17:13:29.969355] E [rpc-clnt.c:365:saved_frames_unwind] (--> /lib64/libglusterfs.so.0(_gf_log_callingfn+0x17d)[0x7f78c3e4fe6d] (--> /lib64/libgfrpc.so.0(saved_frames_unwind+0x1d1)[0x7f78c3c169a1] (--> /lib64/libgfrpc.so.0(saved_frames_destroy+0xe)[0x7f78c3c16abe] (--> /lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x87)[0x7f78c3c18157] (--> /lib64/libgfrpc.so.0(rpc_clnt_notify+0x288)[0x7f78c3c18c28] ))))) 0-virt0-client-3: forced unwinding frame type(GF-DUMP) op(NULL(2)) called at 2017-06-07 17:08:06.371268 (xid=0x23) +[2017-06-07 17:13:29.972665] E [MSGID: 108008] [afr-transaction.c:2619:afr_write_txn_refresh_done] 0-virt0-replicate-1: Failing FSETXATTR on gfid 86042280-9ae1-444f-8342-be4442f82111: split-brain observed. [Input/output error] +[2017-06-07 17:13:29.977821] E [MSGID: 108008] [afr-read-txn.c:90:afr_read_txn_refresh_done] 0-virt0-replicate-1: Failing FGETXATTR on gfid 86042280-9ae1-444f-8342-be4442f82111: split-brain observed. [Input/output error] +[2017-06-07 17:13:29.981667] E [MSGID: 114031] [client-rpc-fops.c:1593:client3_3_finodelk_cbk] 0-virt0-client-2: remote operation failed [Invalid argument] +[2017-06-07 17:13:30.157560] E [MSGID: 108006] [afr-common.c:4781:afr_notify] 0-virt0-replicate-0: All subvolumes are down. Going offline until atleast one of them comes back up. +[2017-06-07 17:13:30.157904] E [MSGID: 108006] [afr-common.c:4781:afr_notify] 0-virt0-replicate-1: All subvolumes are down. Going offline until atleast one of them comes back up. +qemu-img: gluster://dalpinfglt04/virt0/fedora6.raw: error while converting raw: Could not create image: Transport endpoint is not connected + +The file was created but nothing was written to it. Either way, I don't think encryption-at-rest is tested much with qemu integration. + + +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/145 + + diff --git a/results/classifier/118/review/1696746 b/results/classifier/118/review/1696746 new file mode 100644 index 000000000..e9d7da2cb --- /dev/null +++ b/results/classifier/118/review/1696746 @@ -0,0 +1,84 @@ +mistranslation: 0.818 +network: 0.803 +user-level: 0.706 +socket: 0.698 +device: 0.672 +graphic: 0.648 +semantic: 0.569 +virtual: 0.446 +performance: 0.425 +permissions: 0.344 +ppc: 0.340 +PID: 0.322 +i386: 0.312 +x86: 0.292 +register: 0.279 +hypervisor: 0.253 +peripherals: 0.217 +assembly: 0.204 +boot: 0.197 +vnc: 0.195 +debug: 0.183 +architecture: 0.177 +arm: 0.111 +risc-v: 0.110 +VMM: 0.079 +files: 0.077 +KVM: 0.066 +TCG: 0.056 +kernel: 0.045 +-------------------- +network: 0.979 +virtual: 0.979 +user-level: 0.826 +hypervisor: 0.662 +TCG: 0.230 +x86: 0.063 +files: 0.038 +permissions: 0.025 +device: 0.022 +socket: 0.021 +kernel: 0.018 +debug: 0.017 +PID: 0.010 +arm: 0.009 +i386: 0.007 +semantic: 0.007 +ppc: 0.006 +risc-v: 0.004 +architecture: 0.004 +assembly: 0.004 +performance: 0.003 +register: 0.003 +VMM: 0.003 +boot: 0.003 +KVM: 0.002 +peripherals: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +netdev user,restrict=on prevents forwarded ports from being accessed from other systems + +I've got a guest only network and I'm wanting to access SSH on one of the guests externally. +I'm using -netdev user,id=usernet0,hostfwd=tcp::2222-:22,restrict=yes -device virtio-net-pci,netdev=usernet0 +to forward 2222 to 22 in the guest. + +The docs state: +restrict=on|off + + If this option is enabled, the guest will be isolated, i.e. it will not be able to contact the host and no guest IP packets will be routed over the host to the outside. This option does not affect any explicitly set forwarding rules. + + +However, with restrict=on, the forwarded port is only accessible from the host. Other systems receive no data. + +This was tested with qemu 2.8. Changelog for 2.9 doesn't mention any (relevant) user networking changes, so that should also fail. + +slirp (i.e. user networking) has been moved to a separate project... does this problem still persist with the latest version of QEMU? If so, could you please report it to the libslirp project instead: + +https://gitlab.freedesktop.org/slirp/libslirp/-/issues + +Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1699277 b/results/classifier/118/review/1699277 new file mode 100644 index 000000000..359e6cdfd --- /dev/null +++ b/results/classifier/118/review/1699277 @@ -0,0 +1,182 @@ +semantic: 0.868 +register: 0.862 +user-level: 0.856 +permissions: 0.847 +assembly: 0.847 +boot: 0.846 +performance: 0.841 +device: 0.838 +virtual: 0.832 +architecture: 0.830 +graphic: 0.822 +TCG: 0.818 +peripherals: 0.810 +PID: 0.803 +risc-v: 0.798 +KVM: 0.796 +arm: 0.785 +hypervisor: 0.773 +kernel: 0.762 +debug: 0.730 +ppc: 0.726 +VMM: 0.702 +mistranslation: 0.672 +socket: 0.670 +files: 0.664 +x86: 0.634 +vnc: 0.617 +network: 0.593 +i386: 0.559 +-------------------- +kernel: 0.982 +KVM: 0.912 +debug: 0.842 +boot: 0.801 +hypervisor: 0.148 +virtual: 0.148 +PID: 0.033 +performance: 0.025 +register: 0.020 +TCG: 0.016 +architecture: 0.013 +files: 0.010 +semantic: 0.009 +user-level: 0.008 +device: 0.007 +assembly: 0.006 +VMM: 0.004 +graphic: 0.002 +socket: 0.002 +peripherals: 0.002 +network: 0.002 +permissions: 0.002 +risc-v: 0.001 +mistranslation: 0.001 +ppc: 0.001 +vnc: 0.001 +x86: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-system-s390x: asserts while booting Debian Stretch installer + +QEMU 2.9.0 (Arch Linux) asserts when I try to install Debian Stretch. + +Steps to reproduce: + +wget http://ftp.debian.org/debian/dists/stretch/main/installer-s390x/current/images/generic/initrd.debian +wget http://ftp.debian.org/debian/dists/stretch/main/installer-s390x/current/images/generic/kernel.debian +qemu-img create -f qcow2 hda.qcow2 80G +qemu-system-s390x -kernel kernel.debian -initrd initrd.debian -nographic -drive file=hda.qcow2 + +Output: + +[ 0.051915] Linux version 4.9.0-3-s390x (<email address hidden>) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2 (2017-06-12) +[ 0.053000] setup: Linux is running under KVM in 64-bit mode +[ 0.053780] setup: Max memory size: 128MB +[ 0.067239] Write protected kernel read-only data: 8848k +[ 0.082461] Zone ranges: +[ 0.083717] DMA [mem 0x0000000000000000-0x000000007fffffff] +[ 0.084163] Normal empty +[ 0.084185] Movable zone start for each node +[ 0.084223] Early memory node ranges +[ 0.084306] node 0: [mem 0x0000000000000000-0x0000000007ffffff] +[ 0.084468] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] +[ 0.087697] percpu: Embedded 19 pages/cpu @0000000007f87000 s40704 r8192 d28928 u77824 +[ 0.088991] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 +[ 0.089108] Kernel command line: +[ 0.096684] PID hash table entries: 512 (order: 0, 4096 bytes) +[ 0.096853] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) +[ 0.097041] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) +[ 0.102453] Memory: 105164K/131072K available (6060K kernel code, 802K rwdata, 2784K rodata, 508K init, 648K bss, 25908K reserved, 0K cma-reserved) +[ 0.109112] Hierarchical RCU implementation. +[ 0.109134] Build-time adjustment of leaf fanout to 64. +[ 0.109155] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=2. +[ 0.109194] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=2 +[ 0.122047] NR_IRQS:3 nr_irqs:3 3 +[ 0.124317] clocksource: tod: mask: 0xffffffffffffffff max_cycles: 0x3b0a9be803b0a9, max_idle_ns: 1805497147909793 ns +[ 0.138366] console [ttyS1] enabled +[ 0.139126] pid_max: default: 32768 minimum: 301 +[ 0.143164] Security Framework initialized +[ 0.143215] Yama: disabled by default; enable with sysctl kernel.yama.* +[ 0.143955] AppArmor: AppArmor disabled by boot time parameter +[ 0.144489] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) +[ 0.144538] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) +[ 0.156937] ftrace: allocating 19165 entries in 75 pages +[ 0.408921] cpu: 1 configured CPUs, 0 standby CPUs +[ 0.433942] Brought up 1 CPUs +[ 0.451811] devtmpfs: initialized +[ 0.467021] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns +[ 0.467549] futex hash table entries: 512 (order: 5, 131072 bytes) +[ 0.476626] NET: Registered protocol family 16 +[ 0.482575] The s390-virtio transport is deprecated. Please switch to a modern host providing virtio-ccw. +[ 0.693017] VFS: Disk quotas dquot_6.6.0 +[ 0.693296] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 0.695029] hugetlbfs: disabling because there are no supported hugepage sizes +[ 0.703040] NET: Registered protocol family 2 +[ 0.709803] TCP established hash table entries: 1024 (order: 1, 8192 bytes) +[ 0.710003] TCP bind hash table entries: 1024 (order: 2, 16384 bytes) +[ 0.710134] TCP: Hash tables configured (established 1024 bind 1024) +[ 0.710879] UDP hash table entries: 256 (order: 1, 8192 bytes) +[ 0.711005] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) +[ 0.712409] NET: Registered protocol family 1 +[ 0.717432] Unpacking initramfs... +[ 1.308935] random: fast init done +[ 1.597369] Freeing initrd memory: 10152K (0000000000f90000 - 000000000197a000) +[ 1.600200] hypfs: The hardware system does not support hypfs +[ 1.601718] hypfs: Initialization of hypfs failed with rc=-61 +[ 1.605317] audit: initializing netlink subsys (disabled) +[ 1.606211] audit: type=2000 audit(1497977949.601:1): initialized +[ 1.611137] workingset: timestamp_bits=46 max_order=15 bucket_order=0 +[ 1.612066] zbud: loaded +[ 1.642108] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) +[ 1.643111] io scheduler noop registered +[ 1.643160] io scheduler deadline registered +[ 1.643383] io scheduler cfq registered (default) +[ 1.644143] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 +[ 1.644221] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 +[ 1.645626] hvc_iucv: The z/VM IUCV HVC device driver cannot be used without z/VM +[ 1.647547] mousedev: PS/2 mouse device common for all mice +[ 1.649359] ledtrig-cpu: registered to indicate activity on CPUs +[ 1.649884] cio: Channel measurement facility initialized using format extended (mode autodetected) +[ 1.657228] NET: Registered protocol family 10 +[ 1.663924] mip6: Mobile IPv6 +[ 1.664068] NET: Registered protocol family 17 +[ 1.664195] mpls_gso: MPLS GSO support +[ 1.667936] registered taskstats version 1 +[ 1.669547] zswap: loaded using pool lzo/zbud +[ 1.674474] ima: No TPM chip found, activating TPM-bypass! +[ 1.739953] Freeing unused kernel memory: 508K (0000000000a6f000 - 0000000000aee000) +[ 1.740381] Write protected read-only-after-init data: 4k +** +ERROR:/build/qemu/src/qemu-2.9.0/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +[1] 13880 abort (core dumped) qemu-system-s390x -kernel kernel.debian -initrd initrd.debian -nographic + +Trace: +#0 0x00007ffff10fb670 in raise () at /usr/lib/libc.so.6 +#1 0x00007ffff10fcd00 in abort () at /usr/lib/libc.so.6 +#2 0x00007ffff35dfc9d in g_assertion_message () at /usr/lib/libglib-2.0.so.0 +#3 0x00007ffff35dfd2a in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0 +#4 0x00005555556abb84 in () +#5 0x000055555572ab73 in css_adapter_interrupt () +#6 0x000055555571be68 in virtio_notify () +#7 0x00005555556f84ce in () +#8 0x00005555556f9afd in () +#9 0x00005555556fa78f in virtio_blk_handle_vq () +#10 0x000055555571b7f1 in virtio_queue_notify () +#11 0x000055555572ceb7 in () +#12 0x0000555555726f86 in s390_virtio_hypercall () +#13 0x0000555555752c85 in helper_diag () +#14 0x00007fffe46664bf in code_gen_buffer () +#15 0x00005555556ab2f5 in cpu_exec () +#16 0x00005555556ce08d in () +#17 0x00007ffff1474297 in start_thread () at /usr/lib/libpthread.so.0 +#18 0x00007ffff11b525f in clone () at /usr/lib/libc.so.6 + +Thanks for the bug report! If you've got a chance to use the latest development version of QEMU from the git repository instead, could you please try whether you could also reproduce the problem there? I think we've already got the fix for this problem in there: + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2cf9953beebd194a432ebd + +Thank you for the super quick response. +I can confirm that the bug is fixed with the current version in git. + diff --git a/results/classifier/118/review/1700 b/results/classifier/118/review/1700 new file mode 100644 index 000000000..035001efe --- /dev/null +++ b/results/classifier/118/review/1700 @@ -0,0 +1,61 @@ +mistranslation: 0.902 +device: 0.867 +performance: 0.826 +debug: 0.694 +architecture: 0.692 +arm: 0.600 +risc-v: 0.380 +graphic: 0.374 +socket: 0.310 +network: 0.299 +semantic: 0.282 +files: 0.235 +boot: 0.228 +i386: 0.223 +ppc: 0.223 +TCG: 0.223 +permissions: 0.221 +peripherals: 0.200 +register: 0.137 +kernel: 0.121 +virtual: 0.119 +x86: 0.108 +hypervisor: 0.090 +vnc: 0.089 +assembly: 0.058 +PID: 0.055 +user-level: 0.033 +VMM: 0.024 +KVM: 0.005 +-------------------- +debug: 0.934 +kernel: 0.765 +performance: 0.222 +assembly: 0.209 +device: 0.095 +virtual: 0.061 +peripherals: 0.038 +x86: 0.024 +hypervisor: 0.013 +files: 0.012 +semantic: 0.010 +i386: 0.006 +user-level: 0.006 +boot: 0.003 +arm: 0.003 +register: 0.003 +PID: 0.002 +graphic: 0.002 +ppc: 0.002 +KVM: 0.001 +socket: 0.001 +architecture: 0.001 +TCG: 0.001 +network: 0.001 +risc-v: 0.001 +permissions: 0.001 +mistranslation: 0.001 +vnc: 0.000 +VMM: 0.000 + +TriCore: helper_ret() is not correctly restoring PSW diff --git a/results/classifier/118/review/1705717 b/results/classifier/118/review/1705717 new file mode 100644 index 000000000..b6209db76 --- /dev/null +++ b/results/classifier/118/review/1705717 @@ -0,0 +1,123 @@ +user-level: 0.829 +VMM: 0.762 +ppc: 0.724 +i386: 0.719 +vnc: 0.718 +TCG: 0.708 +x86: 0.679 +mistranslation: 0.678 +peripherals: 0.656 +hypervisor: 0.655 +risc-v: 0.628 +PID: 0.601 +register: 0.594 +graphic: 0.593 +virtual: 0.592 +files: 0.589 +assembly: 0.587 +KVM: 0.583 +network: 0.574 +semantic: 0.567 +arm: 0.566 +device: 0.558 +performance: 0.539 +permissions: 0.529 +kernel: 0.525 +debug: 0.523 +socket: 0.508 +architecture: 0.496 +boot: 0.411 +-------------------- +KVM: 0.951 +hypervisor: 0.671 +kernel: 0.303 +debug: 0.195 +x86: 0.101 +PID: 0.029 +performance: 0.027 +vnc: 0.020 +architecture: 0.019 +socket: 0.015 +files: 0.013 +user-level: 0.006 +device: 0.005 +assembly: 0.005 +virtual: 0.005 +semantic: 0.004 +register: 0.004 +i386: 0.003 +permissions: 0.002 +TCG: 0.002 +network: 0.002 +VMM: 0.002 +boot: 0.002 +graphic: 0.001 +risc-v: 0.001 +peripherals: 0.001 +ppc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +Live migration fails with 'host' cpu when KVM is inserted with nested=1 + +Qemu v2.9.0 +Linux kernel 4.9.34 + +Live migration(pre-copy) being done from one physical host to another: + +Source Qemu: +sudo qemu-system-x86_64 -drive file=${IMAGE_DIR}/${IMAGE_NAME},if=virtio -m 2048 -smp 1 -net nic,model=virtio,macaddr=${MAC} -net tap,ifname=qtap0,script=no,downscript=no -vnc :1 --enable-kvm -cpu kvm64 -qmp tcp:*:4242,server,nowait + +And KVM is inserted with nested=1 on both source and destination machine. + +Migration fails with a nested specific assertion failure on destination at target/i386/kvm.c +1629 + +Migration is successful in the following cases- + +A) cpu model is 'host' and kvm is inserted without nested=1 parameter +B) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=1) +C) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=0) +D) Between an L0 and a guest Hypervisor L1, with 'kvm64' as CPU type (and nested=1 for L0 KVM) + +Physical host(s)- +$ lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 12 +On-line CPU(s) list: 0-11 +Thread(s) per core: 1 +Core(s) per socket: 6 +Socket(s): 2 +NUMA node(s): 2 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 62 +Model name: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz +Stepping: 4 +CPU MHz: 1200.091 +CPU max MHz: 2600.0000 +CPU min MHz: 1200.0000 +BogoMIPS: 4203.28 +Virtualization: VT-x +L1d cache: 32K +L1i cache: 32K +L2 cache: 256K +L3 cache: 15360K +NUMA node0 CPU(s): 0-5 +NUMA node1 CPU(s): 6-11 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts + +Hi, + Can you please give the exact assertion failure. + +However, I'm confused - I think you're saying that your setup is that both hosts have nested enabled, but this is a migration of top level VM - correct? Does the top level VM have a guest inside it - migration with a nested guest is known not to work, however migration of a VM on a host with nested enabled should work if the guest doesn't use the nest. + + +Hello, +I could not replicate this behavior on another system. +So, please close this bug. +Apologies for the inconvenience. + +Hmm OK; but if you do hit it again please just reopen this one and give the full assert and details + diff --git a/results/classifier/118/review/1708215 b/results/classifier/118/review/1708215 new file mode 100644 index 000000000..409adb944 --- /dev/null +++ b/results/classifier/118/review/1708215 @@ -0,0 +1,91 @@ +mistranslation: 0.947 +architecture: 0.848 +graphic: 0.799 +semantic: 0.734 +user-level: 0.708 +virtual: 0.705 +device: 0.691 +arm: 0.649 +performance: 0.633 +PID: 0.588 +ppc: 0.572 +permissions: 0.554 +hypervisor: 0.526 +register: 0.444 +network: 0.425 +vnc: 0.405 +peripherals: 0.403 +i386: 0.376 +files: 0.349 +assembly: 0.345 +boot: 0.342 +VMM: 0.340 +x86: 0.340 +debug: 0.316 +risc-v: 0.234 +socket: 0.229 +TCG: 0.094 +KVM: 0.079 +kernel: 0.049 +-------------------- +virtual: 0.996 +user-level: 0.774 +debug: 0.523 +hypervisor: 0.336 +x86: 0.168 +register: 0.045 +network: 0.035 +files: 0.029 +socket: 0.019 +boot: 0.015 +PID: 0.014 +VMM: 0.012 +device: 0.012 +semantic: 0.009 +kernel: 0.007 +vnc: 0.004 +architecture: 0.004 +performance: 0.004 +arm: 0.003 +i386: 0.003 +TCG: 0.003 +assembly: 0.002 +peripherals: 0.002 +KVM: 0.002 +risc-v: 0.002 +permissions: 0.002 +ppc: 0.002 +graphic: 0.002 +mistranslation: 0.000 + +Windows 10 clipboard bug + +Hello, + +I am using qemu on arch: + pacman -Q libvirt qemu linux virt-manager +libvirt 3.5.0-1 +qemu 2.9.0-2 +linux 4.12.3-1 +virt-manager 1.4.1-2 + +I have a windows 10 Guest, with all updates and the following packages installed in the guest: +- QEMU guest agent 7.3.2 +- SPICE Guest Tools 0.132 + +When I start the VM, I can copy/paste from the host to the guest. However, after I use COPY inside the VM, copy/paste is not working any more from host to guest. However, I can still copy/paste from guest to host. + +To summarize: +- copy/paste from guest to host works always +- copy/paste from host to guest works only if copy was not previously used in guest. + +If this bug needs to be reported using another portal or if I can provide any further information, please contact me. + +Best Regards, +gxgung + +UPDATE: +Restarting "SPICE VDAagent" within the VM allows me to paste again from host to VM, however as soon as I use copy within the VM, it stops working again. + +This sounds like a bug in Spice, and not like a bug in QEMU. If you still face this problem, please report it to the spice project instead (see https://www.spice-space.org/support.html). + diff --git a/results/classifier/118/review/1709025 b/results/classifier/118/review/1709025 new file mode 100644 index 000000000..b99466723 --- /dev/null +++ b/results/classifier/118/review/1709025 @@ -0,0 +1,109 @@ +risc-v: 0.924 +peripherals: 0.912 +mistranslation: 0.866 +VMM: 0.826 +vnc: 0.823 +i386: 0.819 +files: 0.805 +ppc: 0.797 +user-level: 0.785 +x86: 0.775 +arm: 0.764 +debug: 0.753 +KVM: 0.751 +graphic: 0.748 +hypervisor: 0.738 +performance: 0.735 +architecture: 0.726 +TCG: 0.723 +device: 0.722 +PID: 0.716 +assembly: 0.700 +semantic: 0.659 +kernel: 0.654 +socket: 0.641 +network: 0.635 +virtual: 0.634 +register: 0.633 +permissions: 0.618 +boot: 0.447 +-------------------- +kernel: 0.912 +debug: 0.203 +files: 0.124 +KVM: 0.108 +VMM: 0.107 +ppc: 0.045 +x86: 0.034 +TCG: 0.026 +i386: 0.021 +virtual: 0.020 +risc-v: 0.016 +device: 0.010 +hypervisor: 0.008 +PID: 0.008 +performance: 0.008 +user-level: 0.005 +semantic: 0.004 +assembly: 0.004 +register: 0.004 +architecture: 0.003 +vnc: 0.002 +arm: 0.002 +peripherals: 0.002 +boot: 0.001 +network: 0.001 +graphic: 0.001 +permissions: 0.001 +socket: 0.001 +mistranslation: 0.001 + +Disk corrupted after snapshot deletion + + I found the vm disk corruption after snapshot deletion sometimes(the probability is very low, I'm afraid i can't reproduce it). And I found there is a patch for it as follow, but I'm not sure whether the patch repaired the bug. + Drain disk before snapshot deletion can't guarantee anything, there is still pending IO in snapshot-deletion process. Anyone can help? + +author Zhang Haoyu <email address hidden> 2014-10-21 16:38:01 +0800 +committer Stefan Hajnoczi <email address hidden> 2014-11-03 09:48:42 +0000 +commit 3432a1929ee18e08787ce35476abd74f2c93a17c (patch) +tree 13a81c0a46707d91622f1593ccf7b926935371fd /block/snapshot.c +parent 573742a5431a99ceaba6968ae269cee247727cce (diff) +snapshot: add bdrv_drain_all() to bdrv_snapshot_delete() to avoid concurrency problem +If there are still pending i/o while deleting snapshot, +because deleting snapshot is done in non-coroutine context, and +the pending i/o read/write (bdrv_co_do_rw) is done in coroutine context, +so it's possible to cause concurrency problem between above two operations. +Add bdrv_drain_all() to bdrv_snapshot_delete() to avoid this problem. + +Signed-off-by: Zhang Haoyu <email address hidden> +Reviewed-by: Paolo Bonzini <email address hidden> +Message-id: <email address hidden> +Signed-off-by: Stefan Hajnoczi <email address hidden> +Diffstat (limited to 'block/snapshot.c') +-rw-r--r-- block/snapshot.c 4 +1 files changed, 4 insertions, 0 deletions +diff --git a/block/snapshot.c b/block/snapshot.c +index 85c52ff..698e1a1 100644 +--- a/block/snapshot.c ++++ b/block/snapshot.c +@@ -236,6 +236,10 @@ int bdrv_snapshot_delete(BlockDriverState *bs, + error_setg(errp, "snapshot_id and name are both NULL"); + return -EINVAL; + } ++ ++ /* drain all pending i/o before deleting snapshot */ ++ bdrv_drain_all(); ++ + if (drv->bdrv_snapshot_delete) { + return drv->bdrv_snapshot_delete(bs, snapshot_id, name, errp); + } + +My qemu version is 2.1.2 + +Please try again with the latest release of QEMU first (currently 2.9, or the latest RC of 2.10). QEMU 2.1.2 is very old, the bug might have been fixed in the latest release already. + +Thanks for your reply +For some reason, I can't update my version. I believe the latest version have fixed the problem in commit 3432a1929ee18e08787ce35476abd74f2c93a17c or 27a7649a48f9019fa5bd2998d8e342791397bdda. But I'm not sure the first patch have fixed the problem, as the second patch is too much change for me. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1709170 b/results/classifier/118/review/1709170 new file mode 100644 index 000000000..52efece89 --- /dev/null +++ b/results/classifier/118/review/1709170 @@ -0,0 +1,179 @@ +risc-v: 0.930 +mistranslation: 0.909 +ppc: 0.903 +user-level: 0.880 +virtual: 0.856 +KVM: 0.854 +vnc: 0.853 +debug: 0.853 +TCG: 0.852 +hypervisor: 0.850 +graphic: 0.848 +network: 0.846 +arm: 0.843 +VMM: 0.843 +peripherals: 0.838 +device: 0.838 +register: 0.838 +PID: 0.835 +assembly: 0.833 +semantic: 0.826 +socket: 0.826 +performance: 0.823 +permissions: 0.820 +kernel: 0.818 +architecture: 0.814 +files: 0.813 +boot: 0.742 +x86: 0.712 +i386: 0.523 +-------------------- +arm: 0.156 +virtual: 0.126 +kernel: 0.124 +debug: 0.110 +TCG: 0.092 +register: 0.088 +files: 0.082 +hypervisor: 0.072 +risc-v: 0.071 +PID: 0.070 +vnc: 0.057 +socket: 0.035 +user-level: 0.035 +device: 0.035 +boot: 0.030 +network: 0.019 +semantic: 0.019 +VMM: 0.015 +mistranslation: 0.007 +peripherals: 0.005 +ppc: 0.004 +architecture: 0.003 +performance: 0.003 +permissions: 0.003 +assembly: 0.002 +graphic: 0.001 +x86: 0.001 +i386: 0.001 +KVM: 0.001 + +QEMU fails to honor O_TMPFILE + +When making a call like + + open("/tmp", O_TMPFILE | O_RDWR); + +under QEMU, we ged -EISDIR. + +Under any kernel 3.11 or later, we are supposed to get an unnamed file in /tmp. In case the filesystem for /tmp does not support unnamed files, we are supposed to get EOPNOTSUPP. + +[I don't know the QEMU version, since this happened in a system I don't have access to] + +Hi Thiago, + +What is the version of glibc on the targets you are building to? There was an O_TMPFILE bug in older glibc's: + +https://sourceware.org/bugzilla/show_bug.cgi?id=17912 + +On Mon, Aug 07, 2017 at 08:18:04PM -0000, Thiago Macieira wrote: +> Public bug reported: +> +> When making a call like +> +> open("/tmp", O_TMPFILE | O_RDWR); +> +> under QEMU, we ged -EISDIR. +> +> Under any kernel 3.11 or later, we are supposed to get an unnamed file +> in /tmp. In case the filesystem for /tmp does not support unnamed files, +> we are supposed to get EOPNOTSUPP. + +Actually, -EISDIR is valid error when underlying system doesn't support O_TMPFILE. +See man openat or the kernel definition for O_TMPFILE. + +Regardless, I'm submitting a patch to properly translate the O_TMPFILE. + +Riku + + +Since O_TMPFILE might differ between guest and host, +add it to the bitmask_transtbl. While at it, fix the definitions +of O_DIRECTORY etc on arm64, which are identical to arm32 according +to kernel sources. + +This fixes open14 and openat03 ltp testcases. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1709170 + +--- + linux-user/strace.c | 4 ++++ + linux-user/syscall.c | 3 +++ + linux-user/syscall_defs.h | 8 +++++++- + 3 files changed, 14 insertions(+), 1 deletion(-) + +diff --git a/linux-user/strace.c b/linux-user/strace.c +index d821d165ff..bd897a3f20 100644 +--- a/linux-user/strace.c ++++ b/linux-user/strace.c +@@ -838,6 +838,10 @@ UNUSED static struct flags open_flags[] = { + #ifdef O_PATH + FLAG_TARGET(O_PATH), + #endif ++#ifdef O_TMPFILE ++ FLAG_TARGET(O_TMPFILE), ++ FLAG_TARGET(__O_TMPFILE), ++#endif + FLAG_END, + }; + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 54343c06be..b3aa8099b4 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -342,6 +342,9 @@ static bitmask_transtbl fcntl_flags_tbl[] = { + #if defined(O_PATH) + { TARGET_O_PATH, TARGET_O_PATH, O_PATH, O_PATH }, + #endif ++#if defined(O_TMPFILE) ++ { TARGET_O_TMPFILE, TARGET_O_TMPFILE, O_TMPFILE, O_TMPFILE }, ++#endif + /* Don't terminate the list prematurely on 64-bit host+guest. */ + #if TARGET_O_LARGEFILE != 0 || O_LARGEFILE != 0 + { TARGET_O_LARGEFILE, TARGET_O_LARGEFILE, O_LARGEFILE, O_LARGEFILE, }, +diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h +index 40c5027e93..6e2287e918 100644 +--- a/linux-user/syscall_defs.h ++++ b/linux-user/syscall_defs.h +@@ -2416,7 +2416,7 @@ struct target_statfs64 { + #define TARGET_O_CLOEXEC 010000000 + #define TARGET___O_SYNC 000100000 + #define TARGET_O_PATH 020000000 +-#elif defined(TARGET_ARM) || defined(TARGET_M68K) ++#elif defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_AARCH64) + #define TARGET_O_DIRECTORY 040000 /* must be a directory */ + #define TARGET_O_NOFOLLOW 0100000 /* don't follow links */ + #define TARGET_O_DIRECT 0200000 /* direct disk access hint */ +@@ -2513,6 +2513,12 @@ struct target_statfs64 { + #ifndef TARGET_O_PATH + #define TARGET_O_PATH 010000000 + #endif ++#ifndef TARGET___O_TMPFILE ++#define TARGET___O_TMPFILE 020000000 ++#endif ++#ifndef TARGET_O_TMPFILE ++#define TARGET_O_TMPFILE (TARGET___O_TMPFILE | TARGET_O_DIRECTORY) ++#endif + #ifndef TARGET_O_NDELAY + #define TARGET_O_NDELAY TARGET_O_NONBLOCK + #endif +-- +2.11.0 + + + +It was a Yocto 2.0 sysroot running on an Ubuntu 16.04 host. + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5f9cee46cd4ec4600e1a + diff --git a/results/classifier/118/review/1711602 b/results/classifier/118/review/1711602 new file mode 100644 index 000000000..0fe0e70c4 --- /dev/null +++ b/results/classifier/118/review/1711602 @@ -0,0 +1,993 @@ +mistranslation: 0.825 +risc-v: 0.751 +user-level: 0.702 +peripherals: 0.607 +KVM: 0.584 +hypervisor: 0.572 +register: 0.571 +virtual: 0.553 +device: 0.551 +semantic: 0.526 +ppc: 0.515 +vnc: 0.474 +x86: 0.468 +graphic: 0.468 +network: 0.467 +assembly: 0.444 +PID: 0.443 +VMM: 0.435 +permissions: 0.410 +arm: 0.387 +performance: 0.366 +TCG: 0.361 +architecture: 0.360 +debug: 0.353 +kernel: 0.348 +files: 0.341 +socket: 0.262 +boot: 0.257 +i386: 0.234 +-------------------- +virtual: 0.945 +x86: 0.928 +KVM: 0.914 +hypervisor: 0.909 +debug: 0.383 +user-level: 0.370 +TCG: 0.126 +PID: 0.064 +files: 0.015 +socket: 0.013 +register: 0.010 +VMM: 0.005 +ppc: 0.005 +network: 0.005 +device: 0.004 +performance: 0.002 +assembly: 0.002 +kernel: 0.002 +semantic: 0.002 +risc-v: 0.002 +vnc: 0.001 +graphic: 0.001 +i386: 0.001 +architecture: 0.001 +boot: 0.001 +permissions: 0.000 +arm: 0.000 +mistranslation: 0.000 +peripherals: 0.000 + +--copy-storage-all failing with qemu 2.10 + +We fixed an issue around disk locking already in regard to qemu-nbd [1], but there still seem to be issues. + +$ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.196/system +error: internal error: qemu unexpectedly closed the monitor: 2017-08-18T12:10:29.800397Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0) +2017-08-18T12:10:48.545776Z qemu-system-x86_64: load of migration failed: Input/output error + +Source libvirt log for the guest: +2017-08-18 12:09:08.251+0000: initiating migration +2017-08-18T12:09:08.809023Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer +2017-08-18T12:09:08.809481Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer + +Target libvirt log for the guest: +2017-08-18T12:09:08.730911Z qemu-system-x86_64: load of migration failed: Input/output error +2017-08-18 12:09:09.010+0000: shutting down, reason=crashed + +Given the timing it seems that the actual copy now works (it is busy ~10 seconds on my environment which would be the copy). +Also we don't see the old errors we saw before, but afterwards on the actual take-over it fails. + +Dmesg has no related denials as often apparmor is in the mix. + +Need to check libvirt logs of source [2] and target [3] in Detail. + +[1]: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02200.html +[2]: http://paste.ubuntu.com/25339356/ +[3]: http://paste.ubuntu.com/25339358/ + +Is anybody but me testing this combo ? +All else seems to work nice, just this special (and only this) migration setup fails. + +--copy-storage-inc also affected. + +It seems in the copy storage set of migrations is overall affected. + +Note: We do upgrade migration checks from the old version onto the new one with the planned upgrade - that revealed that if the migration source is still at the old level the migration works (even with the 2.10 based one on the target). + + +I reached out to the people involved in the initial fixes which were related to image locking and qemu-nbd. But this might after all be something completely different. +Yet until we know better it might be wiser to reach out to more people. + +=> http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg03465.html + +The source log is virsh, I need to ensure we also have a source libvirtd log ... + +Since this is pretty reproducible here on the setup: + +- Two systems (actually two lxd containers on one system) +- Both running Artful with qemu 2.10-rc3 and libvirt 3.6 +- Storage path is not shared but set up equivalent with a manual pre-copy +- Migration with post copy is failing, no other options set, example: + $ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.100/system +- Same setup works on the qemu versions in Xenial (2.5), Yakkety (2.6), and Zesty (2.8) +- In fact it seems even a migration from a Zesty qemu (2.8) to the new (2.10) works + +To simplify downloading the logs I'm attaching here a full set of: +- virsh +- source libvirtd +- target libvirtd + + + + + +I've seen something in the logs which I want to eliminate from the list of possibilities: + "warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]" + +We had always a patch I questioned to enable svm capabilitiy for guests in general, it worked all the time but I'd have preferred to be an explicit user opt-in. +I remember seeing the warning in the past which made me neglect it at first, but maybe the target capability check is now more strict. + +I'll drop this change for a test build and run all that again to be sure. +I doubt that is the reason, but let verifying this particular lead be my task - please be open with other suggestions. + +Currently I plan to test with the svm/vmx changes disabled as well as a cross test on ppc64 and s390x which might complete the picture. + +The 'host doesn't support requested feature' is probably a red-herring in this case +The fact it's failing with an IO error but nothing else suggests either: + a) it's something closing the socket between the two qemu's + b) The I/O error is from storage/NBD + +Assuming it fails on precopy, I'd look at the qemu_loadvm_state_section_startfull to watch all the device states load. +You could also add some debug/tracing in qemu_loadvm_state to see at what point it fails. + +Dave + +Hi David, +confirming the red-herring on the cpu feature - I had a build without runnign over the weekend so this was easy to test - and still the migration fails. + +I have about 7 seconds from kicking off the migration until the sync seems to pass its first phase and then qemu is exiting (at least that is what libvirt thinks): + "closed without SHUTDOWN event; assuming the domain crashed" + +Since the qemu "lives" in that time I can try to debug what happens. +With strace to sniff where things could be I see right before the end: + 0.000203 recvmsg(27, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="", iov_len=32768}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 0 <0.000014> + 0.000049 futex(0xca65dacf4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xca4785a80, 20) = 1 <0.000016> + 0.000038 getpid() = 29750 <0.000023> + 0.000011 tgkill(29750, 29760, SIGUSR1) = 0 <0.000030> + 0.000012 futex(0xca4785a80, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000048> + 0.000010 futex(0xca47b46e4, FUTEX_WAIT_PRIVATE, 19, NULL) = 0 <0.002215> + 0.000032 sendmsg(21, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="{\"timestamp\": {\"seconds\": 1503322067, \"microseconds\": 613178}, \"event\": \"MIGRATION\", \"data\": {\"status\": \"failed\"}}\r\n", iov_len=116}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 116 <0.000024> + 0.000074 write(2, "2017-08-21T13:27:47.613276Z qemu-system-x86_64: load of migration failed: Input/output error\n", 93) = 93 <0.000022> + 0.000055 close(27) = 0 <0.000090> + +Now 29750 is the main process/tgid and 29760 is the third process started on the migration. +It is the one that does the vcpu ioctl's so I assume this is just the one representing the vpu. +Well gdb should be more useful so looking with that. + +As expected by David when I trace on process_incoming_migration_co which prints the "readable" error I see the error pop up on "qemu_loadvm_state" +It appears as "Thread 4 "CPU 0/KVM" received signal SIGUSR1" and similar which is just the break down of the guest. + + +Diving "into" qemu_loadvm_state reveals that it gets until "cpu_synchronize_all_pre_loadvm". +In qemu_loadvm_state none of the initial checks fail. +Then the "ret = vmstate_load_state(f, &vmstate_configuration, &savevm_state, 0);" seems to work fine was well. +It seems reproducible in "cpu_synchronize_all_pre_loadvm" where the crash happens. + +I can catch the incoming qemu easily with: +$ while ! pid=$(pidof qemu-system-x86_64); do /bin/true; done; gdb --pid ${pid} +# Then in gdb break on "cpu_synchronize_all_pre_loadvm" +# And when I step over it I the next thing I see is the "beginning of the end" for the process +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +[Switching to Thread 0x7f418136e700 (LWP 3887)] +__lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + +The guest only has one vcpu, so CPU_FOREACH(cpu) is not much of a loop. +Looking down that path I tracked it to along: +cpu_synchronize_all_pre_loadvm -> cpu_synchronize_pre_loadvm -> kvm_cpu_synchronize_pre_loadvm -> do_run_on_cpu + +Here it queues the function "do_kvm_cpu_synchronize_pre_loadvm" onto the vcpu. +That is done via queue_work_on_cpu(cpu, &wi); which in turn uses eventually "qemu_cpu_kick_thread(cpu);" +That seems to trigger the first SIGUSR1 + +Following that I get the breakpoint that I set at "do_kvm_cpu_synchronize_pre_loadvm". +The actual function only sets "cpu->vcpu_dirty = true;" and works. + +On the way out from there, there is a "qemu_kvm_wait_io_event" which leads to the next SIGUSR1. + +Going on I see another "do_run_on_cpu" with "vapic_do_enable_tpr_reporting" as the function. +I set a breakpoint on that as well but took a full CPUstate before going on: +p *cpu +$4 = {parent_obj = {parent_obj = {class = 0x5ffe7170c0, free = 0x7f62328f15a0 <g_free>, properties = 0x5ffe736e40, ref = 1, + parent = 0x5ffe726160}, id = 0x0, realized = true, pending_deleted_event = false, opts = 0x0, hotplugged = 0, parent_bus = 0x0, gpios = { + lh_first = 0x0}, child_bus = {lh_first = 0x0}, num_child_bus = 0, instance_id_alias = -1, alias_required_for_version = 0}, nr_cores = 1, + nr_threads = 1, thread = 0x5ffe803cd0, thread_id = 8498, running = false, has_waiter = false, halt_cond = 0x5ffe803cf0, thread_kicked = true, + created = true, stop = false, stopped = true, unplug = false, crash_occurred = false, exit_request = false, interrupt_request = 4, + singlestep_enabled = 0, icount_budget = 0, icount_extra = 0, jmp_env = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, + __saved_mask = {__val = {0 <repeats 16 times>}}}}, work_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, + __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, + initialized = true}, queued_work_first = 0x5fffefc990, queued_work_last = 0x5fffefc990, cpu_ases = 0x5ffe803c10, num_ases = 1, + as = 0x5ffe7f9690, memory = 0x5ffe725bd0, env_ptr = 0x5ffe7e44c0, tb_jmp_cache = {0x0 <repeats 4096 times>}, gdb_regs = 0x0, + gdb_num_regs = 57, gdb_num_g_regs = 57, node = {tqe_next = 0x0, tqe_prev = 0x5ffc1783f0 <cpus>}, breakpoints = {tqh_first = 0x0, + tqh_last = 0x5ffe7e4430}, watchpoints = {tqh_first = 0x0, tqh_last = 0x5ffe7e4440}, watchpoint_hit = 0x0, opaque = 0x0, mem_io_pc = 0, + mem_io_vaddr = 0, kvm_fd = 19, kvm_state = 0x5ffe7357a0, kvm_run = 0x7f62374bc000, trace_dstate_delayed = {0}, trace_dstate = {0}, + cpu_index = 0, halted = 1, can_do_io = 1, exception_index = -1, vcpu_dirty = true, throttle_thread_scheduled = false, icount_decr = {u32 = 0, + u16 = {low = 0, high = 0}}, hax_vcpu = 0x0, pending_tlb_flush = 7} + +Continuing I hit the "vapic_do_enable_tpr_reporting" with qemu still running. + +Things go on, the next candidate for "do_run_on_cpu" is "kvm_apic_put" +Another SIGUSR1 to get that kicked it seems. +"kvm_apic_put" breakpoint is reached after that kick. + +Next for "do_run_on_cpu" is "do_kvm_cpu_synchronize_post_init". And that triggered the fourth SIGUSR1. Before I only saw four, hopefully that is the same with so much breakpoints. + +Checked the cpu state again: +1880 static void do_kvm_cpu_synchronize_post_init(CPUState *cpu, run_on_cpu_data arg) +1881 { +1882 kvm_arch_put_registers(cpu, KVM_PUT_FULL_STATE); +1883 cpu->vcpu_dirty = false; +1884 } +1885 +(gdb) p cpu +$5 = (CPUState *) 0x5ffe7dc230 +(gdb) p *cpu +$6 = {parent_obj = {parent_obj = {class = 0x5ffe7170c0, free = 0x7f62328f15a0 <g_free>, properties = 0x5ffe736e40, ref = 1, + parent = 0x5ffe726160}, id = 0x0, realized = true, pending_deleted_event = false, opts = 0x0, hotplugged = 0, parent_bus = 0x0, gpios = { + lh_first = 0x0}, child_bus = {lh_first = 0x0}, num_child_bus = 0, instance_id_alias = -1, alias_required_for_version = 0}, nr_cores = 1, + nr_threads = 1, thread = 0x5ffe803cd0, thread_id = 8498, running = false, has_waiter = false, halt_cond = 0x5ffe803cf0, thread_kicked = false, + created = true, stop = false, stopped = true, unplug = false, crash_occurred = false, exit_request = false, interrupt_request = 4, + singlestep_enabled = 0, icount_budget = 0, icount_extra = 0, jmp_env = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, + __saved_mask = {__val = {0 <repeats 16 times>}}}}, work_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, + __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, + initialized = true}, queued_work_first = 0x0, queued_work_last = 0x0, cpu_ases = 0x5ffe803c10, num_ases = 1, as = 0x5ffe7f9690, + memory = 0x5ffe725bd0, env_ptr = 0x5ffe7e44c0, tb_jmp_cache = {0x0 <repeats 4096 times>}, gdb_regs = 0x0, gdb_num_regs = 57, + gdb_num_g_regs = 57, node = {tqe_next = 0x0, tqe_prev = 0x5ffc1783f0 <cpus>}, breakpoints = {tqh_first = 0x0, tqh_last = 0x5ffe7e4430}, + watchpoints = {tqh_first = 0x0, tqh_last = 0x5ffe7e4440}, watchpoint_hit = 0x0, opaque = 0x0, mem_io_pc = 0, mem_io_vaddr = 0, kvm_fd = 19, + kvm_state = 0x5ffe7357a0, kvm_run = 0x7f62374bc000, trace_dstate_delayed = {0}, trace_dstate = {0}, cpu_index = 0, halted = 1, can_do_io = 1, + exception_index = -1, vcpu_dirty = true, throttle_thread_scheduled = false, icount_decr = {u32 = 0, u16 = {low = 0, high = 0}}, + hax_vcpu = 0x0, pending_tlb_flush = 7} + +And from here stepping into kvm_arch_put_registers: +kvm_arch_put_registers (cpu=cpu@entry=0x5ffe7dc230, level=level@entry=3) at ./target/i386/kvm.c:2591 + +That still is the same vcpu as all the time, x86_cpu is optimized out unfortunately as I had no full debug build with -O0. + +I see it setting up regs in kvm_arch_put_registers without error (all ret=0) and return to do_kvm_cpu_synchronize_post_init. +This eventually sets "cpu->vcpu_dirty = false;" + +After this seems all good I steped through the "way out" and there came another "qemu_kvm_wait_io_event(cpu);". +Without considering this being critical I stepped with "n" and qemu was gone with all its threads. + +qemu_kvm_cpu_thread_fn (arg=0x5ffe7dc230) at ./cpus.c:1134 +1134 } while (!cpu->unplug || cpu_can_run(cpu)); +(gdb) n +1127 if (cpu_can_run(cpu)) { +(gdb) n +1133 qemu_kvm_wait_io_event(cpu); +(gdb) n +[Thread 0x7f6227857700 (LWP 8498) exited] + + +After this I was trying to start closer to the issue, so I put a break on "process_incoming_migration_co" (to skip over much of the initial setup). +Once that was hit I added "qemu_kvm_cpu_thread_fn" and "qemu_kvm_wait_io_event". + +Of course when I try that the other functions do not trigger. +Maybe it is partially influenced by the debugging itself and/or the timing changes it causes. + +I'll check what else I can find with slightly different debugging, but so much as an update for now. + +oh yeh you want to tell gdb to ignore SIGUSR1, something like: + handle SIGUSR1 nostop noprint pass + +Sure, but initially I wanted to see what is going on overall so I let it pop up. + +Started a debugging another session today. +First I confirmed with + (gdb) catch syscall exit exit_group +That this is the "normal" exit along the error message we knew: + migrate_set_state(&mis->state, MIGRATION_STATUS_ACTIVE, + MIGRATION_STATUS_FAILED); + error_report("load of migration failed: %s", strerror(-ret)); + qemu_fclose(mis->from_src_file); + exit(EXIT_FAILURE); + +I found that already the retval of qemu_loadvm_state it -5. +Every thing else afterwards is cleanup. + +Inside qemu_loadvm_state the first 2/3 pass and then that ret=-5 is from "ret = qemu_file_get_error(f);". + +Via a watchpoints I found that the error is set by qemu_fill_buffer. + +b qemu_loadvm_state +handle SIGUSR1 nostop noprint pass +c +# on the break check and watch the status +(gdb) p f +$1 = (QEMUFile *) 0xb9babb3c00 +(gdb) p *f +$2 = {ops = 0xb9b89880a0 <channel_input_ops>, hooks = 0x0, opaque = 0xb9bbabfe00, bytes_xfer = 0, xfer_limit = 0, pos = 0, buf_index = 0, + buf_size = 0, buf = '\000' <repeats 32767 times>, may_free = {0}, iov = {{iov_base = 0x0, iov_len = 0} <repeats 64 times>}, iovcnt = 0, + last_error = 0} + +# ok still no err, set watchpoint +(gdb) p &(f->last_error) +$4 = (int *) 0xb9babbc044 +(gdb) watch *(int *) 0xb9babbc044 +Hardware watchpoint 2: *(int *) 0xb9babbc044 + +# This catches the following +Thread 1 "qemu-system-x86" hit Hardware watchpoint 2: *(int *) 0xb9babbc044 + +Old value = 0 +New value = -5 +0x000000b9b82bd0ec in qemu_file_set_error (ret=-5, f=0xb9babb3c00) at ./migration/qemu-file.c:125 +warning: Source file is more recent than executable. +125 f->last_error = ret; +(gdb) bt +#0 0x000000b9b82bd0ec in qemu_file_set_error (ret=-5, f=0xb9babb3c00) at ./migration/qemu-file.c:125 +#1 qemu_fill_buffer (f=0xb9babb3c00) at ./migration/qemu-file.c:299 +#2 0x000000b9b82bdbb1 in qemu_peek_byte (f=0xb9babb3c00, offset=0) at ./migration/qemu-file.c:553 +#3 0x000000b9b82bdc1b in qemu_get_byte (f=f@entry=0xb9babb3c00) at ./migration/qemu-file.c:566 +#4 0x000000b9b82b5853 in qemu_loadvm_state_main (f=f@entry=0xb9babb3c00, mis=0xb9b8a4f700 <mis_current>) at ./migration/savevm.c:1947 +#5 0x000000b9b82b864f in qemu_loadvm_state (f=f@entry=0xb9babb3c00) at ./migration/savevm.c:2032 +#6 0x000000b9b82af5c3 in process_incoming_migration_co (opaque=0xb9babb3c00) at ./migration/migration.c:320 +#7 0x000000b9b83e42a6 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ./util/coroutine-ucontext.c:79 +#8 0x00007fbf3702fac0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 +#9 0x00007fffe3f9f800 in ?? () +#10 0x0000000000000000 in ?? () + +So this is failing I/O that iterates over a channel. +I was tracking down the len, pending and pos used. + +I found that this is not completely broken (like no access or generla I/O error) +It starts at pos 0 and iterated with varying offsets, but works for quite some time. +Example: + +[...] +Thread 1 "qemu-system-x86" hit Breakpoint 2, qemu_fill_buffer (f=f@entry=0xd3b66f3c00) at ./migration/qemu-file.c:295 +295 if (len > 0) { +$11183 = 28728 +$11184 = 4040 +$11185 = {ops = 0xd3b3d740a0 <channel_input_ops>, hooks = 0x0, opaque = 0xd3b75ee490, bytes_xfer = 0, xfer_limit = 0, pos = 107130146, + buf_index = 0, buf_size = 4040, + buf = "\v\327\a\000\021\000\[...]\000"..., + may_free = {0}, iov = {{iov_base = 0x0, iov_len = 0} <repeats 64 times>}, iovcnt = 0, last_error = 0} +[...] + +Well you could see the whole file read passing by one by one buffer +Yet this isn't particularly fast, so track the one that has len==0 + (gdb) b ./migration/qemu-file.c:295 if len == 0 + +And I got it as: +(gdb) p *f +$11195 = {ops = 0xd3b3d740a0 <channel_input_ops>, hooks = 0x0, opaque = 0xd3b75ee490, bytes_xfer = 0, xfer_limit = 0, pos = 319638837, + buf_index = 0, buf_size = 0, buf = '\000' <repeats 5504 times>..., may_free = {0}, iov = {{iov_base = 0x0, iov_len = 0} <repeats 64 times>}, + iovcnt = 0, last_error = 0} + +Here pending == 0 so buf_size = 0 as well also pos is further down incremented to 319638837. + +Checking in detail I found that I had pending=0 and buf_size=0 as well as non aligned pos entried, but they worked. +So I excluded the buf_size=0/pending=0 as well as the alignment as reasons. +Maybe it just iterates pos out of the range that is working? + + +(gdb) handle SIGUSR1 nostop noprint pass +(gdb) b migration/qemu-file.c:295 +(gdb) command +p f->pos +c +end + +That showed the pos is ever increasing and fails at an offset it never read before. Yet the absolute number was different. +$1 = 0 +$2 = 8948 +$3 = 41423 +[...] +$11359 = 326387440 +$11360 = 326420208 => This was the one failing this time + + +This was a different f->pos than last time, so I wondered if this would change every time. +With a less interactive gdb config I got in three tries: +1. 313153311 +2. 313313376 +3. 313571856 +So a different f->pos to fail each time. + +Different but rather close. +I wondered if the reasons I got a higher one when tracing in more detail printing all offsets could be that there still is something copied/synced and only slowly gets available. + +I stepped through rather slowly and got to 322429260 this time. +So slower continuing on the iteration over qemu_fill_buffer makes it fail "later"? + +Finally it is surely interesting which channel that actually is- likely the migration socket? +And yes, ioc->name in qio_channel_read is: + $8 = 0x56ab78e5c0 "migration-socket-incoming + +So TL;DR summary for now: +- error triggers in qio_channel_read +- file is migration-socket-incoming +- reads work a while, but then fail at high f->pos offsets (slightly different ones each time) +- slower execution seems to lead to slightly higher offsets that are failing +- only happens on --copy-storage-* migrations (libvirt/virsh argument) + +I don't really know atm where to look deeper - is there a good side channel that I could use to look at what is going on on the migration-socket-incoming - Maybe from the source and target while I block in gdb? + +OK, so that looks like a real case of the migration stream failing and getting an IO error; so the question is why: + a) Is the source qemu dieing first and closing the socket? + b) Is libvirt closing the socket for some reason + + + +also, you might want to chase it a bit further down, I think we've got: + + qemu-file-channel.c:channel_get_buffer + io/channel-socket.c or io/channel-file.c qio_channel_file_readv + + it would be good to know what the readv/readmsg is actually returning in the case where it's failing. + +Dave + +I'll track down the actual read and then add debugging the source at the same time (that should be the best way to track the migration socket on both sides). +This might be slightly tricky since I don't know exactly on which offset but I can surely start over 310*10^6 it seems. + +I'll report back once I know more, thanks for your guidance David + +Hmm i just tried to reproduce this and hit (on the source): + +main_channel_client_handle_migrate_connected: client 0x5607d785f610 connected: 0 seamless 0 +qemu-system-x86_64: /root/qemu/io/channel.c:303: qio_channel_yield: Assertion `!ioc->write_coroutine' failed. +2017-08-22 10:50:04.888+0000: shutting down, reason=crashed + + +OK, 3rd try and I've hit the same behaviour as Christian. + + +Stack from qemu_fill_buffer to qio_channel_socket_readv +#0 qio_channel_socket_readv (ioc=<optimized out>, iov=<optimized out>, niov=<optimized out>, fds=0x0, nfds=0x0, errp=0x0) + at ./io/channel-socket.c:477 +#1 0x0000001486ec97e2 in qio_channel_read (ioc=ioc@entry=0x148a73a6c0, + buf=buf@entry=\060\nLw", buflen=buflen@entry=28728, errp=errp@entry=0x0) at ./io/channel.c:112 +#2 0x0000001486e005ec in channel_get_buffer (opaque=<optimized out>, + buf=0x1489844c00 "\060\nLw", pos=<optimized out>, size=28728) at ./migration/qemu-file-channel.c:80 +#3 0x0000001486dff095 in qemu_fill_buffer (f=f@entry=0x1489843c00) at ./migration/qemu-file.c:293 + +I checked that sioc->fd, &msg, sflags) is in fact the socket. +With e.g. with this fd being 27 +tcp ESTAB 1405050 0 ::ffff:10.22.69.30:49152 ::ffff:10.22.69.157:49804 users:(("qemu-system-x86",pid=29273,fd=27)) ino:3345152 sk:30 <-> + skmem:(r1420644,rb1495660,t0,tb332800,f668,w0,o0,bl0,d14) ts sack cubic wscale:7,7 rto:200 rtt:0.04/0.02 ato:80 mss:8948 cwnd:10 bytes_received:1981460 segs_out:37 segs_in:247 data_segs_in:231 send 17896.0Mbps lastsnd:254728 lastrcv:250372 lastack:250372 rcv_rtt:0.205 rcv_space:115461 minrtt:0.04 + +I need to break on the fail of that recvmsg in qio_channel_socket_readv +# the following does not work due to optimization the ret value is only around later +b io/channel-socket.c:478 if ret < 0 +But catching it "inside" the if works +b io/channel-socket.c:479 + + +Take the following with a grain of salt, this is very threaded and noisy to debug. + +Once I hit it the recmsg returned "-1", that was on f->pos = 311641887 +But at the same time I could confirm (via ss) that the socket itself is still open on source and target of the migration. + +-1 is EAGAIN and returns QIO_CHANNEL_ERR_BLOCK +That seems to arrive in nbd_rwv nbd/common.c:44). +And led to "qio_channel_yield" + +There are a few corouting switches in between so I hope I'm not loosing anything. +But that first ret<0 actually worked, it seems the yield and retry got it working. + +I got back to qemu_fill_buffer iterating further after this. +This hit ret<0 in qio_channel_socket_readv again at f->pos 311641887. + +This time on returning the QIO_CHANNEL_ERR_BLOCK it returned to "./migration/qemu-file-channel.c:81". +That was interesting as it is different than before. +After this it seemed to become a death spiral - recmsg returned -1 every time (still on the same offset). +It passed back through the nbd_rwv which called qio_channel_yield for multiple times. + +Then it continued and later on on 321998304 is the last I saw. +It did no more pass b io/channel-socket.c:479 at all, but then led to the exit. + +Hmm, I might have lost myself on the coroutine switches - but it is odd at least. +Trying to redo less interactive and with a bit more prep ... +Maybe the results are more reliable then ... + +Getting back with more later ... + +Only now read comment #27, thanks David for reproducing with me, it is somewhat relieving that you seem to see the same. + +(4th try) breakpoint on qemu_file_set_error, it's bdrv_inactivate_all that's returning the error. + +(gdb) list +1155 if (inactivate_disks) { +1156 /* Inactivate before sending QEMU_VM_EOF so that the +1157 * bdrv_invalidate_cache_all() on the other end won't fail. */ +1158 ret = bdrv_inactivate_all(); +1159 if (ret) { +1160 qemu_file_set_error(f, ret); +1161 return ret; +1162 } +1163 } + + +For me qemu_file_set_error was always called from qemu_fill_buffer, interesting that it seems different for you. +I'll rerun a few times to ensure it really always is always from qemu_fill_buffer for me. + +The difference with the qemu_file_set_error is I'm looking on the source - because what's happening is the source is erroring so closing the socket, and so the error you're seeing on the destination is real - the socket just EOF'd! + +repeated the assert in #26: +Program received signal SIGABRT, Aborted. +0x00007f02163005f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); +(gdb) where +#0 0x00007f02163005f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007f0216301ce8 in __GI_abort () at abort.c:90 +#2 0x00007f02162f9566 in __assert_fail_base (fmt=0x7f0216449288 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x560ac0191e93 "!ioc->write_coroutine", file=file@entry=0x560ac0191e66 "/root/qemu/io/channel.c", line=line@entry=303, function=function@entry=0x560ac0191f60 <__PRETTY_FUNCTION__.22239> "qio_channel_yield") + at assert.c:92 +#3 0x00007f02162f9612 in __GI___assert_fail (assertion=assertion@entry=0x560ac0191e93 "!ioc->write_coroutine", file=file@entry=0x560ac0191e66 "/root/qemu/io/channel.c", line=line@entry=303, function=function@entry=0x560ac0191f60 <__PRETTY_FUNCTION__.22239> "qio_channel_yield") at assert.c:101 +#4 0x0000560ac0036a08 in qio_channel_yield (ioc=ioc@entry=0x560ac2397c90, condition=condition@entry=G_IO_OUT) + at /root/qemu/io/channel.c:303 +#5 0x0000560ac001930e in nbd_rwv (ioc=0x560ac2397c90, iov=<optimized out>, niov=<optimized out>, length=<optimized out>, do_read=do_read@entry=false, errp=errp@entry=0x0) at /root/qemu/nbd/common.c:47 +#6 0x0000560ac0007e24 in nbd_co_send_request (bs=bs@entry=0x560ac30167a0, request=request@entry=0x7f0209afc9a0, qiov=qiov@entry=0x560ac2428d68) at /root/qemu/block/nbd-client.c:154 +#7 0x0000560ac0008244 in nbd_client_co_pwritev (bs=0x560ac30167a0, offset=3414163456, bytes=<optimized out>, qiov=0x560ac2428d68, flags=<optimized out>) at /root/qemu/block/nbd-client.c:260 +#8 0x0000560ac00030e1 in bdrv_driver_pwritev (bs=bs@entry=0x560ac30167a0, offset=offset@entry=3414163456, bytes=bytes@entry=589824, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0) at /root/qemu/block/io.c:877 +#9 0x0000560ac0004480 in bdrv_aligned_pwritev (req=req@entry=0x7f0209afcba0, offset=offset@entry=3414163456, bytes=589824, align=align@entry=1, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0, child=0x560ac1f0a9b0, child=0x560ac1f0a9b0) at /root/qemu/block/io.c:1382 +#10 0x0000560ac0005258 in bdrv_co_pwritev (child=0x560ac1f0a9b0, offset=offset@entry=3414163456, bytes=<optimized out>, qiov=qiov@entry=0x560ac2428d68, flags=0) at /root/qemu/block/io.c:1633 +#11 0x0000560abffbf564 in raw_co_pwritev (bs=0x560ac22807f0, offset=3414163456, bytes=<optimized out>, qiov=0x560ac2428d68, flags=<optimized out>) at /root/qemu/block/raw-format.c:243 +#12 0x0000560ac00030e1 in bdrv_driver_pwritev (bs=bs@entry=0x560ac22807f0, offset=offset@entry=3414163456, bytes=bytes@entry=589824, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0) at /root/qemu/block/io.c:877 +#13 0x0000560ac0004480 in bdrv_aligned_pwritev (req=req@entry=0x7f0209afce70, offset=offset@entry=3414163456, bytes=589824, align=align@entry=1, qiov=qiov@entry=0x560ac2428d68, flags=flags@entry=0, child=0x560ac33c1e70, child=0x560ac33c1e70) at /root/qemu/block/io.c:1382 +#14 0x0000560ac0005258 in bdrv_co_pwritev (child=0x560ac33c1e70, offset=offset@entry=3414163456, bytes=<optimized out>, bytes@entry=589824, qiov=qiov@entry=0x560ac2428d68, flags=0) at /root/qemu/block/io.c:1633 +#15 0x0000560abfff5173 in blk_co_pwritev (blk=0x560ac14f31e0, offset=3414163456, bytes=589824, qiov=0x560ac2428d68, flags=<optimized out>) at /root/qemu/block/block-backend.c:1062 +#16 0x0000560abfff528a in blk_aio_write_entry (opaque=0x560ac2c18f70) at /root/qemu/block/block-backend.c:1253 +#17 0x0000560ac0092cca in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) + at /root/qemu/util/coroutine-ucontext.c:79 +#18 0x00007f0216312110 in __start_context () at /lib64/libc.so.6 +#19 0x00007fff12c4db30 in () +#20 0x0000000000000000 in () +(gdb) + +In 5/5 tries this was on qemu_fill_buffer for my case. + +But that was on the receiving side, and what you found is closer to the root cause on the source of the migration. +I checked on qemu_file_set_error on the source and can confirm your finding that on the source it is from bdrv_inactivate_all. + +#0 qemu_file_set_error (f=f@entry=0x6b76b46c00, ret=ret@entry=-1) at ./migration/qemu-file.c:124 +#1 0x0000006b727140cb in qemu_savevm_state_complete_precopy (f=0x6b76b46c00, iterable_only=iterable_only@entry=false, + inactivate_disks=inactivate_disks@entry=true) at ./migration/savevm.c:1160 +#2 0x0000006b7270c84b in migration_completion (start_time=<synthetic pointer>, old_vm_running=<synthetic pointer>, current_active_state=4, + s=0x6b74ef53b0) at ./migration/migration.c:1858 +#3 migration_thread (opaque=0x6b74ef53b0) at ./migration/migration.c:2023 +#4 0x00007f61a740e74a in start_thread (arg=0x7f61467fc700) at pthread_create.c:456 +#5 0x00007f61a714acaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +Also as I outlined - what seems ages ago in comment #6 - if the source is a qemu 2.8 the migration works for me which would kind of match assuming the root cause is in the source. + +OK, Stefan posted a patch for that assert (see 'nbd-client: avoid spurious qui_channel_yield() re-entry) so now I'm running with the following patch and I'm seeing the bdrv_inactivate return a -1 for +drive-virtio-disk0 +Christian: Could you see what your source says with this patch? + +diff --git a/block.c b/block.c +index 3615a68..f9bd689 100644 +--- a/block.c ++++ b/block.c +@@ -4078,9 +4078,11 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + BdrvChild *child, *parent; + int ret; + ++ fprintf(stderr, "%s: entry for %s\n", __func__, bdrv_get_device_or_node_name(bs)); + if (!setting_flag && bs->drv->bdrv_inactivate) { + ret = bs->drv->bdrv_inactivate(bs); + if (ret < 0) { ++ fprintf(stderr, "%s: exit 1(%d) for %s\n", __func__, ret, bdrv_get_device_or_node_name(bs)); + return ret; + } + } +@@ -4094,6 +4096,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + if (parent->role->inactivate) { + ret = parent->role->inactivate(parent); + if (ret < 0) { ++ fprintf(stderr, "%s: exit 2(%d) for %s\n", __func__, ret, bdrv_get_device_or_node_name(bs)); + bs->open_flags &= ~BDRV_O_INACTIVE; + return ret; + } +@@ -4109,6 +4112,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + QLIST_FOREACH(child, &bs->children, next) { + ret = bdrv_inactivate_recurse(child->bs, setting_flag); + if (ret < 0) { ++ fprintf(stderr, "%s: exit 3(%d) for %s\n", __func__, ret, bdrv_get_device_or_node_name(bs)); + return ret; + } + } +@@ -4117,6 +4121,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs, + * driver */ + bdrv_release_persistent_dirty_bitmaps(bs); + ++ fprintf(stderr, "%s: exit end good for %s\n", __func__, bdrv_get_device_or_node_name(bs)); + return 0; + } + + + +Building with the attached debug patch ... + +I didn't add Stefans patch yet. +Note: the Mentioned patch is at: Note: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg04027.html + +With your debug patch applied I get: +2017-08-22 17:57:04.486+0000: initiating migration +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block145 +bdrv_inactivate_recurse: entry for #block328 +bdrv_inactivate_recurse: entry for #block210 +bdrv_inactivate_recurse: exit end good for #block210 +bdrv_inactivate_recurse: exit end good for #block328 +bdrv_inactivate_recurse: entry for #block082 +bdrv_inactivate_recurse: exit end good for #block082 +bdrv_inactivate_recurse: exit end good for #block145 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block763 +bdrv_inactivate_recurse: entry for #block631 +bdrv_inactivate_recurse: exit end good for #block631 +bdrv_inactivate_recurse: exit end good for #block763 +bdrv_inactivate_recurse: entry for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block544 +bdrv_inactivate_recurse: entry for #block405 +bdrv_inactivate_recurse: exit end good for #block405 +bdrv_inactivate_recurse: exit end good for #block544 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block1086 +bdrv_inactivate_recurse: entry for #block919 +bdrv_inactivate_recurse: exit end good for #block919 +bdrv_inactivate_recurse: exit end good for #block1086 +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: exit 2(-1) for drive-virtio-disk0 + +I'm currently building one with Stefans patch applied as well over (my) night, but let me know if there is more that makes sense to try. + +With the patch from Stefan and your debug applied source and target I still run into the same issue I'd say. +Id's are slightly off, but they are different on every try anyway. + +Still looks the same for me: +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block184 +bdrv_inactivate_recurse: entry for #block319 +bdrv_inactivate_recurse: entry for #block218 +bdrv_inactivate_recurse: exit end good for #block218 +bdrv_inactivate_recurse: exit end good for #block319 +bdrv_inactivate_recurse: entry for #block092 +bdrv_inactivate_recurse: exit end good for #block092 +bdrv_inactivate_recurse: exit end good for #block184 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block1905 +bdrv_inactivate_recurse: entry for #block1889 +bdrv_inactivate_recurse: exit end good for #block1889 +bdrv_inactivate_recurse: exit end good for #block1905 +bdrv_inactivate_recurse: entry for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block551 +bdrv_inactivate_recurse: entry for #block423 +bdrv_inactivate_recurse: exit end good for #block423 +bdrv_inactivate_recurse: exit end good for #block551 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block2246 +bdrv_inactivate_recurse: entry for #block2106 +bdrv_inactivate_recurse: exit end good for #block2106 +bdrv_inactivate_recurse: exit end good for #block2246 +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: exit 2(-1) for drive-virtio-disk0 + +OK, yeh that's the same symptom I saw - it's that final failure that causes bdrv_inactivate_all to return a failure and fail the source migration. + +Please see Fam's patch series "[PATCH for-2.10 0/4] block: Fix non-shared storage migration" that fixes this issue. + +yes, seems to fix it for me. + +Thanks Christian for filing this; we probably wouldn't have spotted it before the release without it +(which the test Stefan has just added will hopefully cure!). + +Hi Stefan, +I was part of the report around the series in "[PATCH for-2.10 0/4] block: Fix non-shared storage migration", but this is happening on rc3 which contains this. + +AFAIK Fam's series is: +dd7fdaad iotests: Add non-shared storage migration case 192 (Fam) +5f7772c4 block-backend: Defer shared_perm tightening migration completion (Fam) +3dff24f2 nbd: Fix order of bdrv_set_perm and bdrv_invalidate_cache (Kevin) +80adf54e stubs: Add vm state change handler stubs (Fam) + +All these got into v2.10.0-rc3 which these tests are based on already. +IMHO - This is not complete for qemu 2.10 and a regression since 2.9 (well since 2.8 as I haven't tested 2.9 personally). + +Ok, clarified with Stefanha +It has exactly the same title as a series of 18th August which was related to a similar issue. +It is about an hour old now on qemu-devel, quoting + +"This fixes the issue reported as https://bugs.launchpad.net/bugs/1711602 + +Fam Zheng (3): + block-backend: Refactor inactivate check + block-backend: Allow more "can inactivate" cases + mirror: Mark target BB as "force allow inactivate" + +Stefan Hajnoczi (1): + block: Update open_flags after ->inactivate() callback" + + +I'll prep a build with that and test as well + +On 08/23/2017 09:55 AM, ChristianEhrhardt wrote: +> Ok, clarified with Stefanha +> It has exactly the same title as a series of 18th August which was related to a similar issue. +> It is about an hour old now on qemu-devel, quoting +> +> "This fixes the issue reported as +> https://bugs.launchpad.net/bugs/1711602 +> +> Fam Zheng (3): +> block-backend: Refactor inactivate check +> block-backend: Allow more "can inactivate" cases +> mirror: Mark target BB as "force allow inactivate" +> +> Stefan Hajnoczi (1): +> block: Update open_flags after ->inactivate() callback" +> +> +> I'll prep a build with that and test as well + +Here's what is brewing for my pull request, although if you can +successfully test things, I'm happy to add a Tested-by: tag before +actually sending the pull request: + +git fetch git://repo.or.cz/qemu/ericb.git nbd + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +Hmm, +it gets further but can still not complete this kind of migration: + +$ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.30/system + +Source: +2017-08-23 16:49:23.022+0000: initiating migration +Unexpected error in bdrv_check_perm() at /build/qemu-VjSgVJ/qemu-2.10~rc3+dfsg/block.c:1574: +2017-08-23T16:49:23.203181Z qemu-system-x86_64: Block node is read-only +2017-08-23 16:49:23.762+0000: shutting down, reason=crashed + +Target: +2017-08-23T16:49:23.495478Z qemu-system-x86_64: Failed to load virtio_pci/modern_state:modern_state +2017-08-23T16:49:23.495505Z qemu-system-x86_64: Failed to load virtio/extra_state:extra_state +2017-08-23T16:49:23.495510Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2017-08-23T16:49:23.495515Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:06.0/virtio-balloon' +2017-08-23T16:49:23.496071Z qemu-system-x86_64: load of migration failed: Input/output error +2017-08-23 16:49:23.797+0000: shutting down, reason=crashed + +I was to eager to get this close-to-real so I don't have Davids fprintf's applied anymore - I'll build those and then run it in the debugger, but until then what I can see is that behavior slightly changes (worse). +It now crashes the guest on the source as well when aborting the migration. + +I need to debug to confirm, but it seems it still aborts the migration + -> qemu-system-x86_64: load of migration failed: Input/output error +But then can't fall back to the source and crashes at + -> qemu-system-x86_64: Block node is read-only + +That was rc3 +: +- nbd-client-avoid-spurious-qio_channel_yield.patch +- the four patches mentioned in comment #43 + +I could also re-base onto master + pacthes or rc4 if there is one soon. +For now building with Davids debug statements applied again to check if we still abort around that assert. + +I need to recheck with that combo - I'd seen that error but only when I'd commented out 'if (!blk->dev && !blk_name(blk)[0]) {' when debugging earlier. + +Looks good here, just retested: + +here's teh top of my git: + +f89f59fad5119f878aaedf711af90802ddcb99c7 nbd-client: avoid spurious qio_channel_yield() re-entry +cf26039a2b50f078b4ad90b88eea5bb28971c0d8 block: Update open_flags after ->inactivate() callback +8ccc527d84ec9a5052cfae19edbc44abb5ac03ae mirror: Mark target BB as "force allow inactivate" +34c3f17c99a43f261560edbd3da1188dd0c398ab block-backend: Allow more "can inactivate" cases +952ad9fd9dd43e92016d5bfc0ff93bdeaec13bf9 block-backend: Refactor inactivate check +1f296733876434118fd766cfef5eb6f29ecab6a8 Update version for v2.10.0-rc3 release + + +just tested current head - 1eed33994e28d4a0437ba6e944bbc3ec5e4a29a0 - seems to work for me. + +Yeah seems to be slightly different than the former assert. + +2017-08-23 18:41:54.556+0000: initiating migration +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block133 +bdrv_inactivate_recurse: entry for #block329 +bdrv_inactivate_recurse: entry for #block202 +bdrv_inactivate_recurse: exit end good for #block202 +bdrv_inactivate_recurse: exit end good for #block329 +bdrv_inactivate_recurse: entry for #block025 +bdrv_inactivate_recurse: exit end good for #block025 +bdrv_inactivate_recurse: exit end good for #block133 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 +bdrv_inactivate_recurse: entry for #block799 +bdrv_inactivate_recurse: entry for #block626 +bdrv_inactivate_recurse: exit end good for #block626 +bdrv_inactivate_recurse: exit end good for #block799 +bdrv_inactivate_recurse: entry for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block570 +bdrv_inactivate_recurse: entry for #block485 +bdrv_inactivate_recurse: exit end good for #block485 +bdrv_inactivate_recurse: exit end good for #block570 +bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 +bdrv_inactivate_recurse: entry for #block1058 +bdrv_inactivate_recurse: entry for #block920 +bdrv_inactivate_recurse: exit end good for #block920 +bdrv_inactivate_recurse: exit end good for #block1058 +bdrv_inactivate_recurse: entry for drive-virtio-disk0 +Unexpected error in bdrv_check_perm() at /build/qemu-0OVYHF/qemu-2.10~rc3+dfsg/block.c:1574: +2017-08-23T18:41:54.730131Z qemu-system-x86_64: Block node is read-only + +Which is: +1553 /* +1554 * Check whether permissions on this node can be changed in a way that +1555 * @cumulative_perms and @cumulative_shared_perms are the new cumulative +1556 * permissions of all its parents. This involves checking whether all necessary +1557 * permission changes to child nodes can be performed. +1558 * +1559 * A call to this function must always be followed by a call to bdrv_set_perm() +1560 * or bdrv_abort_perm_update(). +1561 */ +1562 static int bdrv_check_perm(BlockDriverState *bs, uint64_t cumulative_perms, +1563 uint64_t cumulative_shared_perms, +1564 GSList *ignore_children, Error **errp) +1565 { +1566 BlockDriver *drv = bs->drv; +1567 BdrvChild *c; +1568 int ret; +1569 +1570 /* Write permissions never work with read-only images */ +1571 if ((cumulative_perms & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED)) && +1572 !bdrv_is_writable(bs)) +1573 { +1574 error_setg(errp, "Block node is read-only"); +1575 return -EPERM; +1576 } + +Adding in debug symbols to see in gdb which device that actually is showed me: +I don't know what you might need so the full struct: + +(gdb) p *bs +$2 = {open_flags = 2050, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = true, + drv = 0x1a67219800 <bdrv_mirror_top>, opaque = 0x0, aio_context = 0x1a684ae0d0, aio_notifiers = {lh_first = 0x1a6a4850e0}, + walking_aio_notifiers = false, filename = "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow", '\000' <repeats 4037 times>, + backing_file = "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow", '\000' <repeats 4037 times>, + backing_format = "qcow2\000\000\000\000\000\000\000\000\000\000", full_open_options = 0x0, + exact_filename = "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow", '\000' <repeats 4037 times>, backing = 0x1a6971a4a0, + file = 0x0, bl = {request_alignment = 1, max_pdiscard = 0, pdiscard_alignment = 0, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 0, + opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0, + supported_zero_flags = 0, node_name = "#block814", '\000' <repeats 22 times>, node_list = {tqe_next = 0x1a684b44d0, tqe_prev = 0x1a6b02e0c0}, + bs_list = {tqe_next = 0x1a6a010030, tqe_prev = 0x1a6ab6bc50}, monitor_list = {tqe_next = 0x0, tqe_prev = 0x0}, refcnt = 3, op_blockers = {{ + lh_first = 0x1a69e18e80}, {lh_first = 0x1a69e18ea0}, {lh_first = 0x1a69e18ec0}, {lh_first = 0x1a69e18ee0}, {lh_first = 0x1a69e18f00}, { + lh_first = 0x0}, {lh_first = 0x1a69e18f40}, {lh_first = 0x1a69e18f60}, {lh_first = 0x1a69e18f80}, {lh_first = 0x1a69e18fa0}, { + lh_first = 0x1a6989be30}, {lh_first = 0x1a69e18fc0}, {lh_first = 0x1a69e18fe0}, {lh_first = 0x1a69352e90}, {lh_first = 0x1a69352eb0}, { + lh_first = 0x1a69352ed0}}, job = 0x1a69e18bf0, inherits_from = 0x0, children = {lh_first = 0x1a6971a4a0}, parents = { + lh_first = 0x1a69e18e00}, options = 0x1a69b636a0, explicit_options = 0x1a69e16bb0, detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, + backing_blocker = 0x1a686e2e00, total_sectors = 16777216, before_write_notifiers = {notifiers = {lh_first = 0x0}}, write_threshold_offset = 0, + write_threshold_notifier = {notify = 0x0, node = {le_next = 0x0, le_prev = 0x0}}, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, + __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 39 times>, __align = 0}, initialized = true}, dirty_bitmaps = {lh_first = 0x0}, wr_highest_offset = { + value = 1190584320}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, wakeup = false, io_plugged = 0, enable_write_cache = 0, + quiesce_counter = 0, write_gen = 2, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, + handoff = 0, sequence = 0, holder = 0x0}, tracked_requests = {lh_first = 0x0}, flush_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x1a69b63680}}, active_flush_req = false, flushed_gen = 2} + +And that effectively is my root disk: + +At least the trivial flag in the struct is "read_only = false". +Also on a FS level it is rw: +-rw------- 1 root root 717160448 Aug 23 18:50 /var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow +(qemu is running privileged in this setup with UID 0, so no reason to mark that as read only IMHO) + +So I checked the full context of the if that leads to the error: + (cumulative_perms & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED)) + 3 (in my case) & ( 0x2 | 0x4) + ok that is a match + +So it goes further to + !bdrv_is_writable(bs) + +Which effectively is: + !bdrv_is_read_only(bs) && !(bs->open_flags & BDRV_O_INACTIVE); + !bs->read_only ! (2050 & 0x800) + !false !(true) + true false + +So the problem is that BDRV_O_INACTIVE is set? +Sorry I don't see why that is so (maybe too late for today). +But I hope that helps in understanding the remaining case. + +I checked against your coommit list and I didn't have the following yet. +cf26039a2b50f078b4ad90b88eea5bb28971c0d8 block: Update open_flags after ->inactivate() callback +I took it now from the PULL 0/6 of Eric that appeared after my last test. +Building with that now to report once again. + +If there is no build hickup that next test should just fit in before I fall asleep. +Hoping for the best to report a tested by in time if possible. + +Yes, with all the series of [1] on top it finally works. +Saw it already being merged on master. +Expecting a late rc4 or early release tag and then wrap all it up. + +Thanks everybody involved! + +[1]: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg04513.html + +This bug was fixed in the package qemu - 1:2.10~rc4+dfsg-0ubuntu1 + +--------------- +qemu (1:2.10~rc4+dfsg-0ubuntu1) artful; urgency=medium + + * Merge with Upstream 2.10-rc4; This fixes a migration issue (LP: #1711602); + Remaining changes: + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-kvm.service: systemd unit to call qemu-kvm-init + - d/qemu-system-common.install: install systemd unit and helper script + - d/qemu-system-common.maintscript: clean old sysv and upstart scripts + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: install /etc/default/qemu-kvm + - Enable nesting by default + - set nested=1 module option on intel. (is default on amd) + - re-load kvm_intel.ko if it was loaded without nested=1 + - d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default + in qemu64 cpu type. + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + - libvirt/qemu user/group support + - qemu-system-common.postinst: remove acl placed by udev, and add udevadm + trigger. + - qemu-system-common.preinst: add kvm group if needed + - Distribution specific machine type + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types to ease future live vm migration. + - d/qemu-system-x86.NEWS Info on fixed machine type defintions + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - let qemu-utils recommend sharutils + - s390x support + - Create qemu-system-s390x package + - Include s390-ccw.img firmware + - Enable numa support for s390x + - ppc64[le] support + - d/qemu-system-ppc.links provide usr/bin/qemu-system-ppc64le symlink + - Enable seccomp for ppc64el + - bump libseccomp-dev dependency, 2.3 is the minimum for ppc64 + - arch aware kvm wrappers + - update VCS-git to match the Artful branch + - disable missing x32 architecture + - d/rules: or32 is now named or1k (since 4a09d0bb) + - d/qemu-system-common.docs: new paths since (ac06724a) + - d/qemu-system-common.install: qmp-commands.txt removed, but replaced + by qapi-schema.json which is already packaged (since 4d8bb958) + - d/p/02_kfreebsd.patch: utimensat is no more optional upstream (Update + to Debian patch to match qemu 2.10) + - s390x package now builds correctly on all architectures (LP 1710695) + * Added changes: + - d/qemu-system-common.docs: adapt new path of live-block-operations.rst + since 8508eee7 + - d/qemu-system-common.docs: adapt q35 config paths since 9ca019c1 + - make nios2/hppa not installed explicitly until further stablized + - d/qemu-guest-agent.install: add the new guest agent reference man page + qemu-ga-ref + - d/qemu-system-common.install: add the now generated qapi/qmp reference + along the qapi intro + - d/not-installed: ignore further generated (since 56e8bdd4) files in + dh_missing that are already provided in other formats qemu-doc, + qemu-qmp-ref,qemu-ga-ref + - d/p/ubuntu/define-ubuntu-machine-types.patch: update to match new + changes in 2.10-rc4 + + -- Christian Ehrhardt <email address hidden> Fri, 25 Aug 2017 07:49:30 +0200 + diff --git a/results/classifier/118/review/1711828 b/results/classifier/118/review/1711828 new file mode 100644 index 000000000..3157054d7 --- /dev/null +++ b/results/classifier/118/review/1711828 @@ -0,0 +1,121 @@ +mistranslation: 0.939 +device: 0.830 +user-level: 0.810 +semantic: 0.808 +architecture: 0.770 +graphic: 0.753 +hypervisor: 0.745 +permissions: 0.738 +performance: 0.731 +PID: 0.725 +assembly: 0.691 +network: 0.669 +ppc: 0.658 +kernel: 0.640 +socket: 0.634 +register: 0.627 +x86: 0.609 +debug: 0.606 +vnc: 0.580 +TCG: 0.576 +files: 0.559 +i386: 0.547 +risc-v: 0.546 +VMM: 0.528 +peripherals: 0.508 +arm: 0.477 +boot: 0.460 +KVM: 0.448 +virtual: 0.359 +-------------------- +x86: 0.945 +i386: 0.373 +user-level: 0.321 +debug: 0.243 +hypervisor: 0.148 +TCG: 0.115 +performance: 0.106 +assembly: 0.086 +network: 0.079 +semantic: 0.052 +PID: 0.044 +files: 0.036 +register: 0.030 +virtual: 0.027 +mistranslation: 0.026 +device: 0.026 +socket: 0.024 +boot: 0.018 +vnc: 0.009 +VMM: 0.007 +architecture: 0.007 +risc-v: 0.007 +peripherals: 0.007 +kernel: 0.007 +arm: 0.005 +permissions: 0.005 +ppc: 0.003 +graphic: 0.002 +KVM: 0.000 + +lock mov non generated #UD + +qemu 2.8.1 debian 9.1 + +Could you please add a proper description to this bug? Please also try first whether your problem also occurs with the latest released version of QEMU (version 2.9 or the 2.10 release candidate), to see whether it has been fixed there already. + + + +sorry i english poor： + + +intel manual say： +The LOCK prefix can be prepended only to the following instructions and only to those forms of the instructions +where the destination operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, +CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG. If the LOCK prefix is used with one of +these instructions and the source operand is a memory operand, an undefined opcode exception (#UD) may be +generated. An undefined opcode exception will also be generated if the LOCK prefix is used with any instruction not +in the above list. The XCHG instruction always asserts the LOCK# signal regardless of the presence or absence of +the LOCK prefix. + + +but qemu NO! +lock mov forms of the instructions non generated #UD exception! +my OS : debian 9.1 +QEMU: qemu 2.8.1 + + + + + + + +At 2017-08-21 12:54:44, "Thomas Huth" <email address hidden> wrote: +>Could you please add a proper description to this bug? Please also try +>first whether your problem also occurs with the latest released version +>of QEMU (version 2.9 or the 2.10 release candidate), to see whether it +>has been fixed there already. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1711828 +> +>Title: +> lock mov non generated #UD +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> qemu 2.8.1 debian 9.1 +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1711828/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1713434 b/results/classifier/118/review/1713434 new file mode 100644 index 000000000..844f5ba61 --- /dev/null +++ b/results/classifier/118/review/1713434 @@ -0,0 +1,534 @@ +register: 0.853 +risc-v: 0.843 +device: 0.820 +permissions: 0.809 +arm: 0.800 +assembly: 0.786 +graphic: 0.780 +performance: 0.767 +user-level: 0.763 +socket: 0.759 +boot: 0.758 +TCG: 0.754 +files: 0.751 +architecture: 0.732 +mistranslation: 0.719 +x86: 0.712 +ppc: 0.687 +semantic: 0.664 +PID: 0.660 +debug: 0.654 +vnc: 0.635 +VMM: 0.621 +KVM: 0.614 +hypervisor: 0.601 +peripherals: 0.595 +kernel: 0.595 +network: 0.536 +virtual: 0.536 +i386: 0.456 +-------------------- +ppc: 0.924 +debug: 0.870 +register: 0.770 +assembly: 0.273 +architecture: 0.086 +performance: 0.080 +TCG: 0.066 +PID: 0.047 +files: 0.041 +kernel: 0.019 +virtual: 0.019 +VMM: 0.008 +KVM: 0.007 +hypervisor: 0.006 +device: 0.005 +user-level: 0.005 +risc-v: 0.005 +semantic: 0.003 +graphic: 0.002 +permissions: 0.002 +boot: 0.001 +socket: 0.001 +peripherals: 0.001 +network: 0.001 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.001 +arm: 0.000 +i386: 0.000 + +prom-env-test test aborted and core dumped + +On ppc64le architecture machine the following test case Aborted and Core dumped. + +# tests/prom-env-test --quiet --keep-going -m=quick --GTestLogFD=6 +** +ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed: (qemu != NULL) +Aborted (core dumped) + +Steps to re-produce: +clone from the git +configure & compile +run the unit tests by 'make check' + +(gdb) bt +#0 0x00003fff9d60eff0 in raise () from /lib64/libc.so.6 +#1 0x00003fff9d61136c in abort () from /lib64/libc.so.6 +#2 0x00003fff9de1aa04 in g_assertion_message () from /lib64/libglib-2.0.so.0 +#3 0x00003fff9de1ab0c in g_assertion_message_expr () from /lib64/libglib-2.0.so.0 +#4 0x000000001000cc30 in qtest_get_arch () at tests/libqtest.c:628 +#5 0x00000000100048f0 in main (argc=5, argv=0x3ffff2145538) at tests/prom-env-test.c:82 +(gdb) i r +r0 0xfa 250 +r1 0x3ffff2144d30 70368510627120 +r2 0x3fff9d7b9900 70367091333376 +r3 0x0 0 +r4 0x12a7 4775 +r5 0x6 6 +r6 0x8 8 +r7 0x1 1 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fff9dfa1950 70367099623760 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x0 0 +r19 0x0 0 +r20 0x0 0 +r21 0x0 0 +r22 0x0 0 +r23 0x0 0 +r24 0x0 0 +r25 0x0 0 +r26 0x0 0 +r27 0x100287f8 268601336 +r28 0x16841b40 377756480 +r29 0x4c 76 +r30 0x3ffff2144de8 70368510627304 +r31 0x6 6 +pc 0x3fff9d60eff0 0x3fff9d60eff0 <raise+96> +msr 0x900000000280f033 10376293541503627315 +cr 0x42000842 1107298370 +lr 0x3fff9d61136c 0x3fff9d61136c <abort+396> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x12a7 4775 +trap 0xc00 3072 + +When running tests directly, you've got to specify the QEMU binary like this: + +QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/prom-env-test --quiet --keep-going -m=quick + +But the abort() is indeed ugly here and I think we should print out a user-friendly error message instead. + +The actual failure was the following + + LINK tests/test-hmp + GTESTER check-qtest-ppc64 +** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +GTester: last random seed: R02Sfb567618f7c703a032934c0c11e263c6 +make: *** [check-qtest-ppc64] Error 1 + +But I was going through found the above was aborting. so reported here. + + +The "ERROR:tests/prom-env-test.c:42:check_guest_memory" error is a timeout error... is it reproducible? Was the host you're testing on very loaded at that point in time? + +Host was not loaded at that time. And can be re-producable all the times + + GTESTER check-qtest-ppc64 +** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +GTester: last random seed: R02S5625099e4ad7700238a4e83dbd6576e0 + +this is with new seed. + + +That works for me - no problems with tests/prom-env-test on a POWER8 little endian system here. What host system are you using? Could you also check what happens if you run QEMU directly like this, and post the console output here: + +ppc64-softmmu/qemu-system-ppc64 -nographic -M pseries,accel=tcg -nodefaults -serial stdio -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr power-off' + + +I am using a Power9 machine. + +# ppc64-softmmu/qemu-system-ppc64 -nographic -M pseries,accel=tcg -nodefaults -serial stdio -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr power-off' + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 24 2017 15:15:46 + FW Version = git-89f519f09bf85091 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /pci@800000020000000 +(!) Executing code specified in nvramrc + SLOF Setup = Hello World! + +Hmm, that looks like -prom-env is working correctly with the pseries machine. I wonder whether the problem is somewhere else... Could you please run "make check-qtest-ppc64 V=1" to see whether it rather fails for the mac99 or g3beige machines? + +TEST: tests/prom-env-test... (pid=9915) + /ppc64/prom-env/mac99: OK + /ppc64/prom-env/g3beige: OK + /ppc64/prom-env/pseries: ** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +FAIL +GTester: last random seed: R02S765f0e192be9c96e793728ecc28d6395 +(pid=10152) +FAIL: tests/prom-env-test + +Weird. I managed to run the test on a POWER9 box today, too, and it works for me: + +TEST: tests/prom-env-test... (pid=18912) + /ppc64/prom-env/mac99: OK + /ppc64/prom-env/g3beige: OK + /ppc64/prom-env/pseries: OK +PASS: tests/prom-env-test + +Which OS and C compiler are you using? + +Also, could you please try to add this patch (to add "-serial /dev/stderr") and then post the console output of the prom-env-test: + +diff --git a/tests/prom-env-test.c b/tests/prom-env-test.c +--- a/tests/prom-env-test.c ++++ b/tests/prom-env-test.c +@@ -51,7 +51,7 @@ static void test_machine(const void *machine) + extra_args = strcmp(machine, "pseries") == 0 ? "-nodefaults" : ""; + + args = g_strdup_printf("-M %s,accel=tcg %s -prom-env 'use-nvramrc?=true' " +- "-prom-env 'nvramrc=%x %x l!' ", ++ "-prom-env 'nvramrc=%x %x l!' -serial /dev/stderr", + (const char *)machine, extra_args, MAGIC, ADDRESS); + + qtest_start(args); + + +Strange, + +# gcc --version +gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) +Copyright (C) 2015 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +OS is RHEL based. +# uname -a +Linux host 4.11.0-26.el7a.ppc64le #1 SMP Wed Aug 23 17:27:28 EDT 2017 ppc64le ppc64le ppc64le GNU/Linux + +TEST: tests/prom-env-test... (pid=6726) + /ppc64/prom-env/mac99: +>> ============================================================= +>> OpenBIOS 1.1 [Jul 13 2017 18:28] +>> Configuration device id QEMU version 1 machine id 3 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,970FX +milliseconds isn't unique. +OK + /ppc64/prom-env/g3beige: +>> ============================================================= +>> OpenBIOS 1.1 [Jul 13 2017 18:28] +>> Configuration device id QEMU version 1 machine id 2 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,750 +milliseconds isn't unique. +OK + /ppc64/prom-env/pseries: + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 24 2017 15:15:46 + FW Version = git-89f519f09bf85091 + Press "s" to enter Open Firmware. + +**500 +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x7c7f1b78 == 0xcafec0de) +FAIL +GTester: last random seed: R02Sf6897626ac2ebaf5edd7aa24cc1999df +(pid=6951) +FAIL: tests/prom-env-test + +Very weird, looks like SLOF crashed at a very early stage here. I've got no further clue how to debug this ... could you maybe try it on another POWER9 host if possible? Or check whether slof.bin accidentially got corrupted (md5sum pc-bios/slof.bin should give you db83598b28052e9c12972d86c37b0c69)? Or maybe you could also ask Nikunj to have a look at this? + +# md5sum ./pc-bios/slof.bin +db83598b28052e9c12972d86c37b0c69 ./pc-bios/slof.bin + +Same as what you mentioned. + +Will try to get a different machine and try. If the problem still persists, I will check with Nikunj. + +Thanks a lot for your time. I have learned many things while interacting with you. + +On other machine with same OS and gcc level, it's working fine. Not getting what went wrong in the machine where I can re-produce this issue. +I guess this bug can be closed. Thank you. + + /ppc64/prom-env/pseries: + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 24 2017 15:15:46 + FW Version = git-89f519f09bf85091 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /pci@800000020000000 +(!) Executing code specified in nvramrc + SLOF Setup = OK +PASS: tests/prom-env-test + + + +OK, thanks for testing! Anyway, I'll keep the bug opened to track the original issue that you've mentioned in the description ("ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed") here. + +Similar failure seen with the following test too. + +# make check-qtest-sparc64 V=1 +(cd /home/nasastry/qemu; printf '#define QEMU_PKGVERSION '; if test -n ""; then printf '""\n'; else if test -d .git; then printf '" ('; git describe --match 'v*' 2>/dev/null | tr -d '\n'; if ! git diff-index --quiet HEAD &>/dev/null; then printf -- '-dirty'; fi; printf ')"\n'; else printf '""\n'; fi; fi) > qemu-version.h.tmp +if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi +make -C /home/nasastry/qemu/capstone CAPSTONE_SHARED=no BUILDDIR="/home/nasastry/qemu/capstone" CC="cc" AR="ar" LD="ld" CFLAGS="-fprofile-arcs -ftest-coverage -g -g -I/usr/include/pixman-1 -DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DNCURSES_WIDECHAR -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/include/libpng15 -I/home/nasastry/qemu/capstone/include -I/home/nasastry/qemu/tests -DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86" BUILD_DIR=/home/nasastry/qemu /home/nasastry/qemu/capstone/libcapstone.a +make[1]: Entering directory `/home/nasastry/qemu/capstone' +make[1]: `/home/nasastry/qemu/capstone/libcapstone.a' is up to date. +make[1]: Leaving directory `/home/nasastry/qemu/capstone' +make BUILD_DIR=/home/nasastry/qemu -C sparc64-softmmu V="1" TARGET_DIR="sparc64-softmmu/" all +make[1]: Entering directory `/home/nasastry/qemu/sparc64-softmmu' +make[1]: Leaving directory `/home/nasastry/qemu/sparc64-softmmu' +QTEST_QEMU_BINARY=sparc64-softmmu/qemu-system-sparc64 QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} gtester -k --verbose -m=quick tests/endianness-test tests/prom-env-test tests/qmp-test tests/device-introspect-test tests/qom-test tests/test-hmp +TEST: tests/endianness-test... (pid=72117) + /sparc64/endianness/sun4u: OK + /sparc64/endianness/split/sun4u: OK + /sparc64/endianness/combine/sun4u: OK +PASS: tests/endianness-test +TEST: tests/prom-env-test... (pid=72128) + /sparc64/prom-env/sun4u: ** +ERROR:tests/prom-env-test.c:42:check_guest_memory: assertion failed (signature == MAGIC): (0x00000000 == 0xcafec0de) +FAIL +GTester: last random seed: R02S54a8565ad2895d49d8d1b0dc99da7044 +(pid=74068) +FAIL: tests/prom-env-test +TEST: tests/qmp-test... (pid=74069) + /sparc64/qmp/protocol: OK + /sparc64/qmp/qom-list-types: OK + /sparc64/qmp/query-acpi-ospm-status: OK + /sparc64/qmp/query-balloon: OK + /sparc64/qmp/query-block: OK + /sparc64/qmp/query-block-jobs: OK + /sparc64/qmp/query-blockstats: OK + /sparc64/qmp/query-chardev: OK + /sparc64/qmp/query-chardev-backends: OK + /sparc64/qmp/query-command-line-options: OK + /sparc64/qmp/query-commands: OK + /sparc64/qmp/query-cpus: OK + /sparc64/qmp/query-dump: OK + /sparc64/qmp/query-dump-guest-memory-capability: OK + /sparc64/qmp/query-events: OK + /sparc64/qmp/query-fdsets: OK + /sparc64/qmp/query-hotpluggable-cpus: OK + /sparc64/qmp/query-iothreads: OK + /sparc64/qmp/query-kvm: OK + /sparc64/qmp/query-machines: OK + /sparc64/qmp/query-memdev: OK + /sparc64/qmp/query-memory-devices: OK + /sparc64/qmp/query-memory-size-summary: OK + /sparc64/qmp/query-mice: OK + /sparc64/qmp/query-migrate: OK + /sparc64/qmp/query-migrate-cache-size: OK + /sparc64/qmp/query-migrate-capabilities: OK + /sparc64/qmp/query-migrate-parameters: OK + /sparc64/qmp/query-name: OK + /sparc64/qmp/query-named-block-nodes: OK + /sparc64/qmp/query-qmp-schema: OK + /sparc64/qmp/query-rx-filter: OK + /sparc64/qmp/query-spice: OK + /sparc64/qmp/query-status: OK + /sparc64/qmp/query-target: OK + /sparc64/qmp/query-tpm: OK + /sparc64/qmp/query-tpm-models: OK + /sparc64/qmp/query-tpm-types: OK + /sparc64/qmp/query-uuid: OK + /sparc64/qmp/query-version: OK + /sparc64/qmp/query-vm-generation-id: OK + /sparc64/qmp/query-vnc: OK + /sparc64/qmp/query-vnc-servers: OK + /sparc64/qmp/query-xen-replication-status: OK +PASS: tests/qmp-test +TEST: tests/device-introspect-test... (pid=74165) + /sparc64/device/introspect/list: OK + /sparc64/device/introspect/list-fields: OK + /sparc64/device/introspect/none: OK + /sparc64/device/introspect/abstract: OK + /sparc64/device/introspect/concrete: OK + /sparc64/device/introspect/abstract-interfaces: OK +PASS: tests/device-introspect-test +TEST: tests/qom-test... (pid=74181) + /sparc64/qom/sun4v: OK + /sparc64/qom/none: OK + /sparc64/qom/sun4u: OK + /sparc64/qom/niagara: OK +PASS: tests/qom-test +TEST: tests/test-hmp... (pid=74199) + /sparc64/hmp/sun4v: OK + /sparc64/hmp/none: OK + /sparc64/hmp/sun4u: OK + /sparc64/hmp/niagara: OK + /sparc64/hmp/none+2MB: OK +PASS: tests/test-hmp +make: *** [check-qtest-sparc64] Error 1 + +Is that 100% reproducible? Which version of QEMU did you use here? And which host are you using, POWER9 again? The very latest git master branch is using a timeout of 10 minutes now, so that should be sufficient for all cases... + +Could you please try to run this manually: + +qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' + +... and then paste the output here? + +Git head is at 299d1ea9bb56bd9f45f905125489bdd7d543a1aa +latest today + +100% re-producible. This is different & working Power9 machine than the other day. + +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Unhandled Exception 0x0000000000000034 +PC = 0x00000000ffd0f704 NPC = 0x00000000ffd0f708 +Stopping execution + +and hung here. Not responding to ctrl+c or ctrl+z. + + + + + +Here is the md5sum of openbios-sparc64 + +# md5sum ./pc-bios/openbios-sparc64 +15418a4c9429d9ee9c637701b94c7ffb ./pc-bios/openbios-sparc64 + +> Could you please check with the QEMU 2.10 release to see whether this is a regression or whether it was already failing there? +Sure, I will update here. Most probably tomorrow. + +> I don't have access to POWER9 anymore, so I can't check this right now +No issues, I can check. + +> To quit QEMU, you've got to press "CTRL-a c" and then type "quit" at the monitor prompt. +Thank you. I am learning new things along with raising bugs :-) + +This test case was working till 2.10.0 and got broken in 2.10.1 + +I checked with 2.9.1, 2.10.0-rc2, 2.10.0-rc3, 2.10.0-rc4, 2.10.0 + +Working scenario: +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Hello World! +Welcome to OpenBIOS v1.1 built on Jul 13 2017 18:27 + Type 'help' for detailed information +Trying disk:a... +No valid state has been set by load or init-program + +0 > QEMU 2.10.0 monitor - type 'help' for more information +(qemu) quit + +The above problem is getting re-producible only with configure option "--enable-crypto-afalg" This got introduced in between 2.9.1 and 2.10.0. I will bisect it and update. + +When I tried earlier with 2.9.1 it complained saying "--enable-crypto-afalg" option is not available so I did with out it and continued that's the reason why it worked with 2.10.0 and till rc4. +Tested 2.10.1 with configure option "--enable-crypto-afalg" so it failed. + +So this information made me to say it broke in 2.10.1. + +When I disable this option "crypto-afalg" in 2.10.1 it's working fine and same with latest qemu (git head is at a4f0537db0cd68fa2da097995f6ec00747ca453c) + +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Hello World! +Welcome to OpenBIOS v1.1 built on Oct 19 2017 06:59 + Type 'help' for detailed information +Trying disk:a... +No valid state has been set by load or init-program + +0 > QEMU 2.10.50 monitor - type 'help' for more information +(qemu) quit + + + +After talking to Mark Cave-Ayland over e-mail, to make sure I have the proper versions of OpenBIOS binaries - removed the existing git tree and with a fresh clone not seeing the 'qemu-system-sparc64' related crash. +Before cleanup I was seeing the crash all the times. +Thanks!! + +Some times it's still puzzling, when I got the clean git tree still seeing crash with correct OpenBIOS file. + +[root@zzfp365-lp1 test]# git clone git://git.qemu.org/qemu.git +Cloning into 'qemu'... +remote: Counting objects: 349636, done. +remote: Compressing objects: 100% (66763/66763), done. +remote: Total 349636 (delta 284434), reused 346628 (delta 282016) +Receiving objects: 100% (349636/349636), 112.12 MiB | 1.28 MiB/s, done. +Resolving deltas: 100% (284434/284434), done. + +[root@zzfp365-lp1 qemu]# md5sum ./pc-bios/openbios-sparc64 +15418a4c9429d9ee9c637701b94c7ffb ./pc-bios/openbios-sparc64 + +[root@zzfp365-lp1 qemu]# git pull +Already up-to-date. + +did configure: +./configure --enable-attr --enable-bsd-user --enable-cap-ng --enable-coroutine-pool --enable-crypto-afalg --enable-curl --enable-curses --enable-debug --enable-debug-info --enable-debug-tcg --enable-fdt --enable-gcrypt --enable-gnutls --enable-gprof --enable-gtk --enable-guest-agent --enable-kvm --enable-libiscsi --enable-libssh2 --enable-linux-aio --enable-linux-user --enable-live-block-migration --enable-modules --enable-numa --enable-pie --enable-profiler --enable-qom-cast-debug --enable-rbd --enable-replication --enable-seccomp --enable-smartcard --enable-stack-protector --enable-system --enable-tcg --enable-tcg-interpreter --enable-tools --enable-tpm --enable-trace-backend=ftrace --enable-user --enable-vhost-net --enable-vhost-scsi --enable-vhost-user --enable-vhost-vsock --enable-virtfs --enable-vnc --enable-tpm --enable-vnc-png --enable-vnc-sasl --enable-werror --enable-xfsctl --enable-gcov --enable-debug-stack-usage + +make -j 32 + +# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Unhandled Exception 0x0000000000000034 +PC = 0x00000000ffd0f704 NPC = 0x00000000ffd0f708 +Stopping execution +QEMU 2.10.90 monitor - type 'help' for more information +(qemu) quit + +# md5sum ./pc-bios/openbios-sparc64 +15418a4c9429d9ee9c637701b94c7ffb ./pc-bios/openbios-sparc64 + +git head is at b0fbe46ad82982b289a44ee2495b59b0bad8a842 + +Thomas thanks for your hint about the configuration option named "--enable-tcg-interpreter". By removing it the test case started working fine. + +[root@zzfp365-lp1 qemu]# ./sparc64-softmmu/qemu-system-sparc64 -nographic -M sun4u -prom-env 'use-nvramrc?=true' -prom-env 'nvramrc=." Hello World!" cr' +OpenBIOS for Sparc64 +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Hello World! +Welcome to OpenBIOS v1.1 built on Oct 19 2017 06:59 + Type 'help' for detailed information +Trying disk:a... +No valid state has been set by load or init-program + +0 > QEMU 2.10.90 monitor - type 'help' for more information +(qemu) quit + +OK, so this was "only" the TCG-interpreter that was causing the sparc64 problem here. Since there are known issues with the TCG-interpreter on certain architectures, this is not really related to the prom-env-test. And since the fix for the original "ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed" problem has been committed already ("commit db221e66d8117f8"), I'm marking the status of this bug now accordingly. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=db221e66d8117f810c804 + diff --git a/results/classifier/118/review/1713516 b/results/classifier/118/review/1713516 new file mode 100644 index 000000000..a4a377beb --- /dev/null +++ b/results/classifier/118/review/1713516 @@ -0,0 +1,149 @@ +TCG: 0.833 +x86: 0.809 +register: 0.805 +device: 0.790 +hypervisor: 0.789 +user-level: 0.785 +graphic: 0.785 +virtual: 0.779 +risc-v: 0.758 +permissions: 0.751 +ppc: 0.751 +semantic: 0.750 +vnc: 0.746 +VMM: 0.744 +network: 0.742 +arm: 0.740 +debug: 0.735 +performance: 0.723 +files: 0.705 +architecture: 0.694 +peripherals: 0.690 +mistranslation: 0.686 +KVM: 0.678 +boot: 0.667 +socket: 0.665 +assembly: 0.660 +PID: 0.607 +kernel: 0.539 +i386: 0.521 +-------------------- +debug: 0.909 +virtual: 0.508 +PID: 0.444 +ppc: 0.428 +hypervisor: 0.069 +TCG: 0.026 +files: 0.026 +KVM: 0.020 +device: 0.014 +network: 0.012 +performance: 0.011 +register: 0.010 +semantic: 0.008 +socket: 0.007 +vnc: 0.006 +assembly: 0.006 +user-level: 0.005 +architecture: 0.003 +VMM: 0.002 +kernel: 0.002 +boot: 0.002 +graphic: 0.001 +peripherals: 0.001 +risc-v: 0.001 +permissions: 0.001 +mistranslation: 0.000 +x86: 0.000 +arm: 0.000 +i386: 0.000 + +qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to smp threads, cores + +After fixing other bug, +https://bugs.launchpad.net/qemu/+bug/1713408 +with the proposed patch +http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05357.html + +When tried smp core and thread as negative numbers seeing the following similar error. There is a need to fix for the following. + +Instead of fixing it for every variable/argument. Is there a common place to fix all of these issues? + + +cloned today's git (i.e. 28th Aug 2017) + +# ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm,kvm-type=HV -m size=200g -device virtio-blk-pci,drive=rootdisk -drive file=/home/nasastry/avocado-fvt-wrapper/data/avocado-vt/images/pegas-1.0-ppc64le.qcow2,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -device nec-usb-xhci -smp 8,cores=-1,threads=-1,maxcpus=12 + +(process:27477): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes +Trace/breakpoint trap + +[New Thread 0x3fffb63deb60 (LWP 27731)] +[New Thread 0x3fffb5aceb60 (LWP 27734)] + +(process:27726): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libgcc-4.8.5-16.el7.ppc64le libstdc++-4.8.5-16.el7.ppc64le ncurses-libs-5.9-13.20130511.el7.ppc64le nss-3.28.4-8.el7.ppc64le nss-softokn-freebl-3.28.3-6.el7.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le +(gdb) bt +#0 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +#1 0x00003fffb796be9c in _g_log_abort () from /lib64/libglib-2.0.so.0 +#2 0x00003fffb796d4c4 in g_log_default_handler () from /lib64/libglib-2.0.so.0 +#3 0x00003fffb796d86c in g_logv () from /lib64/libglib-2.0.so.0 +#4 0x00003fffb796db00 in g_log () from /lib64/libglib-2.0.so.0 +#5 0x00003fffb796b694 in g_malloc0 () from /lib64/libglib-2.0.so.0 +#6 0x000000001018fa84 in spapr_possible_cpu_arch_ids (machine=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:3322 +#7 0x000000001018b444 in spapr_init_cpus (spapr=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2096 +#8 0x000000001018bc6c in ppc_spapr_init (machine=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2275 +#9 0x000000001041ca80 in machine_run_board_init (machine=0x111651e0) at hw/core/machine.c:760 +#10 0x0000000010377284 in main (argc=22, argv=0x3ffffffff128, envp=0x3ffffffff1e0) at vl.c:4638 +(gdb) i r +r0 0xfa 250 +r1 0x3fffffffe470 70368744170608 +r2 0x3fffb7608100 70367525765376 +r3 0x0 0 +r4 0x6c4e 27726 +r5 0x5 5 +r6 0x0 0 +r7 0x3fffa8000020 70367267782688 +r8 0x6c4e 27726 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fffb64fccb0 70367507893424 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x1 1 +r19 0x0 0 +r20 0x3fffb796d3f0 70367529325552 +r21 0x0 0 +r22 0x20000000 536870912 +r23 0x1 1 +r24 0x3fffb7a61498 70367530325144 +r25 0x3fffb7a614e8 70367530325224 +r26 0x3fffb7a61488 70367530325128 +r27 0x3fffa80008c0 70367267784896 +r28 0x3fffb79cd2a8 70367529718440 +r29 0x3fffb79cd2a8 70367529718440 +r30 0xffffffffffffffff 18446744073709551615 +r31 0x1 1 +pc 0x3fffb75e5408 0x3fffb75e5408 <raise+56> +msr 0x900000000000d033 10376293541461676083 +cr 0x42244842 1109674050 +lr 0x3fffb796be9c 0x3fffb796be9c <_g_log_abort+60> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x6c4e 27726 +trap 0xc00 3072 + +I've confirmed with Seeteena and this bug was fixed by commit https://git.qemu.org/?p=qemu.git;a=commit;h=c0dd10991903c552811d8cbe9231055b1b3a7ebd + +commit c0dd10991903c552811d8cbe9231055b1b3a7ebd +Author: Seeteena Thoufeek <email address hidden> +Date: Mon Sep 4 13:13:51 2017 +0530 + + vl: exit if maxcpus is negative + diff --git a/results/classifier/118/review/1715296 b/results/classifier/118/review/1715296 new file mode 100644 index 000000000..5c5f659bc --- /dev/null +++ b/results/classifier/118/review/1715296 @@ -0,0 +1,82 @@ +mistranslation: 0.925 +semantic: 0.735 +device: 0.726 +network: 0.676 +peripherals: 0.655 +performance: 0.589 +ppc: 0.573 +socket: 0.518 +architecture: 0.495 +graphic: 0.468 +vnc: 0.466 +register: 0.405 +risc-v: 0.357 +kernel: 0.351 +hypervisor: 0.343 +files: 0.332 +i386: 0.327 +virtual: 0.317 +x86: 0.302 +user-level: 0.302 +PID: 0.300 +permissions: 0.284 +debug: 0.278 +boot: 0.258 +arm: 0.237 +VMM: 0.199 +TCG: 0.198 +KVM: 0.141 +assembly: 0.118 +-------------------- +hypervisor: 0.200 +x86: 0.148 +debug: 0.073 +kernel: 0.048 +TCG: 0.041 +files: 0.038 +device: 0.020 +i386: 0.018 +PID: 0.013 +register: 0.013 +network: 0.009 +peripherals: 0.008 +virtual: 0.007 +user-level: 0.006 +socket: 0.005 +arm: 0.005 +semantic: 0.003 +assembly: 0.003 +architecture: 0.002 +performance: 0.002 +ppc: 0.002 +boot: 0.001 +mistranslation: 0.001 +graphic: 0.001 +VMM: 0.001 +permissions: 0.001 +KVM: 0.001 +vnc: 0.001 +risc-v: 0.001 + +qemu: invalid serial port configuration + +The tty_serial_init() function sets the port c_oflags as follows: +tty.c_oflag |= OPOST not clearing ONLCR, ONLRET and others. +The result is that the postprocess output is enabled and host translates 0xa (LF) to 0xd 0xa (CR LF) which breaks the binary transmissions on serial port even if you set the port to raw mode (no matters if on host and/or guest). +The issue has been reported 11 years ago on qemu-devel mailing list: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +There was also a FreeBSD patch including the fix: +https://lists.freebsd.org/pipermail/freebsd-ports/2006-October/036390.html + +I think the correct port configuration is: +tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON|IMAXBEL); +tty.c_oflag &= ~OPOST; + +In such case the host will perform no output processing and will pass the data as is. +And the guest will be able to configure input/output processing exactly as it wants. + +I believe the following bug is related: https://bugs.launchpad.net/qemu/+bug/1407813 + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/118/review/1716028 b/results/classifier/118/review/1716028 new file mode 100644 index 000000000..63277a8b6 --- /dev/null +++ b/results/classifier/118/review/1716028 @@ -0,0 +1,589 @@ +register: 0.917 +permissions: 0.906 +files: 0.899 +assembly: 0.896 +peripherals: 0.877 +device: 0.874 +architecture: 0.867 +graphic: 0.864 +virtual: 0.862 +boot: 0.860 +kernel: 0.850 +PID: 0.845 +TCG: 0.841 +debug: 0.834 +arm: 0.833 +KVM: 0.829 +network: 0.818 +socket: 0.810 +vnc: 0.810 +semantic: 0.805 +hypervisor: 0.785 +performance: 0.778 +risc-v: 0.772 +ppc: 0.769 +user-level: 0.763 +x86: 0.666 +VMM: 0.661 +mistranslation: 0.440 +i386: 0.294 +-------------------- +x86: 0.986 +hypervisor: 0.800 +kernel: 0.329 +TCG: 0.184 +virtual: 0.066 +user-level: 0.059 +debug: 0.034 +files: 0.032 +register: 0.021 +PID: 0.020 +ppc: 0.015 +semantic: 0.015 +risc-v: 0.009 +i386: 0.007 +VMM: 0.004 +boot: 0.003 +socket: 0.003 +permissions: 0.003 +network: 0.002 +architecture: 0.002 +performance: 0.002 +KVM: 0.002 +graphic: 0.002 +assembly: 0.001 +device: 0.001 +vnc: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 + +qemu 2.10 locks images with no feature flag + +1) % lsb_release -rd +Description: Ubuntu Artful Aardvark (development branch) +Release: 17.10 + +2) % apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.10~rc3+dfsg-0ubuntu1 + Candidate: 1:2.10+dfsg-0ubuntu1 + Version table: + 1:2.10+dfsg-0ubuntu1 500 + 500 http://archive.ubuntu.com//ubuntu devel/main amd64 Packages + *** 1:2.10~rc3+dfsg-0ubuntu1 100 + 100 /var/lib/dpkg/status + +3) qemu locks image files with no way to discover this feature nor how to disable it + +4) qemu provides a way to query if it supports image locking, and what the default value is, and how to disable the locking via cli + +qemu 2.10 now will lock image files and warn if an image is currently locked. This prevent qemu from running (and possibly corrupting said image). + +However, qemu does not provide any way to determine if a qemu binary actually has this capability. Normally behavior changing features are exposed via some change to the qemu help menu or QMP/QAPI output of capabilities. + +I believe this slipped through since libvirt already does image locking, but direct cli users will be caught by this change. + +In particular, we have a use-case where we simulate multipath disks by creating to disks which point to the same file which now breaks without adding the 'file.locking=off' to the -drive parameters; which is also completely undocumented and unexposed. + +Some parts of the cli like -device allow querying of settable options (qemu-system-x86 -device scsi_hd,?) but nothing equivalent exists for -drive parameters. + +ProblemType: Bug +DistroRelease: Ubuntu 17.10 +Package: qemu-system-x86 1:2.10~rc3+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5 +Uname: Linux 4.12.0-11-generic x86_64 +NonfreeKernelModules: zfs zunicode zavl zcommon znvpair +ApportVersion: 2.20.6-0ubuntu7 +Architecture: amd64 +Date: Fri Sep 8 12:56:53 2017 +JournalErrors: + Hint: You are currently not seeing messages from other users and the system. + Users in groups 'adm', 'systemd-journal' can see all messages. + Pass -q to turn off this notice. + -- Logs begin at Mon 2017-01-30 11:56:02 CST, end at Fri 2017-09-08 12:56:46 CDT. -- + -- No entries -- +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +MachineType: HP ProLiant DL360 Gen9 +ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.12.0-11-generic root=UUID=45354276-e0c0-4bf6-9083-f130b89411cc ro --- console=ttyS1,115200 +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) +dmi.bios.date: 03/05/2015 +dmi.bios.vendor: HP +dmi.bios.version: P89 +dmi.chassis.type: 23 +dmi.chassis.vendor: HP +dmi.modalias: dmi:bvnHP:bvrP89:bd03/05/2015:svnHP:pnProLiantDL360Gen9:pvr:cvnHP:ct23:cvr: +dmi.product.family: ProLiant +dmi.product.name: ProLiant DL360 Gen9 +dmi.sys.vendor: HP + + + +Thanks Ryan for filing this bug, as I said in IRC all the file locking is rather new and I think this is for upstream qemu to address. +Might just be a missed use case for them as well. + +I'll be adding an upstream qemu task to get their attention. +@Rayn - It would be nice if - from the multipath tests - you could copy in here a commandline that worked before but fails now. + +Added a qemu task, this seems to be a use case affected by the file locking. +In particular a (formerly working) case for multipath tests that use the same image files multiple times intentionally. + +So far the workaround is to set file.locking=off for all these, which might be just the right thing to do. +But then as outlined by the reporter there currently is no way to query if file locking is supported, nor if it is the current default - so at least adding that might be required to be added in qemu. + +The correct way to query whether file locking is supported is 'query-qmp-schema', which will expose the 'locking' option for the 'file' branch of the 'blockdev-add' command then. + +As a first comment, in your setup, completely disabling file locking is probably a too big hammer. It is preferable to just allow multiple writers on the same image by setting share-rw=on for the block device (e.g. '-device virtio-blk-pci,drive=foo,share-rw=on'). This will allow all guest devices to share the same image, but will still protect the image against other users like an incorrect qemu-img invocation while the VM is running. + +However, note that opening the same image file twice is not the best approach to the problem anyway. This happens to work with raw images (except for the locking), but it would cause corruption for any other image format. + +The better solution (though it may require more changes to your management application) is to open the image once and assign a node-name to it, and then let two guest devices point to the same node. Like above, this requires that share-rw=on be set for guest devices, but it will also work with non-raw image formats because the image file is now opened only once and the sharing is done internally in qemu. + +An example command line fragment might look like this: + + -blockdev node-name=disk,driver=file,filename=hd.img + -device virtio-blk,drive=disk,share-rw=on + -device virtio-blk,drive=disk,share-rw=on + +Technically, you can also keep using -drive instead of -blockdev, but it will result in a mixed state of modern node-name based block device management and the traditional drive based configuration, which might be confusing at times. + +Kevin, + +Thanks for the information. A couple of points for feedback: + +1) there doesn't appear to be a way to run qmp query-schema without spawning a qemu instance in -qmp mode and having a second client issue the query-schema; certainly a qemu-system-$arch -qmp-schema would be quite useful when examining feature availability. While I know the QMP/QAPI introspection is where most of the work has gone to describing how to interact with qemu it's quite cumbersome at best: + +searching for blockdev-add, find arg-type: 48, read arg-type-48, find list of 'variants', know that locking feature is part of 'file', find type: 207, see member 'locking' in list[A], which is of type 296, find type: 296, which is an enum of 'on', 'off', 'auto' + +A. Interesting enough, qapi says the default is None, however qemu certainly locks files by default which would seem to imply a mismatch between qapi defaults and qemu behavior. + +That's pretty heavy; Maybe that warning message qemu prints could provide some hints as to what a user could do (or refer to a manpage on locking?). + +2) share-rw appears to be a blockdev parameter (I see it available via most block devices via qemu-system-$arch -device {scsi-hd,ide-hd,virtio-blk}? However there is no equivalent -blockdev for dumping the default options that a -blockdev parameter takes. The qmp-schema also does not include any information about 'share-rw' w.r.t what values are available that I could find after dumping the schema. + +Thanks smoser: + +#!/bin/sh +qemu-system-x86_64 -S -nodefaults -nographic \ + -serial none -monitor none -qmp stdio <<EOF | +{ "execute": "qmp_capabilities" } +{ "execute": "query-qmp-schema" } +{ "execute": "quit" } +EOF + python3 -c ' +import json, sys +data = json.loads(sys.stdin.read().splitlines()[2]) +print(json.dumps(data, indent=1, sort_keys=True, + separators=(",", ": ")))' + + + + + + + +In our multipath case, the initial open succeeds (it's not locked by anything else) and the second lock attempt fails, however, IIUC the fcntl structure[1] includes the locking pid, which should be our invocation of QEMU; + +Can we not check if the locking pid matches the current pid and not fail? This appears to be the original goal of protecting locked images from being manipulated by external processes. + + + +Having a single QEMU process open the same qcow2 file twice is just as dangerous as having two separate QEMU processes open the same qcow2 file concurrently. In both cases you have qcow2 state cached in a BlockDriverState and nothing is able to invalidate the cache in the other BlockDriverState. So short-circuiting locking if the current pid matches would be wrong. + +Kevin, +Thanks for the suggestion of share-rw=on. I figured I'd try to change our 'xkvm' wrapper around qemu to use that. + +Unfortunately, it looks like , at least in our version of qemu (QEMU emulator +version 2.10.0(Debian 1:2.10+dfsg-0ubuntu1)), that this does not work +with the -drive path. + +$ qemu-img create -f qcow2 disk1.img 1G +$ qemu-system-x86_64 \ + -device virtio-net-pci,netdev=net00 \ + -netdev type=user,id=net00 \ + -drive id=drive01,file=disk1.img,format=qcow2,share-rw=on \ + -device drive=drive01,serial=sn-drive01,driver=virtio-blk,index=1 \ + -device drive=drive01,serial=sn-drive01,driver=virtio-blk,index=2 +qemu-system-x86_64: -drive id=drive01,file=disk1.img,format=qcow2,share-rw=on: Block format 'qcow2' does not support the option 'share-rw' + +I had thought you were suggesting the above, right? + + +The share-rw=on option belongs to -device, not to -drive/-blockdev. + +Your example does work (using -blockdev), but I can't get it to work with +-drive. + +$ qemu-system-x86_64 \ + -drive id=d01,file=disk1.img,format=qcow2 \ + -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on \ + -device drive=d01,serial=s01,driver=virtio-blk,index=2,share-rw=on +warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +qemu-system-x86_64: -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on: Drive 'd01' is already in use because it has been automatically connected to another device (did you need 'if=none' in the drive options?) + + +## ok, fix that error, add 'if=none' to the -drive. + +$ qemu-system-x86_64 \ + -drive id=d01,file=disk1.img,format=qcow2,if=none \ + -device virtio-blk,drive=d01,serial=s01,index=1,share-rw=on \ + -device virtio-blk,drive=d01,serial=s01,index=2,share-rw=on +qemu-system-x86_64: -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on: Property '.index' not found + +## ok, index belongs on the -drive (which I should have known from +## the past, but which seems not the right place). Try that anyway. + +$ qemu-system-x86_64 \ + -drive id=d01,file=disk1.img,format=qcow2,if=none,index=1 \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on +qemu-system-x86_64: -device drive=d01,serial=s01,driver=virtio-blk,share-rw=on: Drive 'd01' is already in use by another device + +## Huh? Isn't that what I said to explicitly allow with share-rw=on? + +Note that I've also tried with 'format=raw'. Is there something I'm +missing to try to use -drive and -device ? + +Lastly (if you're still reading), how do you specify the format of +the file to -blockdev ? adding 'format=qcow2' makes qemu complain that +"'format' is unexpected". + +Thanks for your time. + + +I see the answer to my question above. 'format' is now driver=qcow2. + + +The important difference between your -drive command line and my -blockdev example is that I used the node-name to reference the image. You can specify a node-name with -drive, too (having both id and node-name is one of the main things that I meant what I said mixing both styles can be confusing). + +I also don't think that index=1 does anything useful when used with if=none, so you can leave that out. + +Putting everything together, we get this: + +$ qemu-system-x86_64 \ + -drive node-name=d01,file=disk1.img,format=qcow2,if=none \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on \ + -device virtio-blk,drive=d01,serial=s01,share-rw=on + +Kevin, +thanks again. You've provided enough support for me at this point. I had looked at trying to coalesce multiple -drive values into a single one, and that can definitely be made to work with the newer qemu, but i'm not sure I can make it work with older. + +the goal there would be to do something like: +$ qemu-system-x86_64 \ + -drive id=d01,file.filename=disk1.img,format=qcow2,if=none -\ + -device virtio-blk,drive=d01,serial=s01 \ + -device virtio-blk,drive=d01,serial=s02 + +on newer qemu, that works if i change 'id=' to 'node-name', but on older qemu I can't convince it to let me have 1 drive associated to multiple -device. + +What we ended up doing is at + https://code.launchpad.net/~smoser/curtin/trunk.lp1716028-hack-file-locking-in-qemu/+merge/330456 + + + +Note that 'share-rw' was introduced earlier (commit dabd18f6, qemu 2.9) than 'locking' (commit 16b48d5d, qemu 2.10), so if qemu 2.9 is relevant for you, your hacky check doesn't work. + +We had a discussion today on how to workaround if you drive qmeu via libvirt. +While discussions often and up at the correctness of such setups they exists, I think it is worth to document until libvirt supports that officially. + +TL:DR: +- no native libvirt feature yet +- discussions if <shareable/> should set it +- workaround available via cmdline + +Details on the workaround: +- To use the workaround you have to check your log usually in /var/log/libvirt/qemu/<guestname>.log +- Get the id of the device that matters to you +- then use [1] to tweak qemu cmdline +- example is from [2] to [3] + +[1]: http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html +[2]: https://gist.github.com/anonymous/a2ce3cbf7878995537212f0dafd06d99 +[3]: https://gist.github.com/anonymous/07a357af9e34172b60c83d410fe63fdd + +Note: Depending on the case you might also get lucky with "shareable" and/or "readonly" disk attributes. + + +Umm, the latter is the official way to go, but only in latter libvirt versions. +https://libvirt.org/git/?p=libvirt.git;a=commit;h=28907b0043fbf71085a798372ab9c816ba043b93 + +I'm adding a libvirt bug task for the bionic merge to pick that up "explicitly" + +Also on the qemu side this is "works as intended" and workarounds are documented in this bug. +So we should set that bug status as well - looking back given it was mostly a discussion I guess "opinion" is the best close status in this case. + +I've taked this qemu-file-locking just so we can group/easily find other bugs that have this tag. +link to search for all bugs with that tag is: https://goo.gl/W2aT2T + +or the longer form: +https://bugs.launchpad.net/bugs/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.tag=qemu-file-locking + + + +Libvirt will make this "easier" to be avoided by +commit 28907b0043fbf71085a798372ab9c816ba043b93 +Author: Peter Krempa <email address hidden> +Date: Wed Nov 15 15:21:14 2017 +0100 + + qemu: command: Mark <shared/> disks as such in qemu + + Qemu has now an internal mechanism for locking images to fix specific + cases of disk corruption. This requires libvirt to mark the image as + shared so that qemu lifts certain restrictions. + + Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1378242 + +commit 860a3c4bea1d24773d8a495f213d5de3ac48a462 +Author: Peter Krempa <email address hidden> +Date: Wed Nov 15 15:02:58 2017 +0100 + + qemu: caps: Add capability for 'share-rw' disk option + + 'share-rw' for the disk device configures qemu to allow concurrent + access to the backing storage. + + The capability is checked in various supported disk frontend buses since + it does not make sense to partially backport it. + +Once this is complete in bionic by taking the new upstream I'll take a look at how backportable that is (changes look ok, but might need some testing in the SRU spirit of things). + +This bug was fixed in the package libvirt - 4.0.0-1ubuntu1 + +--------------- +libvirt (4.0.0-1ubuntu1) bionic; urgency=medium + + * Merged with Debian unstable (4.0) + This closes several bugs: + - Error generating apparmor profile when hostname contains spaces + (LP: #799997) + - qemu 2.10 locks files, libvirt shared now sets share-rw=on (LP: #1716028) + - libvirt usb passthrough throws apparmor denials related to + /run/udev/data/+usb (LP: #1727311) + - AppArmor denies access to /sys/block/*/queue/max_segments (LP: #1729626) + - iohelper improvements to let bypass-cache work without opening up the + apparmor isolation (LP: #1719579) + - nodeinfo on s390x to contain more CPU info (LP: #1733688) + - Upgrade libvirt >= 4.0 (LP: #1745934) + * Remaining changes: + - Disable libssh2 support (universe dependency) + - Disable firewalld support (universe dependency) + - Disable selinux + - Set qemu-group to kvm (for compat with older ubuntu) + - Additional apport package-hook + - Modifications to adapt for our delayed switch away from libvirt-bin (can + be dropped >18.04). + + d/p/ubuntu/libvirtd-service-add-bin-alias.patch: systemd: define alias + to old service name so that old references work + + d/p/ubuntu/libvirtd-init-add-bin-alias.patch: sysv init: define alias + to old service name so that old references work + + d/control: transitional package with the old name and maintainer + scripts to handle the transition + - Backwards compatible handling of group rename (can be dropped >18.04). + - config details and autostart of default bridged network. Creating that is + now the default in general, yet our solution provides the following on + top as of today: + + autostart the default network by default + + do not autostart if subnet is already taken (e.g. in guests). + - d/p/ubuntu/Allow-libvirt-group-to-access-the-socket.patch: This is + the group based access to libvirt functions as it was used in Ubuntu + for quite long. + + d/p/ubuntu/daemon-augeas-fix-expected.patch fix some related tests + due to the group access change. + - ubuntu/parallel-shutdown.patch: set parallel shutdown by default. + - d/p/ubuntu/enable-kvm-spice.patch: compat with older Ubuntu qemu/kvm + which provided a separate kvm-spice. + - d/p/ubuntu/ubuntu-libxl-qemu-path.patch: this change was split. The + section that adapts the path of the emulator to the Debian/Ubuntu + packaging is kept. + - d/p/ubuntu/ubuntu-libxl-Fix-up-VRAM-to-minimum-requirements.patch: auto + set VRAM to minimum requirements + - d/p/ubuntu/xen-default-uri.patch: set default URI on xen hosts + - Add libxl log directory + - libvirt-uri.sh: Automatically switch default libvirt URI for users on + Xen dom0 via user profile (was missing on changelogs before) + - d/p/ubuntu/apibuild-skip-libvirt-common.h: drop libvirt-common.h from + included_files to avoid build failures due to duplicate definitions. + - Update README.Debian with Ubuntu changes + - Convert libvirt0, libnss_libvirt and libvirt-dev to multi-arch. + - Enable some additional features on ppc64el and s390x (for arch parity) + + systemtap, zfs, numa and numad on s390x. + + systemtap on ppc64el. + - fix conffile upgrade handling to avoid obsolete files + and inactive duplicates (LP 1694159) + - d/t/control, d/t/smoke-qemu-session: fixup smoke-qemu-session by making + vmlinuz available and accessible (Debian bug 848314) + - d/test/smoke-lxc workaround for debbug 848317/867379 + - d/t/control, d/t/smoke-lxc: fix up lxc smoke test (Debian bug 848317) + - Add dnsmasq configuration to work with system wide dnsmasq (drop >18.04, + no more UCA onto Xenial then which has global dnsmasq by default). + - d/p/ubuntu/ubuntu_machine_type.patch: accept ubuntu types as pci440fx + - conffile handling of files dropped in 3.5 (can be dropped >18.04) + + /etc/init.d/virtlockd was sysv init only + + /etc/apparmor.d/local/usr.sbin.libvirtd and + /etc/apparmor.d/local/usr.lib.libvirt.virt-aa-helper are now generated + by dh_apparmor as needed + - Reworked apparmor Delta, especially the more complex delta is dropped + now, also our former delta is now split into logical pieces, has + improved comments and is part of a continuous upstreaming effort. + Listing related remaining changes: + + d/p/0001-apparmor-Allow-pygrub-to-run-on-Debian-Ubuntu.patch: apparmor: + Allow pygrub to run on Debian/Ubuntu + + d/p/0003-apparmor-libvirt-qemu-Allow-read-access-to-overcommi.patch: + apparmor, libvirt-qemu: Allow read access to overcommit_memory + + d/p/0007-apparmor-libvirt-qemu-Allow-owner-read-access-to-PRO.patch: + apparmor, libvirt-qemu: Allow owner read access to @{PROC}/*/auxv + + d/p/0017-apparmor-virt-aa-helper-Allow-access-to-tmp-director.patch: + apparmor, virt-aa-helper: Allow access to tmp directories + + d/p/ubuntu-aa/0020-virt-aa-helper-ubuntu-storage-paths.patch: + apparmor, virt-aa-helper: Allow various storage pools and image + locations + + d/p/0021-apparmor-virt-aa-helper-Add-openvswitch-support.patch: + apparmor, virt-aa-helper: Add openvswitch support + + d/p/0025-apparmor-fix-newer-virt-manager-1.4.0.patch: Add Apparmor + permissions so virt-manager 1.4.0 viewing works (LP 1668681). + + d/p/0029-appmor-libvirt-qemu-Add-9p-support.patch: appmor, + libvirt-qemu: Add 9p support + + d/p/0030-virt-aa-helper-Complete-9p-support.patch: virt-aa-helper: + add l to 9p file options. + + d/p/0031-virt-aa-helper-Ask-for-no-deny-rule-for-readonly-dis.patch: + virt-aa-helper: Ask for no deny rule for readonly disk (renamed and + reworded, was virt-aa-helper-no-explicity-deny-for-basefiles.patch) + + d/p/0032-apparmor-libvirt-qemu-Allow-reading-charm-specific-c.patch: + apparmor, libvirt-qemu: Allow reading charm-specific ceph config + + d/p/0033-UBUNTU-only-apparmor-for-kvm.powerpc-LP-1680384.patch: allow + commands executed by ubuntu only kvm wrapper on ppc64el (LP 1686621). + + d/p/0034-apparmor-virt-aa-helper-access-for-snapped-nova.patch: + apparmor, virt-aa-helper: access for snapped nova + * Dropped Changes (Upstream): + - d/p/0005-apparmor-libvirt-qemu-Allow-use-of-sgabios.patch: apparmor, + libvirt-qemu: Allow use of sgabios + - d/p/0006-apparmor-libvirt-qemu-Silence-lttng-related-deny-mes.patch: + apparmor, libvirt-qemu: Silence lttng related deny messages + - d/p/0008-apparmor-libvirt-qemu-Allow-read-access-to-sysfs-sys.patch: + apparmor, libvirt-qemu: Allow read access to sysfs system info + - d/p/0009-apparmor-libvirt-qemu-Allow-read-access-to-max_mem_r.patch: + apparmor, libvirt-qemu: Allow read access to max_mem_regions + - d/p/0010-apparmor-libvirt-qemu-Allow-qemu-block-extra-librari.patch: + apparmor, libvirt-qemu: Allow qemu-block-extra libraries + - d/p/0012-apparmor-libvirtd-Allow-access-to-netlink-sockets.patch: + apparmor, libvirtd: Allow access to netlink sockets + - d/p/0013-apparmor-Add-rules-for-mediation-support.patch: + apparmor: Add rules for mediation support + - d/p/0015-apparmor-virt-aa-helper-Allow-access-to-ecryptfs-fil.patch: + apparmor, virt-aa-helper: Allow access to ecryptfs files + - d/p/0016-apparmor-libvirtd-Allow-ixr-to-var-lib-libvirt-virtd.patch: + apparmor, libvirtd: Allow ixr to /var/lib/libvirt/virtd* + - d/p/0018-apparmor-virt-aa-helper-Add-ipv6-network-policy.patch: + apparmor, virt-aa-helper: Add ipv6 network policy + - d/p/0019-apparmor-virt-aa-helper-Allow-access-to-sys-bus-usb-.patch: + apparmor, virt-aa-helper: Allow access to /sys/bus/usb/devices + - d/p/0023-apparmor-qemu-won-t-call-qemu-nbd.patch: apparmor: qemu + won't call qemu-nbd + - d/p/0027-apparmor-allow-reading-cmdline-of-shutdown-signal.patch: + apparmor: allow to parse cmdline of the pid that send the shutdown + signal (LP 1680384). + - d/p/0028-apparmor-add-default-pki-path-of-lbvirt-spice.patch: + apparmor: add default pki path of lbvirt-spice (LP 1690140) + - d/p/ubuntu-aa/0035-virt-aa-helper-locking-disk-files-for-qemu-2.10.patch: + for compatibility with the behavior of qemu 2.10 this adds locking + permission to rules generated for disk files (LP 1709818) + - d/p/ubuntu-aa/0036-virt-aa-helper-locking-loader-nvram-for-qemu-2.10.patch: + for compatibility with the behavior of qemu 2.10 this adds locking + permission to rules generated for loader/nvram (LP 1710960) + - d/p/ubuntu-aa/0037-virt-aa-helper...: grant locking permission on append + files (LP 1726804) + - d/p/ubuntu-aa/0038-virt-aa-helper-fix-paths-for-usb-hostdevs.patch: + fix path generation for USB host devices (LP 1552241) + - d/p/ubuntu-aa/0039-virt-aa-helper-fix-libusb-access-to-udev-usb-data.patch: + generate valid rules on usb passthrough (LP 1686324) + - d/p/avoid-double-locking.patch: fix a deadlock that could occur when + libvirtd interactions raced with dbus causing a deadlock (LP 1714254). + - d/p/u/gnulib-getopt-posix-Fix-build-failure-when-using-ac_cv_head.patch: + fix FTBFS with glibc 2.26 (LP 1718668) + - Extended handling of apparmor profiles - clear lost profiles via cron + (now cleared by virt-aa-helper on domain stop) + - nat only on some ports <port start='1024' end='65535'/> (upstream + default now if nothing is specified, actually dropped last cycle) + * Dropped Changes (In Debian or no more important): + - d/p/0002-apparmor-libvirt-qemu-Allow-macvtap-access.patch: apparmor, + libvirt-qemu: Allow macvtap access + - d/p/0004-apparmor-Explicit-deny-for-setpcap.patch: apparmor: Explicit + deny for setpcap (LP 522845). + - d/p/0014-apparmor-virt-aa-helper-Improve-comment-about-backin.patch: + apparmor, virt-aa-helper: Improve comment about backing store + - d/p/0022-apparmor-drop-references-to-qemu-kvm.patch: apparmor: drop + references to qemu-kvm + - d/p/0024-apparmor-virt-aa-helper-Allow-access-to-name-service.patch: + apparmor, virt-aa-helper: Allow access to name services + - d/p/0026-apparmor-add-generic-base-vfio-device.patch: apparmor: add + /dev/vfio for vf (hot) attach (LP 1680384) (added by virt-aa-helper per + guest if needed). + - d/p/0011-apparmor-libvirt-qemu-Allow-access-to-hugepage-mount.patch: + apparmor, libvirt-qemu: Allow access to hugepage mounts + - Disable sheepdog (was for universe dependency, but is now only a suggest) + - d/p/ubuntu/storage-disable-gluster-test: gluster not enabled, skip test + * Dropped Changes (In Debian/Upstream now based on interim 3.10 work) some of + these were never released, but important to mention for the bug references: + - libnss-libvirt once enabled causes apt to call getdents + avoid this being an issue by dropping a apt conf that allows + this in seccomp (LP: #1732030). + - d/libvirt-daemon-system.postrm: clean up more libvirt directories on + purge + - d/p/ubuntu-aa/0041-apparmor-allow-unix-stream-for-p2p-migrations.patch: + apparmor: allow unix stream for p2p migrations + - d/p/ubuntu-aa/0043-security-apparmor-implement-domainSetPathLabel.patch: + this replaces the hugepage rules and fixes many more formerly missing + - d/p/ubuntu-aa/0044-security-full-path-option-for-DomainSetPathLabel.patch: + allowing to have path wildcards on labels set by domain callbacks + - d/p/ubuntu-aa/0045-security-apparmor-add-Set-Restore-ChardevLabel.patch: + apparmor implementation of security callback + - d/p/ubuntu-aa/0046-apparmor-virt-aa-helper-drop-static-channel-rule.patch: + this is now covered by chardev label callbacks + * Added Changes: + - Revert Debian change "Drop libvirt-bin upgrade handling" + This is needed in Ubuntu one last time (drop >18.04) + - Revert Debian change "Drop maintscript helpers for versions predating + jessie and wheezy-backports". This is needed in Ubuntu one last + time (drop >18.04) + - Refreshed d/p/* to match new version (only fuzz, no semantic change) + - d/libvirt-daemon-system.postrm: change order of libvirt-qemu removal + to avoid error messages on purge + - remove no more used libvirt-dnsmasq user (drop >18.04) + - d/p/ubuntu-aa/0040-apparmor-add-mediation-rules-for-unconfined.patch: + apparmor: add mediation rules for unconfined guests + - d/p/ubuntu-aa/0042-security-introduce-virSecurityManager-Set-Restore-Ch + .patch: backport upstream cahnge to expose already used chardev calls. + - d/libvirt-daemon-system.postrm: Remove the default.xml network link + set up by postinst. + - d/libvirt-daemon-system.maintscript: remove the now dropped conffile + /etc/cron.daily/libvirt-daemon-system + - d/libvirt-daemon-system.postinst: fixups for autostart default network + - use modern shell syntax + - try more default networks before giving up to enable by default + - d/p/ubuntu-aa/0020-virt-aa-helper-ubuntu-storage-paths.patch: + add multipass image path and mark as ubuntu only change. + - d/rules: install virtlockd correctly with defaults file (LP: #1729516) + - extended d/p/0025-apparmor-fix-newer-virt-manager-1.4.0.patch to cover + the slightly changed behavior of libvirt 4.0 (LP: #1741617) + - d/control: make libvirt-daemon-driver-storage-rbd a recommend instead of + just a suggest to have 3rd party relying on rbd out of the box working. + This is deprecated and users of rbd backend should start depending on + this package for it will be dropped to a suggest in future releases. + + -- Christian Ehrhardt <email address hidden> Thu, 14 Dec 2017 14:15:55 +0100 + +The avoidance for libvirt driven cases to map </shared> onto share-rw is complete in Bionic now, so I started to look into a potential SRU. + +But looking back it seems in the meantime everybody learned how to use it. +I have not seen any more dups coming in recently. +The same is true for openstack and likely everyone else. + +Therefore I'll set Won't Fix for Artful, we would have to wait for an upcoming security fix to be out of the queue anyway. If until that is done someone steps up and explains why this really still is needed in Artful I'll backport them, but otherwise I think we are good with Won't fix. + diff --git a/results/classifier/118/review/1716510 b/results/classifier/118/review/1716510 new file mode 100644 index 000000000..488e7717f --- /dev/null +++ b/results/classifier/118/review/1716510 @@ -0,0 +1,80 @@ +register: 0.875 +user-level: 0.861 +permissions: 0.849 +performance: 0.838 +virtual: 0.818 +files: 0.807 +mistranslation: 0.803 +vnc: 0.795 +architecture: 0.794 +hypervisor: 0.791 +ppc: 0.783 +risc-v: 0.781 +KVM: 0.778 +boot: 0.777 +TCG: 0.777 +semantic: 0.769 +i386: 0.760 +debug: 0.759 +VMM: 0.755 +peripherals: 0.752 +graphic: 0.743 +device: 0.742 +x86: 0.738 +arm: 0.733 +socket: 0.728 +assembly: 0.727 +network: 0.664 +PID: 0.652 +kernel: 0.631 +-------------------- +hypervisor: 0.975 +virtual: 0.967 +x86: 0.859 +boot: 0.858 +debug: 0.853 +KVM: 0.663 +socket: 0.223 +kernel: 0.147 +PID: 0.084 +files: 0.062 +VMM: 0.031 +TCG: 0.026 +device: 0.023 +performance: 0.019 +assembly: 0.018 +user-level: 0.017 +ppc: 0.015 +register: 0.013 +semantic: 0.009 +network: 0.006 +architecture: 0.005 +permissions: 0.003 +graphic: 0.002 +risc-v: 0.002 +i386: 0.002 +peripherals: 0.002 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +qemu 2.10.0 cannot boot Windows 10 familly + +On qemu 2.10.0 Windows 10 and Windows Server 2016 hangs during boot. Below is setup of Windows Server 2016. Downgrading to 2.9 fixes the problem. + +/usr/bin/qemu-system-x86_64 -name guest=<name>,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-<name>/master-key.aes -machine pc-q35-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu host,nx=on,hv_relaxed,hv_vapic,hv_spinlocks=0x1000,hv_vpindex,hv_runtime,hv_synic,hv_reset,kvm=off -drive file=/usr/local/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd,if=pflash,format=raw,unit=0 -drive file=/var/lib/libvirt/qemu/nvram/<name>_VARS.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 12,sockets=1,cores=6,threads=2 -object iothread,id=iothread1 -object iothread,id=iothread2 -object iothread,id=iothread3 -object iothread,id=iothread4 -object iothread,id=iothread5 -object iothread,id=iothread6 -object iothread,id=iothread7 -object iothread,id=iothread8 -object iothread,id=iothread9 -object iothread,id=iothread10 -object iothread,id=iothread11 -object iothread,id=iothread12 -uuid <uuid> -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-<name>/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-shutdown -boot strict=on -device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device ioh3420,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device ioh3420,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device ioh3420,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device ioh3420,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device ioh3420,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=2 -drive if=none,media=cdrom,id=drive-sata0-0-1,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=1 -drive file=/dev/mapper/<boot disk>,format=raw,if=none,id=drive-sata0-0-2 -device ide-hd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2,bootindex=3 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=<mac>,bus=pci.1,addr=0x0 -netdev tap,fd=24,id=hostnet1,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=<mac>,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice unix,addr=/var/lib/libvirt/qemu/domain-2-<name>/spice.sock,disable-ticketing,image-compression=auto_glz,seamless-migration=on -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device vhost-scsi-pci,wwpn=<wwpn>,vhostfd=26,id=hostdev0,bus=pcie.0,addr=0x9 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1024,period=1000,bus=pci.5,addr=0x0 -msg timestamp=o + +Possibly a duplicate of: + +https://bugs.launchpad.net/qemu/+bug/1714331 +or +https://bugs.launchpad.net/qemu/+bug/1715700 + +Can you share with us the version of OVMF you are using and potentially try a newer version (see lp 1714331) If not, keep your eye on lp 1715700 for updates. + +Ok. It looks like EDK was added to my distro and using it fixed it - https://packages.gentoo.org/packages/sys-firmware/edk2-ovmf (at least W16 - I'll try W10 tonight). + +Unfortunately when I run strings on edk I haven't seen anything which looked like version. + +Since this seems to be fixed when using EDK, I'm marking this ticket as Fix Released + diff --git a/results/classifier/118/review/1719 b/results/classifier/118/review/1719 new file mode 100644 index 000000000..1a0d19f3d --- /dev/null +++ b/results/classifier/118/review/1719 @@ -0,0 +1,67 @@ +TCG: 0.880 +mistranslation: 0.686 +graphic: 0.650 +device: 0.591 +ppc: 0.546 +semantic: 0.539 +socket: 0.454 +network: 0.408 +architecture: 0.405 +PID: 0.397 +vnc: 0.367 +files: 0.247 +arm: 0.239 +boot: 0.217 +user-level: 0.184 +performance: 0.167 +register: 0.165 +risc-v: 0.156 +virtual: 0.149 +kernel: 0.116 +permissions: 0.111 +debug: 0.108 +VMM: 0.101 +i386: 0.099 +x86: 0.082 +hypervisor: 0.078 +peripherals: 0.070 +assembly: 0.033 +KVM: 0.017 +-------------------- +TCG: 0.826 +files: 0.218 +hypervisor: 0.146 +virtual: 0.054 +x86: 0.034 +register: 0.013 +ppc: 0.009 +kernel: 0.008 +permissions: 0.007 +arm: 0.007 +user-level: 0.007 +semantic: 0.006 +i386: 0.004 +debug: 0.004 +PID: 0.003 +VMM: 0.002 +architecture: 0.002 +device: 0.002 +assembly: 0.002 +risc-v: 0.002 +network: 0.001 +graphic: 0.001 +performance: 0.001 +KVM: 0.001 +boot: 0.001 +socket: 0.001 +vnc: 0.000 +peripherals: 0.000 +mistranslation: 0.000 + +Allow TCG plugins to read memory +Additional information: +* `include/qemu/plugin.h` +* `include/qemu/qemu-plugin.h` +* `plugin/api.c` + +PANDA implemented this already (not sure if this solution is acceptable for the mainline QEMU): https://github.com/qemu/qemu/commit/72c661a7f141ab41fbce5e95eb3593b69f40e246 diff --git a/results/classifier/118/review/1719339 b/results/classifier/118/review/1719339 new file mode 100644 index 000000000..ae52ca677 --- /dev/null +++ b/results/classifier/118/review/1719339 @@ -0,0 +1,98 @@ +user-level: 0.867 +mistranslation: 0.763 +risc-v: 0.707 +peripherals: 0.632 +KVM: 0.614 +TCG: 0.570 +hypervisor: 0.553 +x86: 0.549 +VMM: 0.517 +vnc: 0.506 +ppc: 0.487 +i386: 0.452 +virtual: 0.448 +register: 0.429 +device: 0.429 +network: 0.422 +permissions: 0.420 +files: 0.413 +performance: 0.372 +boot: 0.370 +architecture: 0.364 +debug: 0.362 +assembly: 0.361 +semantic: 0.350 +arm: 0.347 +socket: 0.341 +graphic: 0.337 +kernel: 0.336 +PID: 0.333 +-------------------- +debug: 0.948 +x86: 0.935 +virtual: 0.908 +kernel: 0.753 +hypervisor: 0.737 +KVM: 0.025 +PID: 0.025 +register: 0.019 +VMM: 0.018 +files: 0.015 +device: 0.014 +user-level: 0.012 +TCG: 0.010 +socket: 0.006 +performance: 0.006 +semantic: 0.005 +assembly: 0.003 +boot: 0.002 +ppc: 0.002 +architecture: 0.002 +network: 0.002 +graphic: 0.001 +peripherals: 0.001 +vnc: 0.001 +permissions: 0.001 +risc-v: 0.001 +i386: 0.000 +mistranslation: 0.000 +arm: 0.000 + +serial8250: too much work for irq3 + +It's know issue and sometimes mentioned since 2007. But it seems not fixed. + +http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00140.html +https://bugzilla.redhat.com/show_bug.cgi?id=986761 +http://old-list-archives.xenproject.org/archives/html/xen-devel/2009-02/msg00696.html + +I don't think fixes like increases PASS_LIMIT (/drivers/tty/serial/8250.c) or remove this annoying message (https://patchwork.kernel.org/patch/3920801/) is real fix. Some fix was proposed by H. Peter Anvin https://lkml.org/lkml/2008/2/7/485. + +Can reproduce on Debian Strech host (Qemu 1:2.8+dfsg-6+deb9u2), Ubuntu 16.04.2 LTS (Qemu 1:2.5+dfsg-5ubuntu10.15) also tried to use master branch (QEMU emulator version 2.10.50 (v2.10.0-766-ga43415ebfd-dirty)) if we write a lot of message into console (dmesg or dd if=/dev/zero of=/dev/ttyS1). + +/usr/local/bin/qemu-system-x86_64 -name guest=ultra1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-ultra1/master-key.aes -machine pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Client,ds=on,acpi=on,ss=on,ht=on,tm=on,pbe=on,dtes64=on,monitor=on,ds_cpl=on,vmx=on,smx=on,est=on,tm2=on,xtpr=on,pdcm=on,osxsave=on,tsc_adjust=on,clflushopt=on,pdpe1gb=on -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 4537ca29-73b2-40c3-9b43-666de182ba5f -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-27-ultra1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8.0x7 -drive file=/home/dzagorui/csr/csr_disk.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:a9:4c:86,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4000,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4001,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 -msg timestamp=on + +Use simpler setup for reproducing. +Was used only qemu-system-x86_64 (without using high-level wrappers and managers of virtual machines: libvirt, virsh, virt-install, virt-manager etc..). My setup with two consoles: + +/usr/local/bin/qemu-system-x86_64 -cpu host -enable-kvm -m 256 -smp 4 -kernel /home/dzagorui//bzImage -append 'root=/dev/ram0 loglevel=9 rw console=ttyS0' -initrd /home/dzagorui/initrd.cpio -display none -chardev socket,id=charserial0,host=127.0.0.1,port=4002,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charserial1,host=127.0.0.1,port=4003,telnet,server,nowait -device isa-serial,chardev=charserial1,id=serial1 + +I noticed one thing, that -smp parameter affects this issue. When -smp 1 i can't reproduce this issue at all, when -smp 2 i can produce this issue only in second console (ttyS1), when -smp 4 and higher the issue produces on both consoles (ttyS1/ttyS0). +My Host cpu i5-6200U has 2 cores and 4 threads. + +For reproducing was used this commands (no matter what console we use ttyS1 or ttyS0): +#dmesg > /dev/ttyS* +#dd if=/dev/zero of=/dev/ttyS* + +I'm seeing this on AWS EC2 when there's (apparently) high logging volume to the console, very similarly to https://www.reddit.com/r/sysadmin/comments/6zuqad/mongodb_aws_ec2_serial8250_too_much_work_for_irq4/ + +On further investigation of my instance, there appeared to be no high logging volume to the console, nor anything using the /dev/ttyS0 other than agetty. Switching from the generic kernel to the AWS kernel seems to have stabilised it. + +Further update: AWS kernel experienced the same error messages after just over 3 hours of runtime. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1720 b/results/classifier/118/review/1720 new file mode 100644 index 000000000..913db4080 --- /dev/null +++ b/results/classifier/118/review/1720 @@ -0,0 +1,100 @@ +mistranslation: 0.979 +graphic: 0.856 +arm: 0.791 +device: 0.768 +performance: 0.736 +architecture: 0.636 +x86: 0.589 +kernel: 0.586 +peripherals: 0.584 +PID: 0.578 +ppc: 0.564 +VMM: 0.453 +register: 0.451 +hypervisor: 0.441 +semantic: 0.435 +permissions: 0.431 +network: 0.426 +socket: 0.400 +debug: 0.389 +boot: 0.380 +user-level: 0.372 +i386: 0.310 +assembly: 0.306 +KVM: 0.296 +risc-v: 0.295 +virtual: 0.291 +TCG: 0.251 +vnc: 0.194 +files: 0.122 +-------------------- +arm: 0.850 +kernel: 0.539 +virtual: 0.239 +device: 0.092 +debug: 0.053 +architecture: 0.036 +TCG: 0.024 +files: 0.020 +PID: 0.019 +VMM: 0.017 +semantic: 0.015 +hypervisor: 0.013 +register: 0.012 +boot: 0.010 +peripherals: 0.010 +assembly: 0.008 +user-level: 0.007 +KVM: 0.007 +vnc: 0.005 +performance: 0.005 +socket: 0.004 +risc-v: 0.004 +network: 0.003 +ppc: 0.002 +permissions: 0.002 +graphic: 0.002 +x86: 0.001 +mistranslation: 0.001 +i386: 0.001 + +Problems in mapping memory regions in multiple machines using GPEX pci-host +Description of problem: +Multiple machines use the GPEX pci-host model. This model forsees 3 MMIO regions: +1. ECAM space +2. MMIO space +3. IO space + +In the different machines, aliases to the 3 memory regions are created which are then mapped onto the sysbus. + +For the ARM virt machine for example following calls are happening: + + ecam_alias = g_new0(MemoryRegion, 1); + ecam_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0); + memory_region_init_alias(ecam_alias, OBJECT(dev), "pcie-ecam", ecam_reg, 0, size_ecam); + memory_region_add_subregion(get_system_memory(), base_ecam, ecam_alias); + + mmio_alias = g_new0(MemoryRegion, 1); + mmio_reg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1); + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +We now add a generic PCIe root port (gen_pcie_root_port.c) on the PCIBus exposed by the GPEX device: + + pci_create_simple(PCI_HOST_BRIDGE(dev)->bus, -1, "pcie-root-port"); + +This device contains an MSI-x table which is accessible via BAR 0. + +However, if we try to access this space we always get 0xFFFFFFFF as a return value on reads because the memory regions are not correctly mapped IMO. + +If we again look at the mapping of the MMIO space: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, base_mmio, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +The alias is created to the MMIO region in the GPEX device, at offset base_mmio. Afterwards the memory region alias is mapped onto the sysbus at offset base_mmio. To me it seems that the offset is incorrect in creating the alias and should be 0 instead: + + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio", mmio_reg, 0, size_mmio); + memory_region_add_subregion(get_system_memory(), base_mmio, mmio_alias); + +With this change the above scenario (accessing the MSI-x table of the generic PCIe root port) is working. I'm not sure if this is the correct fix for this problem and how to cope with e.g. high MMIO regions (as are also present in the virt machine). diff --git a/results/classifier/118/review/1721221 b/results/classifier/118/review/1721221 new file mode 100644 index 000000000..28a01f2ba --- /dev/null +++ b/results/classifier/118/review/1721221 @@ -0,0 +1,151 @@ +user-level: 0.817 +risc-v: 0.768 +vnc: 0.703 +x86: 0.701 +ppc: 0.700 +KVM: 0.698 +virtual: 0.693 +arm: 0.687 +TCG: 0.682 +VMM: 0.682 +boot: 0.665 +files: 0.665 +mistranslation: 0.659 +register: 0.657 +device: 0.656 +peripherals: 0.649 +debug: 0.648 +permissions: 0.647 +performance: 0.644 +semantic: 0.637 +assembly: 0.637 +socket: 0.635 +hypervisor: 0.624 +graphic: 0.620 +architecture: 0.614 +network: 0.605 +kernel: 0.602 +i386: 0.598 +PID: 0.584 +-------------------- +x86: 0.956 +hypervisor: 0.905 +KVM: 0.730 +kernel: 0.569 +virtual: 0.568 +debug: 0.261 +PID: 0.034 +TCG: 0.033 +socket: 0.031 +device: 0.026 +files: 0.022 +register: 0.020 +VMM: 0.013 +semantic: 0.009 +architecture: 0.008 +risc-v: 0.006 +assembly: 0.006 +performance: 0.006 +peripherals: 0.005 +network: 0.004 +boot: 0.003 +graphic: 0.003 +user-level: 0.002 +permissions: 0.002 +ppc: 0.002 +vnc: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with "kvm_set_phys_mem: error registering slot: Invalid argument" + +Problem: +Passthrough of a PCI-E Nvidia GTX 970 GFX card to a Windows 10 guest from a Debian Stretch host fails after recent changes to kvm in QEMU master/trunk. Before this recent commit, everything worked as expected. + +QEMU Version: +Master/trunk pulled from github 4/10/17 ( git reflog: d147f7e815 HEAD@{0} ) + +Host: +Debian Stretch kernel SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux + +Guest: +Windows 10 Professional + +Issue is with this commit: +https://github.com/qemu/qemu/commit/f357f564be0bd45245b3ccfbbe20ace08fe83ca8 + +Subsequent commit does not help: +https://github.com/qemu/qemu/commit/3110cdbd8a4845c5b5fb861b0a664c56d993dd3c#diff-7b7a17f6e8ba4195198dd685073f43cb + +Error output from qemu: +(qemu) kvm_set_phys_mem: error registering slot: Invalid argument + +QEMU commandline used: + +./sources/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm -serial none -parallel none -name Windows \ +-enable-kvm -cpu host,kvm=off,hv_vendor_id=sugoidesu,-hypervisor -smp 6,sockets=1,cores=3,threads=2 \ +-m 8G -mem-path /dev/hugepages -mem-prealloc -balloon none \ +-drive if=pflash,format=raw,readonly,file=vms/ovmf-x64/ovmf-x64/OVMF_CODE-pure-efi.fd \ +-drive if=pflash,format=raw,file=vms/ovmf-x64/ovmf-x64/OVMF_VARS-pure-efi.fd \ +-rtc clock=host,base=localtime \ +-readconfig ./vms/q35-virtio-graphical.cfg \ +-object iothread,id=iothread0 -object iothread,id=iothread1 -object iothread,id=iothread2 -object iothread,id=iothread3 \ +-device virtio-scsi-pci,iothread=iothread0,id=scsi0 -device virtio-scsi-pci,iothread=iothread1,id=scsi1 -device virtio-scsi-pci,iothread=iothread2,id=scsi2 -device virtio-scsi-pci,iothread=iothread3,id=scsi3 \ +-device scsi-hd,bus=scsi0.0,drive=drive0,bootindex=1 -device scsi-hd,bus=scsi1.0,drive=drive1 -device scsi-hd,bus=scsi2.0,drive=drive2 -device scsi-hd,bus=scsi3.0,drive=drive3 -device scsi-hd,bus=scsi1.0,drive=drive4 -device scsi-hd,bus=scsi2.0,drive=drive5 -device scsi-hd,bus=scsi3.0,drive=drive6 -device scsi-hd,bus=scsi1.0,drive=drive7 -device scsi-hd,bus=scsi2.0,drive=drive8 -device scsi-hd,bus=scsi3.0,drive=drive9 \ +-drive if=none,id=drive0,file=vms/w10p64.qcow2,format=qcow2,cache=none,discard=unmap \ +-drive if=none,id=drive1,file=vms/w10p64-2.qcow2,format=qcow2,cache=none,discard=unmap \ +-drive if=none,id=drive2,file=/dev/mapper/w10p64-3,format=raw,cache=none \ +-drive if=none,id=drive3,file=vms/w10p64-4.qcow2,format=qcow2,cache=none \ +-drive if=none,id=drive4,file=vms/w10p64-5.qcow2,format=qcow2,cache=none \ +-drive if=none,id=drive5,file=vms/w10p64-6.qcow2,format=qcow2,cache=none,discard=unmap \ +-drive if=none,id=drive6,file=/dev/mapper/w10p64-7,format=raw,cache=none \ +-drive if=none,id=drive7,file=vms/w10p64-8.qcow2,format=qcow2,cache=none,discard=unmap \ +-device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \ +-device vfio-pci,host=01:00.1,multifunction=on \ +-netdev type=tap,id=net1,ifname=tap1,script=no,downscript=no,vhost=on \ +-device virtio-net-pci,netdev=net1,mac=52:54:00:18:32:c9,bus=pcie.2,addr=00.0,ioeventfd=on \ +-device usb-host,bus=usb.0,hostbus=3,hostport=2.1 \ +-device usb-host,hostbus=3,hostport=2.2 \ +-device usb-host,bus=ich9-ehci-1.0,hostbus=3,hostport=2.4 \ +-object input-linux,id=kbd1,evdev=/dev/input/event0,grab_all=yes,repeat=on \ +-drive if=none,id=drive8,file=vms/w10p64.qcow2-9,format=qcow2,discard=unmap \ +-drive if=none,id=drive9,file=vms/w10p64-10.qcow2,format=qcow2,cache=none,discard=unmap \ +-device usb-host,bus=usb.0,hostbus=3,hostport=9 \ +-monitor stdio + +lspci -tv +-[0000:00]-+-00.0 Intel Corporation 4th Gen Core Processor DRAM Controller + +-01.0-[01]--+-00.0 NVIDIA Corporation GM204 [GeForce GTX 970] + | \-00.1 NVIDIA Corporation GM204 High Definition Audio Controller + +-02.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller + +-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller + +-14.0 Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI + +-16.0 Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 + +-19.0 Intel Corporation Ethernet Connection I217-V + +-1a.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 + +-1b.0 Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller + +-1c.0-[02]-- + +-1c.3-[03]----00.0 Broadcom Limited BCM4352 802.11ac Wireless Network Adapter + +-1d.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 + +-1f.0 Intel Corporation Z87 Express LPC Controller + +-1f.2 Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] + \-1f.3 Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller + + +I should probably add that I am using a recent OVMF firmware from this repo: https://www.kraxel.org/repos/jenkins/edk2/ namely edk2.git-ovmf-x64-0-20170914.b2974.g7f2f96f1a8.noarch.rpm dated 18/9/17 + +There's another bug report / discussion thread on qemu-devel about the same commit: + +http://<email address hidden> + +I'll add a note to that thread about this LP report too. + +Apologies, the title of this bug might be very misleading. I've made a huge assumption that PCI-E GFX card pass-through was triggering the bug, purely because a Debian Stretch guest VM on the same host, using the same build of QEMU, which uses virtio-vga for graphics and the same version of OVMF firmware, boots up fine. + +More noise... OK, so I've tested the Windows 10 guest VM using the same criteria but eliminating PCI-E pass-through and using virtio-vga graphics instead, and the the guest boots up fine so perhaps my assumption is correct. + +Let me know if you need to see the memory I/O regions or dmesg of my host etc. + +Fix will end up in QEMU master soon. + diff --git a/results/classifier/118/review/1721744 b/results/classifier/118/review/1721744 new file mode 100644 index 000000000..d9486e48f --- /dev/null +++ b/results/classifier/118/review/1721744 @@ -0,0 +1,143 @@ +user-level: 0.831 +graphic: 0.803 +semantic: 0.799 +register: 0.769 +virtual: 0.750 +debug: 0.728 +PID: 0.717 +permissions: 0.715 +mistranslation: 0.704 +risc-v: 0.685 +arm: 0.669 +assembly: 0.646 +architecture: 0.637 +ppc: 0.635 +performance: 0.611 +boot: 0.599 +KVM: 0.586 +hypervisor: 0.585 +VMM: 0.584 +peripherals: 0.577 +TCG: 0.577 +device: 0.575 +vnc: 0.561 +kernel: 0.560 +network: 0.525 +socket: 0.477 +files: 0.476 +x86: 0.358 +i386: 0.327 +-------------------- +ppc: 0.899 +KVM: 0.874 +TCG: 0.764 +hypervisor: 0.740 +kernel: 0.441 +virtual: 0.395 +VMM: 0.103 +debug: 0.074 +files: 0.055 +register: 0.030 +semantic: 0.012 +risc-v: 0.006 +PID: 0.004 +architecture: 0.004 +socket: 0.003 +boot: 0.003 +device: 0.002 +performance: 0.002 +network: 0.002 +assembly: 0.002 +permissions: 0.002 +graphic: 0.002 +user-level: 0.002 +vnc: 0.001 +mistranslation: 0.001 +peripherals: 0.001 +x86: 0.000 +arm: 0.000 +i386: 0.000 + +Help content missing for newly added machine properties + + +Help content missing for newly added machine properties, it would be needed by libvirt and other management layers to query to add support, Thanks. + +max-cpu-compat,vsmt,modern-hotplug-events,resize-hpt + +Steps: +1. Compile qemu @below commit +2. ./ppc64-softmmu/qemu-system-ppc64 -h +.... +-machine [type=]name[,prop[=value][,...]] + selects emulated machine ('-machine help' for list) + property accel=accel1[:accel2[:...]] selects accelerator + supported accelerators are kvm, xen, hax or tcg (default: tcg) + kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + vmport=on|off|auto controls emulation of vmport (default: auto) + kvm_shadow_mem=size of KVM shadow MMU in bytes + dump-guest-core=on|off include guest memory in a core dump (default=on) + mem-merge=on|off controls memory merge support (default: on) + igd-passthru=on|off controls IGD GFX passthrough support (default=off) + aes-key-wrap=on|off controls support for AES key wrapping (default=on) + dea-key-wrap=on|off controls support for DEA key wrapping (default=on) + suppress-vmdesc=on|off disables self-describing migration (default=off) + nvdimm=on|off controls NVDIMM support (default=off) + enforce-config-section=on|off enforce configuration section migration (default=off) + s390-squash-mcss=on|off controls support for squashing into default css (default=off) +.... + +===> Not showing help of mentioned properties. + + + +Verified at todays below commit +#git show +commit d8f932cc696250cb740240d668b39df5fbb2d5a0 +Merge: 67caeea 4504273 +Author: Peter Maydell <email address hidden> +Date: Thu Oct 5 16:54:29 2017 +0100 + + Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging + + # gpg: Signature made Thu 05 Oct 2017 15:25:21 BST + # gpg: using RSA key 0x9CA4ABB381AB73C8 + # gpg: Good signature from "Stefan Hajnoczi <email address hidden>" + # gpg: aka "Stefan Hajnoczi <email address hidden>" + # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 + + * remotes/stefanha/tags/tracing-pull-request: + checkpatch: fix incompatibility with old perl + + Signed-off-by: Peter Maydell <email address hidden> + +Hmm... -h is common to all targets, ie, you should only find properties that can be passed to -machine for all qemu-system-* binaries (I don't know how s390-squash-mcss landed there but it looks wrong). + +The right way to query properties supported by a pseries machine type is: + +$ ./ppc64-softmmu/qemu-system-ppc64 -machine pseries,help +pseries-2.11.kvm-type=string (Specifies the KVM virtualization mode (HV, PR)) +pseries-2.11.vsmt=uint32 (Virtual SMT: KVM behaves as if this were the host's SMT mode) +pseries-2.11.modern-hotplug-events=bool (Use dedicated hotplug event mechanism in place of standard EPOW events when possible (required for memory hot-unplug support)) +pseries-2.11.max-cpu-compat=string (Maximum permitted CPU compatibility mode. Valid values are power6, power7, power7+, power8, power9.) +pseries-2.11.resize-hpt=string (Resizing of the Hash Page Table (enabled, disabled, required)) +pseries-2.11.kvm-shadow-mem=int (KVM shadow MMU size) +pseries-2.11.enforce-config-section=bool (Set on to enforce configuration section migration) +pseries-2.11.initrd=string (Linux initial ramdisk file) +pseries-2.11.mem-merge=bool (Enable/disable memory merge support) +pseries-2.11.firmware=string (Firmware image) +pseries-2.11.dtb=string (Linux kernel device tree file) +pseries-2.11.suppress-vmdesc=bool (Set on to disable self-describing migration) +pseries-2.11.usb=bool (Set on/off to enable/disable usb) +pseries-2.11.kernel=string (Linux kernel image file) +pseries-2.11.dt-compatible=string (Overrides the "compatible" property of the dt root node) +pseries-2.11.igd-passthru=bool (Set on/off to enable/disable igd passthrou) +pseries-2.11.dumpdtb=string (Dump current dtb to a file and quit) +pseries-2.11.append=string (Linux kernel command line) +pseries-2.11.accel=string (Accelerator list) +pseries-2.11.kernel-irqchip=OnOffSplit (Configure KVM in-kernel irqchip) +pseries-2.11.dump-guest-core=bool (Include guest memory in a core dump) +pseries-2.11.phandle-start=int (The first phandle ID we may generate dynamically) +pseries-2.11.graphics=bool (Set on/off to enable/disable graphics emulation) + + diff --git a/results/classifier/118/review/1722857 b/results/classifier/118/review/1722857 new file mode 100644 index 000000000..9780b9532 --- /dev/null +++ b/results/classifier/118/review/1722857 @@ -0,0 +1,72 @@ +mistranslation: 0.875 +register: 0.745 +vnc: 0.644 +device: 0.613 +ppc: 0.602 +semantic: 0.524 +graphic: 0.519 +peripherals: 0.509 +boot: 0.394 +socket: 0.354 +architecture: 0.334 +network: 0.298 +files: 0.202 +kernel: 0.194 +debug: 0.185 +risc-v: 0.167 +performance: 0.156 +user-level: 0.125 +PID: 0.123 +virtual: 0.113 +i386: 0.105 +assembly: 0.095 +VMM: 0.088 +hypervisor: 0.085 +TCG: 0.081 +permissions: 0.076 +x86: 0.068 +arm: 0.066 +KVM: 0.013 +-------------------- +virtual: 0.828 +hypervisor: 0.080 +device: 0.022 +files: 0.018 +register: 0.009 +TCG: 0.009 +debug: 0.008 +user-level: 0.006 +PID: 0.006 +peripherals: 0.004 +x86: 0.003 +architecture: 0.003 +boot: 0.003 +i386: 0.002 +semantic: 0.002 +arm: 0.002 +kernel: 0.002 +network: 0.002 +assembly: 0.002 +performance: 0.002 +socket: 0.001 +ppc: 0.001 +graphic: 0.001 +vnc: 0.000 +risc-v: 0.000 +VMM: 0.000 +permissions: 0.000 +KVM: 0.000 +mistranslation: 0.000 + +Missing PCI "programming interface" ID emulation for USB host controllers + +Qemu doesn't currently emulate the correct value of the "register level programming interface" field in the PCI config space of USB host controllers. As a result, some guest operating systems (most notably Windows) fail to load e.g. generic xHCI drivers, and instead ask for a vendor-specific driver, which may not be always available. + +Example: "-device nec-usb-xhci" emulates a Renesas (formerly NEC) uPD720202 xHCI controller. However, in the PCI config space, it shows us as class 0C, subclass 03, prog-if 00 (UHCI) where as the real uPD720202 (and all real xHCI controllers) have prog-if 30 (xHCI). A Windows guest booted with this option will not recognize devices attached to the XHCI controller unless drivers from Renesas are manually installed first, even though recent Windows versions include a generic xHCI driver that works perfectly well with real uPD720202 hardware. + +That sounds surprising ... according to the source code: +https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=v5.1.0#l3386 +... QEMU already sets 0x30 as programming interface byte there. Could you please double-check whether your problem still occurs with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1726 b/results/classifier/118/review/1726 new file mode 100644 index 000000000..c74fafd25 --- /dev/null +++ b/results/classifier/118/review/1726 @@ -0,0 +1,157 @@ +user-level: 0.863 +permissions: 0.794 +KVM: 0.789 +virtual: 0.780 +performance: 0.769 +VMM: 0.744 +hypervisor: 0.743 +device: 0.736 +risc-v: 0.727 +mistranslation: 0.714 +TCG: 0.709 +architecture: 0.691 +peripherals: 0.690 +files: 0.688 +boot: 0.684 +vnc: 0.681 +register: 0.661 +ppc: 0.655 +arm: 0.648 +debug: 0.641 +assembly: 0.636 +graphic: 0.623 +x86: 0.620 +semantic: 0.618 +PID: 0.584 +i386: 0.581 +socket: 0.580 +kernel: 0.577 +network: 0.502 +-------------------- +debug: 0.880 +ppc: 0.863 +user-level: 0.598 +hypervisor: 0.440 +TCG: 0.398 +files: 0.060 +virtual: 0.038 +boot: 0.032 +register: 0.015 +semantic: 0.010 +PID: 0.009 +kernel: 0.006 +performance: 0.006 +assembly: 0.004 +network: 0.002 +architecture: 0.002 +device: 0.002 +x86: 0.002 +graphic: 0.002 +VMM: 0.002 +risc-v: 0.001 +peripherals: 0.001 +permissions: 0.001 +KVM: 0.001 +socket: 0.001 +mistranslation: 0.001 +vnc: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-system-ppc64 option -smp 2 broken with commit 20b6643324a79860dcdfe811ffe4a79942bca21e +Description of problem: +I was trying to boot rhel9 image with upstream qemu-system-ppc64 -smp 2 option and observed a segfault (qemu crash). +After doing a git bisect, I found the first bad commit which introduced this issue is below: +``` +[qemu]# git bisect good +20b6643324a79860dcdfe811ffe4a79942bca21e is the first bad commit +commit 20b6643324a79860dcdfe811ffe4a79942bca21e +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Mon Dec 5 17:45:02 2022 -0600 + + tcg/ppc: Reorg goto_tb implementation + + The old ppc64 implementation replaces 2 or 4 insns, which leaves a race + condition in which a thread could be stopped at a PC in the middle of + the sequence, and when restarted does not see the complete address + computation and branches to nowhere. + + The new implemetation replaces only one insn, swapping between + + b <dest> + and + mtctr r31 + + falling through to a general-case indirect branch. + + Reviewed-by: Alex Bennée <alex.bennee@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + + tcg/ppc/tcg-target.c.inc | 152 +++++++++++++---------------------------------- + tcg/ppc/tcg-target.h | 3 +- + 2 files changed, 41 insertions(+), 114 deletions(-) +[qemu]# +``` +Steps to reproduce: +1. Run the qemu command line mentioned +2. Wait for the qemu to crash. +Additional information: +git bisect log: +``` +[root@ltcden6-lp2 qemu]# git bisect log +git bisect start +# status: waiting for both good and bad commits +# bad: [b455ce4c2f300c8ba47cba7232dd03261368a4cb] Merge tag 'q800-for-8.1-pull-request' of https://github.com/vivier/qemu-m68k into staging +git bisect bad b455ce4c2f300c8ba47cba7232dd03261368a4cb +# status: waiting for good commit(s), bad commit known +# good: [b247dba067bf2808de6395ff09ff0cb220ed7c95] tests/avocado: add explicit timeout for ppc64le TCG tests +git bisect good b247dba067bf2808de6395ff09ff0cb220ed7c95 +# bad: [3db629f03e8caf39526cd0415dac16a6a6484107] Merge tag 'pull-request-2023-02-27' of https://gitlab.com/thuth/qemu into staging +git bisect bad 3db629f03e8caf39526cd0415dac16a6a6484107 +# good: [777fa06376ce0249c76d0d852e8f7ed103a63864] Merge tag 'pull-loongarch-20221202' of https://gitlab.com/gaosong/qemu into staging +git bisect good 777fa06376ce0249c76d0d852e8f7ed103a63864 +# bad: [c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8] target/riscv/cpu: set cpu->cfg in register_cpu_props() +git bisect bad c66ffcd5358ba88e93e1ffb15ae42ca52dab12a8 +# good: [bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0] hw/intc: sifive_plic: Fix the pending register range check +git bisect good bc92f261519d5c77c70cf2ebcf0a3b9a414d82d0 +# good: [aa96ab7c9df59c615ca82b49c9062819e0a1c287] Merge tag 'pull-request-2023-01-09' of https://gitlab.com/thuth/qemu into staging +git bisect good aa96ab7c9df59c615ca82b49c9062819e0a1c287 +# good: [a8d6abe1292e1db1ad9be5b2b124b9c01bcda094] Merge tag 'mips-20230113' of https://github.com/philmd/qemu into staging +git bisect good a8d6abe1292e1db1ad9be5b2b124b9c01bcda094 +# bad: [ef4f031fab7b070816454949a1b6b6c7aa3cf503] Merge tag 'pull-tcg-20230117' of https://gitlab.com/rth7680/qemu into staging +git bisect bad ef4f031fab7b070816454949a1b6b6c7aa3cf503 +# good: [0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85] tcg: Change tb_target_set_jmp_target arguments +git bisect good 0fe1c98da9d9abb8e5dc4a67c7e3bcf19aad1e85 +# good: [701ed34833f53880ba38bde09b0846d01fc16d66] Merge tag 'pull-request-2023-01-18' of https://gitlab.com/thuth/qemu into staging +git bisect good 701ed34833f53880ba38bde09b0846d01fc16d66 +# bad: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation +git bisect bad 20b6643324a79860dcdfe811ffe4a79942bca21e +# good: [90c0fee3a28b25d23081b3c435762cadde813ec4] tcg: Always define tb_target_set_jmp_target +git bisect good 90c0fee3a28b25d23081b3c435762cadde813ec4 +# good: [d59d83a1c38869b1e1a4f957eb939aaa8a342721] tcg/aarch64: Reorg goto_tb implementation +git bisect good d59d83a1c38869b1e1a4f957eb939aaa8a342721 +# first bad commit: [20b6643324a79860dcdfe811ffe4a79942bca21e] tcg/ppc: Reorg goto_tb implementation +``` + +gdb backtrace output: + +``` +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00007fff4becfa8c in ?? () +[Current thread is 1 (Thread 0x7fff9e80e780 (LWP 31456))] +(gdb) bt +#0 0x00007fff4becfa8c in () +#1 0x00007fff5682d044 in code_gen_buffer () +#2 0x000000013e3224ec in cpu_tb_exec (cpu=cpu@entry=0x16144fb70, itb=itb@entry=0x7fff5682cf00 <code_gen_buffer+111332932>, tb_exit=tb_exit@entry=0x7fff9e80d7f0) at ../accel/tcg/cpu-exec.c:438 +#3 0x000000013e322ad4 in cpu_loop_exec_tb (tb_exit=0x7fff9e80d7f0, last_tb=<synthetic pointer>, pc=13835058055286981664, tb=0x7fff5682cf00 <code_gen_buffer+111332932>, cpu=<optimized out>) + at ../accel/tcg/cpu-exec.c:871 +#4 cpu_exec_loop (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:981 +#5 0x000000013e3234e8 in cpu_exec_setjmp (cpu=cpu@entry=0x16144fb70, sc=sc@entry=0x7fff9e80d940) at ../accel/tcg/cpu-exec.c:1012 +#6 0x000000013e323e64 in cpu_exec (cpu=0x16144fb70) at ../accel/tcg/cpu-exec.c:1038 +#7 0x000000013e35bba0 in tcg_cpus_exec (cpu=0x16144fb70) at ../accel/tcg/tcg-accel-ops.c:69 +#8 0x000000013e35bd90 in mttcg_cpu_thread_fn (arg=0x16144fb70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#9 0x000000013e57193c in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:505 +#10 0x00007fffa12aa0f0 in start_thread (arg=0x7fff9e80e780) at pthread_create.c:443 +#11 0x00007fffa1352ec8 in clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107 +``` +For any further additional information contact me at : anushree.mathur@linux.vnet.ibm.com diff --git a/results/classifier/118/review/1726394 b/results/classifier/118/review/1726394 new file mode 100644 index 000000000..a1c0b3558 --- /dev/null +++ b/results/classifier/118/review/1726394 @@ -0,0 +1,124 @@ +register: 0.906 +device: 0.898 +debug: 0.894 +permissions: 0.891 +assembly: 0.887 +virtual: 0.882 +PID: 0.869 +semantic: 0.859 +arm: 0.855 +graphic: 0.855 +architecture: 0.853 +KVM: 0.848 +performance: 0.846 +socket: 0.845 +peripherals: 0.818 +vnc: 0.813 +VMM: 0.813 +TCG: 0.812 +network: 0.812 +files: 0.801 +boot: 0.799 +hypervisor: 0.796 +kernel: 0.789 +ppc: 0.765 +user-level: 0.727 +mistranslation: 0.720 +risc-v: 0.697 +x86: 0.676 +i386: 0.651 +-------------------- +kernel: 0.618 +virtual: 0.080 +architecture: 0.049 +debug: 0.029 +register: 0.016 +semantic: 0.008 +TCG: 0.006 +files: 0.005 +PID: 0.005 +user-level: 0.004 +permissions: 0.003 +risc-v: 0.003 +boot: 0.003 +hypervisor: 0.002 +VMM: 0.002 +device: 0.002 +ppc: 0.002 +socket: 0.001 +KVM: 0.001 +vnc: 0.001 +performance: 0.001 +assembly: 0.001 +graphic: 0.001 +network: 0.001 +x86: 0.001 +mistranslation: 0.001 +i386: 0.001 +peripherals: 0.000 +arm: 0.000 + +Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) + +qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. + +I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. + +Returning EINVAL would make sense, as that's what a pre-seccomp kernel or a kernel built without seccomp support would do. + +I worked around this in APT for now by ignoring EFAULT or rather, printing a warning. It would be nice to not do this though. + +FYI - this is from http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00417.html + +Upstream response looks good, but not committed there yet. + +@Julian - given the case will you need this as an SRU as well or is it only tied to newer apt (or newer apt use cases)? + +Test queues in Bionic are still stalling this, there was an error on an iso test on s390x which seemed unrelated to the update - I retriggered for now as I'd assume it needs a newer fixed daily iso. + +v2 of the patch (https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01199.html) has been accepted upstream, though it isn't in master yet. + + + +@pmaydell It's actually https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00828.html :) + + +@paelzer It mostly depends how people run a apt 1.6 foreign architecture chroot with the same pointer size as the host architecture - if they install qemu-user inside the chroot, they're fine, if they copy an old version from the outside, they're not. If the copying is common, we might want to SRU that back to xenial and newer I guess. + +This was blocked migrating on a autopkgtest for a known issue now resolved. +TL;DR no bionic images. Resolved now, should migrate soon. + +While the final fix now accepted in linux-user is slightly different, the difference is only a comment. It is therefore fine if we pick this up on next merge for Bionic. + +Once complete I can plan SRU uploads for this. + +I think we can skip SRUing this, apt now has a new workaround based on execve()ing with QEMU_VERSION=meow, which calls qemu-user to exit with 0. It executes a program guaranteed to exit with 1, and just disables seccomp if that exits with 0. + +https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=243acdee176dd90cb2838690cb5abbd64d4da905 + +It's hacky, but it works :) + +Ok, thanks for the info Julian! + +This bug was fixed in the package qemu - 1:2.10+dfsg-0ubuntu4 + +--------------- +qemu (1:2.10+dfsg-0ubuntu4) bionic; urgency=medium + + * Apply linux-user-return-EINVAL-from-prctl-PR_-_SECCOMP.patch from + James Cowgill to prevent qemu-user from forwarding prctl seccomp + calls (LP: #1726394) + + -- Julian Andres Klode <email address hidden> Sat, 04 Nov 2017 00:21:14 +0100 + +See it passed [1] but britney not picking up. +Giving it some time to do so. + +[1]: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/open-iscsi/20171114_135029_17bf1@/log.gz + +LP, this was unfair to reverse-pass me :-) +Anyway - done - thanks Julian and James C. for your work on that. + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a8b154a637b586441b + diff --git a/results/classifier/118/review/1728448 b/results/classifier/118/review/1728448 new file mode 100644 index 000000000..5d6ea57f2 --- /dev/null +++ b/results/classifier/118/review/1728448 @@ -0,0 +1,132 @@ +register: 0.889 +device: 0.885 +architecture: 0.858 +peripherals: 0.844 +assembly: 0.822 +kernel: 0.822 +permissions: 0.797 +PID: 0.776 +graphic: 0.767 +user-level: 0.763 +debug: 0.746 +semantic: 0.733 +boot: 0.729 +socket: 0.726 +files: 0.707 +arm: 0.707 +network: 0.687 +performance: 0.682 +risc-v: 0.668 +mistranslation: 0.645 +KVM: 0.604 +virtual: 0.604 +hypervisor: 0.590 +VMM: 0.590 +ppc: 0.511 +vnc: 0.422 +TCG: 0.405 +x86: 0.318 +i386: 0.274 +-------------------- +arm: 0.994 +virtual: 0.913 +kernel: 0.673 +user-level: 0.567 +device: 0.278 +TCG: 0.194 +VMM: 0.181 +boot: 0.157 +hypervisor: 0.132 +PID: 0.132 +register: 0.098 +architecture: 0.081 +files: 0.064 +socket: 0.062 +vnc: 0.057 +debug: 0.054 +peripherals: 0.030 +performance: 0.026 +semantic: 0.023 +assembly: 0.006 +graphic: 0.004 +network: 0.004 +risc-v: 0.003 +mistranslation: 0.003 +x86: 0.001 +permissions: 0.001 +KVM: 0.001 +i386: 0.001 +ppc: 0.001 + +qemu-system-arm segmentation fault with cpu cortex-m* + +I try to run an emulation with qemu-system-arm under a cpu cortex-m3 but any execution under the processor result by a segmentation fault. + +My command is : qemu-system-arm -m 256 -M versatilepb -cpu cortex-m3 -kernel ~/qemu/wheezy/vmlinuz-3.2.0-4-versatile -initrd ~/qemu/wheezy/initrd.img-3.2.0-4-versatile -hda ~/qemu/wheezy/hda.img -append 'root=/dev/sda1' + +If a lauch the emulation without specifying a cpu equivalent to cortex-m*, the vm opens up well and works but I absolutely need to run it under cortex-m3. + + +Do you have any idea why I have this problem only with this type of processor ? + +I also try with other boards different from versatilepb but I have the same result. + +I am under ubuntu 17 64bits during my test. + +On 29 October 2017 at 19:24, Kevin <email address hidden> wrote: +> I try to run an emulation with qemu-system-arm under a cpu cortex-m3 but +> any execution under the processor result by a segmentation fault. +> +> My command is : qemu-system-arm -m 256 -M versatilepb -cpu cortex-m3 +> -kernel ~/qemu/wheezy/vmlinuz-3.2.0-4-versatile -initrd +> ~/qemu/wheezy/initrd.img-3.2.0-4-versatile -hda ~/qemu/wheezy/hda.img +> -append 'root=/dev/sda1' + +This command line is never going to work, for multiple reasons. +Unfortunately QEMU currently doesn't do a good job of identifying +option combinations which we know are wrong (like -cpu cortex-m3 +with -M versatilepb) and printing an error message. + +The major problem here is that the cortex-m3 is a microcontroller, +which is significantly different from the 'A-profile' devices +that Linux runs on. It has no MMU and usually 16MB of RAM or less: +why are you trying to run Linux on it? This will never work. + +Secondly, the "versatilepb" board is not a board which you can +use a Cortex-M3 with -- it's only intended to work with certain +CPUs, mainly the arm926. + +Thirdly, that looks like a prebuilt versatile kernel image -- it +probably won't work with a random CPU that's not the one the +versatile has, and it *definitely* won't work with the M3. + +Basic rule of thumb for QEMU ARM boards -- don't try to specify +"-cpu" unless you have documentation that specifically tells you +to. You're much more likely to create something that's just +a broken config that guest software can't handle. This is +always true for the Cortex-M3 -- unless the board is intended +to work with the M3 and is creating the correct interrupt +controller, you'll just end up with a broken model. + +If you need to use the Cortex-M3 then use one of the boards +which works with it -- lm3s6965evb, lm3s811evb, mps2-an385, +mps2-an511, or netduino2. You'll also need to run guest code +which is actually built for the board you're using and for +the Cortex-M3 (likely some kind of RTOS, or bare metal code.) +The MPS2 boards have the most RAM, but they're only in recent +QEMU versions. + +thanks +-- PMM + + +Thank you for you answer. + +I wanted to emulate under cortex-M3 because I need to exéutute an executable who will install a kernel but only runs under cortex-M3, for then realized fuzzing on this kernel. + +But, I will try with freeRTOS. + + +I'm closing this bug as it's a command line issue. Please open a new bug if you have further problems. + + diff --git a/results/classifier/118/review/1728615 b/results/classifier/118/review/1728615 new file mode 100644 index 000000000..2f8596856 --- /dev/null +++ b/results/classifier/118/review/1728615 @@ -0,0 +1,585 @@ +TCG: 0.833 +VMM: 0.822 +KVM: 0.810 +vnc: 0.784 +peripherals: 0.781 +ppc: 0.763 +user-level: 0.762 +x86: 0.756 +risc-v: 0.726 +hypervisor: 0.715 +mistranslation: 0.709 +i386: 0.664 +graphic: 0.662 +virtual: 0.635 +boot: 0.618 +performance: 0.599 +architecture: 0.598 +arm: 0.597 +register: 0.591 +permissions: 0.581 +debug: 0.577 +device: 0.575 +files: 0.564 +assembly: 0.534 +semantic: 0.530 +kernel: 0.525 +PID: 0.487 +socket: 0.480 +network: 0.468 +-------------------- +ppc: 0.929 +debug: 0.849 +architecture: 0.711 +hypervisor: 0.615 +performance: 0.118 +files: 0.058 +TCG: 0.038 +PID: 0.037 +assembly: 0.028 +virtual: 0.024 +register: 0.023 +kernel: 0.020 +semantic: 0.015 +device: 0.008 +user-level: 0.007 +VMM: 0.004 +KVM: 0.004 +boot: 0.003 +graphic: 0.003 +peripherals: 0.003 +permissions: 0.002 +network: 0.002 +risc-v: 0.002 +socket: 0.002 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-io crashes with SIGABRT and Assertion `c->entries[i].offset != 0' failed + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files named backing_img.file and test.img to a directory +2. And customize the following command to point to the above directory and run the same. +/usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" + +3.Output of the above command. +qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +Aborted (core dumped) + +from gdb: +(gdb) bt +#0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +#1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +#2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +#4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +#5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +#6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 +#7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +#8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) + at block/qcow2-cluster.c:1221 +#9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1324 +#10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1511 +#11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +#12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +#13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) + at block/io.c:1440 +#14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +#15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +#16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +#17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +#18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +#19 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +No symbol table info available. +#2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +No symbol table info available. +#3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +No symbol table info available. +#4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 + i = 0 + __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +#5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 + s = 0x2e893210 + refcount_table_index = 0 + ret = 0 + new_block = 0 + blocks_used = 72057594818669408 + meta_offset = 1572863 +#6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) + at block/qcow2-refcount.c:834 + block_index = 268870408 + refcount = 780741808 + cluster_index = 2 + table_index = 0 + s = 0x2e893210 + start = 1048576 + last = 1048576 + cluster_offset = 1048576 + refcount_block = 0x3fff81200000 + old_table_index = -1 + ret = 16383 +#7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 + s = 0x2e893210 + cluster_index = 3 + refcount = 0 + i = 1 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +#8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) + at block/qcow2-cluster.c:1221 + ret = 780743184 + s = 0x2e893210 +#9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1324 + s = 0x2e893210 + l2_index = 4 + l2_table = 0x0 + entry = 0 + nb_clusters = 1 + ret = 0 +---Type <return> to continue, or q <return> to quit--- + keep_old_clusters = false + alloc_cluster_offset = 1048576 + __PRETTY_FUNCTION__ = "handle_alloc" + requested_bytes = 17960562528 + avail_bytes = -2133853344 + nb_bytes = 16383 + old_m = 0x100000000 +#10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) + at block/qcow2-cluster.c:1511 + s = 0x2e893210 + start = 2097152 + remaining = 962560 + cluster_offset = 1048576 + cur_bytes = 962560 + ret = 0 + __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +#11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 + s = 0x2e893210 + offset_in_cluster = 0 + ret = 0 + cur_bytes = 1486848 + cluster_offset = 524288 + hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} + bytes_done = 220672 + cluster_data = 0x0 + l2meta = 0x0 + __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +#12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 + drv = 0x102036f0 <bdrv_qcow2> + sector_num = 780706080 + nb_sectors = 3069122264 + ret = -203160320 + __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +#13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) + at block/io.c:1440 + bs = 0x2e886f60 + drv = 0x102036f0 <bdrv_qcow2> + waited = false + ret = 0 + end_sector = 5976 + bytes_remaining = 1707520 + max_transfer = 2147483647 + __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +#14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 + bs = 0x2e886f60 + req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, + overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} + align = 1 + head_buf = 0x0 +---Type <return> to continue, or q <return> to quit--- + tail_buf = 0x0 + local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} + use_local_qiov = false + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +#15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 + ret = 0 + bs = 0x2e886f60 +#16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 + rwco = 0x3fffc85f0c08 +#17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x2e895a90, i = {780753552, 0}} + self = 0x2e895a90 + co = 0x2e895a90 +#18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#19 0x0000000000000000 in ?? () +No symbol table info available. + +Will attach the 'image_fuzzer' images. + + + +On Wed 01 Nov 2017 07:13:08 AM CET, Thomas Huth wrote: +> On 30.10.2017 15:43, R.Nageswara Sastry wrote: +>> Public bug reported: +>> +>> git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +>> This is on ppc64le architecture. +>> +>> Re-production steps: +>> +>> 1. Copy the attached files named backing_img.file and test.img to a directory +>> 2. And customize the following command to point to the above directory and run the same. +>> /usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" +>> +>> 3.Output of the above command. +>> qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +>> Aborted (core dumped) +>> +>> from gdb: +>> (gdb) bt +>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>> at block/qcow2-refcount.c:834 +>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>> at block/qcow2-cluster.c:1221 +>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1324 +>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1511 +>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>> at block/io.c:1440 +>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>> #19 0x0000000000000000 in ?? () +>> (gdb) bt full +>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>> No symbol table info available. +>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>> No symbol table info available. +>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>> No symbol table info available. +>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>> No symbol table info available. +>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>> i = 0 +>> __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>> s = 0x2e893210 +>> refcount_table_index = 0 +>> ret = 0 +>> new_block = 0 +>> blocks_used = 72057594818669408 +>> meta_offset = 1572863 +>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>> at block/qcow2-refcount.c:834 +>> block_index = 268870408 +>> refcount = 780741808 +>> cluster_index = 2 +>> table_index = 0 +>> s = 0x2e893210 +>> start = 1048576 +>> last = 1048576 +>> cluster_offset = 1048576 +>> refcount_block = 0x3fff81200000 +>> old_table_index = -1 +>> ret = 16383 +>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>> s = 0x2e893210 +>> cluster_index = 3 +>> refcount = 0 +>> i = 1 +>> ret = 0 +>> __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>> at block/qcow2-cluster.c:1221 +>> ret = 780743184 +>> s = 0x2e893210 +>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1324 +>> s = 0x2e893210 +>> l2_index = 4 +>> l2_table = 0x0 +>> entry = 0 +>> nb_clusters = 1 +>> ret = 0 +>> ---Type <return> to continue, or q <return> to quit--- +>> keep_old_clusters = false +>> alloc_cluster_offset = 1048576 +>> __PRETTY_FUNCTION__ = "handle_alloc" +>> requested_bytes = 17960562528 +>> avail_bytes = -2133853344 +>> nb_bytes = 16383 +>> old_m = 0x100000000 +>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>> at block/qcow2-cluster.c:1511 +>> s = 0x2e893210 +>> start = 2097152 +>> remaining = 962560 +>> cluster_offset = 1048576 +>> cur_bytes = 962560 +>> ret = 0 +>> __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>> s = 0x2e893210 +>> offset_in_cluster = 0 +>> ret = 0 +>> cur_bytes = 1486848 +>> cluster_offset = 524288 +>> hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} +>> bytes_done = 220672 +>> cluster_data = 0x0 +>> l2meta = 0x0 +>> __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>> drv = 0x102036f0 <bdrv_qcow2> +>> sector_num = 780706080 +>> nb_sectors = 3069122264 +>> ret = -203160320 +>> __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>> at block/io.c:1440 +>> bs = 0x2e886f60 +>> drv = 0x102036f0 <bdrv_qcow2> +>> waited = false +>> ret = 0 +>> end_sector = 5976 +>> bytes_remaining = 1707520 +>> max_transfer = 2147483647 +>> __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>> bs = 0x2e886f60 +>> req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, +>> overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, +>> sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} +>> align = 1 +>> head_buf = 0x0 +>> ---Type <return> to continue, or q <return> to quit--- +>> tail_buf = 0x0 +>> local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} +>> use_local_qiov = false +>> ret = 0 +>> __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>> ret = 0 +>> bs = 0x2e886f60 +>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>> rwco = 0x3fffc85f0c08 +>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>> arg = {p = 0x2e895a90, i = {780753552, 0}} +>> self = 0x2e895a90 +>> co = 0x2e895a90 +>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>> No symbol table info available. +>> #19 0x0000000000000000 in ?? () +>> No symbol table info available. +> +> Can you also reproduce this on x86, or is it specific to ppc64? + +I can actually reproduce it myself, I'll take a look. + +Berto + + +On Wed 01 Nov 2017 09:55:21 AM CET, Alberto Garcia wrote: +> On Wed 01 Nov 2017 07:13:08 AM CET, Thomas Huth wrote: +>> On 30.10.2017 15:43, R.Nageswara Sastry wrote: +>>> Public bug reported: +>>> +>>> git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +>>> This is on ppc64le architecture. +>>> +>>> Re-production steps: +>>> +>>> 1. Copy the attached files named backing_img.file and test.img to a directory +>>> 2. And customize the following command to point to the above directory and run the same. +>>> /usr/bin/qemu-io <path to>/test.img -c "write 1352192 1707520" +>>> +>>> 3.Output of the above command. +>>> qemu-io: block/qcow2-cache.c:411: qcow2_cache_entry_mark_dirty: Assertion `c->entries[i].offset != 0' failed. +>>> Aborted (core dumped) +>>> +>>> from gdb: +>>> (gdb) bt +>>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>>> at block/qcow2-refcount.c:834 +>>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>>> at block/qcow2-cluster.c:1221 +>>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1324 +>>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1511 +>>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>>> at block/io.c:1440 +>>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>>> #19 0x0000000000000000 in ?? () +>>> (gdb) bt full +>>> #0 0x00003fff833eeff0 in raise () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #1 0x00003fff833f136c in abort () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #2 0x00003fff833e4c44 in __assert_fail_base () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #3 0x00003fff833e4d34 in __assert_fail () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #4 0x000000001006a594 in qcow2_cache_entry_mark_dirty (bs=0x2e886f60, c=0x2e879700, table=0x3fff81200000) at block/qcow2-cache.c:411 +>>> i = 0 +>>> __PRETTY_FUNCTION__ = "qcow2_cache_entry_mark_dirty" +>>> #5 0x0000000010056154 in alloc_refcount_block (bs=0x2e886f60, cluster_index=2, refcount_block=0x3fff80cff808) at block/qcow2-refcount.c:417 +>>> s = 0x2e893210 +>>> refcount_table_index = 0 +>>> ret = 0 +>>> new_block = 0 +>>> blocks_used = 72057594818669408 +>>> meta_offset = 1572863 +>>> #6 0x0000000010057520 in update_refcount (bs=0x2e886f60, offset=1048576, length=524288, addend=1, decrease=false, type=QCOW2_DISCARD_NEVER) +>>> at block/qcow2-refcount.c:834 +>>> block_index = 268870408 +>>> refcount = 780741808 +>>> cluster_index = 2 +>>> table_index = 0 +>>> s = 0x2e893210 +>>> start = 1048576 +>>> last = 1048576 +>>> cluster_offset = 1048576 +>>> refcount_block = 0x3fff81200000 +>>> old_table_index = -1 +>>> ret = 16383 +>>> #7 0x0000000010057dc8 in qcow2_alloc_clusters_at (bs=0x2e886f60, offset=1048576, nb_clusters=1) at block/qcow2-refcount.c:1032 +>>> s = 0x2e893210 +>>> cluster_index = 3 +>>> refcount = 0 +>>> i = 1 +>>> ret = 0 +>>> __PRETTY_FUNCTION__ = "qcow2_alloc_clusters_at" +>>> #8 0x00000000100636d8 in do_alloc_cluster_offset (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cff9e0, nb_clusters=0x3fff80cff9d8) +>>> at block/qcow2-cluster.c:1221 +>>> ret = 780743184 +>>> s = 0x2e893210 +>>> #9 0x0000000010063afc in handle_alloc (bs=0x2e886f60, guest_offset=2097152, host_offset=0x3fff80cffab0, bytes=0x3fff80cffab8, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1324 +>>> s = 0x2e893210 +>>> l2_index = 4 +>>> l2_table = 0x0 +>>> entry = 0 +>>> nb_clusters = 1 +>>> ret = 0 +>>> ---Type <return> to continue, or q <return> to quit--- +>>> keep_old_clusters = false +>>> alloc_cluster_offset = 1048576 +>>> __PRETTY_FUNCTION__ = "handle_alloc" +>>> requested_bytes = 17960562528 +>>> avail_bytes = -2133853344 +>>> nb_bytes = 16383 +>>> old_m = 0x100000000 +>>> #10 0x0000000010064178 in qcow2_alloc_cluster_offset (bs=0x2e886f60, offset=1572864, bytes=0x3fff80cffb4c, host_offset=0x3fff80cffb58, m=0x3fff80cffb60) +>>> at block/qcow2-cluster.c:1511 +>>> s = 0x2e893210 +>>> start = 2097152 +>>> remaining = 962560 +>>> cluster_offset = 1048576 +>>> cur_bytes = 962560 +>>> ret = 0 +>>> __PRETTY_FUNCTION__ = "qcow2_alloc_cluster_offset" +>>> #11 0x000000001004d3f4 in qcow2_co_pwritev (bs=0x2e886f60, offset=1572864, bytes=1486848, qiov=0x3fffc85f0bf0, flags=0) at block/qcow2.c:1919 +>>> s = 0x2e893210 +>>> offset_in_cluster = 0 +>>> ret = 0 +>>> cur_bytes = 1486848 +>>> cluster_offset = 524288 +>>> hd_qiov = {iov = 0x2e858660, niov = 1, nalloc = 1, size = 220672} +>>> bytes_done = 220672 +>>> cluster_data = 0x0 +>>> l2meta = 0x0 +>>> __PRETTY_FUNCTION__ = "qcow2_co_pwritev" +>>> #12 0x00000000100a9648 in bdrv_driver_pwritev (bs=0x2e886f60, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=16) at block/io.c:898 +>>> drv = 0x102036f0 <bdrv_qcow2> +>>> sector_num = 780706080 +>>> nb_sectors = 3069122264 +>>> ret = -203160320 +>>> __PRETTY_FUNCTION__ = "bdrv_driver_pwritev" +>>> #13 0x00000000100ab630 in bdrv_aligned_pwritev (child=0x2e8927f0, req=0x3fff80cffdd8, offset=1352192, bytes=1707520, align=1, qiov=0x3fffc85f0bf0, flags=16) +>>> at block/io.c:1440 +>>> bs = 0x2e886f60 +>>> drv = 0x102036f0 <bdrv_qcow2> +>>> waited = false +>>> ret = 0 +>>> end_sector = 5976 +>>> bytes_remaining = 1707520 +>>> max_transfer = 2147483647 +>>> __PRETTY_FUNCTION__ = "bdrv_aligned_pwritev" +>>> #14 0x00000000100ac4ac in bdrv_co_pwritev (child=0x2e8927f0, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/io.c:1691 +>>> bs = 0x2e886f60 +>>> req = {bs = 0x2e886f60, offset = 1352192, bytes = 1707520, type = BDRV_TRACKED_WRITE, serialising = false, overlap_offset = 1352192, +>>> overlap_bytes = 1707520, list = {le_next = 0x0, le_prev = 0x2e88a1d8}, co = 0x2e895a90, wait_queue = {entries = {sqh_first = 0x0, +>>> sqh_last = 0x3fff80cffe20}}, waiting_for = 0x0} +>>> align = 1 +>>> head_buf = 0x0 +>>> ---Type <return> to continue, or q <return> to quit--- +>>> tail_buf = 0x0 +>>> local_qiov = {iov = 0x3fff80cffdb0, niov = -2133852688, nalloc = 16383, size = 1352192} +>>> use_local_qiov = false +>>> ret = 0 +>>> __PRETTY_FUNCTION__ = "bdrv_co_pwritev" +>>> #15 0x000000001008da0c in blk_co_pwritev (blk=0x2e879410, offset=1352192, bytes=1707520, qiov=0x3fffc85f0bf0, flags=BDRV_REQ_FUA) at block/block-backend.c:1085 +>>> ret = 0 +>>> bs = 0x2e886f60 +>>> #16 0x000000001008db68 in blk_write_entry (opaque=0x3fffc85f0c08) at block/block-backend.c:1110 +>>> rwco = 0x3fffc85f0c08 +>>> #17 0x00000000101aa444 in coroutine_trampoline (i0=780753552, i1=0) at util/coroutine-ucontext.c:79 +>>> arg = {p = 0x2e895a90, i = {780753552, 0}} +>>> self = 0x2e895a90 +>>> co = 0x2e895a90 +>>> #18 0x00003fff83402b9c in makecontext () from /lib64/libc.so.6 +>>> No symbol table info available. +>>> #19 0x0000000000000000 in ?? () +>>> No symbol table info available. +>> +>> Can you also reproduce this on x86, or is it specific to ppc64? + +I'm working on a fix, I'll send the patch later today. + +Berto + + +The attached image is corrupted and QEMU doesn't handle it correctly. + +Here are the fixes for this and other related problems: + + https://lists.gnu.org/archive/html/qemu-block/2017-11/msg00010.html + + +Fix has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6bf45d59f98c898b7d79 + diff --git a/results/classifier/118/review/1728660 b/results/classifier/118/review/1728660 new file mode 100644 index 000000000..e00952f51 --- /dev/null +++ b/results/classifier/118/review/1728660 @@ -0,0 +1,120 @@ +user-level: 0.834 +architecture: 0.808 +virtual: 0.804 +device: 0.796 +graphic: 0.795 +register: 0.787 +permissions: 0.768 +peripherals: 0.762 +TCG: 0.751 +performance: 0.743 +KVM: 0.741 +files: 0.739 +arm: 0.733 +hypervisor: 0.716 +assembly: 0.711 +semantic: 0.700 +VMM: 0.694 +debug: 0.693 +risc-v: 0.689 +PID: 0.689 +ppc: 0.685 +boot: 0.685 +socket: 0.630 +x86: 0.629 +kernel: 0.608 +network: 0.601 +i386: 0.565 +vnc: 0.547 +mistranslation: 0.450 +-------------------- +ppc: 0.816 +architecture: 0.783 +debug: 0.519 +files: 0.087 +TCG: 0.057 +hypervisor: 0.057 +PID: 0.042 +performance: 0.038 +virtual: 0.026 +register: 0.009 +semantic: 0.008 +user-level: 0.006 +assembly: 0.006 +device: 0.006 +network: 0.005 +kernel: 0.004 +VMM: 0.003 +graphic: 0.003 +peripherals: 0.002 +socket: 0.002 +boot: 0.002 +KVM: 0.002 +permissions: 0.001 +risc-v: 0.001 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-io segfaults at block/io.c:2545 + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "discard 108544 97792" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 +2545 if (bs->drv->bdrv_co_pdiscard) { +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 +#1 0x000000001008f260 in blk_co_pdiscard (blk=0x3ee79410, offset=108544, bytes=97792) at block/block-backend.c:1447 +#2 0x0000000010090884 in blk_pdiscard_entry (opaque=0x3fffd7402c58) at block/block-backend.c:1851 +#3 0x00000000101aa444 in coroutine_trampoline (i0=1055521728, i1=0) at util/coroutine-ucontext.c:79 +#4 0x00003fff7a3d2b9c in makecontext () from /lib64/libc.so.6 +#5 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 + num = 9728 + req = {bs = 0x3ee89ad0, offset = 108544, bytes = 97792, type = BDRV_TRACKED_DISCARD, serialising = false, overlap_offset = 108544, + overlap_bytes = 97792, list = {le_next = 0x0, le_prev = 0x3ee8cd48}, co = 0x3ee9fbc0, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff7823fe10}}, waiting_for = 0x0} + max_pdiscard = 2147467264 + ret = 0 + head = 0 + tail = 9728 + align = 16384 + __PRETTY_FUNCTION__ = "bdrv_co_pdiscard" +#1 0x000000001008f260 in blk_co_pdiscard (blk=0x3ee79410, offset=108544, bytes=97792) at block/block-backend.c:1447 + ret = 0 +#2 0x0000000010090884 in blk_pdiscard_entry (opaque=0x3fffd7402c58) at block/block-backend.c:1851 + rwco = 0x3fffd7402c58 +#3 0x00000000101aa444 in coroutine_trampoline (i0=1055521728, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x3ee9fbc0, i = {1055521728, 0}} + self = 0x3ee9fbc0 + co = 0x3ee9fbc0 +#4 0x00003fff7a3d2b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#5 0x0000000000000000 in ?? () +No symbol table info available. + + + +Hi, + +And once again, thanks a lot for reporting this bug! Here, too, I've found a fix and I'll send a patch once I've written a test case. + +Max + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d470ad42acfc73c45d3e8e + diff --git a/results/classifier/118/review/1728661 b/results/classifier/118/review/1728661 new file mode 100644 index 000000000..5d3696f5d --- /dev/null +++ b/results/classifier/118/review/1728661 @@ -0,0 +1,178 @@ +user-level: 0.900 +virtual: 0.886 +permissions: 0.881 +register: 0.880 +graphic: 0.861 +KVM: 0.852 +device: 0.849 +performance: 0.830 +architecture: 0.820 +TCG: 0.810 +hypervisor: 0.794 +risc-v: 0.781 +arm: 0.773 +debug: 0.770 +VMM: 0.762 +x86: 0.753 +semantic: 0.749 +assembly: 0.745 +peripherals: 0.745 +ppc: 0.744 +vnc: 0.734 +files: 0.723 +network: 0.719 +PID: 0.718 +socket: 0.691 +kernel: 0.687 +boot: 0.665 +mistranslation: 0.600 +i386: 0.589 +-------------------- +ppc: 0.884 +debug: 0.877 +architecture: 0.802 +files: 0.109 +TCG: 0.061 +performance: 0.039 +hypervisor: 0.035 +PID: 0.027 +virtual: 0.020 +semantic: 0.009 +register: 0.007 +assembly: 0.006 +user-level: 0.006 +network: 0.005 +device: 0.005 +kernel: 0.004 +VMM: 0.003 +graphic: 0.002 +socket: 0.002 +boot: 0.002 +peripherals: 0.002 +KVM: 0.001 +permissions: 0.001 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.001 +x86: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-io segfaults at block/qcow2.h:533 + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "truncate 66560" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x0000000010054cec in get_refblock_offset (s=0x32ca3210, offset=9223372036854775296) at ./block/qcow2.h:533 +533 return s->refcount_table[index] & REFT_OFFSET_MASK; +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x0000000010054cec in get_refblock_offset (s=0x32ca3210, offset=9223372036854775296) at ./block/qcow2.h:533 +#1 0x000000001005df4c in qcow2_discard_refcount_block (bs=0x32c96f60, discard_block_offs=9223372036854775296) at block/qcow2-refcount.c:3070 +#2 0x000000001005e5c4 in qcow2_shrink_reftable (bs=0x32c96f60) at block/qcow2-refcount.c:3169 +#3 0x0000000010051184 in qcow2_truncate (bs=0x32c96f60, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/qcow2.c:3155 +#4 0x0000000010016480 in bdrv_truncate (child=0x32ca6270, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block.c:3585 +#5 0x0000000010090800 in blk_truncate (blk=0x32c89410, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/block-backend.c:1845 +#6 0x0000000010023028 in truncate_f (blk=0x32c89410, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:1580 +#7 0x000000001001e648 in command (blk=0x32c89410, ct=0x32c96e30, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:117 +#8 0x0000000010024d64 in qemuio_command (blk=0x32c89410, cmd=0x3fffc052f66e "truncate 66560") at qemu-io-cmds.c:2291 +#9 0x000000001000b540 in command_loop () at qemu-io.c:374 +#10 0x000000001000c05c in main (argc=4, argv=0x3fffc051f618) at qemu-io.c:630 +(gdb) bt full +#0 0x0000000010054cec in get_refblock_offset (s=0x32ca3210, offset=9223372036854775296) at ./block/qcow2.h:533 + index = 4294967295 +#1 0x000000001005df4c in qcow2_discard_refcount_block (bs=0x32c96f60, discard_block_offs=9223372036854775296) at block/qcow2-refcount.c:3070 + s = 0x32ca3210 + refblock_offs = 852111520 + cluster_index = 16384 + block_index = 3226593616 + refblock = 0x32cb9570 + ret = 16384 + __PRETTY_FUNCTION__ = "qcow2_discard_refcount_block" +#2 0x000000001005e5c4 in qcow2_shrink_reftable (bs=0x32c96f60) at block/qcow2-refcount.c:3169 + s = 0x32ca3210 + reftable_tmp = 0x32cb9570 + i = 0 + ret = 0 +#3 0x0000000010051184 in qcow2_truncate (bs=0x32c96f60, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/qcow2.c:3155 + last_cluster = 70367675804416 + old_file_size = 70367675804416 + s = 0x32ca3210 + old_length = 1048576 + new_l1_size = 1 + ret = 0 + __func__ = "qcow2_truncate" + __PRETTY_FUNCTION__ = "qcow2_truncate" + __FUNCTION__ = "qcow2_truncate" +#4 0x0000000010016480 in bdrv_truncate (child=0x32ca6270, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block.c:3585 + bs = 0x32c96f60 + drv = 0x102036f0 <bdrv_qcow2> + ret = 16383 + __PRETTY_FUNCTION__ = "bdrv_truncate" + __func__ = "bdrv_truncate" +#5 0x0000000010090800 in blk_truncate (blk=0x32c89410, offset=66560, prealloc=PREALLOC_MODE_OFF, errp=0x3fffc051ecd8) at block/block-backend.c:1845 + __func__ = "blk_truncate" +#6 0x0000000010023028 in truncate_f (blk=0x32c89410, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:1580 + local_err = 0x0 + offset = 66560 + ret = 0 +#7 0x000000001001e648 in command (blk=0x32c89410, ct=0x32c96e30, argc=2, argv=0x32c685a0) at qemu-io-cmds.c:117 + cmd = 0x32c684c0 "truncate" +#8 0x0000000010024d64 in qemuio_command (blk=0x32c89410, cmd=0x3fffc052f66e "truncate 66560") at qemu-io-cmds.c:2291 + ctx = 0x32c924d0 + input = 0x32c684c0 "truncate" + ct = 0x32c96e30 + v = 0x32c685a0 + c = 2 + done = false +#9 0x000000001000b540 in command_loop () at qemu-io.c:374 + i = 0 + done = 0 + fetchable = 0 +---Type <return> to continue, or q <return> to quit--- + prompted = 0 + input = 0x0 +#10 0x000000001000c05c in main (argc=4, argv=0x3fffc051f618) at qemu-io.c:630 + readonly = 0 + sopt = 0x101b2608 "hVc:d:f:rsnCmkt:T:U" + lopt = {{name = 0x101b26d0 "driver", has_arg = 0, flag = 0x0, val = 104}, {name = 0x101b26d8 "help", has_arg = 0, flag = 0x0, val = 86}, { + name = 0x101b26e0 "version", has_arg = 1, flag = 0x0, val = 99}, {name = 0x101b26e8 "cmd", has_arg = 1, flag = 0x0, val = 102}, { + name = 0x101b26f0 "format", has_arg = 0, flag = 0x0, val = 114}, {name = 0x101b2700 "y", has_arg = 0, flag = 0x0, val = 115}, { + name = 0x101b2710 "", has_arg = 0, flag = 0x0, val = 110}, {name = 0x101b2718 "nocache", has_arg = 0, flag = 0x0, val = 67}, { + name = 0x101b2728 "read", has_arg = 0, flag = 0x0, val = 109}, {name = 0x101b2738 "", has_arg = 0, flag = 0x0, val = 107}, { + name = 0x101b2748 "io", has_arg = 1, flag = 0x0, val = 100}, {name = 0x101b2750 "discard", has_arg = 1, flag = 0x0, val = 116}, { + name = 0x101b2758 "cache", has_arg = 1, flag = 0x0, val = 84}, {name = 0x101b25e8 "object", has_arg = 1, flag = 0x0, val = 256}, { + name = 0x101b2760 "trace", has_arg = 0, flag = 0x0, val = 257}, {name = 0x101b1c48 "force-share", has_arg = 0, flag = 0x0, val = 85}, {name = 0x0, + has_arg = 0, flag = 0x0, val = 0}} + c = -1 + opt_index = 0 + flags = 16386 + writethrough = true + local_error = 0x0 + opts = 0x0 + format = 0x0 + trace_file = 0x0 + force_share = false + +image_fuzzer image will be attached. + + + +Hi, + +And finally, also here, thanks a lot for reporting this bug! I've found a fix; sending a patch might take a little longer, though... + +Max + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=23482f8a603a7fc591b770 + diff --git a/results/classifier/118/review/1729 b/results/classifier/118/review/1729 new file mode 100644 index 000000000..116a603f2 --- /dev/null +++ b/results/classifier/118/review/1729 @@ -0,0 +1,107 @@ +arm: 0.952 +x86: 0.947 +ppc: 0.941 +performance: 0.884 +device: 0.875 +kernel: 0.870 +graphic: 0.865 +network: 0.847 +PID: 0.829 +architecture: 0.813 +TCG: 0.805 +socket: 0.801 +vnc: 0.769 +peripherals: 0.769 +permissions: 0.765 +files: 0.764 +user-level: 0.764 +assembly: 0.751 +VMM: 0.730 +register: 0.726 +risc-v: 0.634 +boot: 0.616 +semantic: 0.563 +debug: 0.508 +hypervisor: 0.437 +KVM: 0.397 +i386: 0.377 +mistranslation: 0.373 +virtual: 0.308 +-------------------- +user-level: 0.828 +x86: 0.810 +debug: 0.149 +TCG: 0.117 +virtual: 0.101 +files: 0.094 +arm: 0.044 +PID: 0.027 +register: 0.020 +network: 0.016 +semantic: 0.010 +performance: 0.006 +device: 0.006 +architecture: 0.005 +socket: 0.005 +kernel: 0.004 +boot: 0.004 +VMM: 0.002 +i386: 0.002 +assembly: 0.002 +peripherals: 0.002 +ppc: 0.001 +permissions: 0.001 +risc-v: 0.001 +graphic: 0.001 +KVM: 0.001 +vnc: 0.001 +mistranslation: 0.001 +hypervisor: 0.001 + +mremap fails with EFAULT if address range overlaps with stack guard +Description of problem: +When running 32-bit user-static on 64-bit host, `mremap` behave differently from the kernel. This difference let programs that call `pthread_getattr_np` on musl-libc to run into a loop on repeated calling `mremap`. + +https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c + +``` c + while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE, 0)==MAP_FAILED && errno==ENOMEM) + l += PAGE_SIZE; +``` +Steps to reproduce: +Compile the following program against musl-libc arm 32-bit, and run it in qemu-user-static on x86_64 host. + +``` c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} +``` + +For example, on x86_64 fedora 38 with podman and qemu-user-static installed, we can reproduce this with alpine container: + +``` +$ podman run --rm -it --arch arm/v7 docker.io/library/alpine:latest + +/ # apk add alpine-sdk + +...... + +/ # cat test.c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} + +/ # gcc test.c + +/ # ./a.out +``` +Additional information: +Original thread on musl mail list where this was initially reported: https://www.openwall.com/lists/musl/2017/06/15/9 diff --git a/results/classifier/118/review/1735049 b/results/classifier/118/review/1735049 new file mode 100644 index 000000000..9e9bf7d7c --- /dev/null +++ b/results/classifier/118/review/1735049 @@ -0,0 +1,113 @@ +architecture: 0.829 +semantic: 0.816 +mistranslation: 0.758 +graphic: 0.750 +performance: 0.725 +device: 0.692 +x86: 0.615 +i386: 0.598 +files: 0.593 +arm: 0.587 +kernel: 0.569 +user-level: 0.555 +hypervisor: 0.515 +ppc: 0.514 +TCG: 0.501 +permissions: 0.476 +vnc: 0.470 +socket: 0.434 +boot: 0.411 +PID: 0.401 +risc-v: 0.391 +register: 0.380 +network: 0.350 +VMM: 0.345 +debug: 0.332 +assembly: 0.280 +peripherals: 0.279 +KVM: 0.263 +virtual: 0.255 +-------------------- +x86: 0.994 +hypervisor: 0.800 +performance: 0.515 +virtual: 0.432 +TCG: 0.318 +semantic: 0.251 +arm: 0.080 +architecture: 0.048 +files: 0.032 +register: 0.018 +debug: 0.018 +PID: 0.016 +user-level: 0.009 +i386: 0.007 +kernel: 0.007 +device: 0.006 +boot: 0.005 +socket: 0.005 +vnc: 0.004 +risc-v: 0.003 +graphic: 0.003 +VMM: 0.002 +assembly: 0.002 +KVM: 0.002 +network: 0.001 +peripherals: 0.001 +permissions: 0.001 +ppc: 0.001 +mistranslation: 0.001 + +Need MTTCG support for x86 guests + +MTTCG support is notably absent for x86_64 guests. The last Wiki update on MTTCG was back in 2015, and I am having some difficulty determining the current status of the underlying requirements to enable this feature on x86 hosts. + +For instance, has support for strong-on-weak memory consistency been added into QEMU GIT at this point? + +Thanks! + +Patches are now on the list to enable MTTCG for i386 and x86_64 guests. See v2 here: + +https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00237.html + +I'm hoping these patches will be in the next QEMU release. + +Regarding your last question: +> For instance, has support for strong-on-weak memory consistency been added into QEMU GIT at this point? + +Yes, TCG inserts the appropriate barriers around memory accesses since commit b32dc3370a ("tcg: Implement implicit ordering semantics", 2017-09-05) + + + +This feature is in QEMU v3.1, which was released today. + +See the discussion linked below that says that strong on weak is not actually fully supported yet. + +Is that discussion correct? + +=== + +In short they explained to me that since the host arm64 is a weaker memory order than the guest x86 they disabled mttcg because if they would implement it would slow everything down but the good news is that if the guest is the same memory order it is not disabled and if it is weaker memory order it is not disabled also. + +https://github.com/utmapp/UTM/issues/257#issuecomment-612675960 + +=== + +Right, that's what I figured from the code. So basically the launchpad comment was incorrect. There is no MTTCG support for x86 on ARM64. + +https://github.com/utmapp/UTM/issues/257#issuecomment-612689011 + +Looks like support for this was not fully added; my apologies for closing this bug too early. + +Adding full support for strong-on-weak emulation would be simple, at least when it comes to memory ordering. The slowdown would be huge though, see Figure 12 in http://www.cs.columbia.edu/~cota/pubs/cota_cgo17.pdf (i.e. ~2x hmean overhead for SPEC). + +The good news is that with hardware support this overhead is ~0 (see SAO in that figure). + +The other feature that is not yet implemented in upstream QEMU is the correct emulation of LL/SC, although for most code out there this shouldn't be an issue in practice given that most parallel code relies on cmpxchg, not on LL/SC pairs. + +I'm reopening this bug an Cc'ing a few people who are more familiar with the current code than I am in case I missed anything. + +OK, looks like I cannot reopen the bug, probably because the bug tracker moved to gitlab. + +If you care about this feature, please file a bug over there: https://gitlab.com/qemu-project/qemu/-/issues + diff --git a/results/classifier/118/review/1736376 b/results/classifier/118/review/1736376 new file mode 100644 index 000000000..1379c3056 --- /dev/null +++ b/results/classifier/118/review/1736376 @@ -0,0 +1,76 @@ +mistranslation: 0.802 +device: 0.522 +ppc: 0.514 +graphic: 0.481 +semantic: 0.478 +network: 0.462 +files: 0.416 +register: 0.371 +vnc: 0.368 +risc-v: 0.347 +architecture: 0.340 +socket: 0.326 +kernel: 0.279 +i386: 0.270 +performance: 0.263 +VMM: 0.256 +PID: 0.255 +boot: 0.240 +virtual: 0.215 +permissions: 0.211 +peripherals: 0.209 +x86: 0.196 +debug: 0.172 +TCG: 0.171 +hypervisor: 0.160 +user-level: 0.157 +arm: 0.156 +assembly: 0.116 +KVM: 0.024 +-------------------- +files: 0.921 +kernel: 0.914 +hypervisor: 0.866 +debug: 0.192 +virtual: 0.093 +x86: 0.067 +device: 0.047 +user-level: 0.044 +TCG: 0.035 +risc-v: 0.033 +VMM: 0.026 +register: 0.024 +ppc: 0.016 +network: 0.013 +arm: 0.012 +i386: 0.010 +architecture: 0.009 +semantic: 0.007 +socket: 0.004 +KVM: 0.004 +peripherals: 0.003 +assembly: 0.003 +vnc: 0.003 +performance: 0.003 +boot: 0.002 +PID: 0.002 +graphic: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +CVE-2017-7471 repeated? + +In the hw/9pfs/9p-proxy.c file I can see the following which is changed because of CVE-2017-7471 in the hw/9pfs/9p-local.c. I might be wrong but I guess that should be changed as well. + +if(dir_path){ +v9fs_path_sprintf(target,"%s/%s",dir_path->data,name); +} +else{ +v9fs_path_sprintf(target,"%s",name); +} + +When using the proxy backend, all accesses to the host filesystem are handled by an external process running in a chroot() jail. No need to bother about paths in this case. + +CVE-2017-7471 is only applicable to the local backend, because accesses are handled by QEMU directly in this case. + + diff --git a/results/classifier/118/review/1741 b/results/classifier/118/review/1741 new file mode 100644 index 000000000..796cb1d0c --- /dev/null +++ b/results/classifier/118/review/1741 @@ -0,0 +1,61 @@ +architecture: 0.976 +debug: 0.852 +device: 0.843 +graphic: 0.812 +user-level: 0.635 +performance: 0.534 +files: 0.467 +register: 0.459 +network: 0.442 +x86: 0.429 +arm: 0.428 +boot: 0.421 +kernel: 0.393 +mistranslation: 0.334 +TCG: 0.314 +i386: 0.275 +vnc: 0.269 +VMM: 0.264 +socket: 0.237 +peripherals: 0.223 +permissions: 0.215 +PID: 0.196 +semantic: 0.190 +risc-v: 0.182 +KVM: 0.163 +ppc: 0.155 +assembly: 0.117 +hypervisor: 0.115 +virtual: 0.054 +-------------------- +architecture: 0.752 +user-level: 0.689 +files: 0.676 +PID: 0.209 +TCG: 0.036 +debug: 0.022 +virtual: 0.015 +assembly: 0.015 +kernel: 0.012 +register: 0.010 +device: 0.008 +semantic: 0.007 +VMM: 0.004 +i386: 0.003 +x86: 0.003 +boot: 0.002 +performance: 0.002 +graphic: 0.002 +KVM: 0.002 +socket: 0.002 +risc-v: 0.001 +network: 0.001 +ppc: 0.001 +hypervisor: 0.000 +peripherals: 0.000 +vnc: 0.000 +mistranslation: 0.000 +permissions: 0.000 +arm: 0.000 + +95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/118/review/1743191 b/results/classifier/118/review/1743191 new file mode 100644 index 000000000..678fc4f40 --- /dev/null +++ b/results/classifier/118/review/1743191 @@ -0,0 +1,537 @@ +semantic: 0.930 +assembly: 0.917 +device: 0.915 +permissions: 0.907 +register: 0.903 +arm: 0.901 +architecture: 0.900 +boot: 0.897 +debug: 0.895 +virtual: 0.894 +PID: 0.893 +user-level: 0.880 +ppc: 0.874 +performance: 0.867 +risc-v: 0.867 +vnc: 0.864 +mistranslation: 0.852 +socket: 0.851 +graphic: 0.843 +KVM: 0.838 +peripherals: 0.835 +x86: 0.822 +hypervisor: 0.819 +VMM: 0.815 +TCG: 0.799 +network: 0.797 +files: 0.788 +kernel: 0.781 +i386: 0.573 +-------------------- +x86: 0.924 +boot: 0.499 +TCG: 0.290 +virtual: 0.186 +kernel: 0.131 +debug: 0.122 +files: 0.043 +user-level: 0.027 +network: 0.010 +register: 0.009 +socket: 0.004 +hypervisor: 0.004 +performance: 0.004 +PID: 0.004 +semantic: 0.003 +device: 0.003 +VMM: 0.003 +graphic: 0.003 +i386: 0.003 +assembly: 0.002 +ppc: 0.002 +peripherals: 0.002 +architecture: 0.002 +permissions: 0.001 +vnc: 0.001 +risc-v: 0.001 +arm: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +Interacting with NetBSD serial console boot blocks no longer works + +The NetBSD boot blocks display a menu allowing the user to make a +selection using the keyboard. For example, when booting a NetBSD +installation CD-ROM, the menu looks like this: + + 1. Install NetBSD + 2. Install NetBSD (no ACPI) + 3. Install NetBSD (no ACPI, no SMP) + 4. Drop to boot prompt + + Choose an option; RETURN for default; SPACE to stop countdown. + Option 1 will be chosen in 30 seconds. + +When booting NetBSD in a recent qemu using an emulated serial console, +making this menu selection no longer works: when you type the selected +number, the keyboard input is ignored, and the 30-second countdown +continues. In older versions of qemu, it works. + +To reproduce the problem, run: + + wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso + qemu-system-x86_64 -nographic -cdrom boot-com.iso + +During the 30-second countdown, press 4 + +Expected behavior: The countdown stops and you get a ">" prompt + +Incorrect behavior: The countdown continues + +There may also be some corruption of the terminal output; for example, +"Option 1 will be chosen in 30 seconds" may be displayed as "Option 1 +will be chosen in p0 seconds". + +Using bisection, I have determined that the problem appeared with qemu +commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was +updated to 1.11 prerelease, and the problem is still there as of +commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac. The host operating +system used for the tests was Debian 9 x86_64. + +Credit for discovering this bug goes to Paul Goyette. + +Reverting to Seabios 1.10 (version rel-1.10.3.0-gb76661dd) fixes this problem. + +Steps: + +$ cd && mkdir seabios-test && cd seabios-test +$ git clone -b 1.10-stable https://github.com/coreboot/seabios.git +$ cd seabios +$ make +$ qemu-system-x86_64 \ +-drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ +-M q35,accel=kvm -m 350M -cpu host -smp $(nproc) \ +-nic user,model=virtio-net-pci,ipv6=off \ +-nographic -bios /home/oc/seabios-test/seabios/out/bios.bin + +Result: +I can interact with NetBSD boot menu and select one of the available options. + +Host: +Linux e130 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64 GNU/Linux + +QEMU emulator version 4.2.0 + + + +Possibly related thread: +"Do we need a cpu with TSC support to run SeaBIOS?" +https://<email address hidden>/msg11726.html + +Workaround: add "-vga none" to the qemu command line. + +@kraxel-redhat, + +I guess "-vga none" is implicit when using -nographic? + +However, for the sake of trying, I've added "-vga none" and it won't solve it for me (when using default bios). + +Gerd Hommann wrote: +> Workaround: add "-vga none" to the qemu command line. + +This supposed workaround does not work for me. + + +@kraxel-redhat: This issue bisects to commit d6728f301d7e6e31ba0ee2fa51ed4a24feab8860 ("add serial console support"). seabios.git/master + "[PATCH] sercon: vbe modeset is int 10h function 4f02 not 4f00" still has the issue. + +I'm using the following command-line: + + qemu-system-x86_64 -M accel=kvm -m 1G -cpu host -cdrom ~/Downloads/boot-com.iso -nographic + +Ah, it's a special serial console boot iso. I was trying the normal NetBSD-<version>-amd64.iso. + +So, it seems seabios sercon and bootloader are fighting over the serial line. + +seabios enables sercon for no-graphical guests ("-machine graphics=off", "-nographics" enables this too). + +So one option is to turn off seabios sercon: "qemu -nographic -machine graphics=on". + +The other option is to turn on seabios sercon and use the normal boot.iso (this needs the "-vga none" workaround from comment 3, or the sercon patch). + +On Fri, 6 Mar 2020 at 13:24, Gerd Hoffmann <email address hidden> wrote: +> So one option is to turn off seabios sercon: "qemu -nographic -machine +> graphics=on". + +This works for me, but only if I turn off "q35", therefore changing +from a sata disk to a plain ide: + +qemu-system-x86_64 \ +-drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ +-drive if=virtio,file=/home/oc/VM/img/newdisk2.img,index=1,media=disk \ +-m 300M -cpu host -smp $(nproc) \ +-nic user,hostfwd=tcp::6665-:22,model=virtio-net-pci,ipv6=off \ +-nographic -machine accel=kvm,graphics=on + + +Just to clarify my last comment, and in absence of updates, if I launch the VM as: + +qemu-system-x86_64 \ +-drive if=virtio,file=/home/oc/VM/img/openbsd.image,index=0,media=disk \ +-drive if=virtio,file=/home/oc/VM/img/openbsd.image.old,index=1,media=disk \ +-M q35,accel=kvm,graphics=on -m 250M -cpu host -smp $(nproc) \ +-nic user,hostfwd=tcp::6666-:22,model=virtio-net-pci -nographic + +(note the -M q35,accel=kvm,graphics=on), the problem still persists. + +I'm still on version 4.2 and I haven't updated to 5.0 yet. + +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. + +This bug was fixed long ago, so long ago that I have no idea when! + +Please close wiwth an appropriate status. + + +On Thu, 22 Apr 2021, Thomas Huth wrote: + +> 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. +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1743191 +> +> Title: +> Interacting with NetBSD serial console boot blocks no longer works +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> The NetBSD boot blocks display a menu allowing the user to make a +> selection using the keyboard. For example, when booting a NetBSD +> installation CD-ROM, the menu looks like this: +> +> 1. Install NetBSD +> 2. Install NetBSD (no ACPI) +> 3. Install NetBSD (no ACPI, no SMP) +> 4. Drop to boot prompt +> +> Choose an option; RETURN for default; SPACE to stop countdown. +> Option 1 will be chosen in 30 seconds. +> +> When booting NetBSD in a recent qemu using an emulated serial console, +> making this menu selection no longer works: when you type the selected +> number, the keyboard input is ignored, and the 30-second countdown +> continues. In older versions of qemu, it works. +> +> To reproduce the problem, run: +> +> wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso +> qemu-system-x86_64 -nographic -cdrom boot-com.iso +> +> During the 30-second countdown, press 4 +> +> Expected behavior: The countdown stops and you get a ">" prompt +> +> Incorrect behavior: The countdown continues +> +> There may also be some corruption of the terminal output; for example, +> "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1 +> will be chosen in p0 seconds". +> +> Using bisection, I have determined that the problem appeared with qemu +> commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was +> updated to 1.11 prerelease, and the problem is still there as of +> commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac. The host operating +> system used for the tests was Debian 9 x86_64. +> +> Credit for discovering this bug goes to Paul Goyette. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1743191/+subscriptions +> +> !DSPAM:60811a8265601949211437! +> +> + ++--------------------+--------------------------+-----------------------+ +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| (Retired) | FA29 0E3B 35AF E8AE 6651 | <email address hidden> | +| Software Developer | 0786 F758 55DE 53BA 7731 | <email address hidden> | ++--------------------+--------------------------+-----------------------+ + + +Paul Goyette wrote: +> This bug was fixed long ago, so long ago that I have no idea when! + +No, it is not fixed, and I did actually check before I switched the +bug state back to "new". + +Perhaps you are specifying "-machine graphics=on" as suggested in one +of the comments? If so, that's a work-around, and an ugly and +nonintuitive one at that, not a fix. +-- +Andreas Gustafsson, <email address hidden> + + +On Thu, 22 Apr 2021 at 13:46, Andreas Gustafsson +<email address hidden> wrote: +> +> Paul Goyette wrote: +> > This bug was fixed long ago, so long ago that I have no idea when! +> +> No, it is not fixed, and I did actually check before I switched the +> bug state back to "new". +> +> Perhaps you are specifying "-machine graphics=on" as suggested in one +> of the comments? If so, that's a work-around, and an ugly and +> nonintuitive one at that, not a fix. +> -- +> Andreas Gustafsson, <email address hidden> + +I am currently using: + +$ qemu-system-x86_64 --version +QEMU emulator version 5.2.0 + +And I have no problem selecting from menu in serial console, so I +assume this is fixed for me. This is my command line: + +$ cat opt/bin/boot-netbsd-virtio +#!/bin/sh +qemu-system-x86_64 \ +-drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ +-drive if=virtio,file=/home/oc/VM/img/netbsd.image.old,index=1,media=disk \ +-M q35,accel=kvm -m 250M -cpu host -smp $(nproc) \ +-nic user,hostfwd=tcp:127.0.0.1:5555-:22,model=virtio-net-pci,ipv6=off \ +-daemonize -display none -vga none \ +-serial mon:telnet:127.0.0.1:6665,server,nowait \ +-pidfile /home/oc/VM/pid/netbsd-pid -nodefaults + +telnet 127.0.0.1 6665 + + + +-- +Ottavio Caruso + + +On Thu, 22 Apr 2021, Ottavio Caruso wrote: + +> On Thu, 22 Apr 2021 at 13:46, Andreas Gustafsson +> <email address hidden> wrote: +>> +>> Paul Goyette wrote: +>>> This bug was fixed long ago, so long ago that I have no idea when! +>> +>> No, it is not fixed, and I did actually check before I switched the +>> bug state back to "new". +>> +>> Perhaps you are specifying "-machine graphics=on" as suggested in one +>> of the comments? If so, that's a work-around, and an ugly and +>> nonintuitive one at that, not a fix. + +Andreas is correct - I am using the suggested work-around, and the +original bug is NOT fixed. + +I believe Andreas has moved the bug back to New status to reflect +that it is not fixed. (Whether or not it is fixed, _I_ should not +have asked to have _his_ bug closed. It's been so long, I almost +believed it was my bug. :) My apologies to Andreas and everyone +else.) + + +>> -- +>> Andreas Gustafsson, <email address hidden> +> +> I am currently using: +> +> $ qemu-system-x86_64 --version +> QEMU emulator version 5.2.0 +> +> And I have no problem selecting from menu in serial console, so I +> assume this is fixed for me. This is my command line: +> +> $ cat opt/bin/boot-netbsd-virtio +> #!/bin/sh +> qemu-system-x86_64 \ +> -drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ +> -drive if=virtio,file=/home/oc/VM/img/netbsd.image.old,index=1,media=disk \ +> -M q35,accel=kvm -m 250M -cpu host -smp $(nproc) \ +> -nic user,hostfwd=tcp:127.0.0.1:5555-:22,model=virtio-net-pci,ipv6=off \ +> -daemonize -display none -vga none \ +> -serial mon:telnet:127.0.0.1:6665,server,nowait \ +> -pidfile /home/oc/VM/pid/netbsd-pid -nodefaults +> +> telnet 127.0.0.1 6665 +> +> +> -- +> Ottavio Caruso +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1743191 +> +> Title: +> Interacting with NetBSD serial console boot blocks no longer works +> +> Status in QEMU: +> New +> +> Bug description: +> The NetBSD boot blocks display a menu allowing the user to make a +> selection using the keyboard. For example, when booting a NetBSD +> installation CD-ROM, the menu looks like this: +> +> 1. Install NetBSD +> 2. Install NetBSD (no ACPI) +> 3. Install NetBSD (no ACPI, no SMP) +> 4. Drop to boot prompt +> +> Choose an option; RETURN for default; SPACE to stop countdown. +> Option 1 will be chosen in 30 seconds. +> +> When booting NetBSD in a recent qemu using an emulated serial console, +> making this menu selection no longer works: when you type the selected +> number, the keyboard input is ignored, and the 30-second countdown +> continues. In older versions of qemu, it works. +> +> To reproduce the problem, run: +> +> wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso +> qemu-system-x86_64 -nographic -cdrom boot-com.iso +> +> During the 30-second countdown, press 4 +> +> Expected behavior: The countdown stops and you get a ">" prompt +> +> Incorrect behavior: The countdown continues +> +> There may also be some corruption of the terminal output; for example, +> "Option 1 will be chosen in 30 seconds" may be displayed as "Option 1 +> will be chosen in p0 seconds". +> +> Using bisection, I have determined that the problem appeared with qemu +> commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was +> updated to 1.11 prerelease, and the problem is still there as of +> commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac. The host operating +> system used for the tests was Debian 9 x86_64. +> +> Credit for discovering this bug goes to Paul Goyette. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1743191/+subscriptions +> +> !DSPAM:608193ed146681924717040! +> +> + ++--------------------+--------------------------+-----------------------+ +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| (Retired) | FA29 0E3B 35AF E8AE 6651 | <email address hidden> | +| Software Developer | 0786 F758 55DE 53BA 7731 | <email address hidden> | ++--------------------+--------------------------+-----------------------+ + + +Ottavio Caruso wrote: +> I am currently using: +> +> $ qemu-system-x86_64 --version +> QEMU emulator version 5.2.0 +> +> And I have no problem selecting from menu in serial console, so I +> assume this is fixed for me. This is my command line: +> +> $ cat opt/bin/boot-netbsd-virtio +> #!/bin/sh +> qemu-system-x86_64 \ +> -drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ +> -drive if=virtio,file=/home/oc/VM/img/netbsd.image.old,index=1,media=disk \ +> -M q35,accel=kvm -m 250M -cpu host -smp $(nproc) \ +> -nic user,hostfwd=tcp:127.0.0.1:5555-:22,model=virtio-net-pci,ipv6=off \ +> -daemonize -display none -vga none \ +> -serial mon:telnet:127.0.0.1:6665,server,nowait \ +> -pidfile /home/oc/VM/pid/netbsd-pid -nodefaults +> +> telnet 127.0.0.1 6665 + +Have you tried the test case in the original bug report? +-- +Andreas Gustafsson, <email address hidden> + + +On Thu, 22 Apr 2021 at 18:23, Andreas Gustafsson +<email address hidden> wrote: +> +> Ottavio Caruso wrote: +> > I am currently using: +> > +> > $ qemu-system-x86_64 --version +> > QEMU emulator version 5.2.0 +> > +> > And I have no problem selecting from menu in serial console, so I +> > assume this is fixed for me. This is my command line: +> > +> > $ cat opt/bin/boot-netbsd-virtio +> > #!/bin/sh +> > qemu-system-x86_64 \ +> > -drive if=virtio,file=/home/oc/VM/img/netbsd.image,index=0,media=disk \ +> > -drive if=virtio,file=/home/oc/VM/img/netbsd.image.old,index=1,media=disk \ +> > -M q35,accel=kvm -m 250M -cpu host -smp $(nproc) \ +> > -nic user,hostfwd=tcp:127.0.0.1:5555-:22,model=virtio-net-pci,ipv6=off \ +> > -daemonize -display none -vga none \ +> > -serial mon:telnet:127.0.0.1:6665,server,nowait \ +> > -pidfile /home/oc/VM/pid/netbsd-pid -nodefaults +> > +> > telnet 127.0.0.1 6665 +> +> Have you tried the test case in the original bug report? +> -- +> Andreas Gustafsson, <email address hidden> + +You're right. Using the boot-com install image, the problem persists. + + +-- +Ottavio Caruso + +A: Because it messes up the order in which people normally read text. +Q: Why is top-posting such a bad thing? +A: Top-posting. +Q: What is the most annoying thing in e-mail? + + + +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/147 + + diff --git a/results/classifier/118/review/1743214 b/results/classifier/118/review/1743214 new file mode 100644 index 000000000..07b37b369 --- /dev/null +++ b/results/classifier/118/review/1743214 @@ -0,0 +1,109 @@ +mistranslation: 0.894 +boot: 0.853 +KVM: 0.852 +TCG: 0.823 +ppc: 0.817 +device: 0.772 +assembly: 0.731 +hypervisor: 0.720 +PID: 0.718 +kernel: 0.683 +user-level: 0.665 +graphic: 0.655 +permissions: 0.632 +architecture: 0.631 +debug: 0.610 +arm: 0.606 +i386: 0.598 +files: 0.596 +x86: 0.591 +performance: 0.590 +semantic: 0.586 +risc-v: 0.561 +socket: 0.535 +VMM: 0.531 +vnc: 0.523 +register: 0.496 +peripherals: 0.484 +network: 0.445 +virtual: 0.305 +-------------------- +i386: 0.982 +virtual: 0.864 +user-level: 0.784 +x86: 0.781 +boot: 0.344 +hypervisor: 0.174 +files: 0.129 +register: 0.108 +TCG: 0.091 +debug: 0.059 +socket: 0.057 +network: 0.056 +device: 0.039 +PID: 0.036 +KVM: 0.032 +kernel: 0.031 +VMM: 0.029 +vnc: 0.019 +architecture: 0.012 +graphic: 0.006 +semantic: 0.005 +ppc: 0.005 +risc-v: 0.005 +performance: 0.003 +assembly: 0.003 +peripherals: 0.003 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.001 + +OS/2 Warp 3 support broken in 2.11 + +Hello, I used to run OS/2 Warp 3 on QEMU with the following command line: qemu-system-i386 -vga cirrus -soundhw sb16 -hda os2warp3v2.img -boot c. It runs OK on QEMU 2.10, but immediately gives TRAP 0006 (invalid opcode?) on QEMU 2.11 (see screenshot). +If it is important I have Fixpack 40 and GRADD installed in OS/2. +Here is the image: +https://drive.google.com/open?id=15umPecy7JlPLKUP6520MB_87CfrCDWO5 + + + +On Sun, 14 Jan 2018, MVoloshin wrote: +> Hello, I used to run OS/2 Warp 3 on QEMU with the following command +> line: qemu-system-i386 -vga cirrus -soundhw sb16 -hda os2warp3v2.img +> -boot c. It runs OK on QEMU 2.10, but immediately gives TRAP 0006 +> (invalid opcode?) on QEMU 2.11 (see screenshot). +> +> If it is important I have Fixpack 40 and GRADD installed in OS/2. +> Here is the image: +> https://drive.google.com/open?id=15umPecy7JlPLKUP6520MB_87CfrCDWO5 + +This image boots for me without problem with latest version from git so +either it's already fixed or the problem is elsewhere. Can you try latest +git version? If it still does not work with that maybe you need to provide +more details, like configure options or what host arch/OS are you on. + + + +I used QEMU 2.11 for Windows from Stephan Weil (http://qemu.weilnetz.de/). I have Windows 10 (v1709) x64. + +On Sun, 14 Jan 2018, Stefan Weil wrote: +> Zoltan, did you run the test with KVM enabled? +> +> I get a crash when I run the image with latest QEMU on Linux with TCG. + +No, I've used the same command as in the bug report. Now I've retried with +explicit -M pc,accel=tcg and -M pc,accel=kvm and it boots without problem +for me both ways on Linux. If it crashes for you maybe you could try +bisecting, that's what I was trying to do to help but I can't reproduce +it. + +Regards, +BALATON Zoltan + +It looks like this bug affects only QEMU for Windows. + +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/review/1745316 b/results/classifier/118/review/1745316 new file mode 100644 index 000000000..9474b7895 --- /dev/null +++ b/results/classifier/118/review/1745316 @@ -0,0 +1,255 @@ +semantic: 0.856 +debug: 0.850 +architecture: 0.847 +user-level: 0.845 +permissions: 0.836 +register: 0.815 +assembly: 0.814 +graphic: 0.814 +ppc: 0.809 +performance: 0.808 +TCG: 0.798 +risc-v: 0.795 +hypervisor: 0.795 +device: 0.787 +virtual: 0.780 +PID: 0.780 +kernel: 0.778 +vnc: 0.771 +boot: 0.764 +KVM: 0.762 +files: 0.761 +VMM: 0.740 +i386: 0.730 +socket: 0.725 +mistranslation: 0.719 +network: 0.714 +x86: 0.693 +peripherals: 0.667 +arm: 0.655 +-------------------- +user-level: 0.273 +files: 0.051 +virtual: 0.035 +register: 0.025 +TCG: 0.017 +debug: 0.017 +x86: 0.011 +device: 0.009 +i386: 0.006 +boot: 0.006 +ppc: 0.005 +PID: 0.004 +VMM: 0.004 +risc-v: 0.004 +peripherals: 0.004 +network: 0.003 +semantic: 0.003 +graphic: 0.002 +performance: 0.002 +vnc: 0.002 +socket: 0.002 +hypervisor: 0.002 +KVM: 0.002 +kernel: 0.002 +arm: 0.001 +architecture: 0.001 +assembly: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +SDL1.x>SDL2 regressions: non-usbtablet mouse position reporting is broken, and VGA/compatmonitor/serial/etc view switching is unusable + +Hi, + +I almost exclusively use -sdl when I use QEMU. The GTK UI (I'm on Linux) distinctly takes a few extra seconds to start on every boot, and I don't really ever use the extra controls it provides. I hope the SDL-based UI never goes away :) + +The SDL 1.2 > SDL 2.0 update (committed between June 8-20 2017) introduced the following two regressions: + +- PS/2 and serial mouse position reporting became completely broken (only usbtablet works) + +- The compatmonitor/serial/parallel "views" try to open new windows, which does not play well on my system at all + +First of all, here are the bisection details: + +https://github.com/qemu/qemu/commit/269c20b2bbd2aa8531e0cdc741fb166f290d7a2b + (June 8 2017): the last version that works + +https://github.com/qemu/qemu/commit/7e56accdaf35234b69c33c85e4a44a5d56325e53 + (June 20 2017): the first version that fails + +Here are the changelists between these two revisions: + +https://github.com/qemu/qemu/compare/269c20b...7e56acc +(compare direction: OLD to NEW) (Commits: 60 Files changed: 85) + +https://github.com/qemu/qemu/compare/7e56acc...269c20b +(compare direction: NEW to OLD) (Commits: 41 Files changed: 108) + +(Someone else more familiar with Git might know why GitHub returns results for both compare directions. I'm including both links just in case.) + +I've found that configuring commit 7e56acc using --with-sdlapi=1.2 completely remedies all issues. Thus, I think the issue is with SDL 2. + +== #1: Broken mouse position reporting ===================== + +This surfaces immediately with older operating systems. I first experienced it when trying to install OS/2 for the first time, and thought there was something wrong with OS/2. Then I experienced the same issues in Windows 3.1 and MS-DOS applications and I knew something was up with QEMU. + +In a nice coincidence, I've recently been playing around with prehistorically ancient Linux systems, and while looking around a Linux 0.99-based SLS system from 1992 I discovered a low-level (console) mouse-testing utility buried in /usr/X386. This utility only works when I configure QEMU to use a serial mouse, but it reveals some very interesing data: the dx and dy values ("d" = "delta", right?) received by the kernel do not contain relative values such as -1, -10, 2, 5, etc, but instead absolute values such as 0, 12, 37, 112, 329, etc. + +Similarly, if I configure Windows 3.1 to use a serial mouse, the mouse position jumps exponentially around the screen relative to my mouse movements (it's very hard to control), consistent with delta values being reported as absolute instead of relative. + +I found that the DOS CuteMouse driver comes with a mouse-testing program. CuteMouse absolutely refuses to detect QEMU's serial mouse for some reason (?!), but when QEMU is running in PS/2 mode, the mouse tester that comes with CuteMouse reports that the mouse at 632,192 no matter how much I move the mouse around the window. If I look carefully I can see the DOS cursor flickering back and forth as I move the mouse and the tester rewrites the line showing the position info, so I don't think the test program is broken. + +I got curious and wondered if this was actually an internal SDL bug. However, the following test program reports perfect values for me: + +--8<-------------------------------------------------------- + +#include <stdio.h> +#include "SDL2/SDL.h" +int main(void) { + SDL_Init(SDL_INIT_VIDEO); + SDL_Window *window = SDL_CreateWindow("Mouse test", + SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, + 640, 480, SDL_WINDOW_RESIZABLE + ); + if (window == NULL) { + perror(SDL_GetError()); + exit(1); + } + for (;;) { + SDL_Event event; + while (SDL_PollEvent(&event)) { + if (event.type == SDL_MOUSEMOTION) { + printf( + "x=%d y=%d xrel=%d yrel=%d\n", + event.motion.x, event.motion.y, + event.motion.xrel, event.motion.yrel + ); + } + if ( + event.type == SDL_KEYDOWN || + event.type == SDL_QUIT + ) { + SDL_DestroyWindow(window); + SDL_Quit(); + exit(0); + } + } + } +} + +(gcc ... -lSDL2) + +------------------------------------------------------------ + +Unfortunately it would seem the issue is QEMU-specific. + +--- + +Finding modern test targets to verify mouse functionality with was actually a small challenge. I tested Ubuntu, Lubuntu and even GParted, but the recent Linux kernels in all three systems automatically loaded the usbtablet module early in the boot process, completely hiding the bug. + +I've found two actively-maintained somewhat-mainstream platforms that make for good tests. These are both ISOs: + +- ReactOS: + - http://www.reactos.org/download + - pick "Download LiveCD" and then "proceed with the download" at + bottom-right of popup + +- Tiny Core Linux: + - http://distro.ibiblio.org/tinycorelinux/downloads.html + - pick TinyCore (16MB) + +ReactOS is a very good example, as it's actively maintained and is probably heavily tested in QEMU (albeit apparently without SDL(2)). + +Tiny Core is a bit of a mixed bag. It's actively maintained and uses a recent kernel (without usbdevice). It also uses a resurrected low-memory XFree86 target that was officially dropped decades ago for its graphics (and mouse input). It could be argued that Tiny Core's mild obscurity makes it an even better test target. + +--- + +I've attached to this report the mouse test utilities I've played with. Both are faster to iterate with than waiting for Tiny Core or ReactOS to boot. + +----- FreeDOS + CuteMouse + mousetst ----- + +This boots completely and is ready to look at the mouse position in around a second. It automatically starts the mouse tester on startup and APM-shuts-down QEMU when you exit the mouse tester with ESC. I can highly recommend this version for iteration/verification. + +$ qemu-system-i386 -fda freedos-mousetest.img +$ qemu-system-i386 -fda freedos-mousetest.img -sdl + + +----- Linux-0.99 (SLS) + 'mouse.c' ----- + +This is a heavily stripped-down SLS configuration containing just the mouse testing utility. + +$ qemu-system-i386 -boot a -fda sls-boot.img -hda sls-mousetest.img \ + -serial msmouse + +$ qemu-system-i386 -boot a -fda sls-boot.img -hda sls-mousetest.img \ + -serial msmouse -sdl + +Login as root (no password), and then + +# ./mouse Microsoft /dev/ttyS0 + +Also, the following produces junk results, but I'm including it because it may be interesting anyway: + +$ qemu-system-i386 -boot a -fda sls-boot.img -hda sls-mousetest.img -sdl + +and + +# ./mouse Microsoft /dev/ps2aux + +The reason I think this is noteworthy is that the button state affects the reported values (incorrectly, but they do still change), but moving the mouse does not. So while the interpretation is wrong, the behavior seems to be similar to that reported by CuteMouse's mouse tester. (Unless the position fields are being perfectly skipped over.) + +When you're done with this image - `halt` takes several seconds and there's really no point. Just closing QEMU manually is faster. (This is also why I used the shorter -[hf]da syntax - writes to the disk images are not relevant.) + +(Also - since I can't possibly leave this info out :) - http://www.oldlinux.org/Linux.old/distributions/SLS/, `sls-1.0.tar.bz2`. This is a turnkey disk image that Just Works(TM). `boot.img` attached below is in fact the same as `a.img` in this archive.) + +--- + +In case it's useful, I included a Windows 3.1 test image when I reported https://bugs.launchpad.net/qemu/+bug/1745312. This image (which happens to be configured for PS/2) can be found in this folder: https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c + +For reference: this image includes a lot of cruft as it's an active test image I've used for a lot of different things. It contains a full copy of the contents of the Win3.1 installation disks in W31INST. You can `deltree c:\windows` and reinstall by running `setup` in that directory (takes 3-5 minutes), or `subst a: c:\w31inst` before starting Windows and you'll be able to use Windows Setup to switch to a serial mouse. + +== #2: SDL view switching unusability ====================== + +This issue is (somewhat) more straightforward to demonstrate. Simply + +$ qemu-system-i386 -sdl + +and then hit CTRL+ALT+2 (or 3 or 4). + +On my system, when I do this, QEMU creates and destroys new windows in an infinite loop for as long as I have CTRL+ALT+n held down. I have to hit `2` really quickly! + +I've also observed that some internal contention can frequently cause the compatmonitor window to become blind to the Enter key. It seems to be that this occurs most often when the windowmanager I'm using (tested using i3 and openbox) has focus-follows-mouse enabled and the mouse is over the area of the screen where the compatmonitor window opens itself. Perhaps this is caused by the CTRL+ALT capture code interacting badly with window focus state? (I'm very very interested to hear if you cannot reproduce this.) + +I initially thought all of these changes/glitches were due to some kind of messed-up "upgrade" / deliberate feature that happened to be broken on my system. But the only (obviously-)UI-related tasks I found in the changelist above just mention upgrading SDL, with no particular UI work (that I can see). It looks like this is actually an SDL thing - unless some (preparatory?) changes occurred in QEMU before the commit window I discovered. I have no idea. + +A couple things about fixing this that I want to mention: + +The way the GTK UI does things, views can be switched inside the same window, or they can be detached into new windows. This provides the best of both worlds - and there are situations where I do want both behaviors. + +If QEMU is not averse to burying an obscure option somewhere that lets me pick whether SDL will open views in new windows or the same window, that could be very nice - and it would bring the SDL UI to perfect feature parity with the GTK UI, too. But I'm not sure what QEMU's stance on obscure options is. + +That said, my preference for the SDL 1.x way of doing things is admittedly very probably biased by the usability issues created by this bug. Incidentally, I've taken to using `-serial null -monitor stdio`. But for that to work I have to remember to add it ahead of time, and I do often forget, heh. + +I'll be very interested to play with QEMU view switching once this is less glitchy. If the fixed implementation still opens new windows, I'll see what I think of that once it works stably. :) + + + + + + + +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/review/1746 b/results/classifier/118/review/1746 new file mode 100644 index 000000000..cd0d9869f --- /dev/null +++ b/results/classifier/118/review/1746 @@ -0,0 +1,63 @@ +architecture: 0.939 +device: 0.841 +network: 0.796 +semantic: 0.719 +graphic: 0.713 +ppc: 0.639 +register: 0.583 +socket: 0.573 +arm: 0.569 +PID: 0.534 +boot: 0.497 +permissions: 0.392 +performance: 0.380 +vnc: 0.352 +files: 0.329 +risc-v: 0.310 +debug: 0.266 +assembly: 0.253 +peripherals: 0.241 +mistranslation: 0.233 +VMM: 0.209 +virtual: 0.202 +hypervisor: 0.202 +x86: 0.175 +TCG: 0.141 +i386: 0.110 +kernel: 0.099 +user-level: 0.058 +KVM: 0.005 +-------------------- +arm: 0.854 +virtual: 0.804 +hypervisor: 0.798 +device: 0.067 +TCG: 0.041 +files: 0.032 +register: 0.021 +user-level: 0.012 +semantic: 0.012 +boot: 0.009 +risc-v: 0.008 +network: 0.007 +kernel: 0.007 +socket: 0.005 +peripherals: 0.005 +debug: 0.005 +PID: 0.004 +assembly: 0.003 +architecture: 0.003 +x86: 0.002 +performance: 0.002 +graphic: 0.001 +VMM: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 +i386: 0.000 +ppc: 0.000 +KVM: 0.000 + +PIC32 support in QEMU +Additional information: +There is a fork of an older version of QEMU that includes running a PIC32 microcontoller in QEMU hosted [here](https://github.com/sergev/qemu), however, it is very outdated. diff --git a/results/classifier/118/review/1746943 b/results/classifier/118/review/1746943 new file mode 100644 index 000000000..aed5b8c8d --- /dev/null +++ b/results/classifier/118/review/1746943 @@ -0,0 +1,87 @@ +architecture: 0.898 +graphic: 0.853 +device: 0.843 +performance: 0.839 +ppc: 0.798 +semantic: 0.729 +user-level: 0.635 +network: 0.582 +register: 0.573 +permissions: 0.558 +mistranslation: 0.548 +socket: 0.547 +peripherals: 0.476 +vnc: 0.384 +debug: 0.354 +hypervisor: 0.298 +files: 0.295 +virtual: 0.293 +PID: 0.247 +boot: 0.206 +arm: 0.186 +x86: 0.174 +risc-v: 0.126 +assembly: 0.124 +VMM: 0.122 +kernel: 0.116 +TCG: 0.110 +i386: 0.110 +KVM: 0.015 +-------------------- +debug: 0.914 +virtual: 0.694 +performance: 0.373 +hypervisor: 0.138 +TCG: 0.116 +PID: 0.063 +kernel: 0.033 +user-level: 0.014 +register: 0.013 +files: 0.012 +arm: 0.012 +socket: 0.007 +device: 0.007 +architecture: 0.006 +network: 0.004 +semantic: 0.003 +boot: 0.003 +peripherals: 0.002 +VMM: 0.001 +risc-v: 0.001 +assembly: 0.001 +graphic: 0.001 +vnc: 0.001 +permissions: 0.001 +ppc: 0.001 +x86: 0.000 +KVM: 0.000 +mistranslation: 0.000 +i386: 0.000 + +qemu-aarch64-static: qemu: uncaught target signal 11 for ps/top cmd + +In a docker container created from an aarch64 image, injects qemu-aarch64-static (in /usr/bin) + run ps/top cmd inside this container + + reports "qemu: uncaught target signal 11 (Segmentation fault)" + +Tried qemu-aarch64-static from fedora 27 / ubuntu artful / debian unstable (i.e. qemu version 2.10 - 2.11) + +The aarch64 dock image is fedora 27(and with qemu-aarch64-static Fedora 27), hence I opened a related bug here https://bugzilla.redhat.com/show_bug.cgi?id=1541252 + +I tried psproc-ng from https://launchpad.net/ubuntu/+source/procps/2:3.3.12-1ubuntu2/+build/10452812 + +No SEGV, I guess it may be a CRASH-PATH which is triggered in this specific scenario + +I've did update in redhat bugzilla #1541252, and wait for confirming above. + +BTW, "uncaught target signal 11" makes it hard to figure out "how this SEGV happened" + +Could you provide instructions to reproduce that don't require Fedora or docker, please? + + +Still waiting for repro instructions (eg attaching a binary that doesn't run under QEMU). + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1751264 b/results/classifier/118/review/1751264 new file mode 100644 index 000000000..bedbd41d8 --- /dev/null +++ b/results/classifier/118/review/1751264 @@ -0,0 +1,130 @@ +semantic: 0.825 +user-level: 0.818 +register: 0.811 +permissions: 0.799 +graphic: 0.758 +performance: 0.745 +arm: 0.711 +device: 0.708 +assembly: 0.707 +debug: 0.697 +architecture: 0.697 +PID: 0.652 +hypervisor: 0.541 +kernel: 0.532 +TCG: 0.523 +peripherals: 0.517 +ppc: 0.490 +network: 0.482 +boot: 0.478 +risc-v: 0.470 +mistranslation: 0.468 +files: 0.466 +virtual: 0.446 +vnc: 0.433 +VMM: 0.420 +socket: 0.407 +KVM: 0.375 +x86: 0.330 +i386: 0.176 +-------------------- +virtual: 0.907 +debug: 0.884 +performance: 0.835 +user-level: 0.501 +hypervisor: 0.399 +TCG: 0.218 +x86: 0.218 +VMM: 0.107 +register: 0.084 +risc-v: 0.075 +kernel: 0.063 +files: 0.054 +device: 0.050 +PID: 0.045 +socket: 0.044 +KVM: 0.041 +vnc: 0.037 +i386: 0.019 +semantic: 0.017 +assembly: 0.007 +network: 0.007 +peripherals: 0.006 +graphic: 0.004 +architecture: 0.004 +boot: 0.004 +ppc: 0.004 +arm: 0.002 +permissions: 0.002 +mistranslation: 0.001 + +qemu-img convert issue in a tmpfs partition + +qemu-img convert command is slow when the file to convert is located in a tmpfs formatted partition. + +v2.1.0 on debian/jessie x64, ext4: 10m14s +v2.1.0 on debian/jessie x64, tmpfs: 10m15s + +v2.1.0 on debian/stretch x64, ext4: 11m9s +v2.1.0 on debian/stretch x64, tmpfs: 10m21.362s + +v2.8.0 on debian/jessie x64, ext4: 10m21s +v2.8.0 on debian/jessie x64, tmpfs: Too long + +v2.8.0 on debian/stretch x64, ext4: 10m42s +v2.8.0 on debian/stretch x64, tmpfs: Too long + +It seems that the issue is caused by this commit : https://github.com/qemu/qemu/commit/690c7301600162421b928c7f26fd488fd8fa464e + +In order to reproduce this bug : + +1/ mount a tmpfs partition : mount -t tmpfs tmpfs /tmp +2/ get a vmdk file (we used a 15GB image) and put it on /tmp +3/ run the 'qemu-img convert -O qcow2 /tmp/file.vmdk /path/to/destination' command + +When we trace the process, we can see that there's a lseek loop which is very slow (compare to outside a tmpfs partition). + +Hi, + +This is a combination of (in our opinion) a bug in tmpfs (...and I think maybe btrfs as well?), the fact that the vmdk block driver is not very well optimized, and qemu-img convert assuming that the filesystem works as it thinks it does or that at least the block driver can work around this. + +So what happens is that qemu-img convert tries to find out which data it needs to copy. For this, it queries which parts of the image are allocated. This involves querying both the format level (vmdk in this case) and the protocol level (tmpfs in this case). + +Now the vmdk block driver is not very well optimized, so it only allows querying on cluster boundaries (64 kB by default, as far as I can tell). qcow2 OTOH allows greater areas (I just created a 512 MB image and it can query the whole image at once). + +So the requests go down to the protocol level. We expect that to respond very quickly to an allocation request (the lseek() you are seeing) -- but tmpfs (and I think btrfs, too) don't do that. They take a rather long time. + +For an example, the attached program seeks through a file (in 64 kB steps) with SEEK_DATA/SEEK_HOLE. This is what happens: +$ cd /tmp +$ gcc test.c -std=c11 -Wall -Wextra -pedantic -O3 +$ qemu-img create -f raw -o preallocation=falloc empty 512M +$ qemu-img create -f raw -o preallocation=falloc ~/empty 512M +$ time ./a.out empty +./a.out empty 0,01s user 23,10s system 99% cpu 23,166 total +$ time ./a.out ~/empty +./a.out ~/empty 0,01s user 0,03s system 96% cpu 0,041 total + +So there's a huge difference and that is (in my opinion) a bug in tmpfs. + +(When converting from qcow2 you don't notice this, because qcow2 allows performing a single allocation request for the whole image, so it doesn't matter much whether that's slow.) + + +There are three ways around this: +(1) tmpfs (and probably btrfs? -- although I can't reproduce it myself right now) should be fixed. If they can't tell allocated areas quickly, they should just report the whole file as allocated. + +(2) Our vmdk driver could be optimized. Sure, but that wouldn't solve the real issue and someone would have to do it first (and we don't have a strong interest in this, because all format drivers but qcow2 and raw are there mainly just for reading other formats and converting them to qcow2). + +(3a) qemu-img convert could poll for allocation information less insistently. One way would be to add a switch to disable this behavior completely and force it to just read everything. We already have -S 0 which could do this; but just reading all data and then doing zero detection over it kind of defeats the purpose. If read() + memcmp() is faster than lseek(SEEK_DATA), then the FS is just doing something wrong. + +(3b) Eric Blake has recently added support for a less insisting way to query allocation status that should only go to the format layer (e.g. vmdk) and ignore the protocol layer (e.g. tmpfs). Maybe qemu-img convert should use that. + + +But in any case, I claim the main issue is in tmpfs. + +Max + +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/review/1753 b/results/classifier/118/review/1753 new file mode 100644 index 000000000..acf0f25d9 --- /dev/null +++ b/results/classifier/118/review/1753 @@ -0,0 +1,63 @@ +mistranslation: 0.902 +device: 0.890 +graphic: 0.885 +network: 0.853 +semantic: 0.851 +debug: 0.799 +assembly: 0.791 +architecture: 0.747 +register: 0.719 +performance: 0.712 +risc-v: 0.694 +vnc: 0.601 +VMM: 0.555 +boot: 0.498 +TCG: 0.483 +arm: 0.467 +permissions: 0.461 +ppc: 0.457 +PID: 0.453 +socket: 0.439 +KVM: 0.437 +hypervisor: 0.411 +peripherals: 0.396 +user-level: 0.382 +virtual: 0.339 +i386: 0.276 +files: 0.253 +x86: 0.236 +kernel: 0.156 +-------------------- +hypervisor: 0.948 +virtual: 0.883 +debug: 0.281 +x86: 0.202 +user-level: 0.182 +semantic: 0.123 +TCG: 0.108 +assembly: 0.075 +files: 0.063 +i386: 0.030 +peripherals: 0.018 +device: 0.017 +VMM: 0.013 +kernel: 0.012 +arm: 0.011 +risc-v: 0.011 +ppc: 0.008 +architecture: 0.008 +register: 0.008 +performance: 0.005 +graphic: 0.004 +network: 0.003 +KVM: 0.002 +vnc: 0.002 +socket: 0.002 +boot: 0.002 +mistranslation: 0.002 +PID: 0.001 +permissions: 0.001 + +Does the qemu have luks2 support? +Description of problem: +Does the qemu have luks2 support? diff --git a/results/classifier/118/review/1754656 b/results/classifier/118/review/1754656 new file mode 100644 index 000000000..94063010a --- /dev/null +++ b/results/classifier/118/review/1754656 @@ -0,0 +1,234 @@ +user-level: 0.933 +peripherals: 0.889 +virtual: 0.874 +permissions: 0.871 +register: 0.865 +boot: 0.847 +device: 0.844 +assembly: 0.838 +performance: 0.838 +semantic: 0.829 +VMM: 0.820 +risc-v: 0.820 +ppc: 0.818 +architecture: 0.811 +debug: 0.811 +mistranslation: 0.803 +files: 0.802 +PID: 0.799 +hypervisor: 0.798 +arm: 0.791 +KVM: 0.779 +vnc: 0.778 +graphic: 0.739 +network: 0.731 +socket: 0.701 +TCG: 0.652 +i386: 0.504 +kernel: 0.437 +x86: 0.423 +-------------------- +virtual: 0.666 +user-level: 0.195 +x86: 0.075 +TCG: 0.043 +PID: 0.011 +ppc: 0.010 +i386: 0.008 +network: 0.007 +semantic: 0.007 +socket: 0.005 +hypervisor: 0.005 +kernel: 0.005 +debug: 0.005 +files: 0.004 +architecture: 0.004 +register: 0.004 +performance: 0.003 +arm: 0.002 +device: 0.002 +VMM: 0.002 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +assembly: 0.001 +peripherals: 0.001 +boot: 0.001 +graphic: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM + +Version: + +QEMU emulator version 2.11.1 + +Introduction: + +This is call for action to get attention of somebody in QEMU project/organization, who is capable of actually doing something about this pressing issue. This might be TLDR for some, but that's only because of the complexity of the issue. Please read this with open mind. + +Problem: + +As QEMU users, we need (it is a requirement) to have some mechanism in place, to somehow convert simple POSIX signal sent form host, into graceful ACPI shutdown of the guest. This signal, due various historical reasons and daemon design, must be SIGTERM foremost. + +Status quo: + +After wading through mailing lists and bug tracker I concluded that this is "political" problem and I am in search of somebody, a "politician" within QEMU project, who will help us reach conclusion to this problem. + +First I will present analysis of the situation, and then propose some suggestions for solutions. + +Even then, any of these proposals might be, potentially, seen as problematic in eyes of QEMU maintainers, developers, dictators, long term users or their dogs. + +That's why we need somebody willing, "higher up the chain" or whatever, to orchestrate discussion so that we can actually reach consensus in the matter, solution that is acceptable to **everyone**. + +Analysis: + +Each QEMU emulated virtual machine (vm), running in the host system, is represented by single qemu-* process (followed by several threads). Thus for all intents and purposes, any such instantiated vm, must be seen as it's own, separate, daemon. + +I repeat running qemu-* vm **is a daemon**. + +QEMU provides incredible IO redirection capabilities, so we don't need to get into issues of logging, console and monitor redirections and such, as this is already a (perfectly) solved problem. + +What we cannot currently do, at least easily, reliably and simply, is to shutdown guest gracefully from "outside". + +That is not a problem for those of us, who use some kind of higher level orchestrator (I think one of them is virsh, but this is not important in this matter) that takes care of this by communicating with QEMU directly (I guess this is done by sending commands to internal monitor by pipe (or socket) held open by mentioned orchestrator). + +However it is a problem for those of us, who run qemu-* processes bare or supervised. + +Let's say I, as administrator, want to implement vm instance as supervised service. +I can use any supervisor for that, systemd even. Let us not get into into supervisor wars. + +At basic level almost all supervisors are similar. Supervisor usually is yet another process, that "leads" the qemu-* one. + +In case of systemd it is PID1, but in case of other supervision schemes, like daemontools, runit, s6 or nosh, it is separate '*supervise' process instead. + +When such supervisor is tearing down the service, "leading"/supervising, parent will send SIGTERM to it's child qemu-* process. + +This behaviour is almost universal among all supervisors. This due the fact, that it is customary for daemons to cease all operations and exit cleanly when receiving SGITERM signal. If daemon child fails to exit within configurable timeframe, supervisor deals with it by the means of SIGKILL. + +As such, one would expect, similarly, for qemu-* process to send ACPI shutdown event to guest internally (roughly equivalent to 'system_powerdown' monitor command) on SIGTERM reception. + +But this is not what happens! + +Instead, qemu-* just flushes pending IO and kills the guest instantly. + +Then, on next vm "boot", guest detects this as power failure event, and performs fsck checks and other things, it is supposed to do in case of power failure. We are not mentioning possible data loss that might have happened due to this behavior, either. + +Some supervisors (like systemd for example) might provide feature to change "termiante operations" signal to something else like SIGTERM, but that is not universal supervisor feature by any means. Default action for any proper daemon is to cleanly terminate on SIGTERM. + +That is why we need ability to somehow instruct QEMU to **always** perform graceful ACPI shutdown on SIGTERM. + +Potential reply to this bug saying that one should send 'system_powerdown' over monitor connection won't fly! + +As it is not always possible (nor required) to hook into supervisor's signal processing (main reason being intentional supervisor simplicity in search of extreme reliability, and de facto standardized behavior of daemons to exit cleanly on SIGTERM). + +More over, in situations like machine reboot, most supervisors won't play around with signal remapping, they will simply send out SIGTERM to all supervised processes. We want our qemu-* instances to come up undamaged from such action (on next host reboot) and not have them stuck in fscks (or worse - ending up damaged) . + +If this can be extended further, inside QEMU, with internal signal to action remapping, the better, but supporting graceful shutdown on SIGTERM is hard requirement. + +Proposed solutions: + +0. modify QEMU so that it emits ACPI shutdown event equivalent to 'system_powerdown' monitor command by default + - this seems to be a "no go", with backwards compat. and "current users expectations" + cited as the reasons + - I won't go into a fact that QEMU changed option handling without BOLD notice few times + +1. add single switch '-graceful-shutdown-on-sgiterm' + - this was rejected when person tried to submit patch implementing something similar + to what I am requesting, only bound to SIGHUP + - that person (implementing graceful poweroff on SIGHUP) was wrong, almost no + supervision scheme in existence sends out SIGHUP on service termination request, + although all supervisors are able to send out SIGHUP when instructed + - in daemons SIGHUP is usually reserved for "daemon reload" which can be interpreted + like "reboot" in QEMU context + - if we see qemu-* proces for what it is, a daemon, it must react properly to SIGTERM foremost + +2. add ability to map internal monitor action commands to few signals like SIGTERM, SIGHUP, SIGINTR, SIGUSR1, SIGUSR2, SIGALARM etc + - this seems like best solution to me, that allows us to satisfy both + backwards compat. and "current users" requirement, yet allows us + to use qemu-* with proper supervision, and it even adds something extra + (I know some of these signals are used internally by QEMU) + - QEMU already has options parsing infrastructure in place to handle this nicely, something like: + : -signal SIGTERM,monitorcommand=system_powerdown -signal SIGHUP,monitorcommand=system_reset + would be great in this case + +3. add ability to map signals to executable scripts + - with this scheme QEMU would spawn child on signal reception, and this + script would then be used to perform the action + - this solution is most complex, most convoluted and most "flexible" + - for example with definition like this: + : -signal SIGTERM,script=signals/sigterm + qemu would perform this sequence of tasks: + - on SIGTERM qemu-* would spawn child script ./signals/sigterm + - this script would then pull out monitor fd descriptor from some kind of fd holder + - would write 'system_powerdown' command into monitor fd and terminate + - qemu-* would then read the command from monitor + - qemu-* would then interpret read-in command and gracefully terminate + - option parsing infrastructure is in place and QEMU is able to spawn and reap it's own children + which is proven by network up/down scripts + + +Of these, it seems that 0. and 1. are simplest to implement, yet "politically" unimplementable. + +More over QEMU people seem to be hard set on SIGTERM meaning "killing unresponsive guest". + +2. seems like most reasonable proposal that has potential to make everyone happy. It is also most reliable because internal QEMU command dispatch would have least chances to fail. + +3. is most flexible and can also be combined with 2. Reliability wise, there is slight chance signal handling script will fail to execute, leaving qemu-* at the mercy of supervisor (timeouted SIGKILL). + +Both 2 and 3 should probably provide configurable timeout after which QEMU would perform default action (eg. as it does now). + +Conclusion: + +I hope QEMU project members understand severity of the issue and are open to listed solutions. It might be that proposed solutions don't match QEMU project "spirit" perfectly. If so, I urge people capable of resolving this, to propose their versions. + +The fact is, that with proliferation of systemd, popularity of alternative supervisors is on the rise as well, but even under systemd, unintuitive handling of SIGTERM by bare QEMU processes is a problem. + +Further Reading: + +https://patchwork.kernel.org/patch/9626293/ + + - Daniel P. Berrange says: + "Because QEMU already designate that as doing an immediate stop - ie it'll + allow QEMU block layer to flush pending I/O, but it will not wait for the + guest to shutdown. If we change that behaviour we'll break anyone who + is already relying on SIGHUP - qemu might never exit at all if the guest + ignores the ACPI request" + + - this behaviour is incorrect if we perceive qemu-* process as daemon, proper, + yet it is, supposedly, entrenched in QEMU userbase + - signals remapping capability would allow us to keep the "old" behavior for entrenched users + while it would allow administrators and orchestrator writers to select signal disposition + they actually need + +https://bugs.launchpad.net/qemu/+bug/1217339 +and +https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg03039.html + + - on my QEMU version of 2.11.1 SIGTERM just kills the guest without proper shutdown + - although thread says exit is graceful + - dicussion is problematic in several ways: + - SIGTERM is not intended to "terminate unresponsive guest" eg "terminate daemon uncleanly" + in any sane daemon in existence + - it means "terminate gracefully" + - if "terminate unresponsive guest" was true meaning of SIGTERM, databases like + mariadb or postgers would kill themselves on SIGTERM, leaving data in + inconsistent state, which they, of course, do not! + - some kind of "signal tapping" similar to "port tapping" is suggested + - this is non-obvious and error prone and nonstandard (no normal supervisor + will play such signal tapping games) + - signal remapping makes more sense in this regard + +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. + + + +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/148 + + diff --git a/results/classifier/118/review/1756080 b/results/classifier/118/review/1756080 new file mode 100644 index 000000000..6fb714e9b --- /dev/null +++ b/results/classifier/118/review/1756080 @@ -0,0 +1,67 @@ +mistranslation: 0.887 +boot: 0.822 +arm: 0.794 +device: 0.687 +architecture: 0.680 +kernel: 0.600 +semantic: 0.511 +graphic: 0.416 +files: 0.371 +socket: 0.333 +register: 0.316 +risc-v: 0.299 +performance: 0.293 +vnc: 0.291 +ppc: 0.281 +network: 0.261 +user-level: 0.255 +permissions: 0.253 +virtual: 0.227 +VMM: 0.214 +x86: 0.214 +TCG: 0.209 +i386: 0.187 +PID: 0.168 +assembly: 0.166 +peripherals: 0.159 +hypervisor: 0.133 +debug: 0.125 +KVM: 0.098 +-------------------- +arm: 0.997 +kernel: 0.997 +boot: 0.917 +virtual: 0.908 +hypervisor: 0.173 +semantic: 0.131 +architecture: 0.073 +register: 0.030 +TCG: 0.023 +user-level: 0.021 +device: 0.014 +files: 0.012 +debug: 0.009 +PID: 0.007 +performance: 0.006 +assembly: 0.006 +socket: 0.004 +x86: 0.003 +risc-v: 0.003 +graphic: 0.003 +network: 0.002 +permissions: 0.002 +peripherals: 0.002 +i386: 0.002 +mistranslation: 0.001 +ppc: 0.001 +KVM: 0.001 +VMM: 0.001 +vnc: 0.000 + +QEMU does not provide non-Linux kernels with ATAGS structure on ARM targets + +This would be a useful feature. Many kernels, particularly hobbyist kernels, have support for ATAGS. + +QEMU doesn't care whether the kernel you provide it is Linux or something else. If you pass -kernel something that's not an ELF file, we'll load and boot it using the Linux boot protocol (including ATAGS, potentially). If you pass an ELF file or pass -bios a binary blob, we'll just start it in the way the CPU usually resets, on the assumption it can deal with whatever that is. + + diff --git a/results/classifier/118/review/1756807 b/results/classifier/118/review/1756807 new file mode 100644 index 000000000..67ea478d1 --- /dev/null +++ b/results/classifier/118/review/1756807 @@ -0,0 +1,187 @@ +mistranslation: 0.829 +permissions: 0.829 +semantic: 0.803 +register: 0.785 +virtual: 0.780 +user-level: 0.776 +debug: 0.774 +device: 0.761 +risc-v: 0.759 +graphic: 0.755 +assembly: 0.749 +architecture: 0.729 +performance: 0.728 +TCG: 0.718 +arm: 0.710 +files: 0.703 +PID: 0.702 +peripherals: 0.683 +VMM: 0.669 +boot: 0.666 +vnc: 0.661 +x86: 0.646 +hypervisor: 0.633 +socket: 0.628 +KVM: 0.598 +network: 0.570 +kernel: 0.517 +ppc: 0.517 +i386: 0.505 +-------------------- +performance: 0.992 +arm: 0.591 +virtual: 0.339 +hypervisor: 0.100 +PID: 0.054 +debug: 0.047 +TCG: 0.032 +files: 0.027 +boot: 0.019 +ppc: 0.016 +register: 0.015 +device: 0.014 +x86: 0.010 +socket: 0.005 +user-level: 0.004 +kernel: 0.003 +network: 0.003 +graphic: 0.003 +i386: 0.002 +assembly: 0.002 +VMM: 0.002 +KVM: 0.002 +semantic: 0.002 +architecture: 0.001 +risc-v: 0.001 +peripherals: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +performance regression in qemu-user + proot + +To reproduce: + +1. Install qemu-user-static and proot +2. Enter some arm chroot using them: + + proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash + +3. Run a command which normally takes a short but measurable amount of time: + + cd /usr/share/doc && time grep -R hello + +Result: + +This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04. + +Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected. + +If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though. + +Logs: + + + +System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04 +qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0) +proot 5.1.0 + +al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-desktop:/# cd /usr/share/doc +root@al-desktop:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m0.066s +user 0m0.040s +sys 0m0.008s + + + + + +System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04 +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4) +proot 5.1.0 + +al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-thinkpad:/# cd /usr/share/doc +root@al-thinkpad:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m24.176s +user 0m0.366s +sys 0m11.352s + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: qemu (not installed) +ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 +Uname: Linux 4.15.0-12-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +Date: Mon Mar 19 07:13:25 2018 +InstallationDate: Installed on 2018-03-18 (0 days ago) +InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318) +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) + + + +Also, I noticed this while running a script that normally takes 12 minutes. After 12 hours I killed it. It never stopped advancing or threw any errors. It was just excruciatingly slow the whole time. + +That script builds chroots and can be found here: https://github.com/ali1234/rpi-ramdisk + +Hi Alistair, +I've seen a few similar reports, but afaik it is an upstream issue - we have no custom ubuntu bits in that area applied. + +To confirm that and ask upstream about it I'D ask you if you have a way to build qemu from upstream and check which version there broke it? + +git bisect start +# good: [ba87166e14ffd7299c35badc4c11f3fa3c129ec6] Update version for 2.10.2 release +git bisect good ba87166e14ffd7299c35badc4c11f3fa3c129ec6 +# bad: [7c1beb52ed86191d9e965444d934adaa2531710f] Update version for 2.11.1 release +git bisect bad 7c1beb52ed86191d9e965444d934adaa2531710f +# good: [1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec] Update version for v2.10.0 release +git bisect good 1ab5eb4efb91a3d4569b0df6e824cc08ab4bd8ec +# good: [23ca459a455c83ffadb03ab1eedf0b6cff62bfeb] mirror: Switch mirror_dirty_init() to byte-based iteration +git bisect good 23ca459a455c83ffadb03ab1eedf0b6cff62bfeb +# bad: [8cbf74b23cafd1bcee5fdef769f8e94ace43935f] qcow2: Reduce is_zero() rounding +git bisect bad 8cbf74b23cafd1bcee5fdef769f8e94ace43935f +# good: [861cd431c99e56ddb5953ca1da164a9c32b477ca] Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.11-20171017' into staging +git bisect good 861cd431c99e56ddb5953ca1da164a9c32b477ca +# bad: [2bcf018340cbf233f7145e643fc1bb367f23fd90] s390x/tcg: low-address protection support +git bisect bad 2bcf018340cbf233f7145e643fc1bb367f23fd90 +# bad: [840e0691303f84f7837bc75b37595e9b4419f35d] Merge remote-tracking branch 'remotes/mcayland/tags/qemu-openbios-signed' into staging +git bisect bad 840e0691303f84f7837bc75b37595e9b4419f35d +# good: [3da023b5827543ee4c022986ea2ad9d1274410b2] scsi: reject configurations with logical block size > physical block size +git bisect good 3da023b5827543ee4c022986ea2ad9d1274410b2 +# good: [ba6f0fc25e3c14fbb36f4b5a616a89cd3f1de6d0] Merge remote-tracking branch 'remotes/kraxel/tags/opengl-20171017-pull-request' into staging +git bisect good ba6f0fc25e3c14fbb36f4b5a616a89cd3f1de6d0 +# bad: [f443e3960d9d3340dd286e5fc0b661bb165a8b22] linux-user: Fix TARGET_MTIOCTOP/MTIOCGET/MTIOCPOS values +git bisect bad f443e3960d9d3340dd286e5fc0b661bb165a8b22 +# good: [de258eb07db6cf893ef1bfad8c0cedc0b983db55] tcg: Fix off-by-one in assert in page_set_flags +git bisect good de258eb07db6cf893ef1bfad8c0cedc0b983db55 +# bad: [cc1b3960a1a54125d2c87719fa945179bffbae68] linux-user/sh4: Reduce TARGET_VIRT_ADDR_SPACE_BITS to 31 +git bisect bad cc1b3960a1a54125d2c87719fa945179bffbae68 +# bad: [18e80c55bb6ec17c05ec0ba717ec83933c2bfc07] linux-user: Tidy and enforce reserved_va initialization +git bisect bad 18e80c55bb6ec17c05ec0ba717ec83933c2bfc07 +# first bad commit: [18e80c55bb6ec17c05ec0ba717ec83933c2bfc07] linux-user: Tidy and enforce reserved_va initialization + + +origin/master is also affected. + +This upstream bug may be related. It has a patch. + +https://bugs.launchpad.net/qemu/+bug/1740219 + +Thanks for the check Alistar, + +Lets add a Qemu (upstream) bug task so this one is mirrored to the ML. + +I'm not familiar with that area, but on the ML one can decide if it is a dup to https://bugs.launchpad.net/qemu/+bug/1740219 or not. + +I just tested the patch from https://bugs.launchpad.net/qemu/+bug/1740219 and it fixes the problem for me. Specifically I only tried the final patch of the series. + +Then lets join there and let your update give that thread some new life. + diff --git a/results/classifier/118/review/1759337 b/results/classifier/118/review/1759337 new file mode 100644 index 000000000..b2a6ffa88 --- /dev/null +++ b/results/classifier/118/review/1759337 @@ -0,0 +1,82 @@ +x86: 0.950 +device: 0.891 +VMM: 0.872 +graphic: 0.867 +semantic: 0.847 +virtual: 0.773 +files: 0.771 +ppc: 0.750 +performance: 0.738 +vnc: 0.715 +architecture: 0.700 +i386: 0.693 +mistranslation: 0.662 +PID: 0.657 +register: 0.639 +hypervisor: 0.631 +network: 0.614 +debug: 0.611 +user-level: 0.575 +kernel: 0.567 +permissions: 0.565 +socket: 0.546 +arm: 0.493 +boot: 0.488 +KVM: 0.483 +risc-v: 0.478 +peripherals: 0.423 +TCG: 0.406 +assembly: 0.308 +-------------------- +x86: 0.847 +hypervisor: 0.794 +virtual: 0.746 +user-level: 0.217 +network: 0.134 +TCG: 0.118 +debug: 0.086 +files: 0.038 +PID: 0.020 +semantic: 0.020 +kernel: 0.017 +ppc: 0.012 +device: 0.007 +socket: 0.006 +risc-v: 0.005 +performance: 0.004 +permissions: 0.004 +register: 0.004 +assembly: 0.003 +boot: 0.003 +architecture: 0.002 +vnc: 0.002 +arm: 0.001 +VMM: 0.001 +graphic: 0.001 +peripherals: 0.001 +i386: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +'Failed to get "write" lock' error when trying to run a VM with disk image file on an SMB share + +This has been reported and discussed downstream: + +https://bugzilla.redhat.com/show_bug.cgi?id=1484130 + +but doesn't seem to be getting a lot of traction there. + +Basically, with qemu since at least 2.10, you cannot use a disk image on an SMB share that's mounted with protocol version 3 (I think possibly 2 or higher). This is made much more serious because kernel 4.13 upstream made version 3 the *default* for SMB mounts, because version 1 is insecure and should not be used. + +So basically, anyone with a recent qemu and kernel cannot use disk images stored on an SMB share. This is a major inconvenience for me because, well, an SMB share is exactly where I store my VM disk images, usually: I have a big NAS drive where I keep them all, only now I can't because of this bug, and I'm manually swapping them in and out of the very limited space I have on my system drive (SSD). + +The error you get is: + +qemu-system-x86_64: -drive file=/share/data/isos/vms/desktop_test_1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0: Failed to get "write" lock +Is another process using the image? + +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/review/1761535 b/results/classifier/118/review/1761535 new file mode 100644 index 000000000..1089eb027 --- /dev/null +++ b/results/classifier/118/review/1761535 @@ -0,0 +1,115 @@ +x86: 0.927 +debug: 0.893 +architecture: 0.890 +arm: 0.884 +device: 0.871 +peripherals: 0.856 +performance: 0.804 +ppc: 0.800 +files: 0.795 +risc-v: 0.776 +permissions: 0.763 +PID: 0.740 +socket: 0.739 +hypervisor: 0.734 +vnc: 0.727 +graphic: 0.694 +register: 0.678 +user-level: 0.653 +network: 0.636 +semantic: 0.630 +TCG: 0.619 +boot: 0.560 +kernel: 0.468 +mistranslation: 0.447 +VMM: 0.437 +KVM: 0.433 +i386: 0.411 +assembly: 0.389 +virtual: 0.384 +-------------------- +debug: 0.920 +arm: 0.801 +virtual: 0.578 +user-level: 0.544 +PID: 0.201 +hypervisor: 0.100 +files: 0.092 +TCG: 0.061 +performance: 0.046 +x86: 0.018 +register: 0.017 +socket: 0.009 +device: 0.009 +permissions: 0.008 +network: 0.008 +semantic: 0.007 +architecture: 0.007 +kernel: 0.005 +ppc: 0.004 +i386: 0.003 +boot: 0.003 +graphic: 0.002 +assembly: 0.002 +peripherals: 0.002 +vnc: 0.002 +VMM: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +qemu-aarch64-static docker arm64v8/openjdk coredump + +I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. + +To reproduce (and get to the core dump): + +$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version +qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash +root@bf75cf45d311:/# javac +Usage: javac <options> <source files> +where possible options include: + -g Generate all debugging info +<...snip...> + @<filename> Read options and filenames from file + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +...TERMINAL HANGS... + + +To get the core dump, In a separate terminal: + +# snapshot the file system of the hung image +$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump + +# connect with known working qemu +$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash + +$$ ls -lat +total 10608 +<snip> +-rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core +drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp +<snip> + +Could you provide a binary that we can use to reproduce, please? (preferably a setup that doesn't require me to figure out how to install and use docker...) + + +I realized I had a javac lying around from last time somebody wanted me to debug a java problem, and I'm also seeing SEGVs with simpler programs like ls (!), so I'll have a look at those and hopefully that will be the same cause as what you're seeing. + + +I think this should be fixed by https://patchwork.ozlabs.org/patch/896295/ + +(incidentally the segfault is in the guest /bin/sh, not in javac or ls.) + + +Now fixed in master, commit 7f0f4208b3a96, and will be in 2.12.0. + + +Many thanks! + +I've just compiled master, and docker/aarch64/openjdk image now works as expected on my x86 machine. + diff --git a/results/classifier/118/review/1763 b/results/classifier/118/review/1763 new file mode 100644 index 000000000..3091d6e9a --- /dev/null +++ b/results/classifier/118/review/1763 @@ -0,0 +1,72 @@ +architecture: 0.977 +device: 0.892 +arm: 0.739 +graphic: 0.702 +PID: 0.488 +network: 0.439 +semantic: 0.419 +debug: 0.349 +performance: 0.341 +mistranslation: 0.287 +permissions: 0.273 +files: 0.246 +virtual: 0.236 +hypervisor: 0.220 +boot: 0.197 +ppc: 0.193 +VMM: 0.184 +user-level: 0.172 +kernel: 0.171 +register: 0.168 +peripherals: 0.166 +socket: 0.163 +vnc: 0.134 +TCG: 0.096 +assembly: 0.032 +x86: 0.028 +risc-v: 0.022 +KVM: 0.009 +i386: 0.006 +-------------------- +arm: 0.912 +virtual: 0.793 +hypervisor: 0.589 +kernel: 0.147 +TCG: 0.110 +debug: 0.068 +register: 0.055 +PID: 0.028 +files: 0.023 +user-level: 0.017 +device: 0.014 +performance: 0.012 +socket: 0.006 +boot: 0.005 +semantic: 0.005 +assembly: 0.004 +architecture: 0.003 +network: 0.003 +peripherals: 0.003 +VMM: 0.002 +permissions: 0.001 +risc-v: 0.001 +KVM: 0.001 +graphic: 0.001 +mistranslation: 0.000 +vnc: 0.000 +x86: 0.000 +ppc: 0.000 +i386: 0.000 + +ldd fails with qemu-aarch64 +Description of problem: +see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172 +Steps to reproduce: +1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls + +Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries. +Additional information: +``` +WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested +ldd: exited with unknown exit code (139) +``` diff --git a/results/classifier/118/review/1763536 b/results/classifier/118/review/1763536 new file mode 100644 index 000000000..e02108c58 --- /dev/null +++ b/results/classifier/118/review/1763536 @@ -0,0 +1,212 @@ +ppc: 0.870 +user-level: 0.854 +vnc: 0.824 +performance: 0.817 +risc-v: 0.799 +TCG: 0.796 +architecture: 0.796 +mistranslation: 0.786 +virtual: 0.775 +PID: 0.772 +arm: 0.771 +assembly: 0.764 +register: 0.754 +peripherals: 0.753 +device: 0.751 +KVM: 0.741 +files: 0.738 +graphic: 0.731 +socket: 0.731 +x86: 0.730 +debug: 0.726 +semantic: 0.724 +permissions: 0.720 +hypervisor: 0.715 +kernel: 0.688 +VMM: 0.666 +network: 0.639 +boot: 0.636 +i386: 0.500 +-------------------- +virtual: 0.820 +debug: 0.722 +ppc: 0.289 +x86: 0.173 +performance: 0.110 +PID: 0.092 +user-level: 0.091 +register: 0.069 +files: 0.069 +hypervisor: 0.058 +TCG: 0.031 +socket: 0.019 +device: 0.016 +kernel: 0.014 +network: 0.011 +semantic: 0.010 +permissions: 0.006 +i386: 0.006 +architecture: 0.006 +boot: 0.005 +graphic: 0.004 +peripherals: 0.004 +assembly: 0.004 +risc-v: 0.002 +VMM: 0.002 +arm: 0.001 +KVM: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +go build fails under qemu-ppc64le-static (qemu-user) + +I am using qemu-user (built static) in a docker container environment. When running multi-threaded go commands in the container (go build for example) the process may hang, report segfaults or other errors. I built qemu-ppc64le from the upstream git (master). + +I see the problem running on a multi core system with Intel i7 processors. +# cat /proc/cpuinfo | grep "model name" +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz + +Steps to reproduce: +1) Build qemu-ppc64le as static and copy into docker build directory named it qemu-ppc64le-static. + +2) Add hello.go to docker build dir. + +package main +import "fmt" +func main() { + fmt.Println("hello world") +} + +3) Create the Dockerfile from below: + +FROM ppc64le/golang:1.10.1-alpine3. +COPY qemu-ppc64le-static /usr/bin/ +COPY hello.go /go + +4) Build container +$ docker build -t qemutest -f Dockerfile ./go + +5) Run test +$ docker run -it qemutest + +/go # /usr/bin/qemu-ppc64le-static --version +qemu-ppc64le version 2.11.93 (v2.12.0-rc3-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +/go # go version +go version go1.10.1 linux/ppc64le + +/go # go build hello.go +fatal error: fatal error: stopm holding locksunexpected signal during runtime execution + +panic during panic +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1003528c] + +runtime stack: +runtime: unexpected return pc for syscall.Syscall6 called from 0xc42007f500 +stack: frame={sp:0xc4203be840, fp:0xc4203be860} stack=[0x4000b7ecf0,0x4000b928f0) + +syscall.Syscall6(0x100744e8, 0x3d, 0xc42050c140, 0x20, 0x18, 0x10422b80, 0xc4203be968[signal , 0x10012d88SIGSEGV: segmentation violation, 0xc420594000 code=, 0x00x1 addr=0x0 pc=0x1003528c) +] + +runtime stack: + /usr/local/go/src/syscall/asm_linux_ppc64x.s:61runtime.throw(0x10472d19, 0x13) + + /usr/local/go/src/runtime/panic.go:0x6c616 +0x68 + + +runtime.stopm() + /usr/local/go/src/runtime/proc.go:1939goroutine +10x158 + [runtime.exitsyscall0semacquire(0xc42007f500) + /usr/local/go/src/runtime/proc.go:3129 +]: +0x130 +runtime.mcall(0xc42007f500) + /usr/local/go/src/runtime/asm_ppc64x.s:183 +0x58sync.runtime_Semacquire +(0xc4201fab1c) + /usr/local/go/src/runtime/sema.go:56 +0x38 + +---- +Note the results may differ between attempts, hangs and other faults sometimes happen. +---- +If I run "go: single threaded I don't see the problem, for example: + +/go # GOMAXPROCS=1 go build -p 1 hello.go +/go # ./hello +hello world + +I see the same issue with arm64. I don't think this is a go issue, but don't have a real evidence to prove that. This problem looks similar to other problem I have seen reported against qemu running multi-threaded applications. + +I missed a step for reproduction. Step 1 should be: +docker run --rm --privileged multiarch/qemu-user-static:register +This modprobes binfmt and registers qemu-ppc64le-static as the interpreter for ppc64le executables. + +FYI: To workaround this issue you can limit the docker container to a single cpu like this: + +docker run --cpuset-cpus 0 -it cross-test3 go build hello.go + +This works for docker build as well. + +docker build--cpuset-cpus 0 ..... + +Do you have a simpler repro case (ie one that doesn't require docker) ? + + +I will attempt to find an way to re-create without docker. The key is we need a way to create a ppc64le (or arm64) fakeroot with go that we can chroot into. That is easy to do with docker. BTW: the use case using docker and qemu-user-static is becoming fairly common way to cross build container images. + +I care more about the arm64 case, so if you're going to do one then that would be my preference. + + +Using QEMU from tag v2.12.0-rc4 on Ubuntu Xenial ppc64el, it works. + +muriloo@jaspion1:~/go-docker$ sudo docker run --rm -it qemutest +/go # /usr/bin/qemu-ppc64le-static --version +qemu-ppc64 version 2.11.94 (v2.12.0-rc4-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +/go # go version +go version go1.10.1 linux/ppc64le +/go # go build hello.go +/go # ./hello +hello world +/go # + +Here is how I configured QEMU: + +muriloo@jaspion1:~/sources/qemu$ ./configure --target-list=ppc64-linux-user --disable-system --disable-tools --static + +muriloo@jaspion1:~$ uname -a +Linux jaspion1 4.4.0-119-generic #143-Ubuntu SMP Mon Apr 2 16:08:02 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +With QEMU from tag v2.12.0-rc4 on Fedora 27 x86_64, it works too. + +muriloo@laptop$ docker run --rm -it qemutest +/go # qemu-ppc64le-static --version +qemu-ppc64le version 2.11.94 (v2.12.0-rc4) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +/go # go version +go version go1.10.1 linux/ppc64le +/go # go build hello.go +/go # ./hello +hello world +/go # + +muriloo@laptop$ uname -a +Linux laptop 4.15.17-300.fc27.x86_64 #1 SMP Thu Apr 12 18:19:17 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +muriloo@laptop$ rpm -q docker +docker-1.13.1-51.git4032bd5.fc27.x86_64 + +Thanks for the update, I will test that version and report back ( it may be a few days) + +We recently fixed bug #1696773 which was a cause of various crashes or other problems when trying to run go binaries under linux-user, including "go build hello.go". So I strongly suspect this is a duplicate of that bug. Could you test with the QEMU v4.1.0 rc3 or later, please? + + +Have you ever tried with a newer version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/177 b/results/classifier/118/review/177 new file mode 100644 index 000000000..acc70dc4b --- /dev/null +++ b/results/classifier/118/review/177 @@ -0,0 +1,61 @@ +mistranslation: 0.994 +semantic: 0.663 +virtual: 0.587 +architecture: 0.343 +device: 0.316 +peripherals: 0.315 +arm: 0.309 +graphic: 0.214 +user-level: 0.214 +performance: 0.185 +permissions: 0.178 +network: 0.162 +ppc: 0.127 +vnc: 0.118 +VMM: 0.099 +register: 0.088 +debug: 0.086 +files: 0.053 +boot: 0.042 +TCG: 0.037 +i386: 0.029 +PID: 0.028 +assembly: 0.026 +risc-v: 0.020 +x86: 0.019 +KVM: 0.018 +hypervisor: 0.015 +socket: 0.013 +kernel: 0.011 +-------------------- +virtual: 0.882 +device: 0.247 +files: 0.163 +hypervisor: 0.151 +user-level: 0.089 +network: 0.065 +debug: 0.054 +peripherals: 0.049 +x86: 0.039 +assembly: 0.031 +semantic: 0.029 +performance: 0.013 +i386: 0.009 +PID: 0.006 +register: 0.005 +ppc: 0.004 +boot: 0.003 +VMM: 0.002 +TCG: 0.002 +permissions: 0.001 +KVM: 0.001 +kernel: 0.001 +graphic: 0.001 +socket: 0.001 +architecture: 0.001 +mistranslation: 0.001 +vnc: 0.000 +risc-v: 0.000 +arm: 0.000 + +qemu-bridge-helper undocumented and broken diff --git a/results/classifier/118/review/1771 b/results/classifier/118/review/1771 new file mode 100644 index 000000000..1daeeca00 --- /dev/null +++ b/results/classifier/118/review/1771 @@ -0,0 +1,93 @@ +user-level: 0.977 +architecture: 0.936 +graphic: 0.917 +peripherals: 0.911 +performance: 0.867 +device: 0.843 +PID: 0.781 +socket: 0.778 +semantic: 0.749 +vnc: 0.729 +files: 0.645 +kernel: 0.641 +permissions: 0.638 +debug: 0.624 +ppc: 0.601 +network: 0.581 +boot: 0.572 +mistranslation: 0.523 +assembly: 0.491 +arm: 0.481 +register: 0.477 +risc-v: 0.437 +VMM: 0.262 +TCG: 0.252 +hypervisor: 0.251 +virtual: 0.234 +x86: 0.128 +KVM: 0.118 +i386: 0.068 +-------------------- +user-level: 0.576 +assembly: 0.343 +register: 0.148 +files: 0.134 +debug: 0.090 +virtual: 0.052 +semantic: 0.038 +architecture: 0.032 +PID: 0.012 +kernel: 0.011 +TCG: 0.009 +hypervisor: 0.009 +device: 0.004 +performance: 0.004 +boot: 0.003 +network: 0.002 +graphic: 0.001 +peripherals: 0.001 +VMM: 0.001 +KVM: 0.001 +socket: 0.001 +permissions: 0.001 +mistranslation: 0.001 +vnc: 0.001 +risc-v: 0.000 +i386: 0.000 +ppc: 0.000 +arm: 0.000 +x86: 0.000 + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/118/review/1771570 b/results/classifier/118/review/1771570 new file mode 100644 index 000000000..7410541de --- /dev/null +++ b/results/classifier/118/review/1771570 @@ -0,0 +1,87 @@ +architecture: 0.826 +files: 0.749 +device: 0.647 +semantic: 0.634 +performance: 0.630 +graphic: 0.544 +user-level: 0.540 +x86: 0.476 +mistranslation: 0.467 +socket: 0.435 +network: 0.434 +permissions: 0.412 +register: 0.366 +ppc: 0.357 +debug: 0.346 +boot: 0.344 +PID: 0.338 +peripherals: 0.337 +kernel: 0.333 +risc-v: 0.330 +vnc: 0.296 +virtual: 0.277 +hypervisor: 0.277 +arm: 0.248 +TCG: 0.198 +VMM: 0.193 +i386: 0.127 +KVM: 0.121 +assembly: 0.096 +-------------------- +hypervisor: 0.809 +virtual: 0.668 +kernel: 0.596 +user-level: 0.190 +files: 0.074 +TCG: 0.029 +debug: 0.022 +architecture: 0.014 +PID: 0.011 +semantic: 0.010 +register: 0.008 +performance: 0.006 +KVM: 0.005 +network: 0.005 +device: 0.004 +VMM: 0.004 +permissions: 0.002 +socket: 0.002 +assembly: 0.002 +ppc: 0.002 +boot: 0.002 +peripherals: 0.002 +vnc: 0.001 +graphic: 0.001 +risc-v: 0.001 +arm: 0.001 +x86: 0.001 +mistranslation: 0.000 +i386: 0.000 + +qemu-aarch64 $program > $file doesn't pipe output to file in 2.12.0 + +Running qemu-aarch64 $program > $file doesn't pipe anything to $file. The file is created but empty. + +qemu-aarch64 --help > $file works, so piping output in my system seems to work. +qemu-x86_64 $program > $file works, too. + +I'm running version 2.12.0 build from source with ./configure && make + +Output of uname -a: +Linux zhostname> 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Running "unbuffer qemu-aarch64 $program > $file" allows to pipe the output. + +Is it intentional that I need to disable buffering to allow piping to other processes? If yes, this issue can be closed. + +further reading about unbuffer: https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe#25378 + + + +No, this should work on qemu-aarch64 the same way as for x86. I just tried redirection to a file with a sample program, and it worked fine for me. Can you provide a test case binary that fails like this, please? + + +This issue is now marked as invalid, sorry for the trouble. + +qemu works just fine. The problem was with my linker configuration, it was using a different dynamic library for aarch64. Switching to a standard development stack solved my problem. + diff --git a/results/classifier/118/review/1771948 b/results/classifier/118/review/1771948 new file mode 100644 index 000000000..5442fb48e --- /dev/null +++ b/results/classifier/118/review/1771948 @@ -0,0 +1,98 @@ +architecture: 0.905 +performance: 0.896 +files: 0.855 +graphic: 0.837 +semantic: 0.818 +kernel: 0.811 +user-level: 0.792 +device: 0.763 +permissions: 0.742 +arm: 0.710 +debug: 0.692 +ppc: 0.636 +hypervisor: 0.634 +peripherals: 0.626 +register: 0.622 +network: 0.610 +vnc: 0.606 +socket: 0.601 +virtual: 0.579 +PID: 0.544 +mistranslation: 0.540 +VMM: 0.526 +assembly: 0.504 +risc-v: 0.499 +TCG: 0.495 +boot: 0.482 +x86: 0.432 +KVM: 0.408 +i386: 0.314 +-------------------- +arm: 0.970 +virtual: 0.930 +debug: 0.870 +assembly: 0.820 +boot: 0.645 +kernel: 0.580 +hypervisor: 0.318 +user-level: 0.128 +architecture: 0.101 +TCG: 0.095 +register: 0.083 +semantic: 0.040 +network: 0.033 +PID: 0.028 +files: 0.028 +performance: 0.024 +device: 0.013 +VMM: 0.007 +risc-v: 0.005 +peripherals: 0.004 +socket: 0.003 +vnc: 0.003 +graphic: 0.002 +permissions: 0.002 +KVM: 0.001 +x86: 0.001 +ppc: 0.001 +mistranslation: 0.001 +i386: 0.000 + +aarch64 msr CNTFRQ_EL0 + +Hello, + +I'm running qemu 2.12 on a raspberry pi 3 with the command: + +qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin + +On my start file (right in the beginning with the highest EL), the following instructions: + +ldr x0 , =19200000 +msr CNTFRQ_EL0, x0 + + +and qemu halts on the "msr CNTFRQ_EL0, x0" instruction. + +I believe this is not a normal behavior. + +Thank you + +Mmm, that's not really supposed to happen. Do you have a test guest binary you can attach that I can reproduce with? + + +Looking more closely at this, I think this is because you've passed QEMU a file which it is treating as a Linux kernel. (-kernel treats raw binaries and uimage files as Linux kernels; it treats ELF files as not being Linux kernels). Linux expects to be started in EL2, so although the emulated CPU has EL3, we start your program in EL2. Your program is therefore not running at the highest available exception level, and can't write to CNTFRQ_EL0. + +For "bare metal" images where you want to do things at EL3, it may be better to build them as ELF files which are linked to load at address 0. Note that all four cores will start at address zero simultaneously, so you'll need a bit of "pen code" to sort the secondaries out from the primary. https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S might be useful reference. As I understand it, this is how your code would be run on real raspi3 hardware too. + + +Thank you for your reply. Sorry to take so long (was on vacations). + +Your comment seems correct to me. I tried with the ELF file instead of the binary file and it worked perfectly (and all the cores were running instead of just core 0). + +From my point of view, this bug can be marked as invalid. + +Thank you again. + + + diff --git a/results/classifier/118/review/1772086 b/results/classifier/118/review/1772086 new file mode 100644 index 000000000..5c8d143da --- /dev/null +++ b/results/classifier/118/review/1772086 @@ -0,0 +1,93 @@ +mistranslation: 0.865 +semantic: 0.766 +kernel: 0.722 +ppc: 0.675 +peripherals: 0.656 +device: 0.626 +architecture: 0.612 +PID: 0.554 +graphic: 0.549 +files: 0.546 +hypervisor: 0.489 +network: 0.489 +performance: 0.468 +register: 0.440 +vnc: 0.429 +user-level: 0.414 +socket: 0.409 +permissions: 0.385 +debug: 0.383 +boot: 0.294 +VMM: 0.279 +TCG: 0.261 +risc-v: 0.259 +KVM: 0.257 +x86: 0.236 +arm: 0.226 +virtual: 0.226 +i386: 0.187 +assembly: 0.150 +-------------------- +debug: 0.839 +virtual: 0.792 +kernel: 0.649 +KVM: 0.615 +x86: 0.138 +TCG: 0.048 +files: 0.044 +hypervisor: 0.042 +i386: 0.035 +VMM: 0.031 +peripherals: 0.018 +device: 0.017 +PID: 0.014 +user-level: 0.012 +network: 0.011 +register: 0.010 +socket: 0.008 +semantic: 0.003 +performance: 0.002 +risc-v: 0.002 +assembly: 0.002 +ppc: 0.002 +vnc: 0.001 +architecture: 0.001 +graphic: 0.001 +boot: 0.001 +arm: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +malformed serial data being sent from guest + +When sending data through serial from guest each time 0x0A byte is sent 0x0D is sent before it. For example, when sending {0x29, 0x0A} on the other end I receive {0x29, 0x0D, 0x0A}. + +Something somewhere in the stack is converting LF to CRLF. This could be something inside your guest, or in QEMU, or in the host; to find out where we need more detail. + +Can you describe your setup, including: + * complete QEMU command line + * how you're sending data inside the guest + * how you're reading it on the host end +please? + + +I am unable to provide complete QEMU command line as I'm using virt-manager to deal with configuration. I can say that two serial ports are linked with physical ones through the /dev/ttyS* files. +The guests I tested it with are Windows 98 and Windows XP. For the testing I connected one port to another. I could confirm through a kernel level serial monitor that I was indeed sending just \n but on the second port I received \r\n. I also received \r\n when the port was read by the host. +Host is Ubuntu Xenial. + +After doing a bit of research I think line 142 in file chardev/char-serial.c is problematic. https://github.com/qemu/qemu/blob/master/chardev/char-serial.c#L142 + +It enables output processing, which is something unwanted here. With a simple test program I found out that by default, besides OPOST, ONLCR flag is set in c_oflag. I guess fix would be removing OPOST flag, which would disable any output processing, or setting c_oflag to 0 just to be sure. + +Seems like the problems isn't really new and might be at least 6 years old if not more. https://robert.penz.name/550/mapping-a-serial-device-to-a-kvm-guest-may-lead-to-communication-problems/ + +It's even older than 6 years, see: +https://lists.nongnu.org/archive/html/qemu-devel/2006-06/msg00196.html +and: +https://bugs.launchpad.net/qemu/+bug/1407813 +https://bugs.launchpad.net/qemu/+bug/1715296 + + +Patch has now been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec + diff --git a/results/classifier/118/review/1774412 b/results/classifier/118/review/1774412 new file mode 100644 index 000000000..0813fe7f9 --- /dev/null +++ b/results/classifier/118/review/1774412 @@ -0,0 +1,77 @@ +mistranslation: 0.991 +virtual: 0.893 +performance: 0.838 +semantic: 0.835 +files: 0.826 +device: 0.773 +vnc: 0.743 +network: 0.735 +graphic: 0.732 +architecture: 0.697 +ppc: 0.696 +VMM: 0.667 +hypervisor: 0.654 +socket: 0.638 +register: 0.609 +user-level: 0.568 +i386: 0.541 +kernel: 0.539 +PID: 0.519 +KVM: 0.497 +arm: 0.495 +assembly: 0.463 +risc-v: 0.462 +boot: 0.455 +TCG: 0.452 +peripherals: 0.424 +x86: 0.420 +permissions: 0.371 +debug: 0.358 +-------------------- +user-level: 0.658 +hypervisor: 0.441 +performance: 0.338 +x86: 0.173 +TCG: 0.155 +virtual: 0.100 +files: 0.060 +semantic: 0.041 +register: 0.038 +debug: 0.032 +i386: 0.023 +PID: 0.021 +kernel: 0.016 +device: 0.014 +arm: 0.014 +ppc: 0.014 +network: 0.013 +VMM: 0.009 +risc-v: 0.008 +architecture: 0.007 +socket: 0.006 +KVM: 0.006 +boot: 0.004 +peripherals: 0.004 +assembly: 0.003 +graphic: 0.003 +permissions: 0.003 +vnc: 0.002 +mistranslation: 0.001 + +-icount sleep=on|off documentation is confusing + +The documentation for the -icount option in the qemu man page says: + +"When the virtual cpu is sleeping, the virtual time will advance at default speed unless sleep=on|off is specified. With sleep=on|off, the virtual time will jump to the next timer deadline instantly whenever the virtual cpu goes to sleep mode and will not advance if no timer is enabled." + +Taking this literally and specifying "sleep=on|off" on the command line does not work, so presumably the two instances of "sleep=on|off" should be either "sleep=on" or "sleep=off", +whichever is correct :) + +Also, the synopsis line "-icount [shift=N|auto][,rr=record|replay,rrfile=filename,rrsnapshot=snapshot" fails to mention the sleep keyword at all. + +Should be fixed by this patch: +https://<email address hidden>/ + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=fa647905e6baae9510e7d + diff --git a/results/classifier/118/review/1774853 b/results/classifier/118/review/1774853 new file mode 100644 index 000000000..884eb3ab5 --- /dev/null +++ b/results/classifier/118/review/1774853 @@ -0,0 +1,123 @@ +user-level: 0.913 +permissions: 0.858 +register: 0.840 +graphic: 0.839 +device: 0.833 +semantic: 0.830 +peripherals: 0.824 +hypervisor: 0.823 +socket: 0.811 +debug: 0.811 +performance: 0.810 +architecture: 0.804 +assembly: 0.803 +kernel: 0.796 +network: 0.794 +virtual: 0.789 +PID: 0.789 +arm: 0.786 +mistranslation: 0.784 +files: 0.777 +risc-v: 0.771 +TCG: 0.753 +VMM: 0.748 +KVM: 0.732 +x86: 0.731 +vnc: 0.722 +boot: 0.720 +ppc: 0.702 +i386: 0.603 +-------------------- +user-level: 0.845 +x86: 0.770 +virtual: 0.638 +permissions: 0.180 +debug: 0.064 +files: 0.037 +register: 0.029 +kernel: 0.020 +PID: 0.017 +TCG: 0.011 +boot: 0.010 +semantic: 0.008 +device: 0.007 +arm: 0.007 +hypervisor: 0.006 +risc-v: 0.006 +socket: 0.005 +performance: 0.005 +VMM: 0.004 +assembly: 0.004 +network: 0.004 +ppc: 0.003 +vnc: 0.002 +architecture: 0.002 +mistranslation: 0.001 +i386: 0.001 +peripherals: 0.001 +graphic: 0.001 +KVM: 0.000 + +claims temp file is used by another process + +QEMU emulator version 2.12.50 (v2.12.0-12378-g99a34dc4d2-dirty) + +"c:\Program Files\qemu\qemu-system-x86_64.exe" -net none -parallel none -bios OVMF.fd -L . -hda fat:rw:image +vvfat image chs 1024,16,63 +c:\Program Files\qemu\qemu-system-x86_64.exe: -hda fat:rw:image: Could not open 'C:\Users\tsiros\AppData\Local\Temp\qem5B92.tmp': The process cannot access the file because it is being used by another process. + +someone please delete this + +@tsiros, can you explain why this isn't an issue for you anymore? This is precisely what happens to me, specifically when I create drives as `file=fat:rw:path/to/dir`. When I type `fat:path/to/dir`, everything works fine, though I get some warnings. Was this fixed in newer versions or did you simply realized some issue on your side? Thanks. + +Hi there! Our fork of QEMU still happens to have this issue. Did you happen to find a solution? + +$ ../orbital-qemu/ps4-softmmu/qemu-system-ps4 -bios ./ubios.bin -kernel ./boot.img -drive file=hdd.qcow2 -drive file=fat:rw:sflash/,media=disk -monitor stdio -smp 8 -display orbital +vvfat sflash/ chs 1024,16,63 +C:\tools\msys64\home\Alex\orbital\orbital-qemu\ps4-softmmu\qemu-system-ps4.exe: -drive file=fat:rw:sflash/,media=disk: Could not open 'C:\tools\msys64\tmp\qem1DF0.tmp': The process cannot access the file because it is being used by another process. + +I can't remember at all! + +i am sorry i know how frustrating this is + +i don't remember even if i fixed it or if i gave up + +On Thu, Jun 13, 2019, 03:20 Alexandro Sanchez Bach < +<email address hidden>> wrote: + +> @tsiros, can you explain why this isn't an issue for you anymore? This +> is precisely what happens to me, specifically when I create drives as +> `file=fat:rw:path/to/dir`. When I type `fat:path/to/dir`, everything +> works fine, though I get some warnings. Was this fixed in newer versions +> or did you simply realized some issue on your side? Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1774853 +> +> Title: +> claims temp file is used by another process +> +> Status in QEMU: +> New +> +> Bug description: +> QEMU emulator version 2.12.50 (v2.12.0-12378-g99a34dc4d2-dirty) +> +> "c:\Program Files\qemu\qemu-system-x86_64.exe" -net none -parallel none +> -bios OVMF.fd -L . -hda fat:rw:image +> vvfat image chs 1024,16,63 +> c:\Program Files\qemu\qemu-system-x86_64.exe: -hda fat:rw:image: Could +> not open 'C:\Users\tsiros\AppData\Local\Temp\qem5B92.tmp': The process +> cannot access the file because it is being used by another process. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1774853/+subscriptions +> + + +Is this still reproducible with the latest version of QEMU, or could this ticket be closed nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1777 b/results/classifier/118/review/1777 new file mode 100644 index 000000000..be02eccee --- /dev/null +++ b/results/classifier/118/review/1777 @@ -0,0 +1,61 @@ +architecture: 0.852 +socket: 0.837 +network: 0.824 +device: 0.773 +peripherals: 0.698 +vnc: 0.654 +performance: 0.564 +permissions: 0.542 +debug: 0.503 +arm: 0.413 +PID: 0.364 +register: 0.355 +graphic: 0.331 +hypervisor: 0.302 +boot: 0.268 +risc-v: 0.268 +semantic: 0.257 +ppc: 0.216 +virtual: 0.209 +VMM: 0.203 +mistranslation: 0.156 +x86: 0.144 +i386: 0.113 +TCG: 0.097 +files: 0.092 +assembly: 0.092 +kernel: 0.089 +user-level: 0.055 +KVM: 0.025 +-------------------- +network: 0.956 +socket: 0.926 +debug: 0.827 +virtual: 0.748 +vnc: 0.721 +permissions: 0.124 +user-level: 0.108 +hypervisor: 0.100 +x86: 0.026 +device: 0.015 +register: 0.014 +semantic: 0.012 +TCG: 0.012 +VMM: 0.006 +files: 0.006 +assembly: 0.005 +kernel: 0.003 +risc-v: 0.003 +ppc: 0.003 +i386: 0.003 +arm: 0.002 +KVM: 0.002 +boot: 0.002 +graphic: 0.001 +architecture: 0.001 +peripherals: 0.001 +performance: 0.001 +PID: 0.000 +mistranslation: 0.000 + +Allow logging of IP addresses of connections made to QEMU socket backends for e.g. VNC or SPICE console diff --git a/results/classifier/118/review/1777226 b/results/classifier/118/review/1777226 new file mode 100644 index 000000000..80f21d421 --- /dev/null +++ b/results/classifier/118/review/1777226 @@ -0,0 +1,82 @@ +user-level: 0.953 +device: 0.816 +performance: 0.801 +semantic: 0.785 +files: 0.726 +ppc: 0.700 +graphic: 0.697 +boot: 0.638 +network: 0.615 +register: 0.610 +socket: 0.601 +PID: 0.580 +permissions: 0.579 +vnc: 0.545 +TCG: 0.544 +architecture: 0.533 +kernel: 0.514 +i386: 0.494 +VMM: 0.484 +x86: 0.473 +debug: 0.469 +KVM: 0.462 +mistranslation: 0.440 +risc-v: 0.423 +peripherals: 0.414 +arm: 0.390 +virtual: 0.229 +hypervisor: 0.215 +assembly: 0.134 +-------------------- +debug: 0.317 +TCG: 0.264 +hypervisor: 0.192 +user-level: 0.089 +virtual: 0.041 +boot: 0.040 +files: 0.034 +x86: 0.033 +PID: 0.014 +register: 0.013 +semantic: 0.009 +performance: 0.007 +i386: 0.006 +VMM: 0.005 +kernel: 0.004 +ppc: 0.004 +architecture: 0.004 +network: 0.004 +socket: 0.004 +device: 0.003 +arm: 0.003 +risc-v: 0.003 +assembly: 0.002 +peripherals: 0.002 +vnc: 0.002 +KVM: 0.001 +permissions: 0.001 +graphic: 0.001 +mistranslation: 0.000 + +qemu-user warnings confuse userland applications + +I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: + +configure: Found potential Boot JDK using configure arguments +configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring +configure: (Your Boot JDK version must be one of: 10 11) +configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK +configure exiting with result code 1 + +See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=sh4&ver=11%7E18-1&stamp=1529119043&raw=0 + +Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. + +Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar. + +Yes, we should probably move these "unimplemented syscall" warnings to the LOG_UNIMP logging level (which you can then turn on if you want them). + + +Patch has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=122f9c83f2ef1cd90152 + diff --git a/results/classifier/118/review/1777252 b/results/classifier/118/review/1777252 new file mode 100644 index 000000000..80f6d36f4 --- /dev/null +++ b/results/classifier/118/review/1777252 @@ -0,0 +1,118 @@ +architecture: 0.930 +peripherals: 0.920 +permissions: 0.917 +graphic: 0.903 +register: 0.898 +mistranslation: 0.890 +network: 0.886 +files: 0.880 +arm: 0.879 +user-level: 0.875 +virtual: 0.875 +TCG: 0.862 +hypervisor: 0.862 +performance: 0.860 +device: 0.855 +semantic: 0.852 +socket: 0.841 +debug: 0.833 +risc-v: 0.820 +PID: 0.813 +ppc: 0.811 +boot: 0.807 +vnc: 0.805 +VMM: 0.786 +assembly: 0.775 +kernel: 0.755 +i386: 0.719 +x86: 0.711 +KVM: 0.685 +-------------------- +virtual: 0.052 +files: 0.026 +debug: 0.020 +hypervisor: 0.013 +kernel: 0.009 +user-level: 0.007 +TCG: 0.005 +PID: 0.003 +boot: 0.003 +x86: 0.002 +register: 0.002 +architecture: 0.002 +semantic: 0.002 +graphic: 0.001 +vnc: 0.001 +device: 0.001 +network: 0.001 +risc-v: 0.001 +performance: 0.001 +socket: 0.001 +assembly: 0.001 +KVM: 0.001 +peripherals: 0.001 +VMM: 0.001 +i386: 0.001 +mistranslation: 0.000 +ppc: 0.000 +permissions: 0.000 +arm: 0.000 + +tests/Makefile.include trying to add linking library '-lutil' that break the build on Solaris + +Building script 'tests/Makefile.include' contains following code +``` +ifeq ($(CONFIG_POSIX),y) +LIBS += -lutil +endif +``` + +library -lutil is not available on Solaris, so the building will failed, like +``` +ld: fatal: library -lutil: not found +make: *** [SOMEWHERE/src/qemu-2.12.0/rules.mak:121: qemu-nbd] Error 1 +``` + +Commenting those code out fixed the error. + +I'm sorry, but Solaris is currently unsupported and might get removed in a future release, see: + + https://wiki.qemu.org/ChangeLog/2.12#Warning:_unsupported_host_systems + +So it would be great if you could contribute patches, or find someone who's willing to maintain QEMU on Solaris. + +Does something like this work for you? + +diff --git a/tests/Makefile.include b/tests/Makefile.include +--- a/tests/Makefile.include ++++ b/tests/Makefile.include +@@ -777,7 +777,7 @@ tests/migration/initrd-stress.img: tests/migration/stress$(EXESUF) + rm $(INITRD_WORK_DIR)/init + rmdir $(INITRD_WORK_DIR) + +-ifeq ($(CONFIG_POSIX),y) ++ifeq ($(CONFIG_POSIX)$(call lnot,$(CONFIG_SOLARIS)),yy) + LIBS += -lutil + endif + + +That's great. I spent quite a while last summer looking for the source of that error, without success. I finally just created a stub library named lutil figuring I would then find which function was missing on the next build attempt. But it worked fine so apparently QEMU does not even use whatever is in lutil, at least on Solaris. + +I'm still offering to help maintain this as I have some actual Solaris hardware. + +The condition we use in configure to decide whether to add -lutil to libs_softmmu is "not Darwin and not MinGW and not Solaris and not Haiku"... + +I think the thing we're trying to get from libutil is openpty(), which is in that library for Linux and the BSDs. It's not in libutil for OSX (though since OSX has a libutil anyway it's harmless that it gets linked in). For Windows we avoid code paths that use openpty(), and Solaris doesn't have openpty() at all so we have to hand-roll our own implementation in util/qemu-openpty.c. + +I think the cleanest fix to this problem is to have a configure test that checks "does openpty() require -lutil?", and then use the answer to that both to decide whether to add -lutil to libs_softmmu and to decide whether to add -lutil to the link line for this test binary. + +PS: Thanks for the offer of Solaris hardware access. We may be able to take you up on that but it would also require some time from somebody on our end to set things up to use it. The other possible option is to have one of the free-solaris-equivalents set up as a VM to run tests in in the same way we do for the BSDs in tests/vm. + + +>>> Does something like this work for you? + +Yes, this fix works; but I don't think this is a clean fix, since libutil may also missing in other OS. + +Problem has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d99e97e6912d90a55e9 + diff --git a/results/classifier/118/review/1778 b/results/classifier/118/review/1778 new file mode 100644 index 000000000..e871a93b6 --- /dev/null +++ b/results/classifier/118/review/1778 @@ -0,0 +1,61 @@ +mistranslation: 0.892 +device: 0.832 +performance: 0.716 +graphic: 0.678 +arm: 0.371 +network: 0.353 +peripherals: 0.315 +boot: 0.272 +permissions: 0.208 +hypervisor: 0.198 +debug: 0.190 +register: 0.172 +user-level: 0.165 +VMM: 0.158 +TCG: 0.129 +ppc: 0.119 +PID: 0.116 +vnc: 0.086 +files: 0.084 +virtual: 0.080 +risc-v: 0.077 +kernel: 0.068 +socket: 0.065 +architecture: 0.047 +assembly: 0.046 +semantic: 0.026 +KVM: 0.020 +i386: 0.009 +x86: 0.007 +-------------------- +virtual: 0.967 +hypervisor: 0.752 +user-level: 0.640 +performance: 0.170 +x86: 0.152 +files: 0.084 +i386: 0.039 +device: 0.034 +debug: 0.030 +peripherals: 0.015 +semantic: 0.015 +arm: 0.008 +register: 0.008 +ppc: 0.007 +KVM: 0.006 +PID: 0.004 +boot: 0.004 +assembly: 0.002 +mistranslation: 0.002 +VMM: 0.001 +kernel: 0.001 +socket: 0.001 +TCG: 0.001 +graphic: 0.001 +network: 0.001 +architecture: 0.001 +permissions: 0.001 +risc-v: 0.000 +vnc: 0.000 + +Spice audio play at wrong speed and frequency after qemu-7.2.0 diff --git a/results/classifier/118/review/1778350 b/results/classifier/118/review/1778350 new file mode 100644 index 000000000..2cea5d89b --- /dev/null +++ b/results/classifier/118/review/1778350 @@ -0,0 +1,171 @@ +user-level: 0.929 +VMM: 0.919 +PID: 0.913 +mistranslation: 0.902 +ppc: 0.902 +peripherals: 0.899 +hypervisor: 0.896 +arm: 0.893 +x86: 0.891 +assembly: 0.888 +graphic: 0.878 +virtual: 0.874 +network: 0.872 +semantic: 0.869 +performance: 0.865 +boot: 0.861 +register: 0.855 +socket: 0.850 +debug: 0.850 +risc-v: 0.846 +permissions: 0.841 +files: 0.831 +architecture: 0.828 +KVM: 0.811 +vnc: 0.809 +device: 0.796 +TCG: 0.789 +kernel: 0.743 +i386: 0.488 +-------------------- +x86: 0.862 +boot: 0.575 +debug: 0.286 +TCG: 0.193 +register: 0.122 +virtual: 0.115 +files: 0.098 +VMM: 0.063 +kernel: 0.045 +device: 0.043 +PID: 0.023 +network: 0.020 +socket: 0.018 +risc-v: 0.016 +hypervisor: 0.012 +user-level: 0.012 +arm: 0.011 +vnc: 0.009 +ppc: 0.004 +assembly: 0.003 +performance: 0.003 +architecture: 0.002 +semantic: 0.002 +peripherals: 0.002 +graphic: 0.002 +i386: 0.002 +permissions: 0.001 +KVM: 0.001 +mistranslation: 0.000 + +Android-x86 4.4-r5 won't boot on QEMU since v2.11.0-rc2 + +Try to boot from the Android-x86 4.4-r5 ISO won't boot in QEMU after 2.11.0-rc2. The last known version it works is 2.11.0-rc1. +It also works on the 2.10.x-line, even the 2.10.2 which was released after 2.11.0-rc2! + +How to reproduce: +Download the ISO from +http://www.android-x86.org/releases/releasenote-4-4-r5 or directly https://www.fosshub.com/Android-x86.html/android-x86-4.4-r5.iso + +Start QEMU with this command-line: qemu-system-x86_64 -cdrom android-x86-4.4-r5.iso -m 1024 + +On 2.11.0-rc1 and 2.10.2 after selecting to boot from CD it shows the Android splash after a short while ... +On 2.11.0-rc2 through the latest 2.12 line it goes to black screen shortly right after selecting to boot from CD + +After 'git bisect' -ing it I found the commit that is responsible for this: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9fa99d2519cbf71f871e46871df12cb446dc1c3e + +CC Michael Tsirkin + +On 06/25/2018 06:53 AM, navicrej wrote: +> After 'git bisect' -ing it I found the commit that is responsible for +> this: +> +> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9fa99d2519cbf71f871e46871df12cb446dc1c3e +> + + +On Mon, Jun 25, 2018 at 01:46:16PM -0400, John Snow wrote: +> CC Michael Tsirkin +> +> On 06/25/2018 06:53 AM, navicrej wrote: +> > After 'git bisect' -ing it I found the commit that is responsible for +> > this: +> > +> > https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9fa99d2519cbf71f871e46871df12cb446dc1c3e +> > + +Can you pls try to set x-pci-hole64-fix=off and see whether that helps? + +-- +MST + + +I don't know if there is another way to do that but I changed the properties of x-pci-hole64-fix in hw/pci-host/piix.c and hw/pci-host/q35.c to false on current master and compiled and now it works again. + +Maybe you can add a switch (unless there already is one) so one can change it on runtime without compiling? + +Nevermind that, just found out how to run: + +qemu-system-x86_64 -cdrom android-x86-4.4-r5.iso -m 1024 -global i440FX-pcihost.x-pci-hole64-fix=off -global q35-pcihost.x-pci-hole64-fix=off + + + +I looked at it and while I might be wrong, I suspect +it's a bug in ACPI parser in that version of Linux. +Is there a way for you to try a later Linux version? +Alternatively, I tried to build 4.4-rc2 on Fedora and couldn't. + +On Tue, Jun 26, 2018 at 09:13:12AM -0000, navicrej wrote: +> Nevermind that, just found out how to run: +> +> qemu-system-x86_64 -cdrom android-x86-4.4-r5.iso -m 1024 -global i440FX- +> pcihost.x-pci-hole64-fix=off -global q35-pcihost.x-pci-hole64-fix=off +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1778350 +> +> Title: +> Android-x86 4.4-r5 won't boot on QEMU since v2.11.0-rc2 +> +> Status in QEMU: +> New +> +> Bug description: +> Try to boot from the Android-x86 4.4-r5 ISO won't boot in QEMU after 2.11.0-rc2. The last known version it works is 2.11.0-rc1. +> It also works on the 2.10.x-line, even the 2.10.2 which was released after 2.11.0-rc2! +> +> How to reproduce: +> Download the ISO from +> http://www.android-x86.org/releases/releasenote-4-4-r5 or directly https://www.fosshub.com/Android-x86.html/android-x86-4.4-r5.iso +> +> Start QEMU with this command-line: qemu-system-x86_64 -cdrom +> android-x86-4.4-r5.iso -m 1024 +> +> On 2.11.0-rc1 and 2.10.2 after selecting to boot from CD it shows the Android splash after a short while ... +> On 2.11.0-rc2 through the latest 2.12 line it goes to black screen shortly right after selecting to boot from CD +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1778350/+subscriptions + + +I compiled the 4.4.4-r5 branch but I was not able to change the kernel yet. + +Furthermore I am not able to use any version of Android x86 6.x, 7.x, 8.x on current QEMU with or without the parameters. + +@navicrej -- can you please apply the series + +[Qemu-devel] [PATCH 0/2] hw/pci-host/x86: extend the 64-bit PCI hole relative to the fw-assigned base +https://<email address hidden>/ + +on your end, and see if it makes a difference? + +(I don't expect it to, for the reason I described in <http://<email address hidden>>.) + +Thanks! + +No feedback for almost two years, closing. + diff --git a/results/classifier/118/review/1778473 b/results/classifier/118/review/1778473 new file mode 100644 index 000000000..3a15a5d64 --- /dev/null +++ b/results/classifier/118/review/1778473 @@ -0,0 +1,198 @@ +user-level: 0.888 +register: 0.880 +permissions: 0.866 +debug: 0.861 +architecture: 0.858 +device: 0.842 +graphic: 0.838 +ppc: 0.820 +assembly: 0.819 +PID: 0.818 +performance: 0.817 +KVM: 0.814 +kernel: 0.804 +risc-v: 0.803 +virtual: 0.797 +arm: 0.795 +boot: 0.794 +files: 0.778 +socket: 0.775 +peripherals: 0.773 +semantic: 0.773 +VMM: 0.758 +hypervisor: 0.757 +TCG: 0.752 +x86: 0.740 +mistranslation: 0.710 +vnc: 0.707 +network: 0.695 +i386: 0.636 +-------------------- +x86: 0.997 +kernel: 0.973 +assembly: 0.422 +virtual: 0.358 +debug: 0.255 +PID: 0.081 +architecture: 0.057 +files: 0.051 +register: 0.027 +performance: 0.022 +hypervisor: 0.013 +TCG: 0.012 +device: 0.006 +semantic: 0.005 +boot: 0.003 +KVM: 0.003 +user-level: 0.003 +permissions: 0.002 +graphic: 0.002 +socket: 0.002 +VMM: 0.001 +i386: 0.001 +network: 0.001 +peripherals: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +ppc: 0.001 +vnc: 0.000 +arm: 0.000 + +[Crash] qemu-system-x86_64: mov_ss_trap_64 PANIC: double fault, error_code: 0x0 + +Kselftest test case mov_ss_trap_64 is causing kernel panic on +qemu-system-x86_64 and PASS on real x86_64 hardware. + +qemu-system-x86_64 version is 2.12.0 +host architecture: amd64 + +Test failed on recent stable rc kernel, +4.17.3-rc1, 4.16.18-rc1 and 4.14.52-rc1. + + +Test code snippet, +main() { +<> + printf("[RUN]\tMOV SS; CS CS INT3\n"); + asm volatile ("mov %[ss], %%ss; .byte 0x2e, 0x2e; int3" :: [ss] "m" (ss)); +<> +} + +Kerel crash log, +# cd /opt/kselftests/mainline/x86 +# ./mov_ss_trap_64 + SS = 0x2b, &SS = 0x0x604188 + Set up a watchpoint + DR0 = 604188, DR1 = 400a19, DR7 = 7000a +[RUN] Read from watched memory (should get SIGTRAP) + Got SIGTRAP with RIP=4008ea, EFLAGS.RF=0 +[RUN] MOV SS; INT3 + Got SIGTRAP with RIP=4008fb, EFLAGS.RF=0 +[RUN] MOV SS; INT 3 + Got SIGTRAP with RIP=40090d, EFLAGS.RF=0 +[RUN] M[ 20.305426] PANIC: double fault, error_code: 0x0 +OV SS; CS CS INT3 + Got SIGTRAP with RIP=400920,[ 20.308317] CPU: 3 PID: 2471 Comm: mov_ss_trap_64 Not tainted 4.17.3-rc1 #1 + EFLAGS.RF=0 +[RUN] MOV SS; CSx14 INT3 +[ 20.311664] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 +[ 20.314738] RIP: 0010:error_entry+0x32/0x100 +[ 20.316198] RSP: 0000:fffffe0000086000 EFLAGS: 00010046 +[ 20.317911] RAX: 0000000092400a87 RBX: 0000000000000000 RCX: 0000000000000000 +[ 20.320168] RDX: 0000000000000000 RSI: ffffffff92400f18 RDI: ffffffff92401146 +[ 20.322405] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 +[ 20.324320] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 +[ 20.326073] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 20.327869] FS: 00007f3174aefe80(0000) GS:ffff9f447fd80000(0000) knlGS:0000000000000000 +[ 20.329850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 20.331343] CR2: fffffe0000085ff8 CR3: 0000000136d2e000 CR4: 00000000000006e0 +[ 20.333150] DR0: 0000000000604188 DR1: 0000000000400a19 DR2: 0000000000000000 +[ 20.334893] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 000000000007060a +[ 20.336649] Call Trace: +[ 20.337523] <ENTRY_TRAMPOLINE> +[ 20.338507] ? native_iret+0x7/0x7 +[ 20.339611] ? page_fault+0x8/0x30 +[ 20.340693] ? error_entry+0x86/0x100 +[ 20.341871] ? trace_hardirqs_off_caller+0x7/0xa0 +[ 20.343212] ? trace_hardirqs_off_thunk+0x1a/0x1c +[ 20.344554] ? native_iret+0x7/0x7 +[ 20.345647] ? page_fault+0x8/0x30 +[ 20.346716] ? error_entry+0x86/0x100 +[ 20.347853] ? page_fault+0x8/0x30 +[ 20.348920] ? ist_enter+0x6/0xa0 +[ 20.349961] ? do_int3+0x34/0x120 +[ 20.351095] ? int3+0x14/0x20 +[ 20.352047] </ENTRY_TRAMPOLINE> +[ 20.353060] Code: 48 89 7c 24 08 52 31 d2 51 31 c9 50 41 50 45 31 c0 41 51 45 31 c9 41 52 45 31 d2 41 53 45 31 db 53 31 db 55 31 ed 41 54 45 31 e4 <41> 55 45 31 ed 41 56 45 31 f6 41 57 45 31 ff 56 48 8d 6c 24 09 +[ 20.357895] Kernel panic - not syncing: Machine halted. +[ 20.359385] CPU: 3 PID: 2471 Comm: mov_ss_trap_64 Not tainted 4.17.3-rc1 #1 +[ 20.361271] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 +[ 20.363513] Call Trace: +[ 20.364367] <#DF> +[ 20.365109] dump_stack+0x68/0x95 +[ 20.366131] panic+0xe3/0x22a +[ 20.367207] df_debug+0x2d/0x30 +[ 20.368254] do_double_fault+0x9f/0x120 +[ 20.369387] double_fault+0x23/0x30 +[ 20.370444] RIP: 0010:error_entry+0x32/0x100 +[ 20.371791] RSP: 0000:fffffe0000086000 EFLAGS: 00010046 +[ 20.373246] RAX: 0000000092400a87 RBX: 0000000000000000 RCX: 0000000000000000 +[ 20.375250] RDX: 0000000000000000 RSI: ffffffff92400f18 RDI: ffffffff92401146 +[ 20.377103] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 +[ 20.378958] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 +[ 20.380808] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 20.382744] ? page_fault+0x8/0x30 +[ 20.383925] ? error_entry+0x86/0x100 +[ 20.385037] </#DF> +[ 20.385793] <ENTRY_TRAMPOLINE> +[ 20.386774] ? native_iret+0x7/0x7 +[ 20.387839] ? page_fault+0x8/0x30 +[ 20.388901] ? error_entry+0x86/0x100 +[ 20.389997] ? trace_hardirqs_off_caller+0x7/0xa0 +[ 20.391464] ? trace_hardirqs_off_thunk+0x1a/0x1c +[ 20.392850] ? native_iret+0x7/0x7 +[ 20.393886] ? page_fault+0x8/0x30 +[ 20.394984] ? error_entry+0x86/0x100 +[ 20.396092] ? page_fault+0x8/0x30 +[ 20.397145] ? ist_enter+0x6/0xa0 +[ 20.398167] ? do_int3+0x34/0x120 +[ 20.399213] ? int3+0x14/0x20 +[ 20.400226] </ENTRY_TRAMPOLINE> +[ 20.401574] Kernel Offset: 0x10800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +[ 20.404788] ---[ end Kernel panic - not syncing: Machine halted. ]--- + +Full crash log can be found at, +https://lkft.validation.linaro.org/scheduler/job/303760 + +Download this image. +http://snapshots.linaro.org/openembedded/lkft/morty/intel-core2-32/rpb/linux-stable-rc-4.17/7/rpb-console-image-intel-core2-32-20180624171508-7.hddimg.xz + +Boot command: +qemu-system-x86_64 + -cpu host + -enable-kvm + -nographic + -net nic,model=virtio,macaddr=DE:AD:BE:EF:66:01 + -net tap -m 1024 + -monitor none + -drive format=raw,file=rpb-console-image-intel-core2-32-20180624171508-7.hddimg,if=virtio + -m 4096 + -smp 4 + -drive format=qcow2,file=/lava-guest.qcow2,media=disk,if=virtio + + +After successfull boot, +login as root + +Run the in-built test, +cd /opt/kselftests/mainline/x86 +./mov_ss_trap_64 + +Test case link, +https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/tools/testing/selftests/x86/mov_ss_trap.c?h=linux-4.17.y + +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/review/1780812 b/results/classifier/118/review/1780812 new file mode 100644 index 000000000..a1f9746a7 --- /dev/null +++ b/results/classifier/118/review/1780812 @@ -0,0 +1,76 @@ +mistranslation: 0.966 +x86: 0.895 +semantic: 0.850 +graphic: 0.838 +device: 0.831 +architecture: 0.780 +network: 0.722 +ppc: 0.708 +socket: 0.701 +user-level: 0.674 +performance: 0.653 +PID: 0.628 +kernel: 0.628 +permissions: 0.616 +debug: 0.606 +files: 0.591 +vnc: 0.565 +boot: 0.541 +register: 0.504 +arm: 0.492 +TCG: 0.485 +risc-v: 0.473 +VMM: 0.422 +hypervisor: 0.317 +KVM: 0.286 +peripherals: 0.257 +virtual: 0.234 +i386: 0.234 +assembly: 0.160 +-------------------- +virtual: 0.324 +user-level: 0.203 +TCG: 0.100 +hypervisor: 0.060 +register: 0.049 +files: 0.035 +x86: 0.023 +debug: 0.022 +VMM: 0.022 +kernel: 0.011 +network: 0.010 +semantic: 0.004 +device: 0.004 +graphic: 0.003 +PID: 0.003 +assembly: 0.003 +socket: 0.003 +performance: 0.002 +architecture: 0.001 +boot: 0.001 +peripherals: 0.001 +ppc: 0.001 +risc-v: 0.001 +permissions: 0.001 +KVM: 0.000 +vnc: 0.000 +i386: 0.000 +arm: 0.000 +mistranslation: 0.000 + +Full-Screen Switch Does Nothing When Using SDL + +When using SDL switches, e.g. + +-sdl -full-screen -display sdl + +... you'd expect the display to start full-screen, as per the switch description, but it just starts in a window. Pressing the full-screen key combination (Ctrl+Alt+F) enters fullscreen mode as expected. + +Tested on QEmu 2.12.0 using qemu-system-x86_64. + +Suggested a patch here: +http://marc.info/?<email address hidden> + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6fb34ffcaae0823 + diff --git a/results/classifier/118/review/1781281 b/results/classifier/118/review/1781281 new file mode 100644 index 000000000..2b673ded9 --- /dev/null +++ b/results/classifier/118/review/1781281 @@ -0,0 +1,112 @@ +x86: 0.944 +ppc: 0.901 +architecture: 0.865 +graphic: 0.844 +debug: 0.782 +user-level: 0.743 +vnc: 0.696 +performance: 0.695 +mistranslation: 0.687 +semantic: 0.664 +files: 0.622 +device: 0.614 +PID: 0.598 +virtual: 0.568 +kernel: 0.549 +register: 0.531 +VMM: 0.519 +permissions: 0.519 +assembly: 0.496 +risc-v: 0.487 +network: 0.469 +socket: 0.462 +hypervisor: 0.458 +boot: 0.421 +peripherals: 0.404 +TCG: 0.395 +i386: 0.391 +arm: 0.366 +KVM: 0.323 +-------------------- +debug: 0.900 +ppc: 0.898 +hypervisor: 0.531 +x86: 0.460 +virtual: 0.265 +user-level: 0.229 +PID: 0.034 +files: 0.024 +performance: 0.021 +register: 0.017 +TCG: 0.016 +assembly: 0.014 +kernel: 0.013 +device: 0.012 +semantic: 0.011 +network: 0.003 +socket: 0.003 +graphic: 0.002 +architecture: 0.002 +boot: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +VMM: 0.001 +risc-v: 0.001 +vnc: 0.001 +KVM: 0.000 +arm: 0.000 +i386: 0.000 + +qemu-ppc64le uncaught target signal 4 (Illegal instruction) + +qemu-ppc64le version 2.12.0 +host machine: x86_64 Arch Linux + +I'm currently working on VSX support in libVPX, I'm using qemu to test, on line 723 of vpx_dsp/ppc/loopfilter_vsx.c, when I change the vec_sub to vec_subs I get: + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +Thread 1 "qemu-ppc64le" received signal SIGILL, Illegal instruction. +0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +#1 0x000055555567ee68 in ?? () +#2 0x000055555567fd18 in ?? () +#3 0x00005555556805ef in process_pending_signals () +#4 0x0000555555661e69 in cpu_loop () +#5 0x000055555561fd72 in main () + +This can be reproduced by downloading this patch (patchset 1): + +https://chromium-review.googlesource.com/c/webm/libvpx/+/1134034 + +and running + +qemu-ppc64le -L /home/ltrudeau/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot/ ./test_libvpx --gtest_also_run_disabled_tests "--gtest_filter=VSX/*Loop*/*" + +I don't observe any issues when running the code on a POWER9 machine. + +If it works fine on a POWER9 machine, you should try to run qemu-ppc64le with "-cpu power9". + +Thanks for the reply. + +I tried with the -cpu power9 and it works! + +However, I tried with -cpu power8 and it does not work. I tried the code on a real power8 and it works. So -cpu power8 should work + +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/review/1782107 b/results/classifier/118/review/1782107 new file mode 100644 index 000000000..8742039f2 --- /dev/null +++ b/results/classifier/118/review/1782107 @@ -0,0 +1,95 @@ +architecture: 0.831 +graphic: 0.637 +arm: 0.616 +performance: 0.599 +device: 0.590 +semantic: 0.550 +ppc: 0.516 +network: 0.491 +user-level: 0.477 +hypervisor: 0.471 +files: 0.453 +debug: 0.437 +register: 0.406 +x86: 0.405 +mistranslation: 0.404 +peripherals: 0.377 +risc-v: 0.371 +kernel: 0.352 +permissions: 0.342 +PID: 0.339 +i386: 0.339 +socket: 0.338 +virtual: 0.330 +vnc: 0.311 +boot: 0.303 +VMM: 0.294 +KVM: 0.284 +assembly: 0.277 +TCG: 0.244 +-------------------- +arm: 0.811 +user-level: 0.617 +debug: 0.157 +hypervisor: 0.064 +files: 0.027 +TCG: 0.026 +virtual: 0.014 +performance: 0.011 +PID: 0.009 +kernel: 0.007 +network: 0.005 +semantic: 0.005 +device: 0.004 +risc-v: 0.004 +register: 0.002 +boot: 0.001 +graphic: 0.001 +architecture: 0.001 +assembly: 0.001 +peripherals: 0.001 +ppc: 0.001 +socket: 0.001 +vnc: 0.000 +permissions: 0.000 +VMM: 0.000 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 +KVM: 0.000 + +Random errors when emulating armv7 and using dh + +Howdy, +I'm encountering random errors when using qemu to cross-package my project using dh. In previous iterations of my project it would only fail once every two attempts. Now it fails every time. + +Example error included. + + + +If you'd like to try and replicate this error, a version of my project is publicly available with simple instructions on how to package it (using qemu) here: +https://github.com/Nadav-Ruskin/configsite + + + +The ioctl warnings are I think for BTRFS_IOC_CLONE, which are probably harmless (the calling program ought to cope with it not working and fall back to something else). + +Which version of QEMU are you using ? + +(Unfortunately the log is not very revealing about what has gone wrong: it says "Running setup.py bdist_wheel for itsdangerous ... error" but gives no detail about what the error was. Is it possible to get the python build/install process to be more verbose?) + + +Thank you for the quick reply. + +Version: +nadav@DESKTOP-4DUIS04:/mnt/c/Git/configsite$ dpkg -s qemu-user-static | grep Version +Version: 1:2.11+dfsg-1ubuntu7.4 + + +A log with verbose mode enabled is attached. + +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/review/1785670 b/results/classifier/118/review/1785670 new file mode 100644 index 000000000..124ea7570 --- /dev/null +++ b/results/classifier/118/review/1785670 @@ -0,0 +1,580 @@ +user-level: 0.837 +mistranslation: 0.740 +hypervisor: 0.730 +x86: 0.703 +KVM: 0.685 +ppc: 0.685 +TCG: 0.678 +vnc: 0.676 +device: 0.675 +register: 0.673 +virtual: 0.670 +VMM: 0.670 +permissions: 0.666 +network: 0.665 +architecture: 0.665 +PID: 0.662 +arm: 0.660 +semantic: 0.659 +assembly: 0.658 +kernel: 0.655 +risc-v: 0.655 +graphic: 0.653 +socket: 0.653 +peripherals: 0.652 +performance: 0.649 +files: 0.647 +debug: 0.645 +i386: 0.640 +boot: 0.543 +-------------------- +x86: 0.928 +virtual: 0.925 +network: 0.644 +debug: 0.633 +KVM: 0.382 +hypervisor: 0.140 +PID: 0.137 +assembly: 0.056 +user-level: 0.055 +register: 0.034 +files: 0.033 +TCG: 0.027 +performance: 0.026 +device: 0.021 +socket: 0.020 +semantic: 0.020 +architecture: 0.010 +kernel: 0.010 +VMM: 0.006 +ppc: 0.006 +graphic: 0.003 +vnc: 0.003 +peripherals: 0.002 +i386: 0.002 +risc-v: 0.002 +permissions: 0.001 +boot: 0.001 +arm: 0.001 +mistranslation: 0.001 + +Guest(ubuntu 18.04) crashes when trying uploading file + +I speficy slirp network, and I can open websites, git clone repos. But when I try to upload a file to slack, or try to do a git push, it crashes. + +My host is ubuntu 16.04 with kernel 4.15.0-29-generic, and qemu is latest source in git(commit 1fb57da72ae0886e). The command I use is + +./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm -m 2048 -drive file=../qcow2/guest.qcow2 -netdev user,id=realnet0 -device e1000e,netdev=realnet0 + +The trace is as follows + +*** Error in `./x86_64-softmmu/qemu-system-x86_64': free(): invalid next size (normal): 0x00007f66d80b7300 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f66fb7967e5] +/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f66fb79f37a] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f66fb7a353c] +./x86_64-softmmu/qemu-system-x86_64(+0x6a8549)[0x55dc10c7d549] +./x86_64-softmmu/qemu-system-x86_64(+0x6a99d4)[0x55dc10c7e9d4] +./x86_64-softmmu/qemu-system-x86_64(+0x6ad09a)[0x55dc10c8209a] +./x86_64-softmmu/qemu-system-x86_64(+0x6a3feb)[0x55dc10c78feb] +./x86_64-softmmu/qemu-system-x86_64(+0x6a746e)[0x55dc10c7c46e] +./x86_64-softmmu/qemu-system-x86_64(+0x68fe2c)[0x55dc10c64e2c] +./x86_64-softmmu/qemu-system-x86_64(+0x685b3b)[0x55dc10c5ab3b] +./x86_64-softmmu/qemu-system-x86_64(+0x685bfd)[0x55dc10c5abfd] +./x86_64-softmmu/qemu-system-x86_64(+0x6885a8)[0x55dc10c5d5a8] +./x86_64-softmmu/qemu-system-x86_64(+0x688717)[0x55dc10c5d717] +./x86_64-softmmu/qemu-system-x86_64(+0x685d27)[0x55dc10c5ad27] +./x86_64-softmmu/qemu-system-x86_64(+0x685d54)[0x55dc10c5ad54] +./x86_64-softmmu/qemu-system-x86_64(+0x586bb8)[0x55dc10b5bbb8] +./x86_64-softmmu/qemu-system-x86_64(+0x586d92)[0x55dc10b5bd92] +./x86_64-softmmu/qemu-system-x86_64(+0x586ecd)[0x55dc10b5becd] +./x86_64-softmmu/qemu-system-x86_64(+0x593ea8)[0x55dc10b68ea8] +./x86_64-softmmu/qemu-system-x86_64(+0x59419d)[0x55dc10b6919d] +./x86_64-softmmu/qemu-system-x86_64(+0x5947df)[0x55dc10b697df] +./x86_64-softmmu/qemu-system-x86_64(+0x597ddf)[0x55dc10b6cddf] +./x86_64-softmmu/qemu-system-x86_64(+0x5989e7)[0x55dc10b6d9e7] +./x86_64-softmmu/qemu-system-x86_64(+0x58ae11)[0x55dc10b5fe11] +./x86_64-softmmu/qemu-system-x86_64(+0x30d4f6)[0x55dc108e24f6] +./x86_64-softmmu/qemu-system-x86_64(+0x30d70e)[0x55dc108e270e] +./x86_64-softmmu/qemu-system-x86_64(+0x310336)[0x55dc108e5336] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac368)[0x55dc10881368] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac4b2)[0x55dc108814b2] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac7b8)[0x55dc108817b8] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac809)[0x55dc10881809] +./x86_64-softmmu/qemu-system-x86_64(+0x32b673)[0x55dc10900673] +./x86_64-softmmu/qemu-system-x86_64(+0x2f2875)[0x55dc108c7875] +./x86_64-softmmu/qemu-system-x86_64(+0x81b91c)[0x55dc10df091c] +/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f66fbaf06ba] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f66fb82641d] +======= Memory map: ======== +55dc105d5000-55dc112a9000 r-xp 00000000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc114a9000-55dc115bd000 r--p 00cd4000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc115bd000-55dc11773000 rw-p 00de8000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc11773000-55dc117b5000 rw-p 00000000 00:00 0 +55dc134d6000-55dc14e20000 rw-p 00000000 00:00 0 [heap] +7f6634000000-7f6634021000 rw-p 00000000 00:00 0 +7f6634021000-7f6638000000 ---p 00000000 00:00 0 +7f663c000000-7f663c021000 rw-p 00000000 00:00 0 +7f663c021000-7f6640000000 ---p 00000000 00:00 0 +7f6642000000-7f6644000000 rw-s 00000000 00:05 4882443 /SYSV00000000 (deleted) +7f6644000000-7f6644021000 rw-p 00000000 00:00 0 +7f6644021000-7f6648000000 ---p 00000000 00:00 0 +7f66491cc000-7f66491cd000 ---p 00000000 00:00 0 +7f66491cd000-7f66499cd000 rw-p 00000000 00:00 0 +7f66499cd000-7f66499ce000 ---p 00000000 00:00 0 +7f66499ce000-7f664a1ce000 rw-p 00000000 00:00 0 +7f664a1ce000-7f664a1cf000 ---p 00000000 00:00 0 +7f664a1cf000-7f664a9cf000 rw-p 00000000 00:00 0 +7f664a9cf000-7f664a9d0000 ---p 00000000 00:00 0 +7f664a9d0000-7f664b1d0000 rw-p 00000000 00:00 0 +7f664b1d0000-7f664b1d1000 ---p 00000000 00:00 0 +7f664b1d1000-7f664b9d1000 rw-p 00000000 00:00 0 +7f664b9d1000-7f664b9d2000 ---p 00000000 00:00 0 +7f664b9d2000-7f664bad2000 rw-p 00000000 00:00 0 +7f664bad2000-7f664bad3000 ---p 00000000 00:00 0 +7f664bad3000-7f664bbd3000 rw-p 00000000 00:00 0 +7f664bbd3000-7f664bbd4000 ---p 00000000 00:00 0 +7f664bbd4000-7f664bcd4000 rw-p 00000000 00:00 0 +7f664bcd4000-7f664bcd5000 ---p 00000000 00:00 0 +7f664bcd5000-7f664c4d5000 rw-p 00000000 00:00 0 +7f664c4d5000-7f664c4d6000 ---p 00000000 00:00 0 +7f664c4d6000-7f664c5d6000 rw-p 00000000 00:00 0 +7f664c5d6000-7f664c5d7000 ---p 00000000 00:00 0 +7f664c5d7000-7f664c6d7000 rw-p 00000000 00:00 0 +7f664c6d7000-7f664c6d8000 ---p 00000000 00:00 0 +7f664c6d8000-7f664c7d8000 rw-p 00000000 00:00 0 +7f664c7d8000-7f664c7d9000 ---p 00000000 00:00 0 +7f664c7d9000-7f664c8d9000 rw-p 00000000 00:00 0 +7f664c8d9000-7f664c8da000 ---p 00000000 00:00 0 +7f664c8da000-7f664c9da000 rw-p 00000000 00:00 0 +7f664c9da000-7f664c9db000 ---p 00000000 00:00 0 +7f664c9db000-7f664cadb000 rw-p 00000000 00:00 0 +7f664cadb000-7f664cadc000 ---p 00000000 00:00 0 +7f664cadc000-7f664cbdc000 rw-p 00000000 00:00 0 +7f664cbdc000-7f664cbdd000 ---p 00000000 00:00 0 +7f664cbdd000-7f664ccdd000 rw-p 00000000 00:00 0 +7f664ccdd000-7f664ccde000 ---p 00000000 00:00 0 +7f664ccde000-7f664cdde000 rw-p 00000000 00:00 0 +7f664cdde000-7f664cddf000 ---p 00000000 00:00 0 +7f664cddf000-7f664cedf000 rw-p 00000000 00:00 0 +7f664cedf000-7f664cee0000 ---p 00000000 00:00 0 +7f664cee0000-7f664cfe0000 rw-p 00000000 00:00 0 +7f664cfe0000-7f664cfe1000 ---p 00000000 00:00 0 +7f664cfe1000-7f664d0e1000 rw-p 00000000 00:00 0 +7f664d0e1000-7f664d0e2000 ---p 00000000 00:00 0 +7f664d0e2000-7f664d1e2000 rw-p 00000000 00:00 0 +7f664d1e2000-7f664d1e3000 ---p 00000000 00:00 0 +7f664d1e3000-7f664d2e3000 rw-p 00000000 00:00 0 +7f664d2e3000-7f664d2e4000 ---p 00000000 00:00 0 +7f664d2e4000-7f664d3e4000 rw-p 00000000 00:00 0 +7f664d3e4000-7f664d3e5000 ---p 00000000 00:00 0 +7f664d3e5000-7f664d4e5000 rw-p 00000000 00:00 0 +7f664d4e5000-7f664d4e6000 ---p 00000000 00:00 0 +7f664d4e6000-7f664d5e6000 rw-p 00000000 00:00 0 +7f664d5e6000-7f664d5e7000 ---p 00000000 00:00 0 +7f664d5e7000-7f664d6e7000 rw-p 00000000 00:00 0 +7f664d6e7000-7f664d6e8000 ---p 00000000 00:00 0 +7f664d6e8000-7f664d7e8000 rw-p 00000000 00:00 0 +7f664d7e8000-7f664d7e9000 ---p 00000000 00:00 0 +7f664d7e9000-7f664d8e9000 rw-p 00000000 00:00 0 +7f664d8e9000-7f664d8ea000 ---p 00000000 00:00 0 +7f664d8ea000-7f664d9ea000 rw-p 00000000 00:00 0 +7f664d9ea000-7f664d9eb000 ---p 00000000 00:00 0 +7f664d9eb000-7f664daeb000 rw-p 00000000 00:00 0 +7f664daeb000-7f664daec000 ---p 00000000 00:00 0 +7f664daec000-7f664dbec000 rw-p 00000000 00:00 0 +7f664dbec000-7f664dbed000 ---p 00000000 00:00 0 +7f664dbed000-7f664dced000 rw-p 00000000 00:00 0 +7f664dced000-7f664dcee000 ---p 00000000 00:00 0 +7f664dcee000-7f664ddee000 rw-p 00000000 00:00 0 +7f664ddee000-7f664ddef000 ---p 00000000 00:00 0 +7f664ddef000-7f664deef000 rw-p 00000000 00:00 0 +7f664deef000-7f664def0000 ---p 00000000 00:00 0 +7f664def0000-7f664dff0000 rw-p 00000000 00:00 0 +7f664dff0000-7f664dff1000 ---p 00000000 00:00 0 +7f664dff1000-7f664e0f1000 rw-p 00000000 00:00 0 +7f664e0f1000-7f664e0f2000 ---p 00000000 00:00 0 +7f664e0f2000-7f664e1f2000 rw-p 00000000 00:00 0 +7f664e1f2000-7f664e1f3000 ---p 00000000 00:00 0 +7f664e1f3000-7f664e2f3000 rw-p 00000000 00:00 0 +7f664e2f3000-7f664e2f4000 ---p 00000000 00:00 0 +7f664e2f4000-7f664e3f4000 rw-p 00000000 00:00 0 +7f664e3f4000-7f664e3f5000 ---p 00000000 00:00 0 +7f664e3f5000-7f664e4f5000 rw-p 00000000 00:00 0 +7f664e4f5000-7f664e4f6000 ---p 00000000 00:00 0 +7f664e4f6000-7f664e5f6000 rw-p 00000000 00:00 0 +7f664e5f6000-7f664e5f7000 ---p 00000000 00:00 0 +7f664e5f7000-7f664e6f7000 rw-p 00000000 00:00 0 +7f664e6f7000-7f664e6f8000 ---p 00000000 00:00 0 +7f664e6f8000-7f664e7f8000 rw-p 00000000 00:00 0 +7f664e7f8000-7f664e7f9000 ---p 00000000 00:00 0 +7f664e7f9000-7f664e8f9000 rw-p 00000000 00:00 0 +7f664e8f9000-7f664e8fa000 ---p 00000000 00:00 0 +7f664e8fa000-7f664e9fa000 rw-p 00000000 00:00 0 +7f664e9fa000-7f664e9fb000 ---p 00000000 00:00 0 +7f664e9fb000-7f664eafb000 rw-p 00000000 00:00 0 +7f664eafb000-7f664eafc000 ---p 00000000 00:00 0 +7f664eafc000-7f664ebfc000 rw-p 00000000 00:00 0 +7f664ebfc000-7f664ebfd000 ---p 00000000 00:00 0 +7f664ebfd000-7f664ecfd000 rw-p 00000000 00:00 0 +7f664ecfd000-7f664ecfe000 ---p 00000000 00:00 0 +7f664ecfe000-7f664edfe000 rw-p 00000000 00:00 0 +7f664edfe000-7f664edff000 ---p 00000000 00:00 0 +7f664edff000-7f664eeff000 rw-p 00000000 00:00 0 +7f664eeff000-7f664ef00000 ---p 00000000 00:00 0 +7f664ef00000-7f664f000000 rw-p 00000000 00:00 0 +7f664f6fe000-7f664f6ff000 ---p 00000000 00:00 0 +7f664f6ff000-7f664f7ff000 rw-p 00000000 00:00 0 +7f664f7ff000-7f664f800000 ---p 00000000 00:00 0 +7f664f800000-7f6650000000 rw-p 00000000 00:00 0 +7f6650000000-7f6650022000 rw-p 00000000 00:00 0 +7f6650022000-7f6654000000 ---p 00000000 00:00 0 +7f66540f5000-7f66540f6000 ---p 00000000 00:00 0 +7f66540f6000-7f66541f6000 rw-p 00000000 00:00 0 +7f66541f6000-7f66541f7000 ---p 00000000 00:00 0 +7f66541f7000-7f66542f7000 rw-p 00000000 00:00 0 +7f66542f7000-7f66542f8000 ---p 00000000 00:00 0 +7f66542f8000-7f66543f8000 rw-p 00000000 00:00 0 +7f66543f8000-7f66543f9000 ---p 00000000 00:00 0 +7f66543f9000-7f66544f9000 rw-p 00000000 00:00 0 +7f66544f9000-7f66544fa000 ---p 00000000 00:00 0 +7f66544fa000-7f66545fa000 rw-p 00000000 00:00 0 +7f66545fa000-7f66545fb000 ---p 00000000 00:00 0 +7f66545fb000-7f66546fb000 rw-p 00000000 00:00 0 +7f66546fb000-7f66546fc000 ---p 00000000 00:00 0 +7f66546fc000-7f66547fc000 rw-p 00000000 00:00 0 +7f66547fc000-7f66547fd000 ---p 00000000 00:00 0 +7f66547fd000-7f66548fd000 rw-p 00000000 00:00 0 +7f66548fd000-7f66548fe000 ---p 00000000 00:00 0 +7f66548fe000-7f66549fe000 rw-p 00000000 00:00 0 +7f66549fe000-7f66549ff000 ---p 00000000 00:00 0 +7f66549ff000-7f6654aff000 rw-p 00000000 00:00 0 +7f6654aff000-7f6654b00000 ---p 00000000 00:00 0 +7f6654b00000-7f6654c00000 rw-p 00000000 00:00 0 +7f6654c00000-7f6654c01000 rw-p 00000000 00:00 0 +7f6654c01000-7f6654c02000 ---p 00000000 00:00 0 +7f6654cff000-7f6654d00000 ---p 00000000 00:00 0 +7f6654d00000-7f6654e00000 rw-p 00000000 00:00 0 +7f6654e00000-7f6654e01000 rw-p 00000000 00:00 0 +7f6654e01000-7f6654e02000 ---p 00000000 00:00 0 +7f6654eff000-7f6654f00000 ---p 00000000 00:00 0 +7f6654f00000-7f6655000000 rw-p 00000000 00:00 0 +7f6655000000-7f6655200000 rw-p 00000000 00:00 0 +7f6655200000-7f6655201000 ---p 00000000 00:00 0 +7f665523b000-7f6656af1000 r-xp 00000000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656af1000-7f6656cf0000 ---p 018b6000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf0000-7f6656cf1000 r--p 018b5000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf1000-7f6656cf2000 rw-p 018b6000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf2000-7f6656e71000 r-xp 00000000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6656e71000-7f6657071000 ---p 0017f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657071000-7f6657081000 r--p 0017f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657081000-7f6657082000 rw-p 0018f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657082000-7f6657086000 rw-p 00000000 00:00 0 +7f6657086000-7f6657237000 r-xp 00000000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657237000-7f6657436000 ---p 001b1000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657436000-7f665743e000 r--p 001b0000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f665743e000-7f6657440000 rw-p 001b8000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657440000-7f6657441000 rw-p 00000000 00:00 0 +7f6657441000-7f6657e00000 r--p 00000000 103:02 2235565 /usr/lib/locale/locale-archive +7f6657e00000-7f66d7e00000 rw-p 00000000 00:00 0 +7f66d7e00000-7f66d7e01000 ---p 00000000 00:00 0 +7f66d7eff000-7f66d7f00000 ---p 00000000 00:00 0 +7f66d7f00000-7f66d8000000 rw-p 00000000 00:00 0 +7f66d8000000-7f66d8b29000 rw-p 00000000 00:00 0 +7f66d8b29000-7f66dc000000 ---p 00000000 00:00 0 +7f66dc000000-7f66dc022000 rw-p 00000000 00:00 0 +7f66dc022000-7f66e0000000 ---p 00000000 00:00 0 +7f66e008a000-7f66e008b000 ---p 00000000 00:00 0 +7f66e008b000-7f66e018b000 rw-p 00000000 00:00 0 +7f66e018b000-7f66e01c2000 r-xp 00000000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e01c2000-7f66e03c2000 ---p 00037000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c2000-7f66e03c5000 r--p 00037000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c5000-7f66e03c6000 rw-p 0003a000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c6000-7f66e03fb000 r-xp 00000000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e03fb000-7f66e05fb000 ---p 00035000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fb000-7f66e05fc000 r--p 00035000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fc000-7f66e05fd000 rw-p 00036000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fd000-7f66e05ff000 r-xp 00000000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e05ff000-7f66e07fe000 ---p 00002000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e07fe000-7f66e07ff000 r--p 00001000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e07ff000-7f66e0800000 rw-p 00002000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e0800000-7f66e0840000 rw-p 00000000 00:00 0 +7f66e0840000-7f66e0841000 ---p 00000000 00:00 0 +7f66e08ff000-7f66e0900000 ---p 00000000 00:00 0 +7f66e0900000-7f66e0a00000 rw-p 00000000 00:00 0 +7f66e0a00000-7f66e0a10000 rw-p 00000000 00:00 0 +7f66e0a10000-7f66e0a11000 ---p 00000000 00:00 0 +7f66e0aff000-7f66e0b00000 ---p 00000000 00:00 0 +7f66e0b00000-7f66e0c00000 rw-p 00000000 00:00 0 +7f66e0c00000-7f66e1c00000 rw-p 00000000 00:00 0 +7f66e1c00000-7f66e1c01000 ---p 00000000 00:00 0 +7f66e1cff000-7f66e1d00000 ---p 00000000 00:00 0 +7f66e1d00000-7f66e1e00000 rw-p 00000000 00:00 0 +7f66e1e00000-7f66e1e20000 rw-p 00000000 00:00 0 +7f66e1e20000-7f66e1e21000 ---p 00000000 00:00 0 +7f66e1e5c000-7f66e1eb3000 r--p 00000000 103:02 3277771 /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf +7f66e1eb3000-7f66e1ebe000 r--s 00000000 103:02 3019418 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-6 +7f66e1ebe000-7f66e1ed3000 r--s 00000000 103:02 3019394 /var/cache/fontconfig/04aabc0a78ac019cf9454389977116d2-le64.cache-6 +7f66e1eff000-7f66e1f00000 ---p 00000000 00:00 0 +7f66e1f00000-7f66e2000000 rw-p 00000000 00:00 0 +7f66e2000000-7f66e2040000 rw-p 00000000 00:00 0 +7f66e2040000-7f66e2041000 ---p 00000000 00:00 0 +7f66e204a000-7f66e204b000 rw-p 00000000 00:00 0 +7f66e204b000-7f66e2051000 r--s 00000000 103:02 3019400 /var/cache/fontconfig/2cd17615ca594fa2959ae173292e504c-le64.cache-6 +7f66e2051000-7f66e2052000 r--s 00000000 103:02 3019397 /var/cache/fontconfig/0d8c3b2ac0904cb8a57a757ad11a4a08-le64.cache-6 +7f66e2052000-7f66e2053000 r--s 00000000 103:02 3019399 /var/cache/fontconfig/1ac9eb803944fde146138c791f5cc56a-le64.cache-6 +7f66e2053000-7f66e2057000 r--s 00000000 103:02 3019404 /var/cache/fontconfig/385c0604a188198f04d133e54aba7fe7-le64.cache-6 +7f66e2057000-7f66e2058000 r--s 00000000 103:02 3019431 /var/cache/fontconfig/dc05db6664285cc2f12bf69c139ae4c3-le64.cache-6 +7f66e2058000-7f66e205b000 r--s 00000000 103:02 3019414 /var/cache/fontconfig/767a8244fc0220cfb567a839d0392e0b-le64.cache-6 +7f66e205b000-7f66e2060000 r--s 00000000 103:02 3019417 /var/cache/fontconfig/8801497958630a81b71ace7c5f9b32a8-le64.cache-6 +7f66e2060000-7f66e2067000 r--s 00000000 103:02 3019401 /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-6 +7f66e2067000-7f66e206d000 r--s 00000000 103:02 3019422 /var/cache/fontconfig/b47c4e1ecd0709278f4910c18777a504-le64.cache-6 +7f66e206d000-7f66e2080000 r--s 00000000 103:02 3019428 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-6 +7f66e2080000-7f66e208b000 r--s 00000000 103:02 3019416 /var/cache/fontconfig/83bf95040141907cd45bb53cf7c1c148-le64.cache-6 +7f66e208b000-7f66e209d000 r--s 00000000 103:02 3019420 /var/cache/fontconfig/9b89f8e3dae116d678bbf48e5f21f69b-le64.cache-6 +7f66e209d000-7f66e20bc000 r--s 00000000 103:02 2752558 /usr/share/mime/mime.cache +7f66e20bc000-7f66e20bd000 ---p 00000000 00:00 0 +7f66e20bd000-7f66e21bd000 rw-p 00000000 00:00 0 +7f66e21bd000-7f66e21be000 ---p 00000000 00:00 0 +7f66e21be000-7f66e2ca2000 rw-p 00000000 00:00 0 +7f66e2ca2000-7f66e2ca3000 ---p 00000000 00:00 0 +7f66e2ca3000-7f66e2da3000 rw-p 00000000 00:00 0 +7f66e2da3000-7f66e2da4000 ---p 00000000 00:00 0 +7f66e2da4000-7f66e35a4000 rw-p 00000000 00:00 0 +7f66e35a4000-7f66e35ab000 r-xp 00000000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e35ab000-7f66e37ab000 ---p 00007000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ab000-7f66e37ac000 r--p 00007000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ac000-7f66e37ad000 rw-p 00008000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ad000-7f66e37d7000 r-xp 00000000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e37d7000-7f66e39d6000 ---p 0002a000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d6000-7f66e39d7000 r--p 00029000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d7000-7f66e39d8000 rw-p 0002a000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d8000-7f66e39e1000 r-xp 00000000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e39e1000-7f66e3be0000 ---p 00009000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be0000-7f66e3be1000 r--p 00008000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be1000-7f66e3be2000 rw-p 00009000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be2000-7f66e3bf6000 r-xp 00000000 103:02 2237676 /usr/lib/x86_64-linux-gnu/libtdb.so.1.3.8Aborted (core dumped) + +I can recreate this here. + +#0 0x00007fffec275feb in raise () at /lib64/libc.so.6 +#1 0x00007fffec2605c1 in abort () at /lib64/libc.so.6 +#2 0x00007fffec2b89d7 in __libc_message () at /lib64/libc.so.6 +#3 0x00007fffec2beeac in () at /lib64/libc.so.6 +#4 0x00007fffec2c091c in _int_free () at /lib64/libc.so.6 +#5 0x00007ffff725b4d2 in g_free () at /lib64/libglib-2.0.so.0 +#6 0x0000555555b49551 in m_free (m=0x7fffc44b0dd0) at /home/dgilbert/git/qemu/slirp/mbuf.c:114 +#7 0x0000555555b4a33d in sbappend (so=<optimized out>, m=<optimized out>) at /home/dgilbert/git/qemu/slirp/sbuf.c:82 +#8 0x0000555555b4d6ae in tcp_input (m=0x7fffc44b0dd0, iphlen=<optimized out>, inso=<optimized out>, af=<optimized out>) + at /home/dgilbert/git/qemu/slirp/tcp_input.c:1300 +#9 0x0000555555b48d98 in slirp_input (slirp=<optimized out>, pkt=0x7fffc44ad900 "RU\n", pkt_len=pkt_len@entry=66) + at /home/dgilbert/git/qemu/slirp/slirp.c:875 +#10 0x0000555555b378e0 in net_slirp_receive (nc=<optimized out>, buf=<optimized out>, size=66) at /home/dgilbert/git/qemu/net/slirp.c:121 +#11 0x0000555555b2ff4e in nc_sendv_compat (flags=<optimized out>, iovcnt=3, iov=0x7fffceff9a40, nc=0x5555567d5e60) + at /home/dgilbert/git/qemu/net/net.c:701 +#12 0x0000555555b2ff4e in qemu_deliver_packet_iov (sender=<optimized out>, flags=<optimized out>, iov=0x7fffceff9a40, iovcnt=3, opaque=0x5555567d5e60) + at /home/dgilbert/git/qemu/net/net.c:728 +#13 0x0000555555b32744 in qemu_net_queue_deliver_iov (iovcnt=3, iov=0x7fffceff9a40, flags=0, sender=0x555557a70ae0, queue=0x5555567d6010) + at /home/dgilbert/git/qemu/net/queue.c:179 +#14 0x0000555555b32744 in qemu_net_queue_send_iov (queue=0x5555567d6010, sender=0x555557a70ae0, flags=0, iov=0x7fffceff9a40, iovcnt=3, sent_cb=<optimized out>) at /home/dgilbert/git/qemu/net/queue.c:224 +#15 0x0000555555a6ec61 in net_tx_pkt_sendv (pkt=0x555557a71010, iov_cnt=3, iov=0x7fffceff9a40, nc=0x555557a70ae0) + at /home/dgilbert/git/qemu/hw/net/net_tx_pkt.c:546 +#16 0x0000555555a6ec61 in net_tx_pkt_do_sw_fragmentation (pkt=pkt@entry=0x555557a71010, nc=nc@entry=0x555557a70ae0) + at /home/dgilbert/git/qemu/hw/net/net_tx_pkt.c:588 +#17 0x0000555555a6f87f in net_tx_pkt_send (pkt=0x555557a71010, nc=nc@entry=0x555557a70ae0) at /home/dgilbert/git/qemu/hw/net/net_tx_pkt.c:625 +#18 0x0000555555a78ff8 in e1000e_tx_pkt_send (queue_index=<optimized out>, tx=0x555557a1d1e8, core=0x5555579fcf80) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:665 +#19 0x0000555555a78ff8 in e1000e_process_tx_desc (queue_index=<optimized out>, dp=0x7fffceff9f30, tx=0x555557a1d1e8, core=0x5555579fcf80) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:742 +#20 0x0000555555a78ff8 in e1000e_start_xmit (core=0x5555579fcf80, txr=<optimized out>, txr=<optimized out>) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:933 +#21 0x0000555555a792b9 in e1000e_set_tdt (core=<optimized out>, index=<optimized out>, val=<optimized out>) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:2450 +#22 0x0000555555a7c0a5 in e1000e_core_write (core=0x5555579fcf80, addr=<optimized out>, val=220, size=4) + at /home/dgilbert/git/qemu/hw/net/e1000e_core.c:3255 +#23 0x0000555555876c37 in memory_region_write_accessor (mr=0x5555579fcbb0, addr=14360, value=<optimized out>, size=4, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/dgilbert/git/qemu/memory.c:527 +---Type <return> to continue, or q <return> to quit--- + out>, access_size_max=<optimized out>, access_fn=0x555555876bc0 <memory_region_write_accessor>, mr=0x5555579fcbb0, attrs=...) at /home/dgilbert/git/qemu/memory.c:594 +#25 0x00005555558794c1 in memory_region_dispatch_write (mr=mr@entry=0x5555579fcbb0, addr=14360, data=<optimized out>, size=4, attrs=attrs@entry=...) at /home/dgilbert/git/qemu/memory.c:1479 +#26 0x0000555555823833 in flatview_write_continue (fv=fv@entry=0x7fffc50aebc0, addr=addr@entry=4273485848, attrs=..., buf=buf@entry=0x7ffff7ff3028 <incomplete sequence \334>, len=len@entry=4, addr1=<optimized out>, l=<optimized out>, mr=0x5555579fcbb0) at /home/dgilbert/git/qemu/exec.c:3255 +#27 0x0000555555823a59 in flatview_write (fv=0x7fffc50aebc0, addr=4273485848, attrs=..., buf=0x7ffff7ff3028 <incomplete sequence \334>, len=4) at /home/dgilbert/git/qemu/exec.c:3294 +#28 0x000055555582737f in address_space_write (as=<optimized out>, addr=<optimized out>, attrs=..., buf=buf@entry=0x7ffff7ff3028 <incomplete sequence \334>, len=<optimized out>) at /home/dgilbert/git/qemu/exec.c:3384 +#29 0x000055555582740a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., attrs@entry=..., buf=buf@entry=0x7ffff7ff3028 <incomplete sequence \334>, len=<optimized out>, is_write=<optimized out>) + at /home/dgilbert/git/qemu/exec.c:3395 +#30 0x000055555588b7b8 in kvm_cpu_exec (cpu=cpu@entry=0x55555683ddf0) at /home/dgilbert/git/qemu/accel/kvm/kvm-all.c:1979 +#31 0x0000555555862896 in qemu_kvm_cpu_thread_fn (arg=0x55555683ddf0) at /home/dgilbert/git/qemu/cpus.c:1215 +#32 0x00007fffec605594 in start_thread () at /lib64/libpthread.so.0 +#33 0x00007fffec3390df in clone () at /lib64/libc.so.6 + +(This is with a fedora guest, so that's irrelevant) + +Looks like it might be e1000e specific? +I can recreate it with either q35 with no extra options (it has e1000e by default), pc or q35 specifying e1000e, but plain pc works fine. + +Simple test; scp bigfile from guest to user@10.0.2.2: (i.e. host) + +Dave + +It's indeed e1000e specific, when I change e1000e to e1000, I can upload file freely. Looks like there is an overflow somewhere in e1000e that corrupted the heap chunk header. + +Hi, + +I have find the overflow point using ASAN. + +void +m_cat(struct mbuf *m, struct mbuf *n) +{ + /* + * If there's no room, realloc + */ + if (M_FREEROOM(m) < n->m_len) + m_inc(m, m->m_len + n->m_len); + + memcpy(m->m_data+m->m_len, n->m_data, n->m_len); + m->m_len += n->m_len; + + m_free(n); +} + + +/* make m 'size' bytes large from m_data */ +void +m_inc(struct mbuf *m, int size) +{ + int datasize; + + /* some compilers throw up on gotos. This one we can fake. */ + if (m->m_size > size) { + return; + } + + if (m->m_flags & M_EXT) { + datasize = m->m_data - m->m_ext; + m->m_ext = g_realloc(m->m_ext, size + datasize); + } else { + datasize = m->m_data - m->m_dat; + m->m_ext = g_malloc(size + datasize); + memcpy(m->m_ext, m->m_dat, m->m_size); + m->m_flags |= M_EXT; + } + + m->m_data = m->m_ext + datasize; + m->m_size = size + datasize; +} + +Here m_cat catenates two mbuf, when the first has no buffer, it allocates an M_EXT. +In m_inc, g_malloc called, then return m_cat, the next call to m_cat will trigger oob write. + +Seems the m_len is too big. +In my debug, I see the m->m_len is 0x5b0, but datasize in m_inc is 0x40. Is this right? + +Thanks, +Li Qiang + +==17835==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61f000041dd0 at pc 0x7ffff6e9ad7b bp 0x7fffc6b215d0 sp 0x7fffc6b20d80 +WRITE of size 28 at 0x61f000041dd0 thread T4 + #0 0x7ffff6e9ad7a (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a) + #1 0x55555663fa71 in m_cat slirp/mbuf.c:143 + #2 0x555556632cdd in ip_reass slirp/ip_input.c:341 + #3 0x555556631609 in ip_input slirp/ip_input.c:190 + #4 0x55555663bd91 in slirp_input slirp/slirp.c:874 + #5 0x555556600d6f in net_slirp_receive net/slirp.c:121 + #6 0x5555565e8192 in nc_sendv_compat net/net.c:701 + #7 0x5555565e8322 in qemu_deliver_packet_iov net/net.c:728 + #8 0x5555565edda2 in qemu_net_queue_deliver_iov net/queue.c:179 + #9 0x5555565edfaa in qemu_net_queue_send_iov net/queue.c:224 + #10 0x5555565e8547 in qemu_sendv_packet_async net/net.c:764 + #11 0x5555565e8574 in qemu_sendv_packet net/net.c:772 + #12 0x55555636657c in net_tx_pkt_sendv hw/net/net_tx_pkt.c:546 + #13 0x5555563668f3 in net_tx_pkt_do_sw_fragmentation hw/net/net_tx_pkt.c:588 + #14 0x555556366c93 in net_tx_pkt_send hw/net/net_tx_pkt.c:625 + #15 0x55555638586c in e1000e_tx_pkt_send hw/net/e1000e_core.c:665 + #16 0x555556385fca in e1000e_process_tx_desc hw/net/e1000e_core.c:742 + #17 0x555556387680 in e1000e_start_xmit hw/net/e1000e_core.c:933 + #18 0x55555638f390 in e1000e_set_tdt hw/net/e1000e_core.c:2450 + #19 0x5555563911cb in e1000e_core_write hw/net/e1000e_core.c:3255 + #20 0x555556370524 in e1000e_mmio_write hw/net/e1000e.c:105 + #21 0x555555d4ec07 in memory_region_write_accessor /home/liqiang02/qemu-devel/qemu/memory.c:527 + #22 0x555555d4eee3 in access_with_adjusted_size /home/liqiang02/qemu-devel/qemu/memory.c:594 + #23 0x555555d54d16 in memory_region_dispatch_write /home/liqiang02/qemu-devel/qemu/memory.c:1473 + #24 0x555555c94b76 in flatview_write_continue /home/liqiang02/qemu-devel/qemu/exec.c:3255 + #25 0x555555c94da1 in flatview_write /home/liqiang02/qemu-devel/qemu/exec.c:3294 + #26 0x555555c95354 in address_space_write /home/liqiang02/qemu-devel/qemu/exec.c:3384 + #27 0x555555c953a5 in address_space_rw /home/liqiang02/qemu-devel/qemu/exec.c:3395 + #28 0x555555d92c4d in kvm_cpu_exec /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1979 + #29 0x555555d18936 in qemu_kvm_cpu_thread_fn /home/liqiang02/qemu-devel/qemu/cpus.c:1215 + #30 0x5555569afef1 in qemu_thread_start util/qemu-thread-posix.c:504 + #31 0x7fffdadbd493 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7493) + #32 0x7fffdaafface in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xe8ace) + +AddressSanitizer can not describe address in more detail (wild memory access suspected). +SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a) +Shadow bytes around the buggy address: + 0x0c3e80000360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000390: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0c3e800003b0: fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa + 0x0c3e800003c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e800003f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3e80000400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Heap right redzone: fb + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack partial redzone: f4 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb +Thread T4 created by T0 here: + #0 0x7ffff6e6ef59 in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x30f59) + #1 0x5555569b012f in qemu_thread_create util/qemu-thread-posix.c:534 + #2 0x555555d1b7b9 in qemu_kvm_start_vcpu /home/liqiang02/qemu-devel/qemu/cpus.c:1935 + #3 0x555555d1bf6c in qemu_init_vcpu /home/liqiang02/qemu-devel/qemu/cpus.c:2001 + #4 0x555555f682de in x86_cpu_realizefn /home/liqiang02/qemu-devel/qemu/target/i386/cpu.c:4996 + #5 0x55555621c00c in device_set_realized hw/core/qdev.c:826 + #6 0x5555566f962f in property_set_bool qom/object.c:1984 + #7 0x5555566f5bfc in object_property_set qom/object.c:1176 + #8 0x5555566fbdce in object_property_set_qobject qom/qom-qobject.c:27 + #9 0x5555566f5f19 in object_property_set_bool qom/object.c:1242 + #10 0x555555edf7d7 in pc_new_cpu /home/liqiang02/qemu-devel/qemu/hw/i386/pc.c:1107 + #11 0x555555edfc98 in pc_cpus_init /home/liqiang02/qemu-devel/qemu/hw/i386/pc.c:1155 + #12 0x555555ef2451 in pc_q35_init /home/liqiang02/qemu-devel/qemu/hw/i386/pc_q35.c:130 + #13 0x555555ef37f4 in pc_init_v3_0 /home/liqiang02/qemu-devel/qemu/hw/i386/pc_q35.c:320 + #14 0x55555622ca6d in machine_run_board_init hw/core/machine.c:830 + #15 0x555556099045 in main /home/liqiang02/qemu-devel/qemu/vl.c:4516 + #16 0x7fffdaa372e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) + + + +For me: +c22098c74a fails +864036e251 fails +3835c310bd doesn't crash, but sometimes the outbound connection hangs. + +So perhaps the crash is 864036e251f54c99d31df124aad7f34f01f5344c + +http://patchwork.ozlabs.org/patch/954491/ is a patch which should fix this crash. + + +Glad to see such a quick fix, and ASAN looks like a great tool :) + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=09b94ac0f29db3b022a77 + diff --git a/results/classifier/118/review/1785972 b/results/classifier/118/review/1785972 new file mode 100644 index 000000000..8ea05a3f5 --- /dev/null +++ b/results/classifier/118/review/1785972 @@ -0,0 +1,137 @@ +user-level: 0.826 +peripherals: 0.785 +register: 0.784 +hypervisor: 0.751 +virtual: 0.739 +debug: 0.733 +device: 0.731 +permissions: 0.724 +vnc: 0.719 +mistranslation: 0.710 +TCG: 0.709 +assembly: 0.702 +semantic: 0.702 +files: 0.698 +network: 0.695 +graphic: 0.694 +ppc: 0.679 +x86: 0.674 +architecture: 0.652 +PID: 0.652 +risc-v: 0.647 +kernel: 0.641 +socket: 0.635 +arm: 0.634 +KVM: 0.634 +VMM: 0.612 +performance: 0.612 +boot: 0.545 +i386: 0.491 +-------------------- +virtual: 0.962 +hypervisor: 0.680 +x86: 0.648 +KVM: 0.147 +boot: 0.135 +ppc: 0.115 +performance: 0.099 +debug: 0.083 +kernel: 0.061 +PID: 0.050 +VMM: 0.050 +i386: 0.049 +files: 0.039 +TCG: 0.029 +register: 0.025 +socket: 0.016 +semantic: 0.016 +user-level: 0.014 +risc-v: 0.013 +assembly: 0.009 +permissions: 0.008 +device: 0.008 +arm: 0.006 +architecture: 0.006 +vnc: 0.005 +graphic: 0.004 +network: 0.003 +mistranslation: 0.003 +peripherals: 0.002 + +v3.0.0-rc4: VM fails to start after vcpuhotunplug, managedsave sequence + +VM fails to start after vcpu hot un-plug, managedsave sequence + +Host info: +Kernel: 4.18.0-rc8-00002-g1236568ee3cb + +qemu: commit 6ad90805383e6d04b3ff49681b8519a48c9f4410 (HEAD -> master, tag: v3.0.0-rc4) +QEMU emulator version 2.12.94 (v3.0.0-rc4-dirty) + +libvirt: commit 087de2f5a3dffb27d2eeb0c50a86d5d6984e5a5e (HEAD -> master) +libvirtd (libvirt) 4.6.0 + +Guest Kernel: 4.18.0-rc8-00002-g1236568ee3cb + + +Steps to reproduce: +1. Start a guest(VM) with 2 current , 4 max vcpus +virsh start vm1 +Domain vm1 started + +2. Hotplug 2 vcpus +virsh setvcpus vm1 4 --live + +3. Hot unplug 2 vcpus +virsh setvcpus vm1 2 --live + +4. Managedsave the VM +virsh managedsave vm1 + +Domain vm1 state saved by libvirt + +5. Start the VM ---Fails to start +virsh start vm1 + +error: Failed to start domain avocado-vt-vm1 +error: internal error: qemu unexpectedly closed the monitor: 2018-08-08T06:27:53.853818Z qemu: Unknown savevm section or instance 'spapr_cpu' 2 +2018-08-08T06:27:53.854949Z qemu: load of migration failed: Invalid argument + + + +Testcase: +avocado run libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug --vt-type libvirt --vt-extra-params emulator_path=/usr/share/avocado-plugins-vt/bin/qemu create_vm_libvirt=yes kill_vm_libvirt=yes env_cleanup=yes smp=8 backup_image_before_testing=no libvirt_controller=virtio-scsi scsi_hba=virtio-scsi-pci drive_format=scsi-hd use_os_variant=no restore_image_after_testing=no vga=none display=nographic kernel=/home/kvmci/linux/vmlinux kernel_args='root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug' take_regular_screendumps=no --vt-guest-os JeOS.27.ppc64le +JOB ID : 1f869477ad87e7d7e7e7777f631ae08965f41a74 +JOB LOG : /root/avocado/job-results/job-2018-08-08T02.42-1f86947/job.log + (1/1) type_specific.io-github-autotest-libvirt.libvirt_vcpu_plug_unplug.positive_test.vcpu_set.live.vm_operate.managedsave_with_unplug: ERROR (91.58 s) +RESULTS : PASS 0 | ERROR 1 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 +JOB TIME : 95.89 s + + + +Bisect result: + +v3.0.0-rc0: vcpu hotplug crashes the domain - https://bugs.launchpad.net/qemu/+bug/1780928, this commit fixes that issue, b585395b655a6c1f9d9ebf1f0890e76d0708eed6 ppc/xics: fix ICP reset path + + +v3.0.0-rc1- v3.0.0-rc4: hotplug crash bug fixed, but now we are hitting this one. + +Last good commit I could find, 2309832afdaf8d6451ebc2e81bace8eb8ea41293 where both vcpu hotplug and managed save sequence worked fine. + +The first commit that causes this issue is: + +b94020268e0b6659499e250d25346baaa9888fed (spapr_cpu_core: migrate per-CPU data) + +Simpler way to reproduce: +1. Hotplug a CPU +2. Hot unplug it +3. Migrate the VM (will fail) + +This commit https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01281.html from ~bharata-rao, fixes the issue. + +Applied to ppc-for-3.1. + +https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01317.html + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc71c7760e263f808c4240a + diff --git a/results/classifier/118/review/1788701 b/results/classifier/118/review/1788701 new file mode 100644 index 000000000..6687d2972 --- /dev/null +++ b/results/classifier/118/review/1788701 @@ -0,0 +1,88 @@ +mistranslation: 0.879 +graphic: 0.816 +semantic: 0.751 +performance: 0.727 +device: 0.673 +user-level: 0.632 +hypervisor: 0.619 +register: 0.613 +architecture: 0.571 +debug: 0.570 +PID: 0.568 +x86: 0.551 +i386: 0.531 +permissions: 0.512 +ppc: 0.511 +boot: 0.476 +assembly: 0.471 +peripherals: 0.468 +network: 0.464 +kernel: 0.439 +files: 0.418 +VMM: 0.417 +virtual: 0.391 +socket: 0.342 +arm: 0.332 +KVM: 0.327 +TCG: 0.284 +risc-v: 0.281 +vnc: 0.277 +-------------------- +virtual: 0.881 +hypervisor: 0.718 +user-level: 0.366 +TCG: 0.090 +x86: 0.060 +debug: 0.043 +files: 0.022 +socket: 0.011 +semantic: 0.011 +PID: 0.011 +performance: 0.007 +device: 0.007 +i386: 0.007 +boot: 0.006 +network: 0.004 +risc-v: 0.004 +ppc: 0.004 +arm: 0.003 +kernel: 0.003 +register: 0.002 +graphic: 0.002 +architecture: 0.002 +assembly: 0.001 +vnc: 0.001 +permissions: 0.001 +VMM: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +"Zoom to fit" doesn't work with -display gtk -vga virtio + +qemu version: 2.12.1 + +When using -display gtk for all -vga options (std,qxl,vmware,cirrus) the option "Zoom To Fit" is unchecked and auto-resizing of the window works well; except for -vga virtio: here "Zoom To Fit" is checked and auto-resizing doesn't work. + +Proposal: disable "Zoom To Fit" as default for virtio as well + +virtio-vga will adapt the guest display to the window size (once the guest drivers are loaded). +Therefore it is not needed to auto-resize the window (to avoid display scaling). + +Well, then something isn't right here. + +"Zoom to Fit" disabled: qemu starts with a small window (1:1 scale) and resizes the window when the xserver/window manager starts (1:1 scale). This is the sane and wanted behavior. + +"Zoom to Fit" enabled: qemu starts with a small window and doesn't resizes the window when the xserver/window manager starts. The whole display is squeezed into the small window. The window simply ignores resolution changes of the guest. + +So either there is sth wrong with your statement: "Therefore it is not needed to auto-resize the window" or with my setup (my window manager is dwm, the linux guest uses modesetting as video driver). + + + + + +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/review/1793016 b/results/classifier/118/review/1793016 new file mode 100644 index 000000000..78f07aac0 --- /dev/null +++ b/results/classifier/118/review/1793016 @@ -0,0 +1,101 @@ +mistranslation: 0.895 +graphic: 0.869 +semantic: 0.848 +user-level: 0.794 +x86: 0.775 +device: 0.729 +hypervisor: 0.691 +performance: 0.679 +virtual: 0.652 +architecture: 0.651 +KVM: 0.642 +files: 0.604 +debug: 0.569 +i386: 0.543 +ppc: 0.537 +kernel: 0.536 +peripherals: 0.534 +boot: 0.506 +VMM: 0.486 +network: 0.478 +socket: 0.474 +PID: 0.455 +register: 0.448 +permissions: 0.366 +arm: 0.359 +TCG: 0.352 +vnc: 0.331 +risc-v: 0.322 +assembly: 0.256 +-------------------- +x86: 0.869 +virtual: 0.869 +KVM: 0.716 +kernel: 0.457 +hypervisor: 0.456 +user-level: 0.336 +files: 0.154 +debug: 0.069 +socket: 0.061 +PID: 0.029 +register: 0.027 +risc-v: 0.018 +VMM: 0.017 +semantic: 0.015 +TCG: 0.014 +boot: 0.010 +device: 0.010 +vnc: 0.008 +network: 0.006 +i386: 0.003 +mistranslation: 0.003 +architecture: 0.002 +graphic: 0.002 +peripherals: 0.002 +performance: 0.001 +assembly: 0.001 +ppc: 0.001 +permissions: 0.001 +arm: 0.001 + +vmdk to cqow2 invalid VMDK image descriptor + +Greetings, + +CentOS 7.5.1804 +Linux 3.10.0-862.11.6.el7.x86_64 +qemu-img version 3.0.50 (v3.0.0-614-g19b599f) + +When trying to convert a vmdk flat file to qcow2 format, I get the following error message: +qemu-img: Could not open './sk-R12-flat.vmdk': invalid VMDK image descriptor + +The command line used is +root@s11kvm:/home/goinfre> qemu-img convert -f vmdk -O qcow2 ./sk-R12-flat.vmdk ./sk-R12-flat.qcow2 + + +"file sk-R12-flat.vmdk" returns: +sk-R12-flat.vmdk: x86 boot sector; +GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x40, GRUB version 0.97; +partition 1: ID=0x63, active, starthead 1, startsector 63, 16002 sectors; +partition 2: ID=0x83, starthead 0, startsector 16065, 3084480 sectors; +partition 3: ID=0x83, starthead 0, startsector 3100545, 3084480 sectors; +partition 4: ID=0x5, starthead 0, startsector 6185025, 161581770 sectors, code offset 0x48 + +Found a work around by removing the option "-f vmd" +Still a bug though. + +meant "vmdk" of course. + +Hi, + +Judging from the "file" output and the fact that you say the result is correct when removing "-f vmdk", it appears as if the input is in fact not in vmdk format but just a raw image. +I don't know too much about vmdk, but I suppose that there is a descriptor file that goes aloing with that sk-R12-flat.vmdk (e.g. "sk-R12.vmdk"). So I guess sk-R12-flat.vmdk just contains the raw image data which is pointed to by e.g. sk-R12.vmdk, and the latter would be the file that qemu expects. + +From my perspective, giving the flat file a .vmdk extension is a misnomer, and qemu's vmdk driver is correct in rejecting it -- because it is just a raw file, so it should be handled by the raw driver. But maybe it is common enough that the vmdk driver should give a hint on that. + +Note that the VMware knowledge base (https://kb.vmware.com/s/article/1002511) specifically says that "VMDK" stands for the descriptor file, and it looks like even VMware would reject flat files without a descriptor file. + +Max + +I'm closing this ticket since it was likely just a wrong file extension ... if you disagree, feel free to open the ticket again. + diff --git a/results/classifier/118/review/1793608 b/results/classifier/118/review/1793608 new file mode 100644 index 000000000..a3f805d21 --- /dev/null +++ b/results/classifier/118/review/1793608 @@ -0,0 +1,96 @@ +architecture: 0.912 +x86: 0.896 +user-level: 0.859 +files: 0.796 +mistranslation: 0.794 +graphic: 0.781 +semantic: 0.777 +performance: 0.776 +assembly: 0.747 +hypervisor: 0.737 +ppc: 0.701 +kernel: 0.686 +peripherals: 0.668 +device: 0.645 +permissions: 0.625 +debug: 0.611 +network: 0.605 +socket: 0.600 +risc-v: 0.586 +register: 0.552 +vnc: 0.548 +VMM: 0.527 +PID: 0.521 +TCG: 0.510 +virtual: 0.500 +arm: 0.487 +KVM: 0.477 +boot: 0.423 +i386: 0.219 +-------------------- +assembly: 0.648 +virtual: 0.401 +debug: 0.350 +ppc: 0.083 +user-level: 0.036 +files: 0.031 +architecture: 0.018 +register: 0.013 +TCG: 0.012 +semantic: 0.012 +kernel: 0.011 +PID: 0.010 +hypervisor: 0.010 +x86: 0.006 +performance: 0.004 +device: 0.003 +socket: 0.002 +boot: 0.001 +permissions: 0.001 +network: 0.001 +peripherals: 0.001 +graphic: 0.001 +risc-v: 0.001 +VMM: 0.001 +vnc: 0.001 +KVM: 0.000 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly. + +Small clarification to the bug description above. + +Host architecture: x86_64 (AMD64) +Instructions used for building QEMU 3.0.0 from source are here: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/INSTALL + +The command line for emulating POWER9 target is below: +qemu-ppc64le -cpu POWER9 simd_test.p64_32Lp9 -c 1 + +With the workaround for lxvwsx instruction turned off (as described above) +QEMU crashes in s_test08 function of the following common SIMD test file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/test/simd_test.cpp + +A patch has been posted here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02218.html +("ppc/translate: Implement lxvwsx opcode") + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/review/1794086 b/results/classifier/118/review/1794086 new file mode 100644 index 000000000..9ac5930cb --- /dev/null +++ b/results/classifier/118/review/1794086 @@ -0,0 +1,119 @@ +ppc: 0.923 +PID: 0.842 +user-level: 0.822 +kernel: 0.741 +files: 0.741 +architecture: 0.726 +x86: 0.723 +socket: 0.686 +device: 0.673 +permissions: 0.658 +boot: 0.647 +performance: 0.639 +mistranslation: 0.612 +arm: 0.600 +vnc: 0.593 +semantic: 0.560 +debug: 0.555 +network: 0.554 +TCG: 0.553 +risc-v: 0.520 +VMM: 0.517 +peripherals: 0.504 +register: 0.503 +hypervisor: 0.456 +i386: 0.452 +virtual: 0.414 +graphic: 0.373 +KVM: 0.347 +assembly: 0.263 +-------------------- +user-level: 0.814 +debug: 0.373 +hypervisor: 0.214 +kernel: 0.105 +TCG: 0.061 +x86: 0.051 +virtual: 0.031 +files: 0.028 +semantic: 0.018 +PID: 0.015 +network: 0.005 +device: 0.004 +performance: 0.004 +register: 0.004 +architecture: 0.003 +boot: 0.002 +arm: 0.002 +ppc: 0.002 +socket: 0.002 +i386: 0.001 +peripherals: 0.001 +graphic: 0.001 +assembly: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.001 +risc-v: 0.000 +VMM: 0.000 +KVM: 0.000 + +readlink(2) returns incorrect size for /proc/self/exe + +readlink(2) seems to ignore the size of supplied buffer for the resolved name and always returns the actual size of the resolved name instead. + +Steps to reproduce: + +```bash +echo '#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, const char** argv) +{ + if(argc < 2) exit(1); + char buf[1]; + printf("%d\n", readlink(argv[1], buf, sizeof(buf))); +}' >test.c + +# I used GCC mipsel cross-compiler to reproduce this bug +mipsel-linux-gnu-gcc-5.5 test.c -o a.out + +echo "PWD: `pwd`" +qemu-mipsel ./a.out /proc/self/exe +``` + +Expected output (observed when running a.out natively on Linux 4.17 amd64): +``` +PWD: /tmp/test +1 +``` + +Output observed when running with qemu-mipsel 2.1.2: +``` +PWD: /tmp/test +15 +``` + +According to POSIX description of readlink [1], the function shall return the number of bytes written to the supplied buffer, which obviously cannot exceed size of the buffer. + +Note that the bug is only reproduced with links within /proc filesystem; links to the regular files within /home are resolved normally. + +The bug is present in qemu-mipsel 2.1.2: + +# qemu-mipsel -version +qemu-mipsel version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c) 2003-2008 Fabrice Bellard + +[1]: http://pubs.opengroup.org/onlinepubs/009695399/functions/readlink.html + +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. + + +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/154 + + diff --git a/results/classifier/118/review/1795369 b/results/classifier/118/review/1795369 new file mode 100644 index 000000000..58c10faf5 --- /dev/null +++ b/results/classifier/118/review/1795369 @@ -0,0 +1,103 @@ +user-level: 0.818 +mistranslation: 0.817 +register: 0.777 +device: 0.764 +virtual: 0.762 +permissions: 0.751 +debug: 0.744 +graphic: 0.736 +semantic: 0.735 +boot: 0.735 +files: 0.734 +performance: 0.732 +assembly: 0.732 +network: 0.730 +arm: 0.720 +kernel: 0.719 +architecture: 0.709 +PID: 0.708 +socket: 0.695 +peripherals: 0.690 +KVM: 0.685 +ppc: 0.680 +hypervisor: 0.676 +VMM: 0.662 +TCG: 0.660 +vnc: 0.648 +x86: 0.629 +risc-v: 0.616 +i386: 0.524 +-------------------- +x86: 0.929 +virtual: 0.910 +hypervisor: 0.800 +TCG: 0.757 +debug: 0.098 +boot: 0.056 +performance: 0.038 +register: 0.034 +files: 0.031 +PID: 0.028 +kernel: 0.028 +semantic: 0.008 +user-level: 0.007 +socket: 0.006 +device: 0.005 +VMM: 0.005 +network: 0.004 +KVM: 0.003 +assembly: 0.003 +graphic: 0.002 +architecture: 0.002 +peripherals: 0.002 +permissions: 0.001 +ppc: 0.001 +vnc: 0.001 +mistranslation: 0.000 +risc-v: 0.000 +arm: 0.000 +i386: 0.000 + +Record/replay (icount rr) causes emulation hang or exit with error about missing events in log + +Test case description: + +Guest image is Linux, which just powers off after kernel boots (instead of proceeding to user-space /init or /sbin/init). +Base cmdline: + qemu-system-x86_64 \ + -nodefaults -nographic -machine pc,accel=tcg -m 2048 -cpu qemu64 \ + -kernel bzImage -initrd rootfs -append 'nokaslr console=ttyS0 rdinit=/init_poweroff' \ + -serial SERIAL_VALUE \ + -rtc clock=vm,base=2000-01-01T00:00:00 \ + -icount 1,sleep=off,rr=RR_VALUE,rrfile=icount_rr_capture.bin + +Test 1. +When SERIAL_VALUE=none +Running with RR_VALUE=record completes successfully. +Running with RR_VALUE=replay doesn't completes. qemu process just eating ~100% cpu and memory usage doesn't grow after some moment. I don't see what happens because of problem no.2 (see below). + +Test 2. +When SERIAL_VALUE=stdio +Running with RR_VALUE=record completes successfully. +Running with RR_VALUE=replay causes exit with error: +"qemu-system-x86_64: Missing character write event in the replay log" + +Tests 3,4,5... +SERIAL_VALUE=stdio. Playing with "-rtc" clock and base suboptions, "-icount" sleep suboptions produces non-repeatable results. +In most cases running with RR_VALUE=record completes successfully (but may hang at very begining). +Running with RR_VALUE=replay with combinations of removing "-rtc base=..." and "-icount sleep=..." goes better, but at different places of boot process it may either hang (as in test 1) or exit with error (as in test 2). +When qemu "hangs", it may also happen differently: either it can be stopped by Ctrl-C, or have to be killed. + + +Guest image uploaded here: https://drive.google.com/open?id=1SHG4HyBdcPutc5Au4pyhN8z9w52et51A + +QEMU built from master (commit 042938f46e1c477419d1931381fdadffaa49d45e) with: +<SRC_ROOT>/configure --prefix=<INSTALL_ROOT> --target-list=x86_64-softmmu --enable-debug --disable-pie --enable-tcg --disable-tcg-interpreter --enable-virtfs --disable-docs --disable-guest-agent --disable-modules --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-curses --disable-vnc --disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-cap-ng --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-opengl --disable-virglrenderer --disable-qom-cast-debug --disable-tools --disable-vxhs --disable-crypto-afalg --disable-capstone --disable-replication --disable-xfsctl --disable-seccomp --disable-pvrdma --disable-libpmem + +Applying recent patches from http://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg04038.html doesn't fix any of issues. + +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/review/1800993 b/results/classifier/118/review/1800993 new file mode 100644 index 000000000..0e80387a7 --- /dev/null +++ b/results/classifier/118/review/1800993 @@ -0,0 +1,77 @@ +mistranslation: 0.834 +vnc: 0.771 +virtual: 0.762 +device: 0.736 +network: 0.686 +semantic: 0.587 +performance: 0.558 +architecture: 0.482 +permissions: 0.468 +PID: 0.453 +risc-v: 0.443 +graphic: 0.420 +ppc: 0.405 +register: 0.397 +VMM: 0.393 +socket: 0.342 +KVM: 0.321 +hypervisor: 0.315 +user-level: 0.310 +kernel: 0.304 +boot: 0.298 +files: 0.275 +TCG: 0.191 +debug: 0.183 +i386: 0.177 +arm: 0.154 +x86: 0.144 +peripherals: 0.100 +assembly: 0.053 +-------------------- +virtual: 0.846 +user-level: 0.459 +network: 0.043 +debug: 0.042 +VMM: 0.032 +hypervisor: 0.030 +TCG: 0.022 +x86: 0.010 +semantic: 0.010 +files: 0.007 +vnc: 0.004 +PID: 0.003 +socket: 0.002 +device: 0.002 +kernel: 0.002 +ppc: 0.002 +register: 0.002 +KVM: 0.001 +permissions: 0.001 +boot: 0.001 +graphic: 0.001 +assembly: 0.001 +risc-v: 0.001 +arm: 0.001 +i386: 0.001 +architecture: 0.001 +performance: 0.001 +peripherals: 0.000 +mistranslation: 0.000 + +How to Migration VM Built on Qemu Souce Code Installation + +Respected all, + +I followed https://wiki.qemu.org/Hosts/Linux to build qemu from source code. Its installed successfully with Ubuntu 16.04 VM created using VNC server. + +Now, Could you please suggest me how to migrate VM from one host to another?. + +Email: <email address hidden> + +Hi, this is the bug tracker and not a support request form, so I'm closing this issue. + +(You've already emailed the mailing list, so you already know where to find us!) + +Thanks, +--John + diff --git a/results/classifier/118/review/1810405 b/results/classifier/118/review/1810405 new file mode 100644 index 000000000..1c95c650b --- /dev/null +++ b/results/classifier/118/review/1810405 @@ -0,0 +1,92 @@ +user-level: 0.924 +virtual: 0.915 +graphic: 0.870 +semantic: 0.866 +architecture: 0.813 +files: 0.806 +performance: 0.802 +mistranslation: 0.798 +permissions: 0.769 +device: 0.743 +debug: 0.731 +PID: 0.708 +register: 0.688 +network: 0.681 +socket: 0.655 +kernel: 0.648 +hypervisor: 0.642 +peripherals: 0.631 +arm: 0.629 +boot: 0.604 +risc-v: 0.588 +x86: 0.578 +VMM: 0.571 +ppc: 0.570 +TCG: 0.557 +vnc: 0.548 +KVM: 0.536 +assembly: 0.405 +i386: 0.294 +-------------------- +user-level: 0.521 +virtual: 0.478 +debug: 0.464 +x86: 0.233 +kernel: 0.115 +files: 0.048 +TCG: 0.034 +network: 0.025 +hypervisor: 0.023 +i386: 0.020 +VMM: 0.016 +boot: 0.016 +register: 0.013 +PID: 0.013 +arm: 0.012 +socket: 0.007 +device: 0.004 +vnc: 0.003 +semantic: 0.003 +ppc: 0.002 +risc-v: 0.002 +performance: 0.002 +architecture: 0.001 +KVM: 0.001 +graphic: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +assembly: 0.000 + +source tarball has errors when untarring + +If you download qemu-2.10.0.tar.xv and/or qemu-2.10.1.tar.xv, and follow the directions at https://www.qemu.org/download/, you get a tar error. + + +To repro: +$ wget https://download.qemu.org/qemu-2.10.0.tar.xz +$ tar xJf qemu-2.10.0.tar.xz +tar: qemu-2.10.0/roms/u-boot/scripts/Kconfig: Cannot open: File exists +tar: Exiting with failure status due to previous errors + +$ tar --version +tar (GNU tar) 1.29 +Copyright (C) 2015 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. + +Written by John Gilmore and Jay Fenlason. + + +Apologies if I'm being an idiot here. + +I look in my crystal ball and deduce that you're doing this on a filesystem which isn't case-sensitive. This is bug #1714750, and it's really an issue with the u-boot code that we ship a copy of. You can work around it by extracting the sources with "tar xf qemu-2.10.0.tar.xz --exclude qemu-2.10.0/roms/u-boot/scripts/Kconfig" (the file that is excluded isn't needed to build QEMU). + +It looks like we never finished the fix for 1714750 -- it's fixed in upstream u-boot but we need to move forward to using that u-boot rather than the one we currently ship. + + +Your crystal ball is correct! I was untarring in a Linux vbox, and was blindly assuming since it was on linux it was case sensitive. However, it was on a vboxsf shared with OSX, and apple's file system is case insensitive. Thanks so much for the rapid and nice response. + + + diff --git a/results/classifier/118/review/1811 b/results/classifier/118/review/1811 new file mode 100644 index 000000000..295530327 --- /dev/null +++ b/results/classifier/118/review/1811 @@ -0,0 +1,96 @@ +ppc: 0.924 +boot: 0.909 +architecture: 0.819 +graphic: 0.805 +PID: 0.765 +kernel: 0.719 +device: 0.690 +performance: 0.640 +semantic: 0.626 +peripherals: 0.545 +debug: 0.511 +vnc: 0.509 +register: 0.504 +risc-v: 0.459 +network: 0.417 +socket: 0.409 +permissions: 0.381 +VMM: 0.381 +files: 0.375 +user-level: 0.363 +TCG: 0.356 +arm: 0.347 +assembly: 0.340 +i386: 0.307 +x86: 0.295 +hypervisor: 0.240 +virtual: 0.209 +mistranslation: 0.150 +KVM: 0.125 +-------------------- +debug: 0.942 +user-level: 0.781 +kernel: 0.715 +boot: 0.347 +ppc: 0.101 +TCG: 0.074 +PID: 0.056 +performance: 0.026 +files: 0.024 +device: 0.021 +VMM: 0.015 +register: 0.014 +network: 0.013 +virtual: 0.012 +peripherals: 0.008 +semantic: 0.006 +hypervisor: 0.005 +socket: 0.005 +graphic: 0.004 +assembly: 0.003 +architecture: 0.003 +KVM: 0.001 +x86: 0.001 +vnc: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +arm: 0.001 +permissions: 0.001 +i386: 0.000 + +ppc serial appears to have a maximum ratio of output to input, hides output and only writes it on subsequent input(?!) +Description of problem: +When pasting in large chunks of text, the echo is partial, but completes with subsequent writes (and is drained when the writes are small). Sorry this is really stupid, see video. + +(also, when booting, the console stops at +``` +Building dt strings... +Building dt structure... +Device tree strings 0x00000000062c0000 -> 0x00000000062c0b90 +Device tree struct 0x00000000062d0000 -> 0x00000000062e0000 +Quiescing Open Firmware ... +Booting Linux via __start() @ 0x0000000002000000 ... +Linux ppc64le +#1 SMP Debian 6. +``` +and then continues with more messages from just after the dot: +``` +Linux ppc64le +#1 SMP Debian 6.[ 15.683156] vio vio: uevent: failed to send synthetic uevent: -19 +vio: Failed to write 'add' to '/sys/devices/vio/uevent', ignoring: No such device +/dev/vda2: clean, 17371/987360 files, 345018/3942144 blocks +``` +) +Steps to reproduce: +1. `cat > /dev/null` +2. paste in a couple solid lines +3. observe that the echo completed mid-line +4. paste in a couple more solid lines +5. observe that the echo includes the end of the first few lines, and the start of the second set +6. ^D +7. observe that with every key input into the shell, you get a few bytes back, and those bytes are the tail-end of the second set of lines +8. when the echo buffer is drained, it's drained +Additional information: +Demo video: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1041707;filename=2023-07-21+17-59-25.mp4;msg=5 + +Downstream bug: https://bugs.debian.org/1041707 diff --git a/results/classifier/118/review/1811653 b/results/classifier/118/review/1811653 new file mode 100644 index 000000000..1ae0d0ee0 --- /dev/null +++ b/results/classifier/118/review/1811653 @@ -0,0 +1,107 @@ +semantic: 0.841 +virtual: 0.827 +graphic: 0.820 +assembly: 0.820 +debug: 0.815 +performance: 0.809 +permissions: 0.808 +device: 0.803 +user-level: 0.800 +peripherals: 0.799 +register: 0.780 +hypervisor: 0.775 +arm: 0.773 +risc-v: 0.771 +x86: 0.762 +architecture: 0.758 +VMM: 0.749 +PID: 0.735 +mistranslation: 0.725 +KVM: 0.724 +vnc: 0.722 +files: 0.704 +network: 0.680 +boot: 0.673 +i386: 0.651 +ppc: 0.646 +TCG: 0.643 +socket: 0.609 +kernel: 0.601 +-------------------- +KVM: 0.967 +virtual: 0.947 +performance: 0.765 +hypervisor: 0.590 +x86: 0.295 +debug: 0.205 +register: 0.141 +PID: 0.134 +user-level: 0.127 +files: 0.112 +assembly: 0.077 +peripherals: 0.058 +network: 0.043 +device: 0.042 +socket: 0.027 +TCG: 0.026 +kernel: 0.023 +i386: 0.007 +semantic: 0.005 +arm: 0.005 +risc-v: 0.004 +boot: 0.003 +VMM: 0.003 +architecture: 0.003 +graphic: 0.003 +ppc: 0.003 +vnc: 0.002 +permissions: 0.001 +mistranslation: 0.001 + +usbredir slow when multi bulk packet per second + +QEMU Ver: all version +Client: virt-viewer by spice +Guest VM: win7 +Bug description: + Use Qemu 2.1 or later with usbredir, When I redirect a bulk usb-device from virt-viewer client, +the bulk-usb-device driver or app in GuestVM will send 50 bulk-urb per times. + In VM, using the usblyzer to monitor the usb packet, it show these 50 bulk-urb packet send in 1ms, +But in the QEMU VM log, It shows as below +========================= +2019-01-14T08:27:26.096809Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.105680Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.108219Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.116742Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.119242Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.129851Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.132349Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.141248Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.144932Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +2019-01-14T08:27:26.154035Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 +========================= + + It shows that the bulk packet is single thread send and recv, per bulk packet will use 10-20ms, all 50 bulk-packets will use 500~1000ms, so the in the VM, bulk-urb will timeout always! + + How to send the bulk packet by multithread to speedup the bulk-urb send and recv, for example: +------------ + bulk-out ep 86 stream 0 len 49152 id xxxx1 + bulk-out ep 86 stream 0 len 49152 id xxxx2 + bulk-out ep 86 stream 0 len 49152 id xxxx3 + bulk-out ep 86 stream 0 len 49152 id xxxx4 + bulk-out ... + bulk-out ep 86 stream 0 len 49152 id xxxx50 +... + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx1 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx2 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx3 + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx4 + bulk-out ... + bulk-in status 0 ep 86 stream 0 len 49152 id xxxx50 +------------ + +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/review/1813034 b/results/classifier/118/review/1813034 new file mode 100644 index 000000000..10825e59e --- /dev/null +++ b/results/classifier/118/review/1813034 @@ -0,0 +1,74 @@ +architecture: 0.846 +graphic: 0.730 +device: 0.689 +arm: 0.666 +network: 0.641 +socket: 0.613 +kernel: 0.589 +semantic: 0.566 +performance: 0.556 +ppc: 0.514 +vnc: 0.504 +user-level: 0.503 +PID: 0.495 +risc-v: 0.486 +register: 0.459 +TCG: 0.453 +files: 0.453 +boot: 0.441 +mistranslation: 0.433 +VMM: 0.433 +permissions: 0.402 +KVM: 0.359 +debug: 0.340 +hypervisor: 0.339 +peripherals: 0.326 +virtual: 0.276 +i386: 0.209 +x86: 0.140 +assembly: 0.111 +-------------------- +arm: 0.997 +hypervisor: 0.189 +kernel: 0.175 +files: 0.098 +TCG: 0.043 +VMM: 0.036 +virtual: 0.026 +user-level: 0.022 +debug: 0.016 +register: 0.013 +semantic: 0.011 +PID: 0.008 +device: 0.008 +KVM: 0.008 +architecture: 0.007 +risc-v: 0.006 +socket: 0.004 +boot: 0.004 +assembly: 0.003 +network: 0.002 +performance: 0.002 +ppc: 0.001 +graphic: 0.001 +peripherals: 0.001 +vnc: 0.001 +x86: 0.001 +i386: 0.001 +permissions: 0.000 +mistranslation: 0.000 + +create_elf_tables() doesn't set AT_PLATFORM for 32bit ARM platforms + +The dynamic linker uses AT_PLATFORM from getauxval to substitute $PLATFORM in certain places (man ld.so). It would be nice if it was set to 'v6l', 'v7l' and whatever other platforms there are according to the chosen CPU or via an environment variable. AT_PLATFORM is not guaranteed to be set, so this isn't a major bug, but this is one case where it makes things difficult. + +Patches posted: +https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg02863.html + +I've tried the patch and it solves the problem for my use case. + +Tested with this build: +https://launchpad.net/~schneiderit/+archive/ubuntu/rpi/+build/16488702 + +Merged for 4.0 in c4e0780ed1. + diff --git a/results/classifier/118/review/1813398 b/results/classifier/118/review/1813398 new file mode 100644 index 000000000..cdbfb36c8 --- /dev/null +++ b/results/classifier/118/review/1813398 @@ -0,0 +1,116 @@ +user-level: 0.820 +device: 0.752 +graphic: 0.750 +risc-v: 0.747 +register: 0.741 +peripherals: 0.739 +virtual: 0.735 +mistranslation: 0.730 +performance: 0.726 +arm: 0.714 +hypervisor: 0.709 +x86: 0.703 +architecture: 0.702 +debug: 0.691 +network: 0.688 +ppc: 0.686 +VMM: 0.678 +vnc: 0.668 +semantic: 0.668 +TCG: 0.665 +PID: 0.665 +KVM: 0.656 +permissions: 0.653 +boot: 0.653 +files: 0.650 +socket: 0.631 +assembly: 0.616 +kernel: 0.577 +i386: 0.567 +-------------------- +arm: 0.897 +debug: 0.832 +virtual: 0.223 +files: 0.106 +hypervisor: 0.070 +user-level: 0.065 +TCG: 0.024 +x86: 0.017 +semantic: 0.015 +PID: 0.015 +kernel: 0.011 +register: 0.009 +assembly: 0.008 +performance: 0.004 +architecture: 0.003 +ppc: 0.003 +device: 0.002 +network: 0.002 +i386: 0.001 +socket: 0.001 +VMM: 0.001 +peripherals: 0.001 +boot: 0.001 +risc-v: 0.001 +permissions: 0.001 +KVM: 0.001 +graphic: 0.001 +vnc: 0.000 +mistranslation: 0.000 + +qemu user calls malloc after fork in multi-threaded process + +qemu user may hang in malloc on a musl based system because +it calls malloc after fork (in a pthread_atfork handler) +in the child process. + +this is undefined behaviour since the parent process is +multi-threaded and only as-safe functions may be called +in the child then. (if malloc/free is called concurrently +with fork the malloc state will be corrupted in the child, +it works on glibc because glibc takes the malloc locks +before the fork syscall, but that breaks the as-safety of +fork and thus non-conforming to posix) + +discussed at +https://www.openwall.com/lists/musl/2019/01/26/1 + +the bug is hard to reproduce (requires the call_rcu thread +to call free concurrently with do_fork in the main thread), +this one is observed with qemu-arm 3.1.0 running on x86_64 +executing an arm busybox sh: + +(gdb) bt +#0 malloc (n=<optimized out>, n@entry=9) at src/malloc/malloc.c:306 +#1 0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@entry=9) at gmem.c:99 +#2 0x000000006018bcab in g_strdup (str=<optimized out>, str@entry=0x60200abf "call_rcu") at gstrfuncs.c:363 +#3 0x000000006016e31d in qemu_thread_create (thread=thread@entry=0x7ffe367d1870, name=name@entry=0x60200abf "call_rcu", + start_routine=start_routine@entry=0x60174c00 <call_rcu_thread>, arg=arg@entry=0x0, mode=mode@entry=1) + at /home/pmos/build/src/qemu-3.1.0/util/qemu-thread-posix.c:526 +#4 0x0000000060174b99 in rcu_init_complete () at /home/pmos/build/src/qemu-3.1.0/util/rcu.c:327 +#5 0x00000000601c4fac in __fork_handler (who=1) at src/thread/pthread_atfork.c:26 +#6 0x00000000601be8db in fork () at src/process/fork.c:33 +#7 0x000000006009d191 in do_fork (env=0x627aaed0, flags=flags@entry=17, newsp=newsp@entry=0, parent_tidptr=parent_tidptr@entry=0, + newtls=newtls@entry=0, child_tidptr=child_tidptr@entry=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:5528 +#8 0x00000000600af894 in do_syscall1 (cpu_env=cpu_env@entry=0x627aaed0, num=num@entry=2, arg1=arg1@entry=0, arg2=arg2@entry=-8700192, + arg3=<optimized out>, arg4=8, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:7042 +#9 0x00000000600a835c in do_syscall (cpu_env=cpu_env@entry=0x627aaed0, num=2, arg1=0, arg2=-8700192, arg3=<optimized out>, + arg4=<optimized out>, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:11533 +#10 0x00000000600c265f in cpu_loop (env=env@entry=0x627aaed0) at /home/pmos/build/src/qemu-3.1.0/linux-user/arm/cpu_loop.c:360 +#11 0x00000000600417a2 in main (argc=<optimized out>, argv=0x7ffe367d57b8, envp=<optimized out>) + at /home/pmos/build/src/qemu-3.1.0/linux-user/main.c:819 + +I'm not sure how extensively the RCU code is used (it looks like not much), but I don't think this bug is fixable without disabling it, or at least getting rid of the RCU thread in cases where the emulated process is not multithreaded. + + +note that the bug affects qemu-user on a glibc system too in case +malloc is interposed: glibc can only take the internal locks of +its own malloc implementation, any other malloc has the same issue +as musl's after fork. + + +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/review/1814420 b/results/classifier/118/review/1814420 new file mode 100644 index 000000000..df78c4e7f --- /dev/null +++ b/results/classifier/118/review/1814420 @@ -0,0 +1,92 @@ +user-level: 0.873 +KVM: 0.845 +hypervisor: 0.796 +VMM: 0.788 +x86: 0.774 +mistranslation: 0.770 +ppc: 0.761 +TCG: 0.757 +virtual: 0.753 +risc-v: 0.743 +peripherals: 0.730 +vnc: 0.720 +permissions: 0.710 +i386: 0.693 +performance: 0.663 +boot: 0.648 +register: 0.636 +debug: 0.631 +arm: 0.631 +graphic: 0.623 +architecture: 0.622 +network: 0.619 +assembly: 0.618 +semantic: 0.611 +kernel: 0.603 +device: 0.599 +socket: 0.591 +files: 0.573 +PID: 0.547 +-------------------- +debug: 0.900 +virtual: 0.818 +hypervisor: 0.647 +TCG: 0.367 +PID: 0.205 +user-level: 0.080 +x86: 0.069 +VMM: 0.053 +register: 0.030 +device: 0.022 +files: 0.015 +kernel: 0.014 +semantic: 0.008 +assembly: 0.006 +architecture: 0.006 +performance: 0.005 +ppc: 0.005 +network: 0.004 +KVM: 0.004 +socket: 0.004 +boot: 0.004 +risc-v: 0.003 +graphic: 0.002 +i386: 0.002 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.001 +vnc: 0.001 +arm: 0.000 + +drive-backup with iscsi, it will failed "Could not create image: Invalid argument" + +I use iscsi protocol to drive-backup: + +---iscsi target--- +yum -y install targetcli python-rtslib +systemctl start target +systemctl enable target +targetcli /iscsi create iqn.2019-01.com.iaas +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.1 3260 +targetcli /backstores/fileio create file1 /opt/file1 2G +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/file1 +------------------- + +Now, '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.1:3260/iqn.2019-01.com.iaas/0" } }' + +It may failed: {"id":"libvirt-1785","error":{"class":"GenericError","desc":"Could not create image: Invalid argument"}} + +But, This abnormal will be appear at the first time. Because when I retry again, It works very well. + +Then, I re-start the vm, It still be failed 'Could not create image: Invalid argument' on the first try, and the second try it will work very well. + +--- +Host: centos 7.5 +qemu version: 2.12 and 3.1.0 +qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +Hi, qemu version 3.1 is a bit old in terms of upstream support. Can you confirm that this is still an issue on 4.2 ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1815 b/results/classifier/118/review/1815 new file mode 100644 index 000000000..c7fdeab54 --- /dev/null +++ b/results/classifier/118/review/1815 @@ -0,0 +1,142 @@ +architecture: 0.836 +semantic: 0.829 +graphic: 0.828 +virtual: 0.815 +device: 0.806 +risc-v: 0.802 +performance: 0.791 +hypervisor: 0.789 +peripherals: 0.783 +ppc: 0.779 +arm: 0.773 +PID: 0.766 +register: 0.764 +user-level: 0.763 +assembly: 0.757 +TCG: 0.753 +mistranslation: 0.749 +KVM: 0.744 +debug: 0.742 +kernel: 0.734 +socket: 0.720 +network: 0.695 +vnc: 0.689 +permissions: 0.682 +VMM: 0.669 +boot: 0.665 +x86: 0.637 +files: 0.633 +i386: 0.369 +-------------------- +x86: 0.967 +virtual: 0.675 +kernel: 0.519 +debug: 0.444 +TCG: 0.233 +hypervisor: 0.105 +VMM: 0.093 +assembly: 0.068 +files: 0.062 +device: 0.055 +register: 0.037 +PID: 0.036 +risc-v: 0.035 +semantic: 0.022 +user-level: 0.020 +ppc: 0.020 +performance: 0.018 +KVM: 0.011 +i386: 0.009 +network: 0.007 +architecture: 0.005 +peripherals: 0.005 +socket: 0.004 +graphic: 0.002 +boot: 0.002 +permissions: 0.002 +vnc: 0.001 +arm: 0.001 +mistranslation: 0.001 + +Null pointer access in nvme_directive_receive() +Description of problem: +Got an access within null pointer error when fuzzing nvme. +Steps to reproduce: +Minimized reproducer for the error: + +```plaintext +cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 \ +-nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device \ +nvme,drive=disk0,serial=1 -qtest /dev/null -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +write 0xe0000024 0x4 0x040002 +write 0xe0000014 0x4 0x61004600 +write 0xe0001000 0x1 0x04 +write 0x0 0x1 0x1a +write 0x4 0x1 0x01 +write 0x2c 0x1 0x01 +EOF +``` +Additional information: +The crash report triggered by the reproducer is: + +```plaintext +[I 0.000000] OPENED +[R +0.025407] outl 0xcf8 0x80000810 +[S +0.025443] OK +OK +[R +0.025456] outl 0xcfc 0xe0000000 +[S +0.025470] OK +OK +[R +0.025476] outl 0xcf8 0x80000804 +[S +0.025483] OK +OK +[R +0.025489] outw 0xcfc 0x06 +[S +0.025934] OK +OK +[R +0.025946] write 0xe0000024 0x4 0x040002 +[S +0.025958] OK +OK +[R +0.025964] write 0xe0000014 0x4 0x61004600 +[S +0.025988] OK +OK +[R +0.026025] write 0xe0001000 0x1 0x04 +[S +0.026041] OK +OK +[R +0.026048] write 0x0 0x1 0x1a +[S +0.026256] OK +OK +[R +0.026268] write 0x4 0x1 0x01 +[S +0.026279] OK +OK +[R +0.026292] write 0x2c 0x1 0x01 +[S +0.026303] OK +OK +../hw/nvme/ctrl.c:6890:29: runtime error: member access within null pointer of type 'NvmeEnduranceGroup' (aka 'struct NvmeEnduranceGroup') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/nvme/ctrl.c:6890:29 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==1085476==ERROR: AddressSanitizer: SEGV on unknown address 0x000000001fc8 (pc 0x56306b765ebf bp 0x7ffff17fd890 sp 0x7ffff17f6a00 T0) +==1085476==The signal is caused by a READ memory access. + #0 0x56306b765ebf in nvme_directive_receive ../hw/nvme/ctrl.c:6890:33 + #1 0x56306b765ebf in nvme_admin_cmd ../hw/nvme/ctrl.c:6958:16 + #2 0x56306b765ebf in nvme_process_sq ../hw/nvme/ctrl.c:7015:13 + #3 0x56306cda2c3b in aio_bh_call ../util/async.c:169:5 + #4 0x56306cda3384 in aio_bh_poll ../util/async.c:216:13 + #5 0x56306cd3f15b in aio_dispatch ../util/aio-posix.c:423:5 + #6 0x56306cda72da in aio_ctx_dispatch ../util/async.c:358:5 + #7 0x7fa321cc417c in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5217c) (BuildId: 5fdb313daf182a33a858ba2cc945211b11d34561) + #8 0x56306cda840f in glib_pollfds_poll ../util/main-loop.c:290:9 + #9 0x56306cda840f in os_host_main_loop_wait ../util/main-loop.c:313:5 + #10 0x56306cda840f in main_loop_wait ../util/main-loop.c:592:11 + #11 0x56306bd17f76 in qemu_main_loop ../softmmu/runstate.c:732:9 + #12 0x56306c721835 in qemu_default_main ../softmmu/main.c:37:14 + #13 0x7fa320aeb082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #14 0x56306af0309d in _start (./qemu-system-x86_64+0x1e9109d) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV ../hw/nvme/ctrl.c:6890:33 in nvme_directive_receive +``` diff --git a/results/classifier/118/review/1815024 b/results/classifier/118/review/1815024 new file mode 100644 index 000000000..fe7c5cc92 --- /dev/null +++ b/results/classifier/118/review/1815024 @@ -0,0 +1,87 @@ +architecture: 0.830 +x86: 0.667 +user-level: 0.633 +device: 0.568 +semantic: 0.558 +socket: 0.532 +vnc: 0.525 +files: 0.472 +performance: 0.466 +TCG: 0.463 +PID: 0.462 +network: 0.462 +ppc: 0.461 +register: 0.404 +graphic: 0.386 +kernel: 0.386 +permissions: 0.371 +debug: 0.369 +VMM: 0.367 +boot: 0.322 +arm: 0.303 +assembly: 0.299 +risc-v: 0.271 +hypervisor: 0.250 +peripherals: 0.205 +virtual: 0.190 +KVM: 0.167 +i386: 0.100 +mistranslation: 0.098 +-------------------- +debug: 0.707 +hypervisor: 0.076 +virtual: 0.075 +TCG: 0.069 +user-level: 0.063 +files: 0.041 +PID: 0.039 +architecture: 0.023 +assembly: 0.020 +performance: 0.014 +register: 0.013 +kernel: 0.012 +x86: 0.012 +semantic: 0.008 +network: 0.005 +device: 0.003 +peripherals: 0.002 +VMM: 0.002 +socket: 0.002 +risc-v: 0.001 +boot: 0.001 +graphic: 0.001 +ppc: 0.001 +KVM: 0.001 +permissions: 0.001 +vnc: 0.001 +i386: 0.000 +mistranslation: 0.000 +arm: 0.000 + +SIGILL on instruction "stck" under qemu-s390x in user mode + +qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). + +This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): + + $ gcc -c -o test.o test.c + $ gcc -c -o rdtsc.o rdtsc.S + $ gcc -o test test.o rdtsc.o + +Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). + +Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. + +Thanks, Giovanni. + + + + + + + +I am also attaching the compiled program, in case it is helpful. + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=965018bea7ce79e1987 + diff --git a/results/classifier/118/review/1815143 b/results/classifier/118/review/1815143 new file mode 100644 index 000000000..e2660e90e --- /dev/null +++ b/results/classifier/118/review/1815143 @@ -0,0 +1,157 @@ +mistranslation: 0.885 +user-level: 0.792 +register: 0.769 +debug: 0.748 +semantic: 0.745 +virtual: 0.736 +permissions: 0.731 +device: 0.723 +peripherals: 0.721 +TCG: 0.718 +architecture: 0.711 +arm: 0.703 +socket: 0.697 +risc-v: 0.693 +assembly: 0.680 +performance: 0.676 +ppc: 0.656 +KVM: 0.652 +VMM: 0.639 +PID: 0.634 +boot: 0.634 +graphic: 0.606 +kernel: 0.595 +hypervisor: 0.586 +network: 0.582 +vnc: 0.574 +files: 0.518 +x86: 0.504 +i386: 0.471 +-------------------- +kernel: 0.943 +KVM: 0.883 +register: 0.687 +debug: 0.668 +virtual: 0.639 +hypervisor: 0.615 +assembly: 0.226 +boot: 0.112 +files: 0.076 +PID: 0.075 +TCG: 0.069 +semantic: 0.042 +performance: 0.040 +architecture: 0.029 +VMM: 0.019 +permissions: 0.015 +socket: 0.011 +device: 0.011 +user-level: 0.007 +network: 0.004 +risc-v: 0.003 +ppc: 0.003 +graphic: 0.002 +x86: 0.002 +vnc: 0.002 +peripherals: 0.002 +mistranslation: 0.001 +i386: 0.001 +arm: 0.000 + + qemu-system-s390x fails when running without kvm: fatal: EXECUTE on instruction prefix 0x7f4 not implemented + +just wondering if TCG implements instruction prefix 0x7f4 + +server3:~ # zcat /boot/vmlinux-4.4.162-94.72-default.gz > /tmp/kernel + +--> starting qemu with kvm enabled works fine +server3:~ # qemu-system-s390x -nographic -kernel /tmp/kernel -initrd /boot/initrd -enable-kvm +Initializing cgroup subsys cpuset +Initializing cgroup subsys cpu +Initializing cgroup subsys cpuacct +Linux version 4.4.162-94.72-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Mon Nov 12 18:57:45 UTC 2018 (9de753f) +setup.289988: Linux is running under KVM in 64-bit mode +setup.b050d0: The maximum memory size is 128MB +numa.196305: NUMA mode: plain +Write protected kernel read-only data: 8692k +[...] + +--> but starting qemu without kvm enabled works fails +server3:~ # qemu-system-s390x -nographic -kernel /tmp/kernel -initrd /boot/initrd +qemu: fatal: EXECUTE on instruction prefix 0x7f4 not implemented + +PSW=mask 0000000180000000 addr 000000000067ed6e cc 00 +R00=0000000080000000 R01=000000000067ed76 R02=0000000000000000 R03=0000000000000000 +R04=0000000000111548 R05=0000000000000000 R06=0000000000000000 R07=0000000000000000 +R08=00000000000100f6 R09=0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000ae2000 R13=0000000000681978 R14=0000000000111548 R15=000000000000bef0 +F00=0000000000000000 F01=0000000000000000 F02=0000000000000000 F03=0000000000000000 +F04=0000000000000000 F05=0000000000000000 F06=0000000000000000 F07=0000000000000000 +F08=0000000000000000 F09=0000000000000000 F10=0000000000000000 F11=0000000000000000 +F12=0000000000000000 F13=0000000000000000 F14=0000000000000000 F15=0000000000000000 +V00=00000000000000000000000000000000 V01=00000000000000000000000000000000 +V02=00000000000000000000000000000000 V03=00000000000000000000000000000000 +V04=00000000000000000000000000000000 V05=00000000000000000000000000000000 +V06=00000000000000000000000000000000 V07=00000000000000000000000000000000 +V08=00000000000000000000000000000000 V09=00000000000000000000000000000000 +V10=00000000000000000000000000000000 V11=00000000000000000000000000000000 +V12=00000000000000000000000000000000 V13=00000000000000000000000000000000 +V14=00000000000000000000000000000000 V15=00000000000000000000000000000000 +V16=00000000000000000000000000000000 V17=00000000000000000000000000000000 +V18=00000000000000000000000000000000 V19=00000000000000000000000000000000 +V20=00000000000000000000000000000000 V21=00000000000000000000000000000000 +V22=00000000000000000000000000000000 V23=00000000000000000000000000000000 +V24=00000000000000000000000000000000 V25=00000000000000000000000000000000 +V26=00000000000000000000000000000000 V27=00000000000000000000000000000000 +V28=00000000000000000000000000000000 V29=00000000000000000000000000000000 +V30=00000000000000000000000000000000 V31=00000000000000000000000000000000 +C00=0000000000000000 C01=0000000000000000 C02=0000000000000000 C03=0000000000000000 +C04=0000000000000000 C05=0000000000000000 C06=0000000000000000 C07=0000000000000000 +C08=0000000000000000 C09=0000000000000000 C10=0000000000000000 C11=0000000000000000 +C12=0000000000000000 C13=0000000000000000 C14=0000000000000000 C15=0000000000000000 + +Aborted (core dumped) + + +server3:~ # lscpu +Architecture: s390x +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Big Endian +CPU(s): 2 +On-line CPU(s) list: 0,1 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s) per book: 1 +Book(s) per drawer: 1 +Drawer(s): 2 +NUMA node(s): 1 +Vendor ID: IBM/S390 +Machine type: 2964 +BogoMIPS: 20325.00 +Hypervisor: z/VM 6.4.0 +Hypervisor vendor: IBM +Virtualization type: full +Dispatching mode: horizontal +L1d cache: 128K +L1i cache: 96K +L2d cache: 2048K +L2i cache: 2048K +L3 cache: 65536K +L4 cache: 491520K +NUMA node0 CPU(s): 0-63 +Flags: esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx sie +server3:~ # uname -a +Linux server3 4.4.126-94.22-default #1 SMP Wed Apr 11 07:45:03 UTC 2018 (9649989) s390x s390x s390x GNU/Linux +server3:~ # + +Which version of QEMU are you using here? I think this should be working fine with the latest version of QEMU (>= v2.10). + +Hi, Thomas, you are right, I am using 2.9.1, and it does look OK in 2.10. do you mind to point me which part of code fixed it? Thanks. + +A little bit confused here, I tired to bisect it from 2.10, but it was always good from this branch. then I went back to 2.9.1, it was always crashed. Machine type related? + +This should be the commit that fixed this issue: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=303c681a8f50eb88fbafc + +Confirmed the fix, thanks for the help. + diff --git a/results/classifier/118/review/1815413 b/results/classifier/118/review/1815413 new file mode 100644 index 000000000..5a4ca961e --- /dev/null +++ b/results/classifier/118/review/1815413 @@ -0,0 +1,90 @@ +architecture: 0.865 +mistranslation: 0.792 +x86: 0.704 +device: 0.597 +virtual: 0.528 +semantic: 0.445 +PID: 0.374 +user-level: 0.334 +hypervisor: 0.304 +performance: 0.283 +network: 0.206 +kernel: 0.204 +graphic: 0.200 +arm: 0.187 +register: 0.184 +peripherals: 0.162 +ppc: 0.142 +assembly: 0.135 +debug: 0.131 +VMM: 0.124 +TCG: 0.110 +risc-v: 0.099 +i386: 0.086 +boot: 0.085 +socket: 0.076 +permissions: 0.072 +files: 0.067 +KVM: 0.030 +vnc: 0.025 +-------------------- +x86: 0.933 +hypervisor: 0.241 +socket: 0.168 +architecture: 0.101 +files: 0.066 +kernel: 0.056 +network: 0.030 +virtual: 0.028 +TCG: 0.018 +VMM: 0.015 +device: 0.012 +register: 0.011 +semantic: 0.010 +PID: 0.008 +debug: 0.005 +assembly: 0.004 +user-level: 0.003 +boot: 0.003 +KVM: 0.002 +graphic: 0.002 +peripherals: 0.002 +performance: 0.002 +permissions: 0.002 +vnc: 0.002 +ppc: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +i386: 0.000 +arm: 0.000 + +compile with vhost-vsock support on osx + +compiling latest (3.1.0) on osx 10.14.3 with --enable-vhost-vsock and target = x86_64-softmmu results in compile errors: + +Undefined symbols for architecture x86_64: + "_vhost_dev_cleanup", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + _vhost_vsock_device_unrealize in vhost-vsock.o + "_vhost_dev_disable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_enable_notifiers", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_init", referenced from: + _vhost_vsock_device_realize in vhost-vsock.o + "_vhost_dev_start", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_dev_stop", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + "_vhost_virtqueue_mask", referenced from: + _vhost_vsock_set_status in vhost-vsock.o + _vhost_vsock_guest_notifier_mask in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_mask) + "_vhost_virtqueue_pending", referenced from: + _vhost_vsock_guest_notifier_pending in vhost-vsock.o + (maybe you meant: _cryptodev_vhost_virtqueue_pending) +ld: symbol(s) not found for architecture x86_64 +clang: error: linker command failed with exit code 1 (use -v to see invocation) + +vhost devices are not available on macOS hosts, they are a Linux feature. + diff --git a/results/classifier/118/review/1816614 b/results/classifier/118/review/1816614 new file mode 100644 index 000000000..028928902 --- /dev/null +++ b/results/classifier/118/review/1816614 @@ -0,0 +1,89 @@ +architecture: 0.833 +ppc: 0.747 +arm: 0.731 +mistranslation: 0.659 +device: 0.655 +semantic: 0.650 +graphic: 0.647 +debug: 0.566 +files: 0.551 +register: 0.541 +PID: 0.465 +socket: 0.464 +x86: 0.456 +risc-v: 0.449 +TCG: 0.438 +vnc: 0.436 +network: 0.436 +performance: 0.417 +KVM: 0.416 +hypervisor: 0.397 +virtual: 0.390 +peripherals: 0.388 +kernel: 0.378 +user-level: 0.372 +VMM: 0.359 +boot: 0.331 +i386: 0.319 +permissions: 0.311 +assembly: 0.244 +-------------------- +arm: 0.875 +debug: 0.736 +hypervisor: 0.682 +files: 0.043 +TCG: 0.032 +user-level: 0.030 +virtual: 0.029 +network: 0.023 +architecture: 0.022 +performance: 0.019 +kernel: 0.017 +register: 0.014 +device: 0.011 +PID: 0.011 +semantic: 0.010 +socket: 0.006 +i386: 0.005 +ppc: 0.004 +peripherals: 0.003 +x86: 0.003 +assembly: 0.002 +KVM: 0.002 +vnc: 0.002 +boot: 0.001 +VMM: 0.001 +risc-v: 0.001 +graphic: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +error: static assertion failed: "arm generic timer needs __Int128 defined" + +Hi, + +Accordingly to the instruction from https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842060/QEMU we have downloaded the Xilinx QEMU and tried to build it on Ubuntu 16.04.5 32Bit OS. We have done all the following steps from the instruction: +$ git clone git://github.com/Xilinx/qemu.git +$ cd qemu +$ git submodule update --init dtc +$ ./configure --target-list="aarch64-softmmu,microblazeel-softmmu" --enable-fdt --disable-kvm --disable-xen +$ make +and we have got the error during the compilation: +/home/qemu/include/qemu/int128.h:168:1: error: static assertion failed: "arm generic timer needs __Int128 defined" + _Static_assert(0, "arm generic timer needs __Int128 defined"); + ^ +/home/qemu/rules.mak:66: recipe for target 'stubs/qmp_pc_dimm.o' failed + +Could you please help to solve this issue. + +Last commit: commit 0b2f6a40631acd7e0cf789ea86b188d76c11149d + +Thanks, +Best Regards, +Piotr + +Hi there; this bug database is for issues in upstream QEMU. The assert() you have hit is not in upstream QEMU at all, so it must be something that Xilinx have added. For questions about Xilinx's version, you should talk to them, not us. + +That said, I think the answer is likely to be "they don't support building for 32-bit hosts", and you'll find that if you use a 64-bit host OS instead it will work. + + diff --git a/results/classifier/118/review/1817268 b/results/classifier/118/review/1817268 new file mode 100644 index 000000000..bee20ebb5 --- /dev/null +++ b/results/classifier/118/review/1817268 @@ -0,0 +1,255 @@ +user-level: 0.954 +register: 0.933 +performance: 0.918 +permissions: 0.916 +graphic: 0.914 +boot: 0.911 +assembly: 0.907 +debug: 0.906 +device: 0.902 +semantic: 0.900 +architecture: 0.900 +virtual: 0.896 +PID: 0.889 +socket: 0.880 +kernel: 0.880 +peripherals: 0.880 +vnc: 0.878 +arm: 0.873 +VMM: 0.853 +ppc: 0.847 +hypervisor: 0.837 +KVM: 0.832 +TCG: 0.824 +risc-v: 0.819 +network: 0.815 +mistranslation: 0.806 +files: 0.780 +x86: 0.743 +i386: 0.550 +-------------------- +virtual: 0.937 +hypervisor: 0.795 +user-level: 0.656 +KVM: 0.477 +x86: 0.313 +socket: 0.037 +debug: 0.034 +PID: 0.034 +network: 0.033 +files: 0.031 +register: 0.024 +VMM: 0.022 +TCG: 0.022 +device: 0.018 +kernel: 0.017 +semantic: 0.013 +risc-v: 0.013 +vnc: 0.013 +boot: 0.011 +assembly: 0.007 +peripherals: 0.007 +performance: 0.007 +ppc: 0.005 +architecture: 0.005 +permissions: 0.005 +graphic: 0.004 +mistranslation: 0.001 +i386: 0.001 +arm: 0.001 + +Input/output error during migration + +Operating system: Ubuntu 18.04.2 LTS +qemu version: 2.11.1, but also reproduced with 3.1.0 (compiled manually). +virsh --version: 4.0.0 + +Hello, + +I am having an issue with migration of UEFI virtual machines. If the --copy-storage-inc and the --tunnelled libvirt flags are used together, the migration fails. The same command for non-uefi virtual machines (e.g the same libvirt xml without the <nvram> and <loader> tags) works. + +The command/output error is: + +virsh migrate --verbose --live --p2p --tunnelled --copy-storage-inc --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +error: internal error: qemu unexpectedly closed the monitor: Receiving block device images +2019-02-21T16:20:15.263261Z qemu-system-x86_64: error while loading state section id 2(block) +2019-02-21T16:20:15.263996Z qemu-system-x86_64: load of migration failed: Input/output error + +If I remove one of the --tunnelled or the --copy-storage-inc flag, it works, for example: + +virsh migrate --verbose --live --p2p --copy-storage-inc --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +Migration: [100 %] + +virsh migrate --verbose --live --p2p --tunnelled --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +Migration: [100 %] + +I have no idea why those two flags combined together produce an error, and only for UEFI virtual machines. + +here is the libvirt xml definition: + +<domain type='kvm' id='4'> + <name>testuefi</name> + <uuid>ce12de05-ec09-4b4b-a27a-47003a511bda</uuid> + <description>CentOS 4.5 (32-bit)</description> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>2</vcpu> + <cputune> + <shares>878</shares> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>Apache Software Foundation</entry> + <entry name='product'>CloudStack KVM Hypervisor</entry> + <entry name='uuid'>ce12de05-ec09-4b4b-a27a-47003a511bda</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/testuefi_VARS.fd</nvram> + <boot dev='cdrom'/> + <boot dev='hd'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Westmere</model> + <feature policy='require' name='vmx'/> + <feature policy='require' name='vme'/> + <feature policy='require' name='pclmuldq'/> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/kvm-spice</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/var/lib/libvirt/images/testmigration.qcow2'/> + <backingStore type='file' index='1'> + <format type='raw'/> + <source file='/var/lib/libvirt/images/b3e4b880-0611-43bc-9d71-9cdac138f6e2'/> + <backingStore/> + </backingStore> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver cache='none'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <alias name='ide0-1-0'/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='06:6a:20:00:00:55'/> + <source bridge='public'/> + <target dev='vnet4'/> + <model type='virtio'/> + <driver queues='2'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/2'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/2'> + <source path='/dev/pts/2'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> +</domain> + +Here is the qemu command on the destination host: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name guest=testuefi-VM,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-14-testuefi-VM/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Server,vmx=on,pcid=on,ssbd=on,hypervisor=on -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/testuefi-VM_VARS.fd,if=pflash,format=raw,unit=1 -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid b340b117-1704-4ccf-93a7-21303b12dd7f -smbios 'type=1,manufacturer=Apache Software Foundation,product=CloudStack KVM Hypervisor,uuid=b340b117-1704-4ccf-93a7-21303b12dd7f' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-14-testuefi-VM/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/testmigration.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-1-0,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=37 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=06:a0:66:00:00:0c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc vnc=unix:/var/run/qemu/b340b117-1704-4ccf-93a7-21303b12dd7f.sock -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming defer -msg timestamp=on + +Thanks, + +Hi Mathieu, + How big is your testuefi-VM_VARS.fd file ? Does the problem go away if you pad it to 1MB? + +I've seen a problem migrating pflash where the files aren't 1MB (?) multiples but only using the 'old style' block migration; normally you get an NBD based block migration but when you select tunneling libvirt can't tunnel the nbd stream so falls back to the old style migration and hits this bug. + +Hi David, + +Thanks you for your help. + +The VARS file is 128K. + +I increased the "/var/lib/libvirt/qemu/nvram/testuefi_VARS.fd" var file to 1M, but had this error during migration: + +error: internal error: qemu unexpectedly closed the monitor: 2019-02-22T09:52:34.098833Z qemu-system-x86_64: Length mismatch: system.flash1: 0x100000 in != 0x20000: Invalid argument +2019-02-22T09:52:34.098940Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' + +So I destroyed the machine, removed the "/var/lib/libvirt/qemu/nvram/testuefi_VARS.fd" var file, increased the /usr/share/OVMF/OVMF_VARS.fd file in both hypervisors (src and dest) to 1M, recreated the machine and now the migration works: + +virsh migrate --verbose --live --p2p --tunnelled --copy-storage-inc --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +Migration: [100 %] + +I still have to test if increasing the VARS file do not cause issues on the virtual machine. + + +Yep that Length mismatch is expected - the source and destination do have to match. + +Thanks you, so it is a bug and not the expected behavior right ? + +Yes, I think so; although old-style block migration doesn't get much work on it now; so probably the fix I'd recommend for most cases now would be to pad the var file. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +I guess the bug still exists, I fixed it back in the time by repackaging OVMF_VARS.fd (padded to be 1M). + +I will try to find some time to mount an environment to reproduce the issue again. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1820247 b/results/classifier/118/review/1820247 new file mode 100644 index 000000000..7dd0550bc --- /dev/null +++ b/results/classifier/118/review/1820247 @@ -0,0 +1,477 @@ +user-level: 0.855 +ppc: 0.774 +hypervisor: 0.752 +TCG: 0.747 +mistranslation: 0.727 +KVM: 0.714 +VMM: 0.712 +x86: 0.676 +peripherals: 0.668 +risc-v: 0.667 +vnc: 0.651 +permissions: 0.649 +virtual: 0.647 +socket: 0.632 +device: 0.622 +boot: 0.616 +arm: 0.599 +i386: 0.598 +files: 0.576 +register: 0.573 +architecture: 0.569 +assembly: 0.567 +debug: 0.566 +performance: 0.564 +network: 0.555 +graphic: 0.544 +kernel: 0.530 +PID: 0.504 +semantic: 0.498 +-------------------- +debug: 0.961 +x86: 0.867 +hypervisor: 0.759 +virtual: 0.455 +KVM: 0.318 +kernel: 0.185 +PID: 0.172 +files: 0.164 +register: 0.143 +boot: 0.046 +socket: 0.044 +user-level: 0.022 +performance: 0.014 +semantic: 0.011 +TCG: 0.010 +device: 0.007 +network: 0.006 +assembly: 0.005 +ppc: 0.004 +architecture: 0.003 +VMM: 0.003 +permissions: 0.002 +graphic: 0.002 +peripherals: 0.002 +risc-v: 0.001 +i386: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +QEMU random crash caused by libspice-server + +Hi, + +One of our OpenStack instances crashed. It seems there was some problem related to SPICE. Attaching what we had in qemu log. Also sending our versions: + +Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux + +QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +root@pre-node1:~# cat /var/log/libvirt/qemu/instance-00000038.log +2019-03-10 20:39:36.510+0000: starting up libvirt version: 4.0.0, package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name guest=instance-00000038,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-00000038/master-key.aes -machine pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-00000038,share=yes,size=2147483648,host-nodes=0,policy=bind -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid 3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-00000038/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -add-fd set=0,fd=29 -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device redirected to /dev/pts/2 (label charserial0) +inputs_channel_detach_tablet: +main_channel_link: add main channel client +main_channel_client_handle_pong: net test: latency 32.760000 ms, bitrate 33384953 bps (31.838372 Mbps) +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create + +(process:65324): Spice-WARNING **: 16:35:23.769: Failed to create channel client: Client 0x55e7c157e970: duplicate channel type 2 id 0 +red_qxl_set_cursor_peer: + +(process:65324): Spice-WARNING **: 16:35:24.142: Failed to create channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0 + +(process:65324): Spice-CRITICAL **: 16:35:24.142: cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed +2019-03-13 15:35:31.785+0000: shutting down, reason=crashed + + + + +I am also attaching some gdb information extracted from qemu crash dump file. These are backtraces of particular threads within the crashed QEMU process. + + +Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)): +#0 0x00007f695f02d2b7 in __libc_write (fd=26, buf=0x7ffc33f5b330, nbytes=56) at ../sysdeps/unix/sysv/linux/write.c:27 +#1 0x00007f695ff30ed3 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#2 0x00007f695ff316ce in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#3 0x00007f695ff52db6 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#4 0x00007f695ff58e38 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#5 0x00007f695ff5f463 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#6 0x00007f695ff5f7bb in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#7 0x000055e7bec94584 in () +#8 0x000055e7bec94e58 in aio_dispatch () +#9 0x000055e7bec91e3e in () +#10 0x00007f695fa45387 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#11 0x000055e7bec940a7 in main_loop_wait () +#12 0x000055e7be8b8486 in main () + +Thread 8 (Thread 0x7f68b78fc700 (LWP 61873)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f68b78fb900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f68b78fb900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f68b78fb900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f68b78fc700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 7 (Thread 0x7f688f7fe700 (LWP 61366)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f688f7fd900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f688f7fd900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f688f7fd900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f688f7fe700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 6 (Thread 0x7f687effd700 (LWP 61362)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f687effc900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f687effc900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f687effc900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f687effd700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 5 (Thread 0x7f68b58f1700 (LWP 60991)): +#0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f68b58f0900, expected=0, futex_word=0x55e7c1531d78) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +#1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, abstime=abstime@entry=0x7f68b58f0900) at sem_waitcommon.c:111 +#2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, abstime=0x7f68b58f0900) at sem_waitcommon.c:181 +#3 0x000055e7bec976cf in qemu_sem_timedwait () +#4 0x000055e7bec928bc in () +#5 0x00007f695f0236db in start_thread (arg=0x7f68b58f1700) at pthread_create.c:463 +#6 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 4 (Thread 0x7f69564a2700 (LWP 65331)): +#0 0x00007f695ed46839 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055e7bec9790b in qemu_event_wait () +#2 0x000055e7beca7ebe in () +#3 0x00007f695f0236db in start_thread (arg=0x7f69564a2700) at pthread_create.c:463 +#4 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 3 (Thread 0x7f695449d700 (LWP 65363)): +#0 0x00007f695ed415d7 in ioctl () at ../sysdeps/unix/syscall-template.S:78 +#1 0x000055e7be910547 in kvm_vcpu_ioctl () +#2 0x000055e7be910684 in kvm_cpu_exec () +#3 0x000055e7be8ed3f4 in () +#4 0x00007f695f0236db in start_thread (arg=0x7f695449d700) at pthread_create.c:463 +#5 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2 (Thread 0x7f6952b4f700 (LWP 65366)): +#0 0x00007f695ed415d7 in ioctl () at ../sysdeps/unix/syscall-template.S:78 +#1 0x000055e7be910547 in kvm_vcpu_ioctl () +---Type <return> to continue, or q <return> to quit--- +#2 0x000055e7be910684 in kvm_cpu_exec () +#3 0x000055e7be8ed3f4 in () +#4 0x00007f695f0236db in start_thread (arg=0x7f6952b4f700) at pthread_create.c:463 +#5 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 1 (Thread 0x7f6951a40700 (LWP 65368)): +#0 0x00007f695ec69e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f695ec6b801 in __GI_abort () at abort.c:79 +#2 0x00007f695ff81cc9 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#3 0x00007f695ff63929 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#4 0x00007f695ff314f1 in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#5 0x00007f695ff37d7b in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#6 0x00007f695fa451f5 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x00007f695fa455c0 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#8 0x00007f695fa458d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#9 0x00007f695ff63b3a in () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +#10 0x00007f695f0236db in start_thread (arg=0x7f6951a40700) at pthread_create.c:463 +#11 0x00007f695ed4c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Regards, +Premysl + +Hi Premysl, +this has similarities to [1] which was fixed long ago. +In case it is reproducible for you - as it was asked back then - it might be helpful attaching SPICE_DEBUG=1 log, using remote-viewer. + +And if reproducible in general also worth a quick check to try with the latest qemu version which atm is 3.1 that you have in Debian Buster. + +[1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8 + +Hi Christian, + +thanks for reply, chmmm, what makes you think there are similarities? To me +it looks like a different problem. + +Regards, +Premysl + + +On Mon, Mar 18, 2019 at 8:15 AM Christian Ehrhardt < +<email address hidden>> wrote: + +> Hi Premysl, +> this has similarities to [1] which was fixed long ago. +> In case it is reproducible for you - as it was asked back then - it might +> be helpful attaching SPICE_DEBUG=1 log, using remote-viewer. +> +> And if reproducible in general also worth a quick check to try with the +> latest qemu version which atm is 3.1 that you have in Debian Buster. +> +> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=980714#c8 +> +> ** Bug watch added: Red Hat Bugzilla #980714 +> https://bugzilla.redhat.com/show_bug.cgi?id=980714 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1820247 +> +> Title: +> QEMU random crash caused by libspice-server +> +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> One of our OpenStack instances crashed. It seems there was some +> problem related to SPICE. Attaching what we had in qemu log. Also +> sending our versions: +> +> Linux pre-node1 4.18.0-13-generic #14~18.04.1-Ubuntu SMP Thu Dec 6 +> 14:09:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux +> +> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9) +> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +> +> +> root@pre-node1:~# cat /var/log/libvirt/qemu/instance-00000038.log +> 2019-03-10 20:39:36.510+0000: starting up libvirt version: 4.0.0, +> package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> +> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian +> 1:2.11+dfsg-1ubuntu7.9), hostname: pre-node1 +> LC_ALL=C +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin +> QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name +> guest=instance-00000038,debug-threads=on -S -object +> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-instance-00000038/master-key.aes +> -machine +> pc-i440fx-bionic,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu +> Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,pku=on,ssbd=on,xsaves=on +> -m 2048 -realtime mlock=on -smp 2,sockets=1,cores=1,threads=2 -object +> memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/5-instance-00000038,share=yes,size=2147483648,host-nodes=0,policy=bind +> -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -uuid +> 3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7 -smbios 'type=1,manufacturer=OpenStack +> Foundation,product=OpenStack +> Nova,version=18.1.1,serial=93fa1a55-ba3a-4a99-80b3-3a7bb4e964af,uuid=3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7,family=Virtual +> Machine' -no-user-config -nodefaults -chardev +> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-instance-00000038/monitor.sock,server,nowait +> -mon chardev=charmonitor,id=monitor,mode=control -rtc +> base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet +> -no-shutdown -boot strict=on -device +> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device +> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive +> file=/var/lib/nova/instances/3c3d04f3-4b25-4ea5-8836-0e06eef9dcb7/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,discard=ignore,throttling.iops-read=5000,throttling.iops-write=5000 +> -device +> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 +> -add-fd set=0,fd=29 -chardev +> pty,id=charserial0,logfile=/dev/fdset/0,logappend=on -device +> isa-serial,chardev=charserial0,id=serial0 -chardev +> spicevmc,id=charchannel0,name=vdagent -device +> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 +> -spice port=5900,addr=10.252.0.101,disable-ticketing,seamless-migration=on +> -device +> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 +> -device vfio-pci,host=25:04.1,id=hostdev0,bus=pci.0,addr=0x5 -device +> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +> 2019-03-10T20:39:36.568276Z qemu-system-x86_64: -chardev +> pty,id=charserial0,logfile=/dev/fdset/0,logappend=on: char device +> redirected to /dev/pts/2 (label charserial0) +> inputs_channel_detach_tablet: +> main_channel_link: add main channel client +> main_channel_client_handle_pong: net test: latency 32.760000 ms, bitrate +> 33384953 bps (31.838372 Mbps) +> red_qxl_set_cursor_peer: +> inputs_connect: inputs channel client create +> +> (process:65324): Spice-WARNING **: 16:35:23.769: Failed to create +> channel client: Client 0x55e7c157e970: duplicate channel type 2 id 0 +> red_qxl_set_cursor_peer: +> +> (process:65324): Spice-WARNING **: 16:35:24.142: Failed to create +> channel client: Client 0x55e7c157e970: duplicate channel type 4 id 0 +> +> (process:65324): Spice-CRITICAL **: 16:35:24.142: +> cursor-channel.c:353:cursor_channel_connect: condition `ccc != NULL' failed +> 2019-03-13 15:35:31.785+0000: shutting down, reason=crashed +> +> +> +> I am also attaching some gdb information extracted from qemu crash dump +> file. These are backtraces of particular threads within the crashed QEMU +> process. +> +> +> Thread 9 (Thread 0x7f69649ea5c0 (LWP 65324)): +> #0 0x00007f695f02d2b7 in __libc_write (fd=26, buf=0x7ffc33f5b330, +> nbytes=56) at ../sysdeps/unix/sysv/linux/write.c:27 +> #1 0x00007f695ff30ed3 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #2 0x00007f695ff316ce in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #3 0x00007f695ff52db6 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #4 0x00007f695ff58e38 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #5 0x00007f695ff5f463 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #6 0x00007f695ff5f7bb in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #7 0x000055e7bec94584 in () +> #8 0x000055e7bec94e58 in aio_dispatch () +> #9 0x000055e7bec91e3e in () +> #10 0x00007f695fa45387 in g_main_context_dispatch () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #11 0x000055e7bec940a7 in main_loop_wait () +> #12 0x000055e7be8b8486 in main () +> +> Thread 8 (Thread 0x7f68b78fc700 (LWP 61873)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f68b78fb900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f68b78fb900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f68b78fb900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f68b78fc700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 7 (Thread 0x7f688f7fe700 (LWP 61366)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f688f7fd900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f688f7fd900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f688f7fd900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f688f7fe700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 6 (Thread 0x7f687effd700 (LWP 61362)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f687effc900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f687effc900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f687effc900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f687effd700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 5 (Thread 0x7f68b58f1700 (LWP 60991)): +> #0 0x00007f695f02c8c2 in futex_abstimed_wait_cancelable (private=0, +> abstime=0x7f68b58f0900, expected=0, futex_word=0x55e7c1531d78) +> at ../sysdeps/unix/sysv/linux/futex-internal.h:205 +> #1 0x00007f695f02c8c2 in do_futex_wait (sem=sem@entry=0x55e7c1531d78, +> abstime=abstime@entry=0x7f68b58f0900) at sem_waitcommon.c:111 +> #2 0x00007f695f02c9d3 in __new_sem_wait_slow (sem=0x55e7c1531d78, +> abstime=0x7f68b58f0900) at sem_waitcommon.c:181 +> #3 0x000055e7bec976cf in qemu_sem_timedwait () +> #4 0x000055e7bec928bc in () +> #5 0x00007f695f0236db in start_thread (arg=0x7f68b58f1700) at +> pthread_create.c:463 +> #6 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 4 (Thread 0x7f69564a2700 (LWP 65331)): +> #0 0x00007f695ed46839 in syscall () at +> ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +> #1 0x000055e7bec9790b in qemu_event_wait () +> #2 0x000055e7beca7ebe in () +> #3 0x00007f695f0236db in start_thread (arg=0x7f69564a2700) at +> pthread_create.c:463 +> #4 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 3 (Thread 0x7f695449d700 (LWP 65363)): +> #0 0x00007f695ed415d7 in ioctl () at +> ../sysdeps/unix/syscall-template.S:78 +> #1 0x000055e7be910547 in kvm_vcpu_ioctl () +> #2 0x000055e7be910684 in kvm_cpu_exec () +> #3 0x000055e7be8ed3f4 in () +> #4 0x00007f695f0236db in start_thread (arg=0x7f695449d700) at +> pthread_create.c:463 +> #5 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 2 (Thread 0x7f6952b4f700 (LWP 65366)): +> #0 0x00007f695ed415d7 in ioctl () at +> ../sysdeps/unix/syscall-template.S:78 +> #1 0x000055e7be910547 in kvm_vcpu_ioctl () +> ---Type <return> to continue, or q <return> to quit--- +> #2 0x000055e7be910684 in kvm_cpu_exec () +> #3 0x000055e7be8ed3f4 in () +> #4 0x00007f695f0236db in start_thread (arg=0x7f6952b4f700) at +> pthread_create.c:463 +> #5 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Thread 1 (Thread 0x7f6951a40700 (LWP 65368)): +> #0 0x00007f695ec69e97 in __GI_raise (sig=sig@entry=6) at +> ../sysdeps/unix/sysv/linux/raise.c:51 +> #1 0x00007f695ec6b801 in __GI_abort () at abort.c:79 +> #2 0x00007f695ff81cc9 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #3 0x00007f695ff63929 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #4 0x00007f695ff314f1 in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #5 0x00007f695ff37d7b in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #6 0x00007f695fa451f5 in g_main_context_dispatch () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #7 0x00007f695fa455c0 in () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #8 0x00007f695fa458d2 in g_main_loop_run () at +> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #9 0x00007f695ff63b3a in () at +> /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +> #10 0x00007f695f0236db in start_thread (arg=0x7f6951a40700) at +> pthread_create.c:463 +> #11 0x00007f695ed4c88f in clone () at +> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> Regards, +> Premysl +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1820247/+subscriptions +> + + +Hi, +the warnings around "duplicate channel type 2 id 0" where present in the other bug as well. +And since that often means it passes the same area of code I wanted to suggest to provide the same debug data. + +The actual crash is a different one for sure as the stack traces look different and also the old one is fixed quite some time. + +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/review/1822 b/results/classifier/118/review/1822 new file mode 100644 index 000000000..75a40c58d --- /dev/null +++ b/results/classifier/118/review/1822 @@ -0,0 +1,67 @@ +architecture: 0.941 +graphic: 0.904 +mistranslation: 0.904 +device: 0.881 +arm: 0.876 +network: 0.774 +vnc: 0.751 +socket: 0.746 +kernel: 0.709 +risc-v: 0.706 +ppc: 0.698 +VMM: 0.686 +files: 0.668 +PID: 0.661 +register: 0.639 +debug: 0.580 +semantic: 0.572 +boot: 0.549 +TCG: 0.546 +hypervisor: 0.493 +peripherals: 0.472 +performance: 0.470 +permissions: 0.466 +x86: 0.430 +KVM: 0.406 +user-level: 0.405 +assembly: 0.390 +i386: 0.308 +virtual: 0.255 +-------------------- +files: 0.134 +TCG: 0.134 +user-level: 0.127 +kernel: 0.108 +VMM: 0.064 +x86: 0.064 +register: 0.059 +KVM: 0.051 +hypervisor: 0.048 +virtual: 0.034 +debug: 0.034 +network: 0.022 +semantic: 0.015 +arm: 0.007 +i386: 0.007 +socket: 0.006 +risc-v: 0.005 +PID: 0.004 +assembly: 0.004 +device: 0.004 +ppc: 0.002 +permissions: 0.002 +architecture: 0.002 +boot: 0.001 +vnc: 0.001 +peripherals: 0.001 +graphic: 0.001 +performance: 0.000 +mistranslation: 0.000 + +Signed source tarball for 8.0.4 missing +Description of problem: +Hi! I package this project for Arch Linux. I would like to upgrade to 8.0.4, but unfortunately there is no signed source tarball for that version available yet. +Steps to reproduce: +1. Go to https://download.qemu.org/ and find no source tarball for 8.0.4 +Additional information: + diff --git a/results/classifier/118/review/1824704 b/results/classifier/118/review/1824704 new file mode 100644 index 000000000..3e0af2f7d --- /dev/null +++ b/results/classifier/118/review/1824704 @@ -0,0 +1,147 @@ +mistranslation: 0.888 +semantic: 0.803 +permissions: 0.676 +device: 0.639 +performance: 0.607 +user-level: 0.601 +PID: 0.558 +graphic: 0.557 +arm: 0.418 +socket: 0.372 +assembly: 0.364 +ppc: 0.352 +network: 0.345 +register: 0.336 +VMM: 0.316 +architecture: 0.291 +vnc: 0.291 +debug: 0.283 +hypervisor: 0.279 +kernel: 0.278 +peripherals: 0.223 +TCG: 0.219 +files: 0.216 +boot: 0.209 +risc-v: 0.206 +virtual: 0.203 +KVM: 0.144 +x86: 0.107 +i386: 0.074 +-------------------- +debug: 0.365 +user-level: 0.059 +TCG: 0.059 +virtual: 0.053 +x86: 0.049 +peripherals: 0.028 +network: 0.025 +register: 0.023 +PID: 0.023 +hypervisor: 0.021 +semantic: 0.021 +files: 0.019 +i386: 0.019 +ppc: 0.017 +device: 0.017 +boot: 0.012 +mistranslation: 0.011 +socket: 0.010 +vnc: 0.009 +arm: 0.008 +performance: 0.007 +risc-v: 0.006 +assembly: 0.003 +permissions: 0.002 +kernel: 0.002 +VMM: 0.002 +graphic: 0.002 +architecture: 0.001 +KVM: 0.001 + +-k tr not working after v20171217! turkish keyboard dont working + +hi qemu + +-k tr not working after v20171217! turkish keyboard dont working + +last working without proplem at v20171217! + + +after this version tr keyboard prople. +freedos , winpe , linux images all dont working tr turkish keyboard. + +example press key " ç " show " , " +example 2 press key " . " show " ç " + +tr keyboard work always "en-us" kbd. +:(((((((( + + + +please fix this critical bug. + +Sincerely + +Can you find out which commit broke the keyboard for you? (By using "git bisect" for example) + +24 Eylül 2019 Salı tarihinde Thomas Huth <email address hidden> yazdı: + +> Can you find out which commit broke the keyboard for you? (By using "git +> bisect" for example) +> +> ** Information type changed from Private Security to Public +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1824704 +> +> Title: +> -k tr not working after v20171217! turkish keyboard dont working +> +> Status in QEMU: +> New +> +> Bug description: +> hi qemu +> +> -k tr not working after v20171217! turkish keyboard dont working +> +> last working without proplem at v20171217! +> +> after this version tr keyboard proplem. +> freedos , winpe , linux images all dont working tr turkish +> keyboard. +> +> example press key " ç " show " , " +> example 2 press key " . " show " ç " +> +> tr keyboard work always "en-us" kbd. +> :(((((((( +> +> please fix this critical bug. +> +> Sincerely +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1824704/+subscriptions +> + + +Not working turkish q keyboard + +Ç pres result, +. Press. Result ç + + +I meant which version of QEMU is still working for you? Which version fails? + +What does "localectl" print (both host and guest please)? + + after v20171217 all versions. + + +What does v20171217 refer to? A pre-built binary? Windows? Linux? Mac OS? ... sorry, but you have to be a little bit more specific. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1825 b/results/classifier/118/review/1825 new file mode 100644 index 000000000..4925ac41b --- /dev/null +++ b/results/classifier/118/review/1825 @@ -0,0 +1,74 @@ +x86: 0.963 +architecture: 0.822 +device: 0.751 +graphic: 0.738 +files: 0.708 +semantic: 0.636 +debug: 0.545 +performance: 0.449 +register: 0.424 +PID: 0.418 +network: 0.409 +permissions: 0.362 +vnc: 0.341 +mistranslation: 0.269 +socket: 0.263 +boot: 0.256 +ppc: 0.244 +risc-v: 0.215 +user-level: 0.215 +kernel: 0.189 +VMM: 0.165 +arm: 0.165 +peripherals: 0.154 +hypervisor: 0.126 +virtual: 0.114 +TCG: 0.109 +KVM: 0.035 +assembly: 0.031 +i386: 0.021 +-------------------- +debug: 0.916 +TCG: 0.345 +virtual: 0.301 +user-level: 0.133 +hypervisor: 0.087 +register: 0.046 +PID: 0.044 +performance: 0.022 +files: 0.018 +architecture: 0.016 +kernel: 0.014 +device: 0.008 +x86: 0.007 +arm: 0.007 +KVM: 0.005 +network: 0.005 +VMM: 0.003 +boot: 0.003 +semantic: 0.003 +assembly: 0.003 +risc-v: 0.002 +peripherals: 0.002 +socket: 0.002 +graphic: 0.001 +ppc: 0.001 +permissions: 0.001 +i386: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +pigz crashes when running in an aarch64 chroot (entered through qemu-binfmt) with qemu 8.1.0-rc*, qemu 8.0.3 is ok +Description of problem: +If qemu 8.1.0-rc1, -rc2 or -rc3 is used, pigz crashes. +``` +# chroot /chroot/aarch64 pigz /tmp/test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +``` +With qemu 8.0.3 on the same chroot enviroment, it works and produces the expected /chroot/aarch64/tmp/test.gz +Steps to reproduce: +1. Install an aarch64 chroot environment on x86_64 +2. Try using pigz to compress a file inside the chroot environment using qemu-binfmt +Additional information: +Unfortunately `git bisect`-ing the issue isn't easy because many snapshots between 8.0.0 (good) and 8.1.0-rc1 (first known bad) don't compile. diff --git a/results/classifier/118/review/1825311 b/results/classifier/118/review/1825311 new file mode 100644 index 000000000..10c694a31 --- /dev/null +++ b/results/classifier/118/review/1825311 @@ -0,0 +1,117 @@ +architecture: 0.874 +kernel: 0.753 +performance: 0.749 +peripherals: 0.738 +device: 0.732 +graphic: 0.681 +files: 0.673 +hypervisor: 0.671 +network: 0.660 +ppc: 0.652 +PID: 0.645 +socket: 0.640 +assembly: 0.637 +register: 0.631 +vnc: 0.606 +permissions: 0.605 +mistranslation: 0.604 +VMM: 0.602 +user-level: 0.599 +TCG: 0.575 +i386: 0.561 +risc-v: 0.558 +semantic: 0.557 +x86: 0.528 +virtual: 0.526 +arm: 0.507 +boot: 0.506 +debug: 0.439 +KVM: 0.415 +-------------------- +kernel: 0.982 +performance: 0.561 +assembly: 0.080 +debug: 0.078 +architecture: 0.051 +files: 0.023 +TCG: 0.021 +semantic: 0.016 +graphic: 0.013 +boot: 0.012 +hypervisor: 0.012 +PID: 0.010 +device: 0.007 +register: 0.007 +VMM: 0.006 +virtual: 0.006 +user-level: 0.004 +KVM: 0.003 +vnc: 0.003 +permissions: 0.002 +risc-v: 0.002 +socket: 0.002 +mistranslation: 0.001 +network: 0.001 +peripherals: 0.001 +ppc: 0.001 +arm: 0.000 +x86: 0.000 +i386: 0.000 + +mips_cpu_handle_mmu_fault renders all accessed pages executable + +On MIPS, data accesses to pages mapped in the TLB result in mips_cpu_handle_mmu_fault() marking the page unconditionally executable, even if the TLB entry has the XI bit set. Later on, when there is an attempt to execute this page, no exception is generated, even though TLBXI is expected. + +I am attaching a reproducer image and script. + +Unpatched execution ends like this: + +... +TAP TEST START +1..2 +not ok 1 NonExecutable::ElfDataIsNotExecutable +# Assertion failed /home/jermar/Kernkonzept/software/l4/pkg/l4re-core/test/moe/test_nx.cc:103 +# Expected: -(L4_EIPC_LO + l4_ipc_error(tag, l4_utcb())) >= 0 +# Actual: -2003 (Receive timeout) +# There was no IPC error. +# Assertion failed /home/jermar/Kernkonzept/software/l4/pkg/l4re-core/test/moe/test_nx.cc:125 +# Expected equality of these values: +# pfa +# Which is: 360 +# (l4_addr_t)execute_data +# Which is: 17633344 +# The page fault occured at the expected location. +not ok 2 NonExecutable::StackIsNotExecutable +# Assertion failed /home/jermar/Kernkonzept/software/l4/pkg/l4re-core/test/moe/test_nx.cc:103 +# Expected: -(L4_EIPC_LO + l4_ipc_error(tag, l4_utcb())) >= 0 +# Actual: -2003 (Receive timeout) +# There was no IPC error. +# Assertion failed /home/jermar/Kernkonzept/software/l4/pkg/l4re-core/test/moe/test_nx.cc:144 +# Expected equality of these values: +# pfa +# Which is: 4358144 +# stack_func +# Which is: 4276000 +# The page fault occured at the expected location. +TAP TEST FINISHED + + + +With the proposed patch applied, the execution should end with something like this: + +... +TAP TEST START +1..2 +ok 1 NonExecutable::ElfDataIsNotExecutable +ok 2 NonExecutable::StackIsNotExecutable +TAP TEST FINISHED + + +Patch posted on the list: +https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg03711.html + +Also attaching the 64-bit version of the reproducer. + +This bug should be fixed by commit 7353113fa482e697a77 now in QEMU master; it will be in the 4.1 release. + + diff --git a/results/classifier/118/review/1826401 b/results/classifier/118/review/1826401 new file mode 100644 index 000000000..7dcab37ab --- /dev/null +++ b/results/classifier/118/review/1826401 @@ -0,0 +1,104 @@ +architecture: 0.923 +PID: 0.914 +socket: 0.808 +performance: 0.805 +device: 0.646 +graphic: 0.604 +network: 0.558 +mistranslation: 0.492 +user-level: 0.491 +peripherals: 0.489 +register: 0.355 +files: 0.345 +x86: 0.321 +virtual: 0.304 +semantic: 0.292 +ppc: 0.278 +permissions: 0.225 +kernel: 0.209 +vnc: 0.167 +debug: 0.159 +i386: 0.129 +hypervisor: 0.123 +boot: 0.110 +arm: 0.093 +assembly: 0.075 +TCG: 0.071 +risc-v: 0.052 +VMM: 0.049 +KVM: 0.011 +-------------------- +performance: 0.930 +hypervisor: 0.898 +virtual: 0.880 +PID: 0.599 +debug: 0.337 +TCG: 0.242 +socket: 0.117 +kernel: 0.030 +files: 0.019 +register: 0.017 +boot: 0.015 +user-level: 0.015 +semantic: 0.009 +device: 0.008 +assembly: 0.005 +architecture: 0.005 +network: 0.005 +arm: 0.003 +ppc: 0.003 +vnc: 0.003 +graphic: 0.002 +x86: 0.002 +risc-v: 0.002 +VMM: 0.002 +peripherals: 0.002 +KVM: 0.001 +permissions: 0.001 +i386: 0.001 +mistranslation: 0.000 + +qemu-system-aarch64 has a high cpu usage on windows + +Running qemu-system-aarch64 leads to a high CPU consumption on windows 10. + +Tested with qemu: 4.0.0-rc4 & 3.1.0 & 2.11.0 + +Command: qemu_start_command = [ + qemu-system-aarch64, + "-pidfile", + target_path + "/qemu" + str(instance) + ".pid", + "-machine", + "virt", + "-cpu", + "cortex-a57", + "-nographic", + "-smp", + "2", + "-m", + "2048", + "-kernel", + kernel_path, + "--append", + "console=ttyAMA0 root=/dev/vda2 rw ipx=" + qemu_instance_ip + "/64 net.ifnames=0 biosdevname=0", + "-drive", + "file=" + qemu_instance_img_path + ",if=none,id=blk", + "-device", + "virtio-blk-device,drive=blk", + "-netdev", + "socket,id=mynet0,udp=127.0.0.1:2000,localaddr=127.0.0.1:" + qemu_instance_port, + "-device", + "virtio-net-device,netdev=mynet0", + "-serial", + "file:" + target_path + "/qemu" + str(instance) + ".log" + ] + +*The cpu consumption is ~70%. +*No acceleration used. +*This CPU consumption is obtained only by running the above command. No workload on the guest OS. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? +Also, what guest operating systems were you running ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1828723 b/results/classifier/118/review/1828723 new file mode 100644 index 000000000..07158a748 --- /dev/null +++ b/results/classifier/118/review/1828723 @@ -0,0 +1,92 @@ +architecture: 0.904 +mistranslation: 0.589 +user-level: 0.530 +graphic: 0.384 +semantic: 0.340 +virtual: 0.286 +performance: 0.281 +device: 0.266 +socket: 0.193 +network: 0.165 +permissions: 0.149 +x86: 0.140 +kernel: 0.139 +i386: 0.137 +register: 0.136 +arm: 0.135 +files: 0.133 +peripherals: 0.130 +ppc: 0.113 +risc-v: 0.109 +vnc: 0.109 +PID: 0.104 +boot: 0.104 +TCG: 0.073 +VMM: 0.064 +debug: 0.063 +KVM: 0.056 +hypervisor: 0.054 +assembly: 0.031 +-------------------- +user-level: 0.643 +debug: 0.442 +virtual: 0.066 +TCG: 0.041 +files: 0.020 +PID: 0.014 +ppc: 0.014 +x86: 0.010 +performance: 0.010 +kernel: 0.007 +hypervisor: 0.007 +i386: 0.005 +semantic: 0.005 +network: 0.005 +architecture: 0.005 +arm: 0.003 +socket: 0.003 +register: 0.003 +boot: 0.002 +risc-v: 0.002 +device: 0.002 +permissions: 0.002 +assembly: 0.002 +KVM: 0.002 +VMM: 0.001 +vnc: 0.001 +peripherals: 0.001 +graphic: 0.001 +mistranslation: 0.000 + +[RFE] option to suppress gemu_log() output + +With user mode emulation, messages from genu_log() are emitted unconditionally to stderr. I didn't find a way to suppress them. It would be nice to have options similar to the -D/-d options to be able to filter and/or redirect the output. + +My use case is chroot/container execution for different architectures via binfmt. In this case it will appear as if the binary in question had emitted messages like "Unsupported setsockopt ..." to stderr while in fact the message came from qemu-*-static. + +This series might be helpful: +https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02067.html + +The -d/-D options should work in linux-user as well. You can also set QEMU_LOG_FILENAME and QEMU_LOG environment variables. Do these not work for you? + + +Although arguably the line: + + gemu_log("Unsupported setsockopt level=%d optname=%d\n", level, optname); + +Could be + + qemu_log_mask(LOG_UNIMP,....) + +Not sure where gemu_log is used, it seems to be strace related. + +Indeed I think gemu_log() is the problem here. + + +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/171 + + diff --git a/results/classifier/118/review/1829576 b/results/classifier/118/review/1829576 new file mode 100644 index 000000000..41781d151 --- /dev/null +++ b/results/classifier/118/review/1829576 @@ -0,0 +1,136 @@ +user-level: 0.902 +permissions: 0.881 +risc-v: 0.877 +vnc: 0.864 +ppc: 0.855 +VMM: 0.850 +hypervisor: 0.840 +semantic: 0.836 +TCG: 0.829 +device: 0.828 +register: 0.828 +virtual: 0.818 +mistranslation: 0.816 +peripherals: 0.807 +KVM: 0.801 +x86: 0.799 +boot: 0.796 +graphic: 0.791 +performance: 0.786 +debug: 0.780 +assembly: 0.776 +PID: 0.773 +architecture: 0.772 +socket: 0.755 +files: 0.739 +arm: 0.734 +network: 0.725 +kernel: 0.691 +i386: 0.560 +-------------------- +ppc: 0.761 +x86: 0.719 +kernel: 0.697 +virtual: 0.572 +PID: 0.136 +hypervisor: 0.105 +debug: 0.081 +performance: 0.074 +architecture: 0.073 +user-level: 0.071 +socket: 0.047 +files: 0.037 +boot: 0.032 +register: 0.028 +device: 0.012 +semantic: 0.009 +network: 0.005 +TCG: 0.004 +assembly: 0.003 +peripherals: 0.003 +vnc: 0.003 +permissions: 0.002 +graphic: 0.002 +VMM: 0.002 +risc-v: 0.001 +KVM: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0 + +I have been using QEMU-SYSTEM-PPC64 v3.1.0 to run CentOS7 PPC emulated system. It stopped working when I upgraded to QEMU-4.0.0 . I downgraded back to QEMU-3.1.0 and it started working again. The problem is that my CentOS7 image will not boot up udner QEMU-4.0.0, but works fine under QEMU-3.1.0. + +I have an QCOW2 image available at https://www.mediafire.com/file/d8dda05ro85whn1/linux-centos7-ppc64.qcow2/file . NOTE: It is 15GB. Kind of large. + +I run it as follows: + + qemu-system-ppc64 \ + -name "CENTOS7-PPC64" \ + -cpu POWER7 -machine pseries \ + -m 4096 \ + -netdev bridge,id=netbr0,br=br0 \ + -device e1000,netdev=netbr0,mac=52:54:3c:13:21:33 \ + -hda "./linux-centos7-ppc64.qcow2" \ + -monitor stdio + +HOST: I am using Manjaro Linux on an Intel i7 machine with the QEMU packages installed via the package manager of the distribution. + +[jsantiago@jlsws0 ~]$ uname -a +Linux jlsws0.haivision.com 4.19.42-1-MANJARO #1 SMP PREEMPT Fri May 10 20:52:43 UTC 2019 x86_64 GNU/Linux + +jsantiago@jlsws0 ~]$ cpuinfo +Intel(R) processor family information utility, Version 2019 Update 3 Build 20190214 (id: b645a4a54) +Copyright (C) 2005-2019 Intel Corporation. All rights reserved. + +===== Processor composition ===== +Processor name : Intel(R) Core(TM) i7-6700K +Packages(sockets) : 1 +Cores : 4 +Processors(CPUs) : 8 +Cores per package : 4 +Threads per core : 2 + +===== Processor identification ===== +Processor Thread Id. Core Id. Package Id. +0 0 0 0 +1 0 1 0 +2 0 2 0 +3 0 3 0 +4 1 0 0 +5 1 1 0 +6 1 2 0 +7 1 3 0 +===== Placement on packages ===== +Package Id. Core Id. Processors +0 0,1,2,3 (0,4)(1,5)(2,6)(3,7) + +===== Cache sharing ===== +Cache Size Processors +L1 32 KB (0,4)(1,5)(2,6)(3,7) +L2 256 KB (0,4)(1,5)(2,6)(3,7) +L3 8 MB (0,1,2,3,4,5,6,7) + +I suspect that this may be related to the VSR register conversion. Can you try applying all of the patches below on top of 4.0 to see if they resolve the issue? + +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01254.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01256.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01257.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01260.html + + +I applied the four patches you indicated and the image boots up and runs. Everything seems to be working now. Thank You. + +I also have a regression issue between 3.1.0 and 4.0.0 (actually latest git) on qemu-system-ppc64 but it involves an AIX guest instead (fail to boot). Should I open a new ticket or hop on this one ? + +David has already queued the patches in his ppc-for-4.1 branch at https://github.com/dgibson/qemu/commits/ppc-for-4.1 so they will get merged soon. If you're working with git then I'd try testing the queued branch first and see if that resolves the issue. + +Once the patches have been applied to master we'll add a CC to the stable list so the fixes will be included in the next 4.0 update. + +Same thing here using https://github.com/dgibson/qemu/commits/ppc-for-4.1 ... It might be a completely different problem (athough it looks like a MMU problem). + +Is this fixed now? Can we mark as fix committed? + +It is fixed with the 4.1.0 release. Thank you. + diff --git a/results/classifier/118/review/1829696 b/results/classifier/118/review/1829696 new file mode 100644 index 000000000..eed2b9fdf --- /dev/null +++ b/results/classifier/118/review/1829696 @@ -0,0 +1,450 @@ +risc-v: 0.874 +user-level: 0.868 +mistranslation: 0.848 +architecture: 0.832 +performance: 0.830 +virtual: 0.827 +KVM: 0.826 +hypervisor: 0.823 +permissions: 0.812 +vnc: 0.810 +register: 0.784 +graphic: 0.783 +device: 0.773 +arm: 0.768 +VMM: 0.767 +assembly: 0.764 +peripherals: 0.761 +TCG: 0.753 +ppc: 0.739 +PID: 0.732 +boot: 0.706 +semantic: 0.704 +socket: 0.702 +network: 0.688 +x86: 0.684 +debug: 0.675 +kernel: 0.665 +files: 0.653 +i386: 0.459 +-------------------- +virtual: 0.916 +performance: 0.913 +debug: 0.327 +hypervisor: 0.294 +register: 0.245 +KVM: 0.177 +risc-v: 0.076 +TCG: 0.065 +assembly: 0.040 +files: 0.033 +kernel: 0.032 +x86: 0.031 +socket: 0.031 +VMM: 0.025 +PID: 0.025 +ppc: 0.016 +boot: 0.015 +semantic: 0.012 +user-level: 0.010 +i386: 0.007 +device: 0.005 +architecture: 0.005 +vnc: 0.005 +permissions: 0.003 +network: 0.002 +arm: 0.001 +peripherals: 0.001 +graphic: 0.001 +mistranslation: 0.000 + +qemu-kvm takes 100% CPU when running redhat/centos 7.6 guest VM OS + +Description +=========== +When running redhat or centos 7.6 guest os on vm, +the cpu usage is very low on vm(100% idle), but on host, +qemu-kvm reports 100% cpu busy usage. + +After searching some related bugs report, +I suspect that it is due to the clock settings in vm's domain xml. +My Openstack cluster uses the default clock settings as follow: + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> +And in this report, https://bugs.launchpad.net/qemu/+bug/1174654 +it claims that <timer name='rtc' track='guest'/> can solve the 100% cpu usage problem when using Windows Image Guest OS, +but I makes some tests, the solusion dose not work for me. + + +Steps to reproduce +================== +* create a vm using centos or redhat 7.6 image +* using sar tool inside vm and host to check the cpu usage, and compare them + + +Expected result +=============== +host's cpu usage report should be same with vm's cpu usage + + +Actual result +============= +vm's cpu usage is 100% idle, host's cpu usage is 100% busy + + +Environment +=========== +1. Exact version of OpenStack you are running. +# rpm -qa | grep nova +openstack-nova-compute-13.1.2-1.el7.noarch +python2-novaclient-3.3.2-1.el7.noarch +python-nova-13.1.2-1.el7.noarch +openstack-nova-common-13.1.2-1.el7.noarch + +2. Which hypervisor did you use? + (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) + What's the version of that? +# libvirtd -V +libvirtd (libvirt) 3.9.0 + +# /usr/libexec/qemu-kvm --version +QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 2003-2008 Fabrice Bellard + + +Logs & Configs +============== +The VM xml: +<domain type='kvm' id='29'> + <name>instance-00005022</name> + <uuid>7f5a66a5-****-****-****-75dec****bbb</uuid> + <metadata> + <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> + <nova:package version="13.1.2-1.el7"/> + <nova:name>*******</nova:name> + <nova:creationTime>2019-05-20 03:08:46</nova:creationTime> + <nova:flavor name="2d2dab36-****-****-****-246e9****110"> + <nova:memory>2048</nova:memory> + <nova:disk>12</nova:disk> + <nova:swap>2048</nova:swap> + <nova:ephemeral>0</nova:ephemeral> + <nova:vcpus>1</nova:vcpus> + </nova:flavor> + <nova:owner> + <nova:user uuid="********************">****</nova:user> + <nova:project uuid="********************">****</nova:project> + </nova:owner> + <nova:root type="image" uuid="4496a420-****-****-****-b50f****ada3"/> + </nova:instance> + </metadata> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>1</vcpu> + <cputune> + <shares>1024</shares> + <vcpupin vcpu='0' cpuset='27'/> + <emulatorpin cpuset='27'/> + </cputune> + <numatune> + <memory mode='strict' nodeset='1'/> + <memnode cellid='0' mode='strict' nodeset='1'/> + </numatune> + <resource> + <partition>/machine</partition> + </resource> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>Fedora Project</entry> + <entry name='product'>OpenStack Nova</entry> + <entry name='version'>13.1.2-1.el7</entry> + <entry name='serial'>64ab0e89-****-****-****-05312ef66983</entry> + <entry name='uuid'>7f5a66a5-****-****-****-75decaf82bbb</entry> + <entry name='family'>Virtual Machine</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-rhel7.3.0'>hvm</type> + <boot dev='hd'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>IvyBridge</model> + <topology sockets='1' cores='1' threads='1'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + <feature policy='require' name='xsaveopt'/> + <numa> + <cell id='0' cpus='0' memory='2097152' unit='KiB'/> + </numa> + </cpu> + <clock offset='utc'> + <timer name='pit' tickpolicy='delay'/> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk.swap'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk.config'/> + <backingStore/> + <target dev='hdd' bus='ide'/> + <readonly/> + <alias name='ide0-1-1'/> + <address type='drive' controller='0' bus='1' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='fa:16:3e:a6:ea:4f'/> + <source bridge='brq52c66dc3-64'/> + <bandwidth> + <inbound average='102400'/> + <outbound average='102400'/> + </bandwidth> + <target dev='tapa29e94e5-42'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='file'> + <source path='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/console.log'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <serial type='pty'> + <source path='/dev/pts/10'/> + <target type='isa-serial' port='1'> + <model name='isa-serial'/> + </target> + <alias name='serial1'/> + </serial> + <console type='file'> + <source path='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/console.log'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5910' autoport='yes' listen='0.0.0.0' keymap='en-us'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <stats period='10'/> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> + +CPU Usage Report inside VM: +# sar -u -P 0 1 5 +Linux 3.10.0-957.el7.x86_64 (******) 05/20/2019 _x86_64_ (1 CPU) + +11:34:40 AM CPU %user %nice %system %iowait %steal %idle +11:34:41 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:42 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:43 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:44 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:45 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +Average: 0 0.00 0.00 0.00 0.00 0.00 100.00 + +CPU Usage Report ON HOST(the vm's cpu is pinned on host's no.27 physic cpu): +# sar -u -P 27 1 5 +Linux 3.10.0-862.el7.x86_64 (******) 05/20/2019 _x86_64_ (48 CPU) + +11:34:40 AM CPU %user %nice %system %iowait %steal %idle +11:34:41 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:42 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:43 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:44 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:45 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +Average: 27 100.00 0.00 0.00 0.00 0.00 0.00 + +clocksource inside VM: +# cat /sys/devices/system/clocksource/clocksource0/current_clocksource +kvm_clock + +It shows that only the version 7.6 of redhat or centos affected by this bug, +in my cluster, it is OK for versions from 6.8 to 7.5, but 7.6 is not normal. + +> # libvirtd -V +> libvirtd (libvirt) 3.9.0 +> +> # /usr/libexec/qemu-kvm --version +> QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 2003-2008 Fabrice Bellard + +This looks like the host is running CentOS, with packages dating from approx 7.3. This is very outdated given current version is 7.6. So I don't think it is worth spending time to debug until the host OS is upgraded to the latest QEMU/libvirt/kernel packages at least to see if the problem still reproduces. + + +I tested two newest QEMU versions these days, and sadly, the problem still happens. + +I tried to find the reason why the qemu process take 100% usage of cpu, and collected some facts about it. +I compared the facts with other normal vm's qemu process(who's cpu usage is normal) and didn't turn out any interesting result. + +Please give me some guides to debug this problem if you could, thanks very much. + + + +(The full content of facts is in the attachment) +1. +======the command line to start a VM====== +# ps -ef |grep 1567284 | cat +qemu 1567284 1 99 Jun21 ? 2-18:09:33 /usr/libexec/qemu-kvm -name guest=instance-0000530a,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-0000530a/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-ram,id=ram-node0,size=2147483648,host-nodes=1,policy=bind -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 60d3ad85-1004-47e7-b2cb-5cf1a029ab47 -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=13.1.2-1.el7,serial=c0700413-4a28-4e97-85c4-66fe3ec367dc,uuid=60d3ad85-1004-47e7-b2cb-5cf1a029ab47,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-0000530a/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk.swap,format=raw,if=none,id=drive-virtio-disk1,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk.config,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:21:2c:70,bus=pci.0,addr=0x3 -add-fd set=2,fd=31 -chardev file,id=charserial0,path=/dev/fdset/2,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +root 1567288 2 0 Jun21 ? 00:00:01 [vhost-1567284] +root 1567291 2 0 Jun21 ? 00:00:00 [kvm-pit/1567284] + +2. +===version of QEMU=== +# /usr/libexec/qemu-kvm --version +QEMU emulator version 4.0.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +===version of libvirt=== +# libvirtd -V +libvirtd (libvirt) 3.9.0 + +===version of kernal=== +# uname -a +Linux txyz_40_92 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux +Red Hat Enterprise Linux Server (3.10.0-862.el7.x86_64) 7.5 (Maipo) +# modinfo kvm +filename: /lib/modules/3.10.0-862.el7.x86_64/kernel/arch/x86/kvm/kvm.ko.xz +license: GPL +author: Qumranet +retpoline: Y +rhelversion: 7.5 +srcversion: 8A3372406CDF0ACF69A0E58 +depends: irqbypass +intree: Y +vermagic: 3.10.0-862.el7.x86_64 SMP mod_unload modversions +signer: Red Hat Enterprise Linux kernel signing key +sig_key: 51:73:02:3B:F8:16:37:D7:BF:3C:51:50:13:4E:EC:84:1B:96:FD:0B +sig_hashalgo: sha256 +parm: ignore_msrs:bool +parm: min_timer_period_us:uint +parm: kvmclock_periodic_sync:bool +parm: tsc_tolerance_ppm:uint +parm: lapic_timer_advance_ns:uint +parm: vector_hashing:bool +parm: halt_poll_ns:uint +parm: halt_poll_ns_grow:uint +parm: halt_poll_ns_shrink:uint + +3. +===threads=== +# ps -Lp 1567284 + PID LWP TTY TIME CMD +1567284 1567284 ? 00:00:12 qemu-kvm +1567284 1567286 ? 00:00:00 call_rcu +1567284 1567289 ? 00:00:00 IO mon_iothread +1567284 1567290 ? 2-19:07:09 CPU 0/KVM +1567284 1567293 ? 00:00:00 vnc_worker +1567284 1637413 ? 00:00:00 worker + +===top=== +# top -H -p 1567284 +top - 13:02:07 up 164 days, 21:53, 2 users, load average: 1.00, 1.01, 1.05 +Threads: 6 total, 1 running, 5 sleeping, 0 stopped, 0 zombie +%Cpu(s): 2.1 us, 0.0 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem : 26353241+total, 25289752+free, 2771140 used, 7863752 buff/cache +KiB Swap: 8388604 total, 8388604 free, 0 used. 25926534+avail Mem + scroll coordinates: y = 1/6 (tasks), x = 1/12 (fields) + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +1567290 qemu 20 0 6683072 647416 8336 R 99.7 0.2 4028:04 CPU 0/KVM +1567284 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:12.93 qemu-kvm +1567286 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 call_rcu +1567289 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 IO mon_iothread +1567293 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.27 vnc_worker +1637464 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 worker + +===htop=== +.... + +===vmstat on the host=== +# vmstat 1 5 +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 2 0 0 252897184 366768 7497768 0 0 0 0 0 0 0 0 100 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1394 367 2 0 98 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1442 387 2 0 98 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1479 470 2 0 98 0 0 + 1 0 0 252896752 366776 7497768 0 0 0 12 1373 371 2 0 98 0 0 + +===vmstat on the VM=== +# vmstat 1 5 +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 1 0 0 1490564 81708 238688 0 0 1 2 14 30 0 0 99 1 0 + 0 0 0 1490564 81708 238688 0 0 0 0 29 55 0 0 100 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 26 56 0 0 100 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 17 31 0 0 99 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 19 41 0 0 100 0 0 + +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/review/1829964 b/results/classifier/118/review/1829964 new file mode 100644 index 000000000..87bbf4cdb --- /dev/null +++ b/results/classifier/118/review/1829964 @@ -0,0 +1,148 @@ +semantic: 0.922 +graphic: 0.892 +mistranslation: 0.887 +risc-v: 0.880 +user-level: 0.876 +register: 0.875 +device: 0.874 +assembly: 0.865 +PID: 0.861 +performance: 0.859 +permissions: 0.858 +virtual: 0.852 +boot: 0.845 +hypervisor: 0.842 +arm: 0.837 +architecture: 0.835 +x86: 0.824 +peripherals: 0.821 +files: 0.809 +ppc: 0.796 +debug: 0.789 +VMM: 0.751 +KVM: 0.749 +TCG: 0.740 +network: 0.736 +socket: 0.691 +vnc: 0.597 +kernel: 0.588 +i386: 0.324 +-------------------- +x86: 0.975 +virtual: 0.799 +hypervisor: 0.653 +performance: 0.070 +graphic: 0.018 +files: 0.016 +debug: 0.007 +user-level: 0.006 +KVM: 0.005 +device: 0.004 +kernel: 0.003 +register: 0.003 +risc-v: 0.003 +TCG: 0.003 +PID: 0.003 +VMM: 0.003 +network: 0.003 +vnc: 0.003 +socket: 0.002 +peripherals: 0.002 +permissions: 0.002 +arm: 0.002 +semantic: 0.002 +architecture: 0.002 +i386: 0.002 +boot: 0.002 +assembly: 0.002 +ppc: 0.002 +mistranslation: 0.001 + +HOST VRAM Leak when performs android-x86 window rotation with Virt-GPU + +I will report something strange thing about host VRAM leakage after anroid-x86 window rotation when it runs with virt-gpu(+ virgl-renderer) + +Please watching below video link. + +https://www.youtube.com/watch?v=mJIbGZLWF1s&feature=youtu.be + +(orginal video file : https://drive.google.com/file/d/1lkdTx_8yTbSVjKXlnxnnk96fWe-w6Mxb/view?usp=sharing) + +I don't sure what is the problem... + +Here are my tested history +-------------------------------------------------------------------------------------------------- +Install android-x86 on I7 desktop PCs with intel UHD GPU - No leak. +Install android-x86 on I7 desktop PCs with NVIDIA GTX GPU series - No leak. +Install android-x86 on guest machine emulated skylake cpu with QEMU(+virt-gpu, virgl-renderer) - Leak +(HOST CPU - I5, INTEL UHD GPU) +Install android-x86 on guest machine emulated skylake cpu with QEMU(+virt-gpu, virgl-renderer) - Leak +(HOST CPU - I7, NVIDIA GTX GPU) + +COMMON: +In case of NVIDIA GPU : check vram using nvidia-smi +In case of intel UHD GPU : check shared-vram using free cmd + +We checked guest android-x86 system down when vram is full after performing many rotation +------------------------------------------------------------------------------------------- + +Is it virt-gpu driver's problem? + +I hope someone can help me... + +Thanks in advance!! + +Here are qemu options I used... + +-machine type=q35,accel=kvm -cpu host --enable-kvm \ +-smp cpus=4,cores=4,threads=1 -m 4096 \ +-drive file=ctb0319.qcow2,format=qcow2,if=virtio,aio=threads \ +-device virtio-vga,virgl=on \ +-device qemu-xhci,id=xhci -device usb-mouse,bus=xhci.0 -device usb-kbd,bus=xhci.0 \ +-soundhw hda -display sdl,gl=on -netdev user,id=qemunet0,hostfwd=tcp::4000-:7000,hostfwd=tcp::5555-:5555,hostfwd=tcp::4012-:7012,hostfwd=tcp::4013-:7013 -device virtio-net,netdev=qemunet0 -boot menu=on + +This is the *upstream* QEMU bug tracker here. If you've got a problem with the android emulator, please report these problems to the android emulator project instead. Thanks. + +To Thomas Huth, + +This is not android problem, qemu or virt-gpu problem,. +-------------------- our test log -------------------------------------- +Running android-x86 on I7 bare metal desktop PCs with intel UHD GPU - No leak. +Running android-x86 on QEMU(+virt-gpu, virgl-renderer) - Leak +------------------------------------------------------------------------ + +Also in case of a guest linux, it also have leak after windows manager rotation. + +Ok, sorry, got that wrong - we sometimes get bug reports about the android emulator (which is a fork of QEMU) here, and at a first glance, your bug report looked like one of these misguided bug tickets, too. + +Anyway, please provide some more information: Which version of QEMU are you using? Which operating system are you running in QEMU? + +I tested many qemu & linux versions.... + +in case of qemu, +2.12 +3.10 +3.12 +4.0.0 +All versions I tested have same problem.... + +also I tested many versions of linux +ubuntu 18.04 18.10 +centos 7 +fedora 18 19 +rhel + +Actually it is not only problem of windows rotation, if home launcher refreshed, vram usage is also up... + +I think it related gl related functions... + +so I don't sure it is qemu-virt-gpu problem or virt-gpu driver... + +That is why I already report this problem to android-x86 devel forum and author of virt-gpu drvier... + + + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1830864 b/results/classifier/118/review/1830864 new file mode 100644 index 000000000..be04c86ce --- /dev/null +++ b/results/classifier/118/review/1830864 @@ -0,0 +1,148 @@ +user-level: 0.819 +register: 0.794 +virtual: 0.777 +performance: 0.754 +hypervisor: 0.749 +arm: 0.747 +boot: 0.738 +device: 0.735 +permissions: 0.728 +semantic: 0.721 +peripherals: 0.702 +mistranslation: 0.697 +ppc: 0.684 +architecture: 0.683 +assembly: 0.672 +graphic: 0.663 +vnc: 0.660 +x86: 0.659 +TCG: 0.646 +KVM: 0.644 +debug: 0.642 +risc-v: 0.639 +socket: 0.623 +PID: 0.612 +kernel: 0.602 +VMM: 0.601 +network: 0.595 +files: 0.555 +i386: 0.551 +-------------------- +arm: 0.998 +virtual: 0.882 +hypervisor: 0.859 +debug: 0.822 +KVM: 0.752 +kernel: 0.347 +architecture: 0.214 +performance: 0.183 +socket: 0.135 +register: 0.078 +TCG: 0.071 +PID: 0.069 +files: 0.058 +device: 0.031 +user-level: 0.028 +semantic: 0.020 +boot: 0.019 +VMM: 0.017 +assembly: 0.010 +permissions: 0.006 +risc-v: 0.006 +peripherals: 0.004 +network: 0.003 +graphic: 0.002 +mistranslation: 0.001 +vnc: 0.001 +i386: 0.000 +x86: 0.000 +ppc: 0.000 + +Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(&cpu_->isar); })' failed + +The following assertion: + + assert(no_aa32 || cpu_isar_feature(arm_div, cpu)); + +introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some +asserts on aarch32 support", 2018-11-02), fails for me. I intended to +launch a 32-bit ARM guest (with KVM acceleration) on my AArch64 host +(APM Mustang A3). + +Libvirt generated the following QEMU command line: + +> LC_ALL=C \ +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +> QEMU_AUDIO_DRV=none \ +> /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \ +> -name guest=f28.32bit,debug-threads=on \ +> -S \ +> -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-f28.32bit/master-key.aes \ +> -machine virt-4.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \ +> -cpu host,aarch64=off \ +> -drive file=/root/QEMU_EFI.fd.padded,if=pflash,format=raw,unit=0,readonly=on \ +> -drive file=/var/lib/libvirt/qemu/nvram/f28.32bit_VARS.fd,if=pflash,format=raw,unit=1 \ +> -m 8192 \ +> -realtime mlock=off \ +> -smp 8,sockets=8,cores=1,threads=1 \ +> -uuid d525042e-1b37-4058-86ca-c6a2086e8485 \ +> -no-user-config \ +> -nodefaults \ +> -chardev socket,id=charmonitor,fd=27,server,nowait \ +> -mon chardev=charmonitor,id=monitor,mode=control \ +> -rtc base=utc \ +> -no-shutdown \ +> -boot strict=on \ +> -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +> -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ +> -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ +> -device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \ +> -device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \ +> -device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \ +> -device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \ +> -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x0 \ +> -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +> -drive file=/var/lib/libvirt/images/f28.32bit.root.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on \ +> -drive file=/var/lib/libvirt/images/f28.32bit.home.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,werror=enospc,cache=writeback,discard=unmap \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,write-cache=on \ +> -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 \ +> -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:d1:c8,bus=pci.4,addr=0x0,romfile= \ +> -chardev pty,id=charserial0 \ +> -serial chardev:charserial0 \ +> -chardev socket,id=charchannel0,fd=31,server,nowait \ +> -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +> -device usb-tablet,id=input0,bus=usb.0,port=1 \ +> -device usb-kbd,id=input1,bus=usb.0,port=2 \ +> -vnc 127.0.0.1:0 \ +> -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.5,addr=0x0 \ +> -object rng-random,id=objrng0,filename=/dev/urandom \ +> -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.6,addr=0x0 \ +> -msg timestamp=on + +and then I got: + +> qemu-system-aarch64: /root/src/upstream/qemu/target/arm/cpu.c:986: +> arm_cpu_realizefn: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); +> isar_feature_arm_div(&cpu_->isar); })' failed. + +QEMU was built at commit 8dc7fd56dd4f ("Merge remote-tracking branch +'remotes/philmd-gitlab/tags/fw_cfg-20190523-pull-request' into staging", +2019-05-23). + +(Originally reported on the mailing list in the following thread: +<http://<email address hidden>>.) + +This happens because: + * the host kernel is older than 4.15 and does not expose ID registers to userspace via the KVM_GET_ONE_REG ioctl + * our fallback set of ID register values in target/arm/kvm64.c kvm_arm_get_host_cpu_features() is extremely minimalist + * the consistency checks on ID register values in arm_cpu_realizefn() are made unconditionally, rather than only if we're using TCG + +https://patchwork.ozlabs.org/patch/1133724/ is a fix for this which takes the approach of only asserting if we're using TCG, since that's really the case we're guarding for problems with and the only one that's a bug in QEMU (as opposed to an issue with the host kernel or host CPU). + + +Fix for this is in git and will be in 4.1.0. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8f4821d77e465bc + diff --git a/results/classifier/118/review/1831225 b/results/classifier/118/review/1831225 new file mode 100644 index 000000000..9e4f72aaf --- /dev/null +++ b/results/classifier/118/review/1831225 @@ -0,0 +1,553 @@ +risc-v: 0.845 +permissions: 0.821 +x86: 0.818 +user-level: 0.816 +hypervisor: 0.811 +register: 0.800 +device: 0.781 +virtual: 0.776 +peripherals: 0.771 +graphic: 0.770 +vnc: 0.769 +debug: 0.767 +ppc: 0.767 +performance: 0.765 +kernel: 0.757 +files: 0.742 +arm: 0.740 +mistranslation: 0.738 +VMM: 0.738 +assembly: 0.729 +socket: 0.723 +semantic: 0.720 +boot: 0.719 +KVM: 0.712 +TCG: 0.708 +architecture: 0.705 +PID: 0.704 +network: 0.607 +i386: 0.600 +-------------------- +debug: 0.988 +virtual: 0.920 +KVM: 0.920 +kernel: 0.813 +x86: 0.459 +performance: 0.156 +hypervisor: 0.102 +assembly: 0.068 +i386: 0.027 +files: 0.022 +PID: 0.016 +user-level: 0.010 +VMM: 0.006 +register: 0.006 +ppc: 0.006 +TCG: 0.005 +semantic: 0.003 +architecture: 0.003 +device: 0.002 +arm: 0.002 +network: 0.001 +socket: 0.001 +risc-v: 0.001 +graphic: 0.001 +boot: 0.001 +permissions: 0.001 +vnc: 0.001 +peripherals: 0.001 +mistranslation: 0.000 + +guest migration 100% cpu freeze bug + +# Investigate migration cpu hog(100%) bug + +I have some issues when migrating from kernel 4.14.63 running qemu 2.11.2 to kernel 4.19.43 running qemu 2.11.2. +The hypervisors are running on debian jessie with libvirt v5.3.0. +Linux, libvirt and qemu are all custom compiled. + +I migrated around 10.000 vms and every once in a while a vm is stuck at 100% cpu after what we can see right now is that the target hypervisor runs on linux 4.19.53. This happened with 4 vms so far. It is not that easy to debug, we found this out pretty quickly because we are running monitoring on frozen vms after migrations. + +Last year we were having the same "kind of" bug https://bugs.launchpad.net/qemu/+bug/1775555 when trying to upgrade qemu 2.6 to 2.11. +This bug was fixed after applying the following patch: http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg00820.html + +This patch is still applied as you can see because of the available pre_load var on the kvmclock_vmsd struct: +(gdb) ptype kvmclock_vmsd +type = const struct VMStateDescription { + const char *name; + int unmigratable; + int version_id; + int minimum_version_id; + int minimum_version_id_old; + MigrationPriority priority; + LoadStateHandler *load_state_old; + int (*pre_load)(void *); + int (*post_load)(void *, int); + int (*pre_save)(void *); + _Bool (*needed)(void *); + VMStateField *fields; + const VMStateDescription **subsections; +} + +I attached gdb to a vcpu thread of one stuck vm, and a bt showed the following info: +Thread 4 (Thread 0x7f3a431a4700 (LWP 37799)): +#0 0x00007f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84 +#1 0x000055d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fca78d0, type=type@entry=44672) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050 +#2 0x000055d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fca78d0) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887 +#3 0x000055d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fca78d0) at /home/dbosschieter/src/qemu-pkg/src/cpus.c:1136 +#4 0x00007f3a579ba4a4 in start_thread (arg=0x7f3a431a4700) at pthread_create.c:456 +#5 0x00007f3a576fcd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +Thread 3 (Thread 0x7f3a439a5700 (LWP 37798)): +#0 0x00007f3a576f5017 in ioctl () at ../sysdeps/unix/syscall-template.S:84 +#1 0x000055d84d15de57 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55d84fc5cbb0, type=type@entry=44672) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:2050 +#2 0x000055d84d15dfc6 in kvm_cpu_exec (cpu=cpu@entry=0x55d84fc5cbb0) at /home/dbosschieter/src/qemu-pkg/src/accel/kvm/kvm-all.c:1887 +#3 0x000055d84d13ab64 in qemu_kvm_cpu_thread_fn (arg=0x55d84fc5cbb0) at /home/dbosschieter/src/qemu-pkg/src/cpus.c:1136 +#4 0x00007f3a579ba4a4 in start_thread (arg=0x7f3a439a5700) at pthread_create.c:456 +#5 0x00007f3a576fcd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 + +The ioctl call is a ioctl(18, KVM_RUN and it looks like it is looping inside the vm itself. + +I saved the state of the VM (with `virsh save`) after I found it was hanging on its vcpu threads. Then I restored this vm on a test environment running the same kernel, QEMU and libvirt version). After the restore the VM still was haning at 100% cpu usage on all the vcpus. +I tried to use the perf kvm guest option to trace the guest vm with a copy of the kernel, modules and kallsyms files from inside the guest vm and I got to the following perf stat: + + Event Total %Total CurAvg/s + kvm_entry 5198993 23.1 277007 + kvm_exit 5198976 23.1 277006 + kvm_apic 1732103 7.7 92289 + kvm_msr 1732101 7.7 92289 + kvm_inj_virq 1731904 7.7 92278 + kvm_eoi 1731900 7.7 92278 + kvm_apic_accept_irq 1731900 7.7 92278 + kvm_hv_timer_state 1731780 7.7 92274 + kvm_pv_eoi 1731701 7.7 92267 + kvm_ple_window 36 0.0 2 + Total 22521394 1199967 + +We tried to run the crash tool against a dump of guest vm memory and that gave us the following backtrace: +crash> bt +PID: 0 TASK: ffffffff81610040 CPU: 0 COMMAND: "swapper/0" + [exception RIP: native_read_tsc+2] + RIP: ffffffff810146a9 RSP: ffff88003fc03df0 RFLAGS: 00000046 + RAX: 000000008762c0fa RBX: ffff88003fc13680 RCX: 0000000000000001 + RDX: 0000000000fe4871 RSI: 0000000000000000 RDI: ffff88003fc13603 + RBP: 000000000003052c R8: 0000000000000200 R9: ffffffff8169b180 + R10: 0000000000000020 R11: 0000000000000005 R12: 006a33290b40455c + R13: 00000000df1fd292 R14: 000000002ca284ff R15: 00fe485f3febe21a + CS: 0010 SS: 0018 + #0 [ffff88003fc03df0] pvclock_clocksource_read at ffffffff8102cbb3 + #1 [ffff88003fc03e40] kvm_clock_read at ffffffff8102c2c9 + #2 [ffff88003fc03e50] timekeeping_get_ns at ffffffff810691b0 + #3 [ffff88003fc03e60] ktime_get at ffffffff810695c8 + #4 [ffff88003fc03e90] sched_rt_period_timer at ffffffff8103e4f5 + #5 [ffff88003fc03ee0] __run_hrtimer at ffffffff810652d3 + #6 [ffff88003fc03f20] hrtimer_interrupt at ffffffff81065abd + #7 [ffff88003fc03f90] smp_apic_timer_interrupt at ffffffff81024ba8 + #8 [ffff88003fc03fb0] apic_timer_interrupt at ffffffff813587e2 +--- <IRQ stack> --- + #9 [ffffffff81601e98] apic_timer_interrupt at ffffffff813587e2 + [exception RIP: native_safe_halt+2] + RIP: ffffffff8102c360 RSP: ffffffff81601f40 RFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffffffff81601fd8 RCX: 00000000ffffffff + RDX: 00000000ffffffff RSI: 0000000000000000 RDI: 0000000000000001 + RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000000 + R10: 0000000000000020 R11: 0000000000000005 R12: ffffffff816f5d80 + R13: ffffffffffffffff R14: 000000000008c800 R15: 0000000000000000 + ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018 +#10 [ffffffff81601f40] default_idle at ffffffff81014c35 +#11 [ffffffff81601f50] cpu_idle at ffffffff8100d258 + +So it seems like the vm is reading its clock constantly trying to catch up some time after the migration. + +Last time it was a bug that was only triggered on newer Gold cpu hardware, but this time we also see this coming back on older Intel E5 cpus we tried to reproduce with a migrate loop of 3 days times between kernel 4.14.63 and 4.19.43 but this gave us no results. + +The vms were running ubuntu 14.04, centos 7, debian 7, debian 8 these vms are running linux kernel 3.*. + +The thing is that we are out of ideas for reproducing this, it seems like it the same kind of bug we are hitting, just like last time the vm is basically only trying to read the clock. Perhaps we can try to read the clock data and also try to read what the guest is actually waiting for, which value of the counter does it want to reach. + +I am not sure how to pinpoint the cause of this issue, I would like some help and possible some extra tips on debugging. +We are able to read the guests kernel which makes it a bit easier to debug, reproducing and finding the source of the problem is still something we are trying to figure out. + +A virsh dumpxml of one of the guests: + +<domain type='kvm' id='15'> + <name>vps12</name> + <uuid>xxxxxxxx-953c-d629-1276-00000616xxxx</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <numatune> + <memory mode='interleave' nodeset='0-1'/> + </numatune> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> + <boot dev='hd'/> + <boot dev='network'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Westmere</model> + <topology sockets='1' cores='2' threads='1'/> + <feature policy='require' name='vme'/> + <feature policy='require' name='pclmuldq'/> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + </cpu> + <clock offset='utc'> + <timer name='hpet' present='yes'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/var/local/mnt/vps/vps12/vps12.raw'/> + <backingStore/> + <target dev='hda' bus='virtio'/> + <iotune> + <read_bytes_sec>734003200</read_bytes_sec> + <write_bytes_sec>576716800</write_bytes_sec> + <read_iops_sec>3500</read_iops_sec> + <write_iops_sec>2500</write_iops_sec> + </iotune> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <interface type='bridge'> + <mac address='xx:xx:xx:xx:xx:xx'/> + <source bridge='brxx'/> + <target dev='vxxxx'/> + <model type='virtio'/> + <filterref filter='firewall-vps12'/> + <link state='up'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'> + <alias name='input0'/> + </input> + <input type='tablet' bus='usb'> + <alias name='input1'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <sound model='es1370'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+997:+998</label> + <imagelabel>+997:+998</imagelabel> + </seclabel> +</domain> + + +Hi Dion, + Since you've got a crash dump, can you check the dmesg in the guest to see if there's any messages? + + +Hi Alan, + + +Dmesg shows nothing special: +[29891577.708544] IPv6 addrconf: prefix with wrong length 48 +[29891580.650637] IPv6 addrconf: prefix with wrong length 48 +[29891582.013656] IPv6 addrconf: prefix with wrong length 48 +[29891583.753246] IPv6 addrconf: prefix with wrong length 48 +[29891585.397941] IPv6 addrconf: prefix with wrong length 48 +[29891587.031141] IPv6 addrconf: prefix with wrong length 48 +[29891588.991541] IPv6 addrconf: prefix with wrong length 48 +[29891590.162395] IPv6 addrconf: prefix with wrong length 48 +[29891592.681133] IPv6 addrconf: prefix with wrong length 48 +[29891593.418342] IPv6 addrconf: prefix with wrong length 48 +[29891596.491791] IPv6 addrconf: prefix with wrong length 48 +[29891597.262282] IPv6 addrconf: prefix with wrong length 48 +[29891600.116510] IPv6 addrconf: prefix with wrong length 48 +[29891600.987599] IPv6 addrconf: prefix with wrong length 48 +[29891603.954923] IPv6 addrconf: prefix with wrong length 48 +[29891604.554989] IPv6 addrconf: prefix with wrong length 48 +[29891607.641694] IPv6 addrconf: prefix with wrong length 48 +[29891607.855495] IPv6 addrconf: prefix with wrong length 48 +[29891611.128803] IPv6 addrconf: prefix with wrong length 48 +[29891611.293230] IPv6 addrconf: prefix with wrong length 48 +[29891615.011260] IPv6 addrconf: prefix with wrong length 48 +[29891615.182883] IPv6 addrconf: prefix with wrong length 48 +[29891618.577801] IPv6 addrconf: prefix with wrong length 48 +[29891619.146512] IPv6 addrconf: prefix with wrong length 48 +[29891622.250595] IPv6 addrconf: prefix with wrong length 48 +[29891623.051844] IPv6 addrconf: prefix with wrong length 48 +[29891625.642684] IPv6 addrconf: prefix with wrong length 48 +[29891626.457455] IPv6 addrconf: prefix with wrong length 48 + +Crash shows me the uptime though which doesn't seem right: + DATE: Tue Nov 29 18:55:46 2603 + UPTIME: 106751 days, 23:55:03 +Not sure if this is related to the amount of kvm clock calls. + +Interesting; I'd seen something similar - in rh https://bugzilla.redhat.com/show_bug.cgi?id=1538078 +and as well as the bogus date we'd had lots of log messages of the form: + + CE: lapic increasing min_delta_ns to <very big number> nsec + + +we were reckoning the clock jumped a bit during the migrate, and then triggered an old guest kernel bug, https://bugzilla.redhat.com/show_bug.cgi?id=1183773 - and we'd only ever triggered it on older distros (rhel6 etc), and think we backported two newer kernel patches: + +commit 80a05b9ffa7dc13f6693902dd8999a2b61a3a0d7 +Author: Thomas Gleixner <email address hidden> +Date: Fri Mar 12 17:34:14 2010 +0100 + + clockevents: Sanitize min_delta_ns adjustment and prevent overflows + +and: +commit d1748302f70be7469809809283fe164156a34231 +Author: Martin Schwidefsky <email address hidden> +Date: Tue Aug 23 15:29:42 2011 +0200 + + clockevents: Make minimum delay adjustments configurable + +but if you're getting that symptom on a RHEL7 / newer than 2011 kernel then I'm worried that there's another case. + +This was a very difficult to reproduce last time I looked at the rh bz's above - the slightest change anywhere and it would go away. + + +Is there a way that we can check that it indeed is the case that the clock jumped a bit, we can try to read some kernel variables. +We just got another hung guest's crash dump working, this vm also shows a weird uptime + DATE: Fri Dec 23 09:06:16 2603 + UPTIME: 106752 days, 00:10:35 + +Till now we have only see this happening on guests with linux kernel 3.*. + +Again dmesg shows nothing. + +The only way this has yet happened was when the target hypervisor kernel was 4.19. +So it seems that something changed over there, the only thing is it not quite a small diff ;) between 4.14 and 4.19. And because it only happens once every couple of thousand migrations with unknown conditions makes it a hard to bisect this. +Source hypervisor kernel could be 4.14 and 4.19. + +If the clock did jump during the migration, is there something that we could do about that on source/target hypervisor, with a libvirt xml change, etc, to prevent it I mean. + +It seems like the patch is applied to the guests source kernel. + +crash> clock_event_device +struct clock_event_device { + void (*event_handler)(struct clock_event_device *); + int (*set_next_event)(unsigned long, struct clock_event_device *); + int (*set_next_ktime)(ktime_t, struct clock_event_device *); + ktime_t next_event; + u64 max_delta_ns; + u64 min_delta_ns; + u32 mult; + u32 shift; + enum clock_event_mode mode; + unsigned int features; + unsigned long retries; + void (*broadcast)(const struct cpumask *); + void (*set_mode)(enum clock_event_mode, struct clock_event_device *); + void (*suspend)(struct clock_event_device *); + void (*resume)(struct clock_event_device *); + unsigned long min_delta_ticks; + unsigned long max_delta_ticks; + const char *name; + int rating; + int irq; + const struct cpumask *cpumask; + struct list_head list; + struct module *owner; +} +SIZE: 0xc0 +crash> clockevents_program_min_delta +clockevents_program_min_delta = $2 = + {int (struct clock_event_device *)} 0xffffffff810daa20 <clockevents_program_min_delta> + + +You say it's only happened since 4.19 - that's possible - but since this bug is so tricky to trigger it's also possible that any slight change in 4.19. + +You could try disabling kvm_clock? + +Dave + +Hi, + +i suffer fro this bug too (or very similar) on 4.15.0-50-generic, without the patch mentionned earlier (i use this patch last year to migrate from previous qemu version). + +Jean-Philippe + +Hi Jean, + +Could you elaborate, is it the qemu patch that you applied and didn't apply that to the current qem u version you are running? + +Could you try to get a crash dump from a frozen vm working, see if you get the same kind of backtrace in there. + +Which specific qemu version are you running, which cpu are you migrating from/to, which kernel version are you running from/to? + +Could you dump the xml in this comment section from a defined guest that was frozen? + +Dion + +Hi David, + +I have digged further into our issue and we have seen issues only when migrating from servers that have a different tsc frequency. + +Example: +Source (kernel 4.14.63) +[ 2.068227] tsc: Refined TSC clocksource calibration: 2593.906 MHz +[ 2.068373] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563bf907c6, max_idle_ns: 440795319401 ns +[ 4.908200] clocksource: Switched to clocksource tsc + +Destination (kernel 4.19.43): +[ 0.000000] tsc: Detected 2600.000 MHz processor +[ 3.647553] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x257a3c3232d, max_idle_ns: 440795236700 ns +[ 4.421582] clocksource: Switched to clocksource tsc-early +[ 5.747791] tsc: Refined TSC clocksource calibration: 2593.904 MHz +[ 5.747952] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563bd843df, max_idle_ns: 440795257314 ns +[ 5.748261] clocksource: Switched to clocksource tsc + +Source (kernel 4.19.43): +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2199.852 MHz processor +[ 4.041367] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb5a71147a, max_idle_ns: 440795225528 ns +[ 4.504477] clocksource: Switched to clocksource tsc-early +[ 6.231559] tsc: Refined TSC clocksource calibration: 2200.002 MHz +[ 6.231718] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1fb634b8814, max_idle_ns: 440795202126 ns +[ 6.801999] clocksource: Switched to clocksource tsc + +Destionation (kernel 4.19.43): +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2394.538 MHz processor +[ 5.486287] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x22840fdedc8, max_idle_ns: 440795293830 ns +[ 6.182944] clocksource: Switched to clocksource tsc-early +[ 7.596489] tsc: Refined TSC clocksource calibration: 2394.454 MHz +[ 7.596641] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2283c0783fd, max_idle_ns: 440795301468 ns +[ 9.316929] clocksource: Switched to clocksource tsc + +Source (kernel 4.14.63): +[ 2.068227] tsc: Refined TSC clocksource calibration: 2593.906 MHz +[ 2.068373] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563bf907c6, max_idle_ns: 440795319401 ns +[ 4.908200] clocksource: Switched to clocksource tsc + +Destination (kernel 4.19.43): +[ 0.000000] tsc: Detected 2600.000 MHz processor +[ 3.661033] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x257a3c3232d, max_idle_ns: 440795236700 ns +[ 4.435033] clocksource: Switched to clocksource tsc-early +[ 5.761251] tsc: Refined TSC clocksource calibration: 2593.905 MHz +[ 5.761412] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2563be32fd6, max_idle_ns: 440795226961 ns +[ 5.761731] clocksource: Switched to clocksource tsc + +And what I have seen from reading a bit about time keeping(https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt) and counters and the virtualisation of it, is that it is pretty difficult to get right, so it is already amazing that it goes alright most of the times. + +When diffing I stumbled upon this: https://lore.kernel.org/patchwork/patch/866471/ +And I was thinking about reverting those changes and then try another 10k of migrations see if that makes any difference as we still are not able to reproduce the issue. + +I could also try to prefer migrations from similiar refined TSC clocksource calibration HZes don't, which I would rather not do but I think I understand why having the exact same frequency is prefered, what is your thought on this matter? + +Disabling kvm-clock is not really an option as we don't want to restart and login on all of the running vms. + +Dion + +An update on our further research. We tried bumping the hypervisor kernel form 4.19.43 to 4.19.50 which included the following patch, which we hoped to be related to our issue: + +https://<email address hidden>/#t + +Sadly after a few thousand migrations we encountered two freezes again, and halted further migrations. Again the affected VMs seem to run pre-4.x kernels and all but one freezes occurred with Gold 6126 CPUs. + +While analyzing memory dumps of the VMs with the crash utility we found a peculiar similarity. They all seem to have jumped ~584 years, which led me to this bug report from 2011: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/805341 . Does this provide any insight into what the issue might be on host-level? + +It is very well possible that the issue lies in the guest kernel, but as the service we provide is unmanaged we have no control over it. + +Could you try running the guests without the TSC_DEADLINE CPUID flag set? + +This round we built 4.19.55, disabled the kvm_intel.preemption_timer parameter and ensured kvm.lapic_timer_advance_ns is 0, as advised by Paolo Bonzini. Sadly, yet again we encountered a freeze. + +Any other suggestions? + +Hi, this is an update after some extended tests and a fallback migration to 4.14. + +After doing another >10k migrations we are sure to say that we also encounter this issue on kernel 4.14. +We migrate vpses from servers in serial (one after the other) mode. And we notice that on some servers we encounter multiple freezes within a short period. These cases often occur in succession from the same source hypervisor, which for most (if not all) we've seen has a Gold CPU. So it seems like we are facing the same issue we were facing before in https://bugs.launchpad.net/qemu/+bug/1775555 + +The thing is though, we applied the patches that supposedly "fixed" it last time, except that right now it seems like the issue is still there and that after applying the previous patch we are still having issues running on the same kernel with the same qemu version (v2.11.2). + +Are there any other changes lately that could perhaps have fixed it which are worth trying? +We noticed that some pre migration checks were added to libvirt which would let the migration go into error if there are any severe mismatches between 2 hypervisor (hardware/kernel) configurations. + +We could try to run that and see if these throw more errors which could point us into some direction, is this something that you would recommend? + + +We have found a vm that recovered from a freeze and it seems like it has jumped in time. +Below I have pasted a dump of tty1, it is ocr'd though so some characters could have been misinterpreted. + +hild +[13198552.767867] le-rss:010 Killed process 10374 (crop) total,r,4376400, anon-rss,018, tl [13230065.246354] lid Out of memory: Kill process 2009 Icron) score 1 or sacrifice c [13230065.251227] le-rss:OkB Killed process 19050 (cron) total-am:437040B, anon-r=0,42, fi [13230065.378536] Out of memory: Kill process 2003 (cron) score 1 or sacrifice 1132 Killed process 19622 Icron) total-vM:4376400, anon-rss:018, fi +le-rss:OkB +[14071563.261117] Out of memory: Kill process 2083 (cron) score 1 or sacrifice child +[14071563.263500] Killed process 20260 (cron) total-vM:4376400, anon-rss:000, fi le-rss:OkB +[9223372037.903009] BUG: soft lockup - CPU#0 stuck for 4281394478s! [screen:4843] +[9223372037.983809] Stack: +[9223372037.983809] +[9223372037.903009] Call Trace: +[9223372037.983809] <IRQ> +[922337203].983809] <EOI> Code: 83 c4 58 5b 5d c9 90 90 to Of al 9e 19 c0 c9 9c 50 66 .6 90 66 90 c9 57 9E .6 90 c9 f0 BO 67 00 66 66 90 66 90 fd c9 40 c7 07 c9 fa 66 00 00 00 66 90 00 40 66 66 c7 47 90 c9 fb 66 66 90 00 066: + +This is VM is running Debian 7, it was approximately frozen for around 2 hours and 25 minutes before spinning back into action. + +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. + +Hi Thomas, + +We are still seeing this every once in a while. I can definitely tell you that it is connected to older Linux Guest kernels and we have not been able to identify a specific version which would make searching for a fix commit a bit easier. + +We are going to upgrade all our host kernels to 5.4 after which we will upgrade to a newer version of QEMU, temporarily working around this issue by selecting a specific set of hardware for migrations of older guest kernels. + +As time goes by the issue becomes less important as there will be less 3.* linux guest kernels running on our platform, but at the time of writing this is a significant amount. + +The guest kernels that we came across already had this patch applied: https://bugzilla.redhat.com/show_bug.cgi?id=1183773 + + +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/223 + + diff --git a/results/classifier/118/review/1833053 b/results/classifier/118/review/1833053 new file mode 100644 index 000000000..158b5801f --- /dev/null +++ b/results/classifier/118/review/1833053 @@ -0,0 +1,113 @@ +user-level: 0.909 +hypervisor: 0.901 +mistranslation: 0.872 +peripherals: 0.868 +VMM: 0.850 +KVM: 0.841 +vnc: 0.840 +ppc: 0.832 +TCG: 0.830 +x86: 0.829 +risc-v: 0.811 +virtual: 0.808 +permissions: 0.801 +boot: 0.799 +arm: 0.794 +device: 0.776 +graphic: 0.771 +register: 0.764 +performance: 0.760 +network: 0.754 +semantic: 0.731 +i386: 0.724 +architecture: 0.715 +assembly: 0.687 +debug: 0.684 +socket: 0.637 +files: 0.632 +PID: 0.610 +kernel: 0.579 +-------------------- +virtual: 0.984 +debug: 0.979 +x86: 0.952 +hypervisor: 0.655 +KVM: 0.184 +user-level: 0.113 +register: 0.091 +TCG: 0.062 +files: 0.032 +PID: 0.025 +socket: 0.016 +VMM: 0.014 +kernel: 0.012 +device: 0.012 +performance: 0.010 +semantic: 0.009 +risc-v: 0.005 +architecture: 0.004 +network: 0.004 +assembly: 0.003 +boot: 0.003 +peripherals: 0.003 +vnc: 0.003 +graphic: 0.002 +permissions: 0.001 +ppc: 0.001 +i386: 0.000 +mistranslation: 0.000 +arm: 0.000 + +qemu guest crashes on spice client USB redirected device removal + +Hello, + +I am experiencing guest crashes, which cannot be reproduced at all times, but are pretty frequent (4 out of 5 tries it would crash). The guest crashes when a previously attached USB redirected device through SPICE has been removed by the client. + +Steps to reproduce: +1.) Start windows 10 guest with display driver Spice +2.) Connect to the console with remote-viewer spice://IP:PORT or via virt-viewer (tunnelled through SSH) +3.) Attach a client USB device, for example storage device, iPhone or Android phone +4.) Observe the guest OS detects it and sets it up +5.) Go back to 'USB device selection' and untick the USB device +6.) Observe the guest VM crashed and the below assertion was printed in the qemu log for this virtual machine: + +qemu-system-x86_64: /var/tmp/portage/app-emulation/qemu-4.0.0-r3/work/qemu-4.0.0/hw/usb/core.c:720: usb_ep_get: Assertion `dev != NULL' failed. +2019-06-17 09:25:09.160+0000: shutting down, reason=crashed + + +Versions of related packages on the host: +app-emulation/qemu-4.0.0-r3 +app-emulation/spice-0.14.0-r2:0 +app-emulation/spice-protocol-0.12.14:0 +net-misc/spice-gtk-0.35:0 +Kernel: 5.1.7-gentoo on Intel x86_64 CPU + +Version of the spice-tools on the guest: +virtio-win 0.1-126 +QXL 0.1-21 +mingw-vdagent-win 0.8.0 + +QEMU command line (generated by libvirt): + +/usr/bin/qemu-system-x86_64 -name guest=W10VM,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-41-W10VM/master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_synic,hv_stimer -m 4500 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid b39afae2-5085-4659-891c-b3c65e65af2e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=26,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-hpet -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x8 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/libvirt/images/W10VM.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,cache=unsafe,discard=unmap,detect-zeroes=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-cache=on -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:44:f6:21,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=30,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -spice port=5901,addr=0.0.0.0,seamless-migration=on -device qxl-vga,id=video0,ram_size=134217728,vram_size=134217728,vram64_size_mb=0,vgamem_mb=64,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + + +I have attempted to collect a backtrace, but will need direction as I am not sure on which thread to listen and where to set the breakpoint, 'thread apply all backtrace' does not seem to work well with the qemu process... + +Thank you + +Hello, +I have the same qemu behaviour. It happens every time I have unplugged physical usb device attached to guest from the host system. My device is USB GSM dongle. Some times it disconnects and reconnects again for unknown reason, may be power loss... With version 3.1.0 qemu (gentoo linux) this disconnects had normal USB device disconnects in guest system. But with version 4.0.0 it gets guest VM to crash. + +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. + + +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/179 + + diff --git a/results/classifier/118/review/1833661 b/results/classifier/118/review/1833661 new file mode 100644 index 000000000..45cea5d2a --- /dev/null +++ b/results/classifier/118/review/1833661 @@ -0,0 +1,217 @@ +semantic: 0.874 +register: 0.864 +mistranslation: 0.853 +permissions: 0.853 +assembly: 0.852 +graphic: 0.848 +user-level: 0.844 +architecture: 0.837 +virtual: 0.822 +performance: 0.819 +device: 0.811 +arm: 0.810 +KVM: 0.786 +PID: 0.781 +kernel: 0.775 +peripherals: 0.769 +risc-v: 0.768 +debug: 0.766 +hypervisor: 0.744 +TCG: 0.718 +socket: 0.716 +ppc: 0.712 +vnc: 0.709 +files: 0.707 +network: 0.705 +boot: 0.692 +x86: 0.687 +i386: 0.670 +VMM: 0.638 +-------------------- +kernel: 0.945 +x86: 0.582 +debug: 0.139 +virtual: 0.098 +PID: 0.055 +files: 0.048 +device: 0.028 +TCG: 0.018 +boot: 0.016 +i386: 0.015 +assembly: 0.013 +performance: 0.011 +register: 0.010 +VMM: 0.009 +socket: 0.008 +architecture: 0.006 +vnc: 0.005 +semantic: 0.004 +ppc: 0.003 +KVM: 0.003 +hypervisor: 0.003 +risc-v: 0.002 +network: 0.002 +permissions: 0.002 +peripherals: 0.002 +arm: 0.002 +graphic: 0.001 +user-level: 0.001 +mistranslation: 0.001 + +Linux kernel oops on Malta board while accessing pflash + +commit 33d609990621dea6c7d056c86f707b8811320ac1 + +While running tests/acceptance/linux_ssh_mips_malta.py, the big-endian tests fail: + + 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 + Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 + Creating 3 MTD partitions on "physmap-flash.0": + 0x000000000000-0x000000100000 : "YAMON" + 0x000000100000-0x0000003e0000 : "User FS" + 0x0000003e0000-0x000000400000 : "Board Config" + CPU 0 Unable to handle kernel paging request at virtual address 00000014 + +The 64-bit test fails with: + + CPU 0 Unable to handle kernel paging request at virtual address 0000000000000028 + +Relevant 32-bit output: + +tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta32eb_kernel3_2_0 + +[ 34.968000] Using buffer write method +[ 38.324000] Searching for RedBoot partition table in physmap-flash.0 at offset 0x3f0000 +[ 38.328000] No RedBoot partition table detected in physmap-flash.0 +[ 39.032000] Creating 3 MTD partitions on "physmap-flash.0": +[ 39.032000] 0x000000000000-0x000000100000 : "YAMON" +[ 39.052000] 0x000000100000-0x0000003e0000 : "User FS" +[ 39.068000] 0x0000003e0000-0x000000400000 : "Board Config" +[ 40.924000] CPU 0 Unable to handle kernel paging request at virtual address 00000014, epc == c0203278, ra == c0203254 +[ 40.932000] Oops[#1]: +[ 40.932000] Cpu 0 +[ 40.932000] $ 0 : 00000000 1000a400 00000000 00000001 +[ 40.932000] $ 4 : c012f590 00000001 00000000 7fffffff +[ 40.932000] $ 8 : 8fbcbfe0 0000a400 00000000 8fae0000 +[ 40.932000] $12 : 74646368 00000001 806c0078 61720053 +[ 40.932000] $16 : 8fb38000 8fba63c0 c0200000 00000001 +[ 40.932000] $20 : 00000000 c0205074 8020953c 7fac45e4 +[ 40.932000] $24 : 00000003 80338058 +[ 40.932000] $28 : 8fbca000 8fbcbcd0 00000008 c0203254 +[ 40.932000] Hi : 00000009 +[ 40.932000] Lo : 85d47900 +[ 40.932000] epc : c0203278 mtd_open+0x94/0x1d0 [mtdchar] +[ 40.932000] Not tainted +[ 40.932000] ra : c0203254 mtd_open+0x70/0x1d0 [mtdchar] +[ 40.932000] Status: 1000a403 KERNEL EXL IE +[ 40.932000] Cause : 10800008 +[ 40.932000] BadVA : 00000014 +[ 40.932000] PrId : 00019300 (MIPS 24Kc) +[ 40.932000] Modules linked in: mtdchar(+) redboot cfi_cmdset_0001 cfi_probe cfi_util gen_probe sg evdev uhci_hcd ehci_hcd physmap map_funcs chipreg usbcore mtd psmouse sr_mod i2c_piix4 i2c_core cdrom serio_raw usb_common +[ 40.932000] Process mtd_probe (pid: 268, threadinfo=8fbca000, task=8fbbda88, tls=774b0490) +[ 40.932000] Stack : 00000000 8e9b9470 8fba63c0 8e9b9470 802094b0 8e9ad980 8e9b9470 8fba63c0 +[ 40.932000] 8e9ad980 802095d4 00000000 00000000 00000000 7fac45e4 00000003 8033768c +[ 40.932000] 8fba63c0 8f5a7518 8f811c80 8e9b9470 802094b0 00000000 00000000 7fac45e4 +[ 40.932000] 00000008 80202bb4 8fbcbe14 8fbcbe68 8fbcbdc0 8f4f4498 8f811c80 8fbcbe70 +[ 40.932000] 8fa29140 8fbcbe68 8e9b9470 00000024 00000000 00000000 00000005 7fac45e4 +[ 40.932000] ... +[ 40.932000] Call Trace: +[ 40.932000] [<c0203278>] mtd_open+0x94/0x1d0 [mtdchar] +[ 40.932000] [<802095d4>] chrdev_open+0x124/0x250 +[ 40.932000] [<80202bb4>] __dentry_open+0x27c/0x3d8 +[ 40.932000] [<8020400c>] nameidata_to_filp+0x64/0x78 +[ 40.932000] [<80214160>] do_last.isra.17+0x3a4/0x81c +[ 40.932000] [<802146d4>] path_openat+0xc0/0x4c4 +[ 40.932000] [<80214bf0>] do_filp_open+0x3c/0xac +[ 40.932000] [<80204134>] do_sys_open+0x114/0x200 +[ 40.932000] [<8010a9d0>] stack_done+0x20/0x40 +[ 40.932000] +[ 40.932000] +[ 40.932000] Code: 3c02c013 3c02c020 8c425070 <8c440014> 3c028022 2442eef4 0040f809 02602821 10400043 +[ 40.956000] ---[ end trace e666aa8cbfdf5c7f ]--- +udevd[192]: 'mtd_probe /dev/.tmp-char-90:3' +[hang] + +Relevant 64-bit output: + +tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta64eb_kernel3_2_0 + +[ 0.000000] Initializing cgroup subsys cpuset +[ 0.000000] Initializing cgroup subsys cpu +[ 0.000000] Linux version 3.2.0-4-5kc-malta (<email address hidden>) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 Debian 3.2.51-1 +[ 0.000000] bootconsole [early0] enabled +[ 0.000000] CPU revision is: 000182a0 (MIPS 20Kc) +[ 0.000000] FPU revision is: 000f8200 +[ 0.000000] Checking for the multiply/shift bug... no. +[ 0.000000] Checking for the daddiu bug... no. +[ 0.000000] Determined physical RAM map: +[ 0.000000] memory: 0000000000001000 @ 0000000000000000 (reserved) +[ 0.000000] memory: 00000000000ef000 @ 0000000000001000 (ROM data) +[ 0.000000] memory: 0000000000748000 @ 00000000000f0000 (reserved) +[ 0.000000] memory: 00000000077c7000 @ 0000000000838000 (usable) +[ 0.000000] Wasting 117824 bytes for tracking 2104 unused pages +[ 0.000000] Initrd not found or empty - disabling initrd +[ 0.000000] Kernel command line: printk.time=0 console=ttyS0 root=/dev/sda1 +[...] +Freeing prom memory: 956k freed +Freeing unused kernel memory: 244k freed + +INIT: version 2.88 booting + +Using makefile-style concurrent boot in runlevel S. +physmap platform flash device: 00400000 at 1e000000 +sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[...] +sd 0:0:0:0: Attached scsi generic sg0 type 0 +sr 1:0:0:0: Attached scsi generic sg1 type 5 +physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 +input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input1 +Intel/Sharp Extended Query Table at 0x0031 +Using buffer write method +Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 +Creating 3 MTD partitions on "physmap-flash.0": +0x000000000000-0x000000100000 : "YAMON" +0x000000100000-0x0000003e0000 : "User FS" +0x0000003e0000-0x000000400000 : "Board Config" +CPU 0 Unable to handle kernel paging request at virtual address 0000000000000028, epc == ffffffffc00f9234, ra == ffffffffc00f9210 + +When running tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta64el_kernel3_2_0, I'm getting in roughly 8% of executions: + +2019-09-18 22:37:43,665 linux_ssh_mips_m L0065 DEBUG| Intel/Sharp Extended Query Table at 0x0031 +2019-09-18 22:37:43,668 linux_ssh_mips_m L0065 DEBUG| Using buffer write method +2019-09-18 22:37:45,722 linux_ssh_mips_m L0065 DEBUG| Searching for RedBoot partition table in physmap-flash.0 at offset 0x1003f0000 +2019-09-18 22:37:46,287 linux_ssh_mips_m L0065 DEBUG| ESC[?25lESC[?1cESC7Creating 3 MTD partitions on "physmap-flash.0": +2019-09-18 22:37:46,287 linux_ssh_mips_m L0065 DEBUG| 0x000000000000-0x000000100000 : "YAMON" +2019-09-18 22:37:46,314 linux_ssh_mips_m L0065 DEBUG| 0x000000100000-0x0000003e0000 : "User FS" +2019-09-18 22:37:46,319 linux_ssh_mips_m L0065 DEBUG| 0x0000003e0000-0x000000400000 : "Board Config" +2019-09-18 22:37:47,260 linux_ssh_mips_m L0065 DEBUG| ESC[1G[ESC[32m ok ESC[39;49mCPU 0 Unable to handle kernel paging request at virtual address +0000000000000028, epc == ffffffffc00ed234, ra == ffffffffc00ed210 +2019-09-18 22:37:47,262 linux_ssh_mips_m L0065 DEBUG| Oops[#1]: + + +And when running tests/acceptance/linux_ssh_mips_malta.py:LinuxSSH.test_mips_malta32eb_kernel3_2_0: + +2019-09-19 00:02:47,151 linux_ssh_mips_m L0065 DEBUG| Searching for RedBoot partition table in physmap-flash.0 at offset 0x3f0000 +2019-09-19 00:02:47,154 linux_ssh_mips_m L0065 DEBUG| No RedBoot partition table detected in physmap-flash.0 +2019-09-19 00:02:47,847 linux_ssh_mips_m L0065 DEBUG| Creating 3 MTD partitions on "physmap-flash.0": +2019-09-19 00:02:47,850 linux_ssh_mips_m L0065 DEBUG| 0x000000000000-0x000000100000 : "YAMON" +2019-09-19 00:02:47,875 linux_ssh_mips_m L0065 DEBUG| 0x000000100000-0x0000003e0000 : "User FS" +2019-09-19 00:02:47,875 linux_ssh_mips_m L0065 DEBUG| 0x0000003e0000-0x000000400000 : "Board Config" +2019-09-19 00:02:48,792 linux_ssh_mips_m L0065 DEBUG| ESC[?25lESC[?1cESC7CPU 0 Unable to handle kernel paging request at virtual address 00000014, + epc == c0205278, ra == c0205254 +2019-09-19 00:02:48,794 linux_ssh_mips_m L0065 DEBUG| Oops[#1]: + +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. + + + +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/51 + + diff --git a/results/classifier/118/review/1836 b/results/classifier/118/review/1836 new file mode 100644 index 000000000..36e489742 --- /dev/null +++ b/results/classifier/118/review/1836 @@ -0,0 +1,61 @@ +mistranslation: 0.903 +virtual: 0.808 +device: 0.646 +performance: 0.554 +graphic: 0.447 +boot: 0.441 +user-level: 0.426 +semantic: 0.398 +peripherals: 0.272 +network: 0.226 +permissions: 0.218 +assembly: 0.179 +arm: 0.153 +debug: 0.145 +vnc: 0.132 +hypervisor: 0.129 +risc-v: 0.119 +register: 0.118 +kernel: 0.096 +socket: 0.089 +architecture: 0.079 +x86: 0.076 +ppc: 0.061 +files: 0.054 +i386: 0.021 +PID: 0.011 +VMM: 0.006 +KVM: 0.005 +TCG: 0.003 +-------------------- +boot: 0.552 +device: 0.517 +performance: 0.316 +virtual: 0.109 +user-level: 0.044 +x86: 0.023 +semantic: 0.015 +files: 0.008 +PID: 0.008 +kernel: 0.006 +hypervisor: 0.005 +debug: 0.002 +i386: 0.002 +socket: 0.002 +graphic: 0.001 +assembly: 0.001 +register: 0.001 +network: 0.001 +peripherals: 0.001 +architecture: 0.001 +mistranslation: 0.001 +TCG: 0.000 +arm: 0.000 +ppc: 0.000 +VMM: 0.000 +permissions: 0.000 +vnc: 0.000 +risc-v: 0.000 +KVM: 0.000 + +AIX no longer boots diff --git a/results/classifier/118/review/1837218 b/results/classifier/118/review/1837218 new file mode 100644 index 000000000..5184deffa --- /dev/null +++ b/results/classifier/118/review/1837218 @@ -0,0 +1,101 @@ +semantic: 0.833 +user-level: 0.796 +register: 0.787 +ppc: 0.770 +arm: 0.762 +graphic: 0.733 +device: 0.729 +x86: 0.725 +performance: 0.714 +debug: 0.711 +risc-v: 0.708 +permissions: 0.661 +PID: 0.661 +virtual: 0.657 +KVM: 0.651 +peripherals: 0.648 +hypervisor: 0.643 +mistranslation: 0.635 +architecture: 0.611 +vnc: 0.605 +network: 0.573 +boot: 0.567 +assembly: 0.558 +TCG: 0.552 +VMM: 0.531 +socket: 0.523 +kernel: 0.489 +files: 0.486 +i386: 0.282 +-------------------- +virtual: 0.931 +debug: 0.931 +hypervisor: 0.796 +KVM: 0.404 +boot: 0.365 +PID: 0.230 +socket: 0.180 +x86: 0.136 +register: 0.095 +TCG: 0.094 +VMM: 0.056 +performance: 0.053 +kernel: 0.044 +device: 0.036 +files: 0.022 +assembly: 0.012 +network: 0.011 +semantic: 0.008 +ppc: 0.006 +user-level: 0.004 +architecture: 0.004 +graphic: 0.004 +peripherals: 0.003 +risc-v: 0.002 +permissions: 0.002 +vnc: 0.001 +arm: 0.000 +mistranslation: 0.000 +i386: 0.000 + +qemu segfaults after spice update with bochs-display + +Description: + +qemu segfaults after latest spice update with bochs-display. Downgrading spice solves the issue. Switching to qxl-vga and/or virtio-gpu also works even with new spice. + +Additional info: +* package version(s) + +spice 0.14.2-1 +qemu-headless 4.0.0-3 + +* config and/or log files etc. + +pf@defiant:~ » /mnt/vms/02-archlinux/start.sh +/mnt/vms/02-archlinux/start.sh: line 41: 13501 Segmentation fault (core dumped) qemu-system-x86_64 -name "${NAME}" -display none -spice ipv4,addr=127.0.0.1,port=270${ID},disable-ticketing,disable-copy-paste,disable-agent-file-xfer,agent-mouse=off -serial mon:telnet:127.0.0.1:280${ID},server,nowait,nodelay -gdb tcp::260${ID} -nodefaults -machine q35,accel=kvm -cpu max -smp cores=${CPU},threads=1,sockets=1 -m ${MEM} -drive if=pflash,format=raw,readonly,file="${BIOS}" -drive if=pflash,format=raw,file="${VARS}" -device virtio-rng -device bochs-display -device virtio-keyboard -netdev bridge,id=bridge.0,br=vm0 -device virtio-net,mac=${_MAC}:01,netdev=bridge.0,mq=on,vectors=${_VECTORS} -fsdev local,id="${NAME}",path="${SHARED}",security_model=mapped,writeout=immediate -device virtio-9p-pci,fsdev="${NAME}",mount_tag="shared" -device virtio-scsi,id=scsi,num_queues=${CPU},vectors=${_VECTORS} -device scsi-hd,drive=hd1 -drive if=none,media=disk,id=hd1,file="${DISK1}",format=raw,cache=directsync,discard=unmap,detect-zeroes=unmap -device scsi-hd,drive=hd2 -drive if=none,media=disk,id=hd2,file="${DISK2}",format=raw,cache=directsync,discard=unmap,detect-zeroes=unmap -device scsi-cd,drive=cd1 -drive if=none,media=cdrom,id=cd1,file="${CDROM1}",format=raw,cache=directsync + +Steps to reproduce: + +Update spice, launch a VM like the above and observe a segfault. + +Arc Linux report: https://bugs.archlinux.org/task/63229 + +I've built qemu v4.1.0-rc1 with debug symbols, but got no luck in reproducing this. + +I've also built qemu v4.0.0 with debug info, and the issue is not reproducible with such a build. + +Stack trace w/o debug symbols: + +#0 0x000055b7d9f96a49 address_space_dispatch_free (qemu-system-x86_64) +#1 0x000055b7d9ff1169 n/a (qemu-system-x86_64) +#2 0x000055b7da40126c n/a (qemu-system-x86_64) +#3 0x000055b7da3ef121 n/a (qemu-system-x86_64) +#4 0x00007f257e69e57f start_thread (libpthread.so.0) +#5 0x00007f257e5ce0e3 __clone (libc.so.6) + +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. + +The issue is not experienced any more. + diff --git a/results/classifier/118/review/1837347 b/results/classifier/118/review/1837347 new file mode 100644 index 000000000..34752dc20 --- /dev/null +++ b/results/classifier/118/review/1837347 @@ -0,0 +1,110 @@ +x86: 0.889 +user-level: 0.851 +arm: 0.806 +kernel: 0.805 +architecture: 0.802 +permissions: 0.767 +mistranslation: 0.745 +files: 0.735 +boot: 0.700 +device: 0.697 +performance: 0.689 +graphic: 0.678 +semantic: 0.643 +network: 0.628 +PID: 0.588 +socket: 0.567 +register: 0.560 +virtual: 0.549 +ppc: 0.532 +peripherals: 0.510 +i386: 0.485 +vnc: 0.483 +debug: 0.467 +VMM: 0.463 +TCG: 0.462 +hypervisor: 0.449 +risc-v: 0.436 +assembly: 0.429 +KVM: 0.402 +-------------------- +arm: 0.968 +debug: 0.949 +virtual: 0.915 +hypervisor: 0.526 +performance: 0.070 +PID: 0.070 +kernel: 0.047 +TCG: 0.041 +user-level: 0.028 +files: 0.024 +boot: 0.012 +device: 0.011 +socket: 0.010 +semantic: 0.008 +network: 0.006 +register: 0.005 +risc-v: 0.004 +vnc: 0.004 +permissions: 0.003 +graphic: 0.003 +x86: 0.003 +assembly: 0.003 +VMM: 0.003 +architecture: 0.003 +peripherals: 0.001 +mistranslation: 0.000 +ppc: 0.000 +i386: 0.000 +KVM: 0.000 + +guest userspace process core dump after raspi2 kernel boot + +Host info: +========== +x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site) + +Guest info: +=========== +ARM7l, Raspbian OS off the main raspberry pi site + +QEMU command: +============= +qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb bootpart/bcm2709-rpi-2-b.dtb -drive file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio + +kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following commands: + +guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1 +><fs> copy-out / bootpart/ +><fs> quit + +Output: +======= + +https://pastebin.com/fL1eXhV0 + +References: +=========== +https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ +https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/ + + +The core dump error can occur at both times, before logging in and after logging in, in this case I have given the output after logging in to show the initial processes running. + +Also please let me know if I using any kernel flags incorrectly + +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/review/1838913 b/results/classifier/118/review/1838913 new file mode 100644 index 000000000..fffda4cca --- /dev/null +++ b/results/classifier/118/review/1838913 @@ -0,0 +1,111 @@ +architecture: 0.949 +virtual: 0.791 +graphic: 0.625 +hypervisor: 0.618 +device: 0.590 +semantic: 0.587 +kernel: 0.563 +performance: 0.513 +debug: 0.508 +ppc: 0.477 +socket: 0.466 +arm: 0.447 +user-level: 0.444 +files: 0.443 +x86: 0.393 +register: 0.387 +mistranslation: 0.362 +vnc: 0.352 +permissions: 0.347 +network: 0.346 +peripherals: 0.344 +assembly: 0.334 +boot: 0.312 +PID: 0.259 +VMM: 0.245 +risc-v: 0.241 +KVM: 0.219 +TCG: 0.211 +i386: 0.180 +-------------------- +hypervisor: 0.851 +virtual: 0.413 +assembly: 0.383 +kernel: 0.120 +architecture: 0.071 +debug: 0.057 +TCG: 0.049 +user-level: 0.033 +files: 0.025 +semantic: 0.025 +register: 0.020 +PID: 0.012 +VMM: 0.011 +performance: 0.007 +arm: 0.006 +device: 0.004 +vnc: 0.004 +socket: 0.003 +network: 0.002 +boot: 0.002 +KVM: 0.002 +risc-v: 0.001 +graphic: 0.001 +permissions: 0.001 +peripherals: 0.001 +x86: 0.001 +ppc: 0.001 +mistranslation: 0.001 +i386: 0.000 + +Single-step exceptions incorrectly routed to EL1 when ELD is EL2 (TDE = 1) (qemu version 3.1) + +Hi, + +I've been encountering issues with QEMU 3.1 when trying to single-step EL1 code, with ELD = EL2 (MDCR_EL2.TDE = 1). I could test with latest commit in a few hours, if you want. + +EL1 is Aarch64. + +These happen as soon as MDSCR_EL1.SS is set to 1 and ERET is executed: + +1) Single-step exceptions are generated even if they should not be (SPSR_EL2.SS = 0) + +2) Single-step exceptions are routed to EL1 + +Exception return from AArch64 EL2 to AArch64 EL1 PC 0x4000005c +Taking exception 1 [Undefined Instruction] +...from EL1 to EL1 +...with ESR 0x32/0xca000022 +...with ELR 0x4000005c +...to EL1 PC 0x200 PSTATE 0x3c5 + +EC 0x32 (0b110010) is Exception_SoftwareStepLowerEl. + +You can find enclosed minimal code (and resulting .elf) for reproduction. + +qemu-system-aarch64 -nographic -machine virt,virtualization=on -d unimp,int -cpu cortex-a57 -kernel test_hyp.elf + + + +Yes, we're directing single-step exceptions to the wrong EL. (I think this is probably a hangover from the fact that we implemented singlestep at about the same time or before we properly implemented EL2 support, so we haven't shaken out all the "assumes debug EL is EL1" assumptions still.) + + +I've just submitted this patchset: +https://<email address hidden>/ + +which I think should fix this bug. With those changes, the test image takes a single-step exception to EL2, and then (because there's no code at the exception entry point) takes a series of EL2-to-EL2 undef exceptions, which I think is expected and correct behaviour. + + +Thanks for the patch! + +I tested it with more complex code, it seems to work fine (and fixes the bug), e.g. with an infinite loop of 2 instructions: + +Single-step exeception ELR = 0x0000000060100000, ISV = 1, EX = 0 +Single-step exeception ELR = 0x0000000060100004, ISV = 1, EX = 0 +(and so on) + +(I haven't been able to test load-exclusive instructions yet but I don't see why it would fail for EL2 specifically, anyway) + +This is fixed in master by commit 8bd587c1066f445 which will be in the 4.2 release. + + diff --git a/results/classifier/118/review/1838946 b/results/classifier/118/review/1838946 new file mode 100644 index 000000000..bea1ca911 --- /dev/null +++ b/results/classifier/118/review/1838946 @@ -0,0 +1,681 @@ +user-level: 0.895 +ppc: 0.884 +mistranslation: 0.871 +register: 0.867 +permissions: 0.866 +risc-v: 0.855 +graphic: 0.848 +TCG: 0.843 +peripherals: 0.840 +network: 0.831 +arm: 0.829 +x86: 0.827 +device: 0.824 +hypervisor: 0.815 +vnc: 0.813 +KVM: 0.811 +performance: 0.809 +architecture: 0.808 +debug: 0.807 +virtual: 0.797 +VMM: 0.794 +files: 0.792 +assembly: 0.787 +socket: 0.784 +semantic: 0.782 +boot: 0.779 +PID: 0.778 +kernel: 0.720 +i386: 0.597 +-------------------- +arm: 0.987 +virtual: 0.488 +debug: 0.385 +hypervisor: 0.068 +assembly: 0.044 +PID: 0.044 +files: 0.032 +performance: 0.019 +register: 0.010 +semantic: 0.008 +TCG: 0.008 +kernel: 0.007 +user-level: 0.005 +architecture: 0.004 +device: 0.003 +network: 0.003 +socket: 0.002 +graphic: 0.001 +VMM: 0.001 +permissions: 0.001 +peripherals: 0.001 +boot: 0.001 +vnc: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +KVM: 0.000 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu 3.10 golang crash + +Encountered below crashes in qemu 3.10 arm +Also have raised the same in golang groups. But seems like in ARM32 hardware, the below commands works fine, only in qemu if crashes. +https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/golang-nuts/1txPOGa4aGc + +Need some pointers to narrow down + +Please see log below. + +$ qemu-arm-static --version +qemu-arm version 3.1.0 (qemu-3.1.0-6.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + + + + +arheneus@bbdee4f6f57d:/sonic/src/telemetry/test$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +github.com/openconfig/ygot (download) +github.com/kylelemons/godebug (download) +github.com/openconfig/goyang (download) +SIGSEGV: segmentation violation +PC=0x4512c m=12 sigcode=1 + +goroutine 15 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11c3, 0xf513b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280a0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 fp=0xf51380 sp=0xf5137c pc=0x88298 +os.(*Process).blockUntilWaitable(0xf80300, 0xf80300, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 fp=0xf51438 sp=0xf51380 pc=0xa94a0 +os.(*Process).wait(0xf80300, 0x13, 0xe6e1d0, 0xeba010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c fp=0xf51470 sp=0xf51438 pc=0xa2d58 +os.(*Process).Wait(0xf80300, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c fp=0xf51484 sp=0xf51470 pc=0xa2494 +os/exec.(*Cmd).Wait(0xe14000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 fp=0xf514bc sp=0xf51484 pc=0xf8620 +os/exec.(*Cmd).Run(0xe14000, 0xd5c720, 0xf30000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 fp=0xf514cc sp=0xf514bc pc=0xf7e1c +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x116f8e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 fp=0xf515bc sp=0xf514cc pc=0x3549bc +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177d90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c fp=0xf51978 sp=0xf515bc pc=0x3594fc +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177d90, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c fp=0xf51f44 sp=0xf51978 pc=0x35e374 +cmd/go/internal/work.(*Builder).Do.func1(0x1177d90) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 fp=0xf51f84 sp=0xf51f44 pc=0x38287c +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 fp=0xf51fdc sp=0xf51f84 pc=0x382b24 +runtime.goexit() + /usr/local/go/src/runtime/asm_arm.s:867 +0x4 fp=0xf51fdc sp=0xf51fdc pc=0x67f44 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 1 [semacquire]: +sync.runtime_Semacquire(0xdf0078) + /usr/local/go/src/runtime/sema.go:56 +0x2c +sync.(*WaitGroup).Wait(0xdf0070) + /usr/local/go/src/sync/waitgroup.go:130 +0x84 +cmd/go/internal/work.(*Builder).Do(0xd5cf60, 0x1177290) + /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x304 +cmd/go/internal/work.InstallPackages(0xc82078, 0x1, 0x1, 0xc0e938, 0x1, 0x2) + /usr/local/go/src/cmd/go/internal/work/build.go:506 +0xa88 +cmd/go/internal/get.runGet(0x810d78, 0xc82078, 0x1, 0x1) + /usr/local/go/src/cmd/go/internal/get/get.go:196 +0x1b0 +main.main() + /usr/local/go/src/cmd/go/main.go:219 +0x93c + +goroutine 19 [syscall]: +os/signal.signal_recv(0x0) + /usr/local/go/src/runtime/sigqueue.go:139 +0x130 +os/signal.loop() + /usr/local/go/src/os/signal/signal_unix.go:23 +0x14 +created by os/signal.init.0 + /usr/local/go/src/os/signal/signal_unix.go:29 +0x30 + +goroutine 13 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11ec, 0x10153b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe001e0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xe62840, 0xe62840, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xe62840, 0x1, 0xc0e360, 0xe00160) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xe62840, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xf8e0b0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xf8e0b0, 0xca8060, 0xe6cd00) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0x1015890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0xfb6210, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0xfb6210, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0xfb6210) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 14 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11ed, 0xe393b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xd280f0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0x115c4e0, 0x115c4e0, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0x115c4e0, 0x1, 0xe78160, 0xd28070) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0x115c4e0, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0x10b8000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0x10b8000, 0xf3e060, 0xf0c000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0xe39890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177b80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177b80, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177b80) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 16 [runnable]: +os/exec.(*Cmd).writerDescriptor(0x10b80b0, 0x54bd38, 0xf3e120, 0xf3e0c0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:257 +0x484 +os/exec.(*Cmd).stderr(0x10b80b0, 0x1112090, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:254 +0xac +os/exec.(*Cmd).Start(0x10b80b0, 0x496701, 0xf3e120) + /usr/local/go/src/os/exec/exec.go:372 +0xa8 +os/exec.(*Cmd).Run(0x10b80b0, 0xf3e120, 0xf0c300) + /usr/local/go/src/os/exec/exec.go:306 +0x1c +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0xf49890) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177ce0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:225 +0x11d4 +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177ce0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177ce0) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 82 [runnable]: +syscall.Syscall(0x3, 0xb, 0x11c2000, 0x8000, 0x0, 0x0, 0x0) + /usr/local/go/src/syscall/asm_linux_arm.s:14 +0x8 +syscall.read(0xb, 0x11c2000, 0x8000, 0x8000, 0x10ea501, 0x0, 0x0) + /usr/local/go/src/syscall/zsyscall_linux_arm.go:732 +0x40 +syscall.Read(0xb, 0x11c2000, 0x8000, 0x8000, 0xdedf9577, 0xe9841d9d, 0xdbb1d24e) + /usr/local/go/src/syscall/syscall_unix.go:172 +0x34 +internal/poll.(*FD).Read(0xd9c140, 0x11c2000, 0x8000, 0x8000, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:165 +0xf0 +os.(*File).read(0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x11c3700, 0x1d, 0x6940) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x171d, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +io.copyBuffer(0xe77be000, 0xe88380, 0x54c3f8, 0xcdc0f0, 0x11c2000, 0x8000, 0x8000, 0x443d58, 0x47a900, 0x0, ...) + /usr/local/go/src/io/io.go:402 +0xd8 +io.Copy(0xe77be000, 0xe88380, 0x54c3f8, 0xcdc0f0, 0xe88380, 0x0, 0x40, 0xb) + /usr/local/go/src/io/io.go:364 +0x48 +cmd/go/internal/cache.FileHash(0xe628a0, 0x25, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/cmd/go/internal/cache/hash.go:149 +0x240 +cmd/go/internal/work.(*Builder).fileHash(0xd5cf60, 0xe628a0, 0x25, 0xe628a0, 0x25) + /usr/local/go/src/cmd/go/internal/work/buildid.go:396 +0x24 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177760, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:292 +0x5ec +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177760, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177760) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 83 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11d1, 0xf4d3b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280b0) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf80330, 0xf80330, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf80330, 0x1, 0xc7e1b0, 0xe28010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf80330, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0x11760b0, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0x11760b0, 0xfc8060, 0xefa800) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0xf278e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177e40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177e40, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177e40) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 84 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11cf, 0xf453b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xeba040) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf74180, 0xf74180, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf74180, 0x1, 0x1112070, 0x100e010) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf74180, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xfe8000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xfe8000, 0xe10060, 0xf18000) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x10878e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177a20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177a20, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177a20) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 85 [syscall]: +syscall.Syscall6(0x118, 0x1, 0x11d5, 0xe373b0, 0x1000004, 0x0, 0x0, 0x1c63c, 0x15e54, 0xeba050) + /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 +os.(*Process).blockUntilWaitable(0xf741b0, 0xf741b0, 0x0, 0x0) + /usr/local/go/src/os/wait_waitid.go:31 +0x64 +os.(*Process).wait(0xf741b0, 0x50, 0xc0e290, 0xe00090) + /usr/local/go/src/os/exec_unix.go:22 +0x2c +os.(*Process).Wait(0xf741b0, 0x4d5f58, 0x4d5f5c, 0x4d5f54) + /usr/local/go/src/os/exec.go:125 +0x1c +os/exec.(*Cmd).Wait(0xf8e000, 0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:465 +0x40 +os/exec.(*Cmd).Run(0xf8e000, 0xcb5e00, 0xe6ca00) + /usr/local/go/src/os/exec/exec.go:309 +0x44 +cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0xf2b8e0) + /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 +cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177ef0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c +cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177ef0, 0x0, 0x0) + /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c +cmd/go/internal/work.(*Builder).Do.func1(0x1177ef0) + /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 +cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) + /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 +created by cmd/go/internal/work.(*Builder).Do + /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 + +goroutine 31 [IO wait]: +internal/poll.runtime_pollWait(0xecac29c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xd7c3d4, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xd7c3d4, 0x1040601, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xd7c3c0, 0x1040600, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe78168, 0x1040600, 0x200, 0x200, 0x1040600, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe78168, 0x1040600, 0x200, 0x200, 0xe9d2f000, 0xff667d78, 0x3) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xf3e060, 0x54c3f8, 0xe78168, 0xe9d2f000, 0xf3e060, 0x1b001, 0xcf62b0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xf3e060, 0x54c3f8, 0xe78168, 0x0, 0x0, 0x0, 0x0, 0xcf60c0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xf3e060, 0x54c3f8, 0xe78168, 0x19, 0xfa910, 0xcf6280, 0xf977dc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xcf6280, 0xf977dc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x10b8000, 0xd280c0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 30 [IO wait]: +internal/poll.runtime_pollWait(0xecac2dc0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xd7c354, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xd7c354, 0xddc001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xd7c340, 0xddc000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe78148, 0xddc000, 0x200, 0x200, 0xddc000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe78148, 0xddc000, 0x200, 0x200, 0xe9d2f000, 0xff667d78, 0x5) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xf3e000, 0x54c3f8, 0xe78148, 0xe9d2f000, 0xf3e000, 0x1b001, 0xcf62b0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xf3e000, 0x54c3f8, 0xe78148, 0x0, 0x0, 0x0, 0x0, 0xcf6140, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xf3e000, 0x54c3f8, 0xe78148, 0x0, 0xfa910, 0xcf6280, 0xf95fdc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xcf6280, 0xf95fdc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x10b8000, 0xd280a0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 37 [IO wait]: +internal/poll.runtime_pollWait(0xecac2f40, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc8514, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc8514, 0x1040801, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc8500, 0x1040800, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e338, 0x1040800, 0x200, 0x200, 0x1040800, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e338, 0x1040800, 0x200, 0x200, 0xe9d2f000, 0xff669250, 0x3) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xca8000, 0x54c3f8, 0xc0e338, 0xe9d2f000, 0xca8000, 0x16601, 0xc36f54) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xca8000, 0x54c3f8, 0xc0e338, 0x0, 0x0, 0x0, 0x0, 0xd9c0c0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xca8000, 0x54c3f8, 0xc0e338, 0xd9c100, 0xfa910, 0xd9c100, 0xc36fdc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0xd9c100, 0xc36fdc) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e0b0, 0xe00190) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 114 [IO wait]: +internal/poll.runtime_pollWait(0xecac23c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xce8694, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xce8694, 0x108e001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xce8680, 0x108e000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe6e1b8, 0x108e000, 0x200, 0x200, 0x108e000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe6e1b8, 0x108e000, 0x200, 0x200, 0xe9d2f000, 0x4e9d0, 0xc37f18) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0x1024000, 0x54c3f8, 0xe6e1b8, 0xe9d2f000, 0x1024000, 0x1177a01, 0xd5cf98) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0x1024000, 0x54c3f8, 0xe6e1b8, 0x0, 0x0, 0x0, 0x2, 0x0, 0x1, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0x1024000, 0x54c3f8, 0xe6e1b8, 0x1, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xe14000, 0x1042840) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 115 [IO wait]: +internal/poll.runtime_pollWait(0xecac22c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xce8714, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xce8714, 0x108e601, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xce8700, 0x108e600, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xe6e1d8, 0x108e600, 0x200, 0x200, 0x108e600, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xe6e1d8, 0x108e600, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xd5c720, 0x54c3f8, 0xe6e1d8, 0xe9d2f000, 0xd5c720, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xd5c720, 0x54c3f8, 0xe6e1d8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xd5c720, 0x54c3f8, 0xe6e1d8, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xe14000, 0x1042860) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 116 [IO wait]: +internal/poll.runtime_pollWait(0xecac2c40, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc72214, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc72214, 0xea4201, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc72200, 0xea4200, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc7e190, 0xea4200, 0x200, 0x200, 0xea4200, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc7e190, 0xea4200, 0x200, 0x200, 0xe9d2f000, 0x3e206820, 0x3331203e) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xfc8000, 0x54c3f8, 0xc7e190, 0xe9d2f000, 0xfc8000, 0x61686d01, 0x32336873) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xfc8000, 0x54c3f8, 0xc7e190, 0x0, 0x0, 0x0, 0x34202b20, 0x7361682a, 0x79656b68, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xfc8000, 0x54c3f8, 0xc7e190, 0x70283233, 0x68090a29, 0x72203d20, 0x5f6c746f) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x203d5e20, 0x3e3e2068) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x11760b0, 0xe28040) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 117 [IO wait]: +internal/poll.runtime_pollWait(0xecac2740, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc72294, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc72294, 0xea4001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc72280, 0xea4000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc7e1b8, 0xea4000, 0x200, 0x200, 0xea4000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc7e1b8, 0xea4000, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xfc8060, 0x54c3f8, 0xc7e1b8, 0xe9d2f000, 0xfc8060, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xfc8060, 0x54c3f8, 0xc7e1b8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xfc8060, 0x54c3f8, 0xc7e1b8, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0x11760b0, 0xe28070) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 130 [IO wait]: +internal/poll.runtime_pollWait(0xecac25c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc8a114, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc8a114, 0xea4401, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc8a100, 0xea4400, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0x1112058, 0xea4400, 0x200, 0x200, 0xea4400, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0x1112058, 0xea4400, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xe10000, 0x54c3f8, 0x1112058, 0xe9d2f000, 0xe10000, 0x1177d01, 0xd5cf98) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xe10000, 0x54c3f8, 0x1112058, 0x0, 0x0, 0x0, 0x2, 0x0, 0x1, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xe10000, 0x54c3f8, 0x1112058, 0x1, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xfe8000, 0x100e040) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 131 [IO wait]: +internal/poll.runtime_pollWait(0xecac24c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xc8a214, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xc8a214, 0x1044001, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xc8a200, 0x1044000, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0x1112078, 0x1044000, 0x200, 0x200, 0x1044000, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0x1112078, 0x1044000, 0x200, 0x200, 0xe9d2f000, 0xa, 0x2) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xe10060, 0x54c3f8, 0x1112078, 0xe9d2f000, 0xe10060, 0x1, 0x2) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xe10060, 0x54c3f8, 0x1112078, 0x0, 0x0, 0x0, 0xee3e90, 0x27, 0xd2, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xe10060, 0x54c3f8, 0x1112078, 0x2, 0xedca50, 0x2b, 0xbc) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xfe8000, 0x100e060) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 132 [IO wait]: +internal/poll.runtime_pollWait(0xecac2240, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc82d4, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc82d4, 0x1044201, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc82c0, 0x1044200, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e270, 0x1044200, 0x200, 0x200, 0x1044200, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e270, 0x1044200, 0x200, 0x200, 0xe9d2f000, 0x0, 0x0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xcb5800, 0x54c3f8, 0xc0e270, 0xe9d2f000, 0xcb5800, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xcb5800, 0x54c3f8, 0xc0e270, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xcb5800, 0x54c3f8, 0xc0e270, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0xcc9f80) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e000, 0xe000c0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c + +goroutine 133 [IO wait]: +internal/poll.runtime_pollWait(0xecac27c0, 0x72, 0x9cc90) + /usr/local/go/src/runtime/netpoll.go:173 +0x44 +internal/poll.(*pollDesc).wait(0xdc8354, 0x72, 0xffffff01, 0x54cc68, 0x7e0240) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x7c +internal/poll.(*pollDesc).waitRead(0xdc8354, 0x1040401, 0x200, 0x200) + /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x2c +internal/poll.(*FD).Read(0xdc8340, 0x1040400, 0x200, 0x200, 0x0, 0x0, 0x0) + /usr/local/go/src/internal/poll/fd_unix.go:169 +0x14c +os.(*File).read(0xc0e298, 0x1040400, 0x200, 0x200, 0x1040400, 0x0, 0x0) + /usr/local/go/src/os/file_unix.go:249 +0x3c +os.(*File).Read(0xc0e298, 0x1040400, 0x200, 0x200, 0xe9d2f000, 0x0, 0x10b81d0) + /usr/local/go/src/os/file.go:108 +0x4c +bytes.(*Buffer).ReadFrom(0xcb5e00, 0x54c3f8, 0xc0e298, 0xe9d2f000, 0xcb5e00, 0x1, 0x0) + /usr/local/go/src/bytes/buffer.go:206 +0xb0 +io.copyBuffer(0x54bd38, 0xcb5e00, 0x54c3f8, 0xc0e298, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) + /usr/local/go/src/io/io.go:388 +0x300 +io.Copy(0x54bd38, 0xcb5e00, 0x54c3f8, 0xc0e298, 0x0, 0x0, 0x0, 0x0) + /usr/local/go/src/io/io.go:364 +0x48 +os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) + /usr/local/go/src/os/exec/exec.go:279 +0x38 +os/exec.(*Cmd).Start.func1(0xf8e000, 0xe000e0) + /usr/local/go/src/os/exec/exec.go:400 +0x1c +created by os/exec.(*Cmd).Start + /usr/local/go/src/os/exec/exec.go:399 +0x41c +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + + + + +-------------- + +With newer golang version +go version +go version go1.11.9 linux/arm +- show quoted text - +GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build218432843=/tmp/go-build -gno-record-gcc-switches" + + +$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +panic: runtime error: invalid memory address or nil pointer dereference +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66180] + +goroutine 11fatal error: [malloc deadlock +, panic during panic +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x66180] + +108033889401^Ifatal error: unexpected signal during runtime execution +stack trace unavailable + +Hi; we very recently fixed a QEMU bug which causes crashes like this for Go binaries running under QEMU's linux-user mode. The fix is in the v4.1.0-rc3 we've just put out and will be in the final 4.1.0 release. Could you retry with that and see if it fixes your problem, please? + + +Facing similar crash with the latest qemu, Can you give some pointers to debug further like backtrace/breakpoints or so + +$ ./qemu-4.1.0-rc3/arm-linux-user/qemu-arm --version +qemu-arm version 4.0.93 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +$ ./qemu-4.1.0-rc3/arm-linux-user/qemu-arm $GOROOT/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli +Fetching https://google.golang.org/grpc?go-get=1 + +<<< LOG Truncated>>> + +Parsing meta tags from https://golang.org/x/net/context?go-get=1 (status code 200) +get "golang.org/x/net/context": found meta tag get.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net/context?go-get=1 +get "golang.org/x/net/context": verifying non-authoritative meta tag +github.com/c9s/goprocinfo (download) +github.com/go-redis/redis (download) +github.com/golang/glog (download) +github.com/workiva/go-datastructures (download) +github.com/openconfig/ygot (download) +github.com/kylelemons/godebug (download) +github.com/openconfig/goyang (download) +go tool compile: signal: aborted (core dumped) +qemu: unhandled CPU exception 0x10004 - aborting +R00=00000000 R01=0000001e R02=00e2b180 R03=00000000 +R04=00000001 R05=000000d8 R06=000000f6 R07=f6ffec64 +R08=00000000 R09=000000e0 R10=00e1e740 R11=00e3610c +R12=00000034 R13=f6ffebc8 R14=00018d90 R15=0006668c +PSR=20000010 --C- A usr32 +go tool compile: signal: aborted (core dumped) +qemu: unhandled CPU exception 0x10004 - aborting +R00=00000000 R01=0000001e R02=00e1e690 R03=00000000 +R04=00000001 R05=00000008 R06=00000004 R07=00000003 +R08=da507899 R09=01070000 R10=01000540 R11=00e3610c +R12=f67cc015 R13=01049f1c R14=00018d90 R15=0006668c +PSR=20000010 --C- A usr32 + + +I suspect you're not using the new version of QEMU in your test. The 'go' binary will fork and exec other go binaries, and Linux binfmt-misc will use the system QEMU binary to run those, even if you were running the top level 'go' binary with the newer QEMU you've built. + +For Ubuntu this means you need to put the new QEMU binary into /usr/bin/qemu-arm-static. (Probably "cat /proc/sys/fs/binfmt_misc/qemu-arm" will tell you what interpreter binary it uses. It will also have a "flags:" line -- if this includes 'F' for fixed then you will have to take further measures beyond just copying the new QEMU binary into place, because it means the kernel opens the interpreter binary very early, rather than only on-demand, so it will have effectively cached the old version. I'm not sure how you get it to forget about the old version and re-open the new version.) + + +Thanks @pmaydell, I missed to check binfmt qemu version. I checked in qemu 4.0.93 and I don't issue any issue. + + +Thanks for retesting! (We haven't quite got 4.1.0 out of the door yet, so I'll just move this bug to 'fix committed' for the moment; we'll update it back to 'fix released' next week.) + + diff --git a/results/classifier/118/review/1840646 b/results/classifier/118/review/1840646 new file mode 100644 index 000000000..231e6e9d1 --- /dev/null +++ b/results/classifier/118/review/1840646 @@ -0,0 +1,78 @@ +mistranslation: 0.900 +network: 0.767 +graphic: 0.676 +device: 0.655 +socket: 0.620 +semantic: 0.430 +register: 0.395 +virtual: 0.395 +ppc: 0.378 +performance: 0.317 +peripherals: 0.295 +PID: 0.250 +debug: 0.249 +vnc: 0.238 +user-level: 0.233 +files: 0.220 +i386: 0.190 +arm: 0.178 +TCG: 0.177 +risc-v: 0.173 +x86: 0.148 +boot: 0.118 +kernel: 0.106 +VMM: 0.087 +permissions: 0.076 +architecture: 0.075 +hypervisor: 0.057 +assembly: 0.051 +KVM: 0.020 +-------------------- +debug: 0.484 +arm: 0.262 +x86: 0.130 +network: 0.101 +files: 0.086 +virtual: 0.082 +TCG: 0.062 +hypervisor: 0.029 +i386: 0.017 +device: 0.011 +assembly: 0.008 +PID: 0.008 +register: 0.007 +ppc: 0.007 +semantic: 0.006 +boot: 0.005 +risc-v: 0.003 +kernel: 0.003 +socket: 0.003 +user-level: 0.003 +performance: 0.002 +VMM: 0.002 +graphic: 0.002 +peripherals: 0.001 +architecture: 0.001 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122: logical fault + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122:16: warning: Logical conjunction always evaluates to false: alen <= 0 && alen >= sizeof(args) - 1. [incorrectLogicOperator] + +Source code is + + if (alen <= 0 && alen >= sizeof(args) - 1) { + +Maybe better code: + + if (alen <= 0 || alen >= sizeof(args) - 1) { + +This isn't QEMU code -- it's just the source for third-party ROMs that we ship with QEMU because we also ship the ROM binaries. Please report it to the upstream project. + + +(Anything in a git submodule will be third-party code that's not part of QEMU.) + + diff --git a/results/classifier/118/review/1840648 b/results/classifier/118/review/1840648 new file mode 100644 index 000000000..897a6d60f --- /dev/null +++ b/results/classifier/118/review/1840648 @@ -0,0 +1,77 @@ +mistranslation: 0.860 +device: 0.617 +socket: 0.612 +semantic: 0.594 +graphic: 0.577 +network: 0.492 +register: 0.426 +files: 0.425 +ppc: 0.422 +performance: 0.303 +debug: 0.302 +user-level: 0.302 +kernel: 0.289 +virtual: 0.261 +vnc: 0.260 +boot: 0.255 +peripherals: 0.249 +PID: 0.238 +x86: 0.238 +i386: 0.223 +permissions: 0.207 +arm: 0.187 +risc-v: 0.166 +VMM: 0.151 +assembly: 0.136 +TCG: 0.131 +architecture: 0.114 +hypervisor: 0.092 +KVM: 0.084 +-------------------- +debug: 0.799 +arm: 0.373 +x86: 0.231 +virtual: 0.188 +hypervisor: 0.147 +TCG: 0.046 +files: 0.043 +PID: 0.020 +i386: 0.019 +device: 0.015 +boot: 0.008 +assembly: 0.008 +ppc: 0.006 +register: 0.006 +semantic: 0.003 +risc-v: 0.003 +kernel: 0.003 +user-level: 0.002 +performance: 0.002 +VMM: 0.002 +network: 0.002 +peripherals: 0.002 +permissions: 0.001 +architecture: 0.001 +socket: 0.001 +graphic: 0.001 +mistranslation: 0.001 +vnc: 0.000 +KVM: 0.000 + +qemu-4.1.0/roms/edk2/MdeModulePkg/Universal/Disk/UdfDxe/FileName.c:161: logical fault ? + +qemu-4.1.0/roms/edk2/MdeModulePkg/Universal/Disk/UdfDxe/FileName.c:161:71: warning: Logical disjunction always evaluates to true: EXPR != '\\' || EXPR != '\0'. [incorrectLogicOperator] + +Source code is + + if ((*(FileName - 1) != L'\\') && ((*(FileName + 2) != L'\\') || + (*(FileName + 2) != L'\0'))) { + +Maybe better code: + + if ((*(FileName - 1) != L'\\') && ((*(FileName + 2) != L'\\') && + (*(FileName + 2) != L'\0'))) { + +This isn't QEMU code -- it's just the source for third-party ROMs that we ship with QEMU because we also ship the ROM binaries. Please report it to the upstream project. + + diff --git a/results/classifier/118/review/1840777 b/results/classifier/118/review/1840777 new file mode 100644 index 000000000..18878dae3 --- /dev/null +++ b/results/classifier/118/review/1840777 @@ -0,0 +1,136 @@ +register: 0.932 +assembly: 0.911 +graphic: 0.909 +user-level: 0.907 +device: 0.901 +permissions: 0.897 +virtual: 0.894 +KVM: 0.892 +performance: 0.892 +peripherals: 0.887 +risc-v: 0.882 +architecture: 0.882 +mistranslation: 0.879 +boot: 0.875 +vnc: 0.860 +debug: 0.858 +kernel: 0.858 +PID: 0.856 +semantic: 0.846 +TCG: 0.845 +arm: 0.826 +VMM: 0.813 +hypervisor: 0.799 +socket: 0.780 +files: 0.773 +network: 0.773 +ppc: 0.742 +i386: 0.729 +x86: 0.690 +-------------------- +kernel: 0.968 +debug: 0.350 +KVM: 0.193 +x86: 0.077 +virtual: 0.071 +TCG: 0.034 +PID: 0.030 +hypervisor: 0.021 +register: 0.020 +arm: 0.017 +performance: 0.017 +device: 0.013 +files: 0.011 +i386: 0.008 +risc-v: 0.007 +semantic: 0.007 +VMM: 0.006 +peripherals: 0.006 +assembly: 0.005 +socket: 0.005 +architecture: 0.004 +user-level: 0.004 +graphic: 0.002 +ppc: 0.002 +mistranslation: 0.002 +network: 0.001 +permissions: 0.001 +vnc: 0.001 +boot: 0.001 + +raspi3 machine can not shutdown + +tag v4.1.0 + +Running "shutdown" within a raspi3 image leads to kernel panic: + + Starting Power-Off... +[ 39.719617] systemd-shutdow: 39 output lines suppressed due to ratelimiting +[ 39.922997] systemd-shutdown[1]: Syncing filesystems and block devices. +[ 39.962415] systemd-shutdown[1]: Sending SIGTERM to remaining processes... +[ 40.006842] systemd-journald[186]: Received SIGTERM from PID 1 (systemd-shutdow). +[ 40.060745] systemd-shutdown[1]: Sending SIGKILL to remaining processes... +[ 40.098318] systemd-shutdown[1]: Unmounting file systems. +[ 40.108351] systemd-shutdown[455]: Remounting '/' read-only in with options 'data=ordered'. +[ 40.128919] EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered +[ 40.152844] systemd-shutdown[1]: All filesystems unmounted. +[ 40.153239] systemd-shutdown[1]: Deactivating swaps. +[ 40.154701] systemd-shutdown[1]: All swaps deactivated. +[ 40.155062] systemd-shutdown[1]: Detaching loop devices. +[ 40.159792] systemd-shutdown[1]: All loop devices detached. +[ 40.201746] kvm: exiting hardware virtualization +[ 40.207628] reboot: Power down +bcm2835-pm: unimplemented device read (size 4, offset 0x20) +bcm2835-pm: unimplemented device write (size 4, value 0x5a000555, offset 0x20) +bcm2835-pm: unimplemented device write (size 4, value 0x5a00000a, offset 0x24) +bcm2835-pm: unimplemented device read (size 4, offset 0x1c) +bcm2835-pm: unimplemented device write (size 4, value 0x5a000020, offset 0x1c) +[ 40.229604] systemd-shutdow: 4 output lines suppressed due to ratelimiting +[ 40.230849] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 +[ 40.230849] +[ 40.231781] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.14.0-3-arm64 #1 Debian 4.14.12-2 +[ 40.232470] Hardware name: Raspberry Pi 3 Model B (DT) +[ 40.233206] Call trace: +[ 40.234096] [<ffff00000808a708>] dump_backtrace+0x0/0x280 +[ 40.234519] [<ffff00000808a9ac>] show_stack+0x24/0x30 +[ 40.234972] [<ffff00000885bb7c>] dump_stack+0x9c/0xc0 +[ 40.235378] [<ffff0000080d1bd4>] panic+0x138/0x2b4 +[ 40.235805] [<ffff0000080d72d4>] do_exit+0xa04/0xa08 +[ 40.236260] [<ffff0000080fa9d8>] SyS_reboot+0x178/0x260 +[ 40.236915] Exception stack(0xffff00000802bec0 to 0xffff00000802c000) +[ 40.237487] bec0: fffffffffee1dead 0000000028121969 000000004321fedc adc576109fd73c00 +[ 40.237949] bee0: 0000000000000028 8080800000000000 0000ffffad2392f8 7f7f7f7f7f7f7f7f +[ 40.238376] bf00: 000000000000008e 0000000000000000 0000000000000069 0000000000000000 +[ 40.238744] bf20: 0000000000000000 0000000000000020 0000000000000000 0000000000000000 +[ 40.239101] bf40: 0000aaaabeb9bf10 0000ffffad3030a8 0000000000000001 0000000000000000 +[ 40.239462] bf60: 0000000000000000 0000aaaaeb6e0040 0000aaaabeb8a008 0000fffff7ce8d30 +[ 40.239802] bf80: 0000001b00000004 0000aaaabeb8a000 0000fffff7ce8fa8 0000000000000000 +[ 40.240134] bfa0: 0000aaaabeb9b000 0000fffff7ce8ac0 0000aaaabeb8741c 0000fffff7ce8aa0 +[ 40.240468] bfc0: 0000ffffad3030c4 0000000000000000 fffffffffee1dead 000000000000008e +[ 40.240809] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +[ 40.241194] [<ffff0000080837b0>] el0_svc_naked+0x24/0x28 +[ 40.241930] Kernel Offset: disabled +[ 40.242197] CPU features: 0x002004 +[ 40.242450] Memory Limit: none +[ 40.243063] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 +[ 40.243063] +qemu-system-aarch64: terminating on signal 2 + +I'm guessing from: + + bcm2835-pm: unimplemented device read (size 4, offset 0x20) + bcm2835-pm: unimplemented device write (size 4, value 0x5a000555, offset 0x20) + bcm2835-pm: unimplemented device write (size 4, value 0x5a00000a, offset 0x24) + bcm2835-pm: unimplemented device read (size 4, offset 0x1c) + bcm2835-pm: unimplemented device write (size 4, value 0x5a000020, offset 0x1c) + +That we don't implement the power control parts of the SoC and therefor the kernel got to a bit it wasn't expecting. + + +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/64 + + diff --git a/results/classifier/118/review/1842774 b/results/classifier/118/review/1842774 new file mode 100644 index 000000000..e26da9fb8 --- /dev/null +++ b/results/classifier/118/review/1842774 @@ -0,0 +1,1375 @@ +semantic: 0.834 +graphic: 0.830 +permissions: 0.828 +user-level: 0.817 +arm: 0.802 +assembly: 0.798 +architecture: 0.784 +socket: 0.773 +debug: 0.766 +register: 0.764 +mistranslation: 0.756 +PID: 0.755 +device: 0.746 +peripherals: 0.745 +network: 0.732 +kernel: 0.719 +performance: 0.718 +hypervisor: 0.712 +ppc: 0.711 +risc-v: 0.686 +vnc: 0.659 +boot: 0.656 +TCG: 0.655 +VMM: 0.650 +files: 0.637 +virtual: 0.636 +KVM: 0.613 +x86: 0.357 +i386: 0.352 +-------------------- +kernel: 0.981 +architecture: 0.020 +semantic: 0.019 +TCG: 0.017 +PID: 0.011 +register: 0.011 +files: 0.009 +socket: 0.009 +boot: 0.007 +VMM: 0.006 +hypervisor: 0.005 +device: 0.005 +virtual: 0.005 +risc-v: 0.004 +assembly: 0.003 +network: 0.003 +vnc: 0.003 +debug: 0.002 +graphic: 0.002 +KVM: 0.002 +mistranslation: 0.002 +performance: 0.001 +permissions: 0.001 +peripherals: 0.001 +user-level: 0.001 +i386: 0.000 +x86: 0.000 +arm: 0.000 +ppc: 0.000 + +Enhanced Hardware Support - Finalize Naming + +This feature request will provide the final naming of the next machine + +Marking as "Incomplete" while awaiting the final naming. + +@IBM: Does it affect the kernel only, or also other packages (like for example qemu) ? + +And btw. I think it will not be limited to eoan/19.10, but will also affect older Ubuntu releases (probably all the way down to xenial). + +------- Comment From <email address hidden> 2019-09-10 05:41 EDT------- +@CAN: Yes, a qemu patch is also required. For previous distros another LP is available.: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842916 + +------- Comment From <email address hidden> 2019-09-18 07:58 EDT------- +See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e2251132995b962281aa80ab54a9288f9e0b6b + +commit a0e2251132995b962281aa80ab54a9288f9e0b6b +Author: Martin Schwidefsky <email address hidden> +Date: Wed Feb 6 08:22:11 2019 +0100 + +s390: add support for IBM z15 machines + +Add detection for machine types 0x8562 and 8x8561 and set the ELF platform +name to z15. Add the miscellaneous-instruction-extension 3 facility to +the list of facilities for z15. + +And allow to generate code that only runs on a z15 machine. + +Reviewed-by: Christian Borntraeger <email address hidden> +Signed-off-by: Martin Schwidefsky <email address hidden> +Signed-off-by: Heiko Carstens <email address hidden> + +for the kernel upstream commit. Applies cleanly to git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan + +Kernel SRU request submitted: +https://lists.ubuntu.com/archives/kernel-team/2019-September/thread.html#103839 + +Patch a0e2251132995b9 is a kernel patch, thus this is certainly not something we need to track in the upstream QEMU bugtracker. + +------- Comment From <email address hidden> 2019-09-24 02:28 EDT------- +The QEMU patch is + +commit 7505deca0bfa859136ec6419dbafc504f22fcac2 +s390x/cpumodel: Add the z15 name to the description of gen15a + +Hi, +since [1] doesn't change the identifier (it stays gen15a), so the only thing that is changing is the description of e.g. seen here: +$ qemu-system-s390x -cpu ? | grep gen15 +s390 gen15a-base IBM 8561 GA1 (static, migration-safe) +s390 gen15a IBM 8561 GA1 (migration-safe) +s390 gen15b-base IBM 8562 GA1 (static, migration-safe) +s390 gen15b IBM 8562 GA1 (migration-safe) + +As far as I see it has no functional impact - is that correct? + +Under that assumption I'm considering this for Eoan as prio-medium (as it is still open), and for SRUs as whishlist. +It might be added there "along" some other SRU later, but isn't reasonable on its own triggering downloads for millions of users - if you don't agree please outline why we'd need this any sooner there. + +FYI: Please note that changing the actual type "gen15a" to something else is even less of an option at least for SRUs as people could use it already and the update would break them. + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=7505deca + +Test build [1] seems ok and MP opened [2]. +But the change is trivial so that should be quick ... + +[1]: https://launchpad.net/~paelzer/+archive/ubuntu/fix-1842774-z15-model-name-eoan +[2]: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/373118 + +In fact while I was waiting to submit this the MP got reviewed. +Uploaded to Eoan ... + +But since beta freeze is in place acceptance there might have to wait a few days. + +------- Comment From <email address hidden> 2019-09-24 09:11 EDT------- +Yes this only updates the description. The name gen15a can not be changed without hurting migration compatibility. +We are looking into adding an alias for cpu names, but this would be a future change. +With that medium priority is fine. + +This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu9 + +--------------- +qemu (1:4.0+dfsg-0ubuntu9) eoan; urgency=medium + + * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: + update the z15 model name (LP: #1842774) + + -- Christian Ehrhardt <email address hidden> Tue, 24 Sep 2019 11:42:58 +0200 + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +------- Comment From <email address hidden> 2019-10-04 03:38 EDT------- +> This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu9 +> +> --------------- +> qemu (1:4.0+dfsg-0ubuntu9) eoan; urgency=medium +> +> * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: +> update the z15 model name (LP: #1842774) +> +> -- Christian Ehrhardt <email address hidden> Tue, 24 Sep 2019 + +QEMU part verified on eoan-proposed + +This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'. + +If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. + +See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! + + +Verification (more a regression testing) done on disco. + +And verification (more a regression testing) done on bionic, too. + +------- Comment From <email address hidden> 2019-10-07 08:11 EDT------- +Functionality successfully tested fine on disco-proposed 5.0.0-32-generic #34-Ubuntu SMP Wed Oct 2 02:06:00 UTC 2019 s390x s390x s390x GNU/Linux + +I can see z15 in the aux vector: + +# gdb --quiet ls +Reading symbols from ls... +(No debugging symbols found in ls) +(gdb) start +Temporary breakpoint 1 at 0x45ae +Starting program: /usr/bin/ls + +Temporary breakpoint 1, 0x000002aa000045ae in main () +(gdb) info auxv +33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x3fffdffe000 +16 AT_HWCAP Machine-dependent CPU capability hints 0x7ffff +6 AT_PAGESZ System page size 4096 +17 AT_CLKTCK Frequency of times() 100 +3 AT_PHDR Program headers for program 0x2aa00000040 +4 AT_PHENT Size of program header entry 56 +5 AT_PHNUM Number of program headers 9 +7 AT_BASE Base address of interpreter 0x3fffdf80000 +8 AT_FLAGS Flags 0x0 +9 AT_ENTRY Entry point of program 0x2aa00006320 +11 AT_UID Real user ID 0 +12 AT_EUID Effective user ID 0 +13 AT_GID Real group ID 0 +14 AT_EGID Effective group ID 0 +23 AT_SECURE Boolean, was exec setuid-like? 0 +25 AT_RANDOM Address of 16 random bytes 0x3fffffff73c +31 AT_EXECFN File name of executable 0x3ffffffffec "/usr/bin/ls" +15 AT_PLATFORM String identifying platform 0x3fffffff74c "z15" +0 AT_NULL End of vector 0x0 + +------- Comment From <email address hidden> 2019-10-07 08:31 EDT------- +Same test (auxv) also works with bionic-proposed. +Linux t35lp61 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:22:41 UTC 2019 s390x s390x s390x GNU/Linux + +This bug was fixed in the package linux - 5.3.0-17.18 + +--------------- +linux (5.3.0-17.18) eoan; urgency=medium + + * eoan/linux: 5.3.0-17.18 -proposed tracker (LP: #1846641) + + * CVE-2019-17056 + - nfc: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17055 + - mISDN: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17054 + - appletalk: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17053 + - ieee802154: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-17052 + - ax25: enforce CAP_NET_RAW for raw sockets + + * CVE-2019-15098 + - ath6kl: fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe() + + * xHCI on AMD Stoney Ridge cannot detect USB 2.0 or 1.1 devices. + (LP: #1846470) + - x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect + + * Re-enable linux-libc-dev build on i386 (LP: #1846508) + - [Packaging] Build only linux-libc-dev for i386 + - [Debian] final-checks -- ignore archtictures with no binaries + + * arm64: loop on boot after installing linux-generic-hwe-18.04-edge/bionic- + proposed (LP: #1845820) + - [Config] Disable CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT + + * Revert ESE DASD discard support (LP: #1846219) + - SAUCE: Revert "s390/dasd: Add discard support for ESE volumes" + + * Miscellaneous Ubuntu changes + - update dkms package versions + +linux (5.3.0-16.17) eoan; urgency=medium + + * eoan/linux: 5.3.0-16.17 -proposed tracker (LP: #1846204) + + * zfs fails to build on s390x with debug symbols enabled (LP: #1846143) + - SAUCE: s390: Mark atomic const ops always inline + +linux (5.3.0-15.16) eoan; urgency=medium + + * eoan/linux: 5.3.0-15.16 -proposed tracker (LP: #1845987) + + * Drop i386 build for 19.10 (LP: #1845714) + - [Packaging] Remove x32 arch references from control files + - [Debian] final-checks -- Get arch list from debian/control + + * ZFS kernel modules lack debug symbols (LP: #1840704) + - [Debian] Fix conditional for setting zfs debug package path + + * Use pyhon3-sphinx instead of python-sphinx for building html docs + (LP: #1845808) + - [Packaging] Update sphinx build dependencies to python3 packages + + * Kernel panic with 19.10 beta image (LP: #1845454) + - efi/tpm: Don't access event->count when it isn't mapped. + - efi/tpm: don't traverse an event log with no events + - efi/tpm: only set efi_tpm_final_log_size after successful event log parsing + +linux (5.3.0-14.15) eoan; urgency=medium + + * eoan/linux: 5.3.0-14.15 -proposed tracker (LP: #1845728) + + * Drop i386 build for 19.10 (LP: #1845714) + - [Debian] Remove support for producing i386 kernels + - [Debian] Don't use CROSS_COMPILE for i386 configs + + * udevadm trigger will fail when trying to add /sys/devices/vio/ + (LP: #1845572) + - SAUCE: powerpc/vio: drop bus_type from parent device + + * Trying to online dasd drive results in invalid input/output from the kernel + on z/VM (LP: #1845323) + - SAUCE: s390/dasd: Fix error handling during online processing + + * intel-lpss driver conflicts with write-combining MTRR region (LP: #1845584) + - SAUCE: mfd: intel-lpss: add quirk for Dell XPS 13 7390 2-in-1 + + * Support Hi1620 zip hw accelerator (LP: #1845355) + - [Config] Enable HiSilicon QM/ZIP as modules + - crypto: hisilicon - add queue management driver for HiSilicon QM module + - crypto: hisilicon - add hardware SGL support + - crypto: hisilicon - add HiSilicon ZIP accelerator support + - crypto: hisilicon - add SRIOV support for ZIP + - Documentation: Add debugfs doc for hisi_zip + - crypto: hisilicon - add debugfs for ZIP and QM + - MAINTAINERS: add maintainer for HiSilicon QM and ZIP controller driver + - crypto: hisilicon - fix kbuild warnings + - crypto: hisilicon - add dependency for CRYPTO_DEV_HISI_ZIP + - crypto: hisilicon - init curr_sgl_dma to fix compile warning + - crypto: hisilicon - add missing single_release + - crypto: hisilicon - fix error handle in hisi_zip_create_req_q + - crypto: hisilicon - Fix warning on printing %p with dma_addr_t + - crypto: hisilicon - Fix return value check in hisi_zip_acompress() + - crypto: hisilicon - avoid unused function warning + + * SafeSetID LSM should be built but disabled by default (LP: #1845391) + - LSM: SafeSetID: Stop releasing uninitialized ruleset + - [Config] Build SafeSetID LSM but don't enable it by default + + * CONFIG_LSM should not specify loadpin since it is not built (LP: #1845383) + - [Config] loadpin shouldn't be in CONFIG_LSM + + * Add new pci-id's for CML-S, ICL (LP: #1845317) + - drm/i915/icl: Add missing device ID + - drm/i915/cml: Add Missing PCI IDs + + * Thunderbolt support for ICL (LP: #1844680) + - thunderbolt: Correct path indices for PCIe tunnel + - thunderbolt: Move NVM upgrade support flag to struct icm + - thunderbolt: Use 32-bit writes when writing ring producer/consumer + - thunderbolt: Do not fail adding switch if some port is not implemented + - thunderbolt: Hide switch attributes that are not set + - thunderbolt: Expose active parts of NVM even if upgrade is not supported + - thunderbolt: Add support for Intel Ice Lake + - ACPI / property: Add two new Thunderbolt property GUIDs to the list + + * Ubuntu 19.10 - Additional PCI patch and fix (LP: #1844668) + - s390/pci: fix MSI message data + + * Enhanced Hardware Support - Finalize Naming (LP: #1842774) + - s390: add support for IBM z15 machines + - [Config] CONFIG_MARCH_Z15=n, CONFIG_TUNE_Z15=n + + * Eoan update: v5.3.1 upstream stable release (LP: #1845642) + - USB: usbcore: Fix slab-out-of-bounds bug during device reset + - media: tm6000: double free if usb disconnect while streaming + - phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current + - ip6_gre: fix a dst leak in ip6erspan_tunnel_xmit + - net/sched: fix race between deactivation and dequeue for NOLOCK qdisc + - net_sched: let qdisc_put() accept NULL pointer + - udp: correct reuseport selection with connected sockets + - xen-netfront: do not assume sk_buff_head list is empty in error handling + - net: dsa: Fix load order between DSA drivers and taggers + - net: stmmac: Hold rtnl lock in suspend/resume callbacks + - KVM: coalesced_mmio: add bounds checking + - Documentation: sphinx: Add missing comma to list of strings + - firmware: google: check if size is valid when decoding VPD data + - serial: sprd: correct the wrong sequence of arguments + - tty/serial: atmel: reschedule TX after RX was started + - nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds + - Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}" + - ovl: fix regression caused by overlapping layers detection + - phy: qcom-qmp: Correct ready status, again + - floppy: fix usercopy direction + - media: technisat-usb2: break out of loop at end of buffer + - Linux 5.3.1 + + * ZFS kernel modules lack debug symbols (LP: #1840704) + - [Debian]: Remove hardcoded $(pkgdir) in debug symbols handling + - [Debian]: Handle debug symbols for modules in extras too + - [Debian]: Check/link modules with debug symbols after DKMS modules + - [Debian]: Warn about modules without debug symbols + - [Debian]: dkms-build: new parameter for debug package directory + - [Debian]: dkms-build: zfs: support for debug symbols + - [Debian]: dkms-build: Avoid executing post-processor scripts twice + - [Debian]: dkms-build: Move zfs special-casing into configure script + + * /proc/self/maps paths missing on live session (was vlc won't start; eoan + 19.10 & bionic 18.04 ubuntu/lubuntu/kubuntu/xubuntu/ubuntu-mate dailies) + (LP: #1842382) + - SAUCE: Revert "UBUNTU: SAUCE: shiftfs: enable overlayfs on shiftfs" + + -- Seth Forshee <email address hidden> Thu, 03 Oct 2019 16:57:05 -0500 + +@SRU Team: +As outlined above this is important for IBM to get product names right everywhere. But at the same time this is "only" a change in a description which doesn't qualify an SRU on its own. So we agreed to only upload it once there is another SRU. + +I now have an Qemu SRU for Bionic that I want to group this with, this will make the Disco SRU go without any other changes to not have Bionic->Disco->Eoan switch back and forth. Therefore I'll upload it for Disco as well when doing so. + +This bug was fixed in the package linux - 5.0.0-32.34 + +--------------- +linux (5.0.0-32.34) disco; urgency=medium + + * disco/linux: 5.0.0-32.34 -proposed tracker (LP: #1846097) + + * CVE-2019-14814 // CVE-2019-14815 // CVE-2019-14816 + - mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings + + * CVE-2019-15505 + - media: technisat-usb2: break out of loop at end of buffer + + * CVE-2019-2181 + - binder: check for overflow when alloc for security context + + * Support Hi1620 zip hw accelerator (LP: #1845355) + - [Config] Enable HiSilicon QM/ZIP as modules + - crypto: hisilicon - add queue management driver for HiSilicon QM module + - crypto: hisilicon - add hardware SGL support + - crypto: hisilicon - add HiSilicon ZIP accelerator support + - crypto: hisilicon - add SRIOV support for ZIP + - Documentation: Add debugfs doc for hisi_zip + - crypto: hisilicon - add debugfs for ZIP and QM + - MAINTAINERS: add maintainer for HiSilicon QM and ZIP controller driver + - crypto: hisilicon - fix kbuild warnings + - crypto: hisilicon - add dependency for CRYPTO_DEV_HISI_ZIP + - crypto: hisilicon - init curr_sgl_dma to fix compile warning + - crypto: hisilicon - add missing single_release + - crypto: hisilicon - fix error handle in hisi_zip_create_req_q + - crypto: hisilicon - Fix warning on printing %p with dma_addr_t + - crypto: hisilicon - Fix return value check in hisi_zip_acompress() + - crypto: hisilicon - avoid unused function warning + + * xfrm interface: several kernel panic (LP: #1836261) + - xfrm interface: fix memory leak on creation + - xfrm interface: avoid corruption on changelink + - xfrm interface: ifname may be wrong in logs + - xfrm interface: fix list corruption for x-netns + - xfrm interface: fix management of phydev + + * shiftfs: drop entries from cache on unlink (LP: #1841977) + - SAUCE: shiftfs: fix buggy unlink logic + + * shiftfs: mark kmem_cache as reclaimable (LP: #1842059) + - SAUCE: shiftfs: mark slab objects SLAB_RECLAIM_ACCOUNT + + * Suspend to RAM(S3) does not wake up for latest megaraid and mpt3sas + adapters(SAS3.5 onwards) (LP: #1838751) + - PCI: Restore Resizable BAR size bits correctly for 1MB BARs + + * No sound inputs from the external microphone and headset on a Dell machine + (LP: #1842265) + - ALSA: hda - Expand pin_match function to match upcoming new tbls + - ALSA: hda - Define a fallback_pin_fixup_tbl for alc269 family + + * Add -fcf-protection=none when using retpoline flags (LP: #1843291) + - SAUCE: kbuild: add -fcf-protection=none when using retpoline flags + + * Disco update: upstream stable patchset 2019-09-25 (LP: #1845390) + - bridge/mdb: remove wrong use of NLM_F_MULTI + - cdc_ether: fix rndis support for Mediatek based smartphones + - ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()' + - isdn/capi: check message length in capi_write() + - ixgbe: Fix secpath usage for IPsec TX offload. + - net: Fix null de-reference of device refcount + - net: gso: Fix skb_segment splat when splitting gso_size mangled skb having + linear-headed frag_list + - net: phylink: Fix flow control resolution + - net: sched: fix reordering issues + - sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero + - sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()' + - sctp: use transport pf_retrans in sctp_do_8_2_transport_strike + - tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR + - tipc: add NULL pointer check before calling kfree_rcu + - tun: fix use-after-free when register netdev failed + - gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist + - gpio: fix line flag validation in linehandle_create + - Btrfs: fix assertion failure during fsync and use of stale transaction + - ixgbe: Prevent u8 wrapping of ITR value to something less than 10us + - genirq: Prevent NULL pointer dereference in resend_irqs() + - KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it + as target for memset() + - KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl + - KVM: x86: work around leak of uninitialized stack contents + - KVM: nVMX: handle page fault in vmread + - x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large + to fix kexec relocation errors + - powerpc: Add barrier_nospec to raw_copy_in_user() + - drm/meson: Add support for XBGR8888 & ABGR8888 formats + - clk: rockchip: Don't yell about bad mmc phases when getting + - mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue + - PCI: Always allow probing with driver_override + - gpio: fix line flag validation in lineevent_create + - ubifs: Correctly use tnc_next() in search_dh_cookie() + - driver core: Fix use-after-free and double free on glue directory + - crypto: talitos - check AES key size + - crypto: talitos - fix CTR alg blocksize + - crypto: talitos - check data blocksize in ablkcipher. + - crypto: talitos - fix ECB algs ivsize + - crypto: talitos - Do not modify req->cryptlen on decryption. + - crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking. + - firmware: ti_sci: Always request response from firmware + - drm: panel-orientation-quirks: Add extra quirk table entry for GPD MicroPC + - drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto + - Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature" + - iio: adc: stm32-dfsdm: fix data type + - modules: fix BUG when load module with rodata=n + - modules: fix compile error if don't have strict module rwx + - platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to + critclk_systems DMI table + - rsi: fix a double free bug in rsi_91x_deinit() + - x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence + GCC9 build warning + - ixgbevf: Fix secpath usage for IPsec Tx offload + - net: fixed_phy: Add forward declaration for struct gpio_desc; + - net: sock_map, fix missing ulp check in sock hash case + - Revert "mmc: bcm2835: Terminate timeout work synchronously" + - mmc: tmio: Fixup runtime PM management during probe + - mmc: tmio: Fixup runtime PM management during remove + - drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+ + - ixgbe: fix double clean of Tx descriptors with xdp + - mt76: mt76x0e: disable 5GHz band for MT7630E + - x86/ima: check EFI SetupMode too + - kvm: nVMX: Remove unnecessary sync_roots from handle_invept + - KVM: SVM: Fix detection of AMD Errata 1096 + + * Disco update: upstream stable patchset 2019-09-19 (LP: #1844722) + - ALSA: hda - Fix potential endless loop at applying quirks + - ALSA: hda/realtek - Fix overridden device-specific initialization + - ALSA: hda/realtek - Add quirk for HP Pavilion 15 + - ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL + - ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre + - sched/fair: Don't assign runtime for throttled cfs_rq + - drm/vmwgfx: Fix double free in vmw_recv_msg() + - vhost/test: fix build for vhost test + - vhost/test: fix build for vhost test - again + - batman-adv: fix uninit-value in batadv_netlink_get_ifindex() + - batman-adv: Only read OGM tvlv_len after buffer len check + - timekeeping: Use proper ktime_add when adding nsecs in coarse offset + - selftests: fib_rule_tests: use pre-defined DEV_ADDR + - powerpc/64: mark start_here_multiplatform as __ref + - media: stm32-dcmi: fix irq = 0 case + - scripts/decode_stacktrace: match basepath using shell prefix operator, not + regex + - nvme-fc: use separate work queue to avoid warning + - modules: always page-align module section allocations + - kernel/module: Fix mem leak in module_add_modinfo_attrs + - drm/vblank: Allow dynamic per-crtc max_vblank_count + - mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies + - tpm: Fix some name collisions with drivers/char/tpm.h + - drm/nouveau: Don't WARN_ON VCPI allocation failures + - drm: add __user attribute to ptr_to_compat() + - drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set + - drm/i915: Sanity check mmap length against object size + - arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's + - kvm: mmu: Fix overflow on kvm mmu page limit calculation + - KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels + - media: i2c: tda1997x: select V4L2_FWNODE + - ext4: protect journal inode's blocks using block_validity + - ARM: dts: qcom: ipq4019: Fix MSI IRQ type + - dt-bindings: mmc: Add supports-cqe property + - dt-bindings: mmc: Add disable-cqe-dcmd property. + - dm mpath: fix missing call of path selector type->end_io + - mmc: sdhci-pci: Add support for Intel CML + - PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify code + - cifs: smbd: take an array of reqeusts when sending upper layer data + - drm/amdkfd: Add missing Polaris10 ID + - kvm: Check irqchip mode before assign irqfd + - Btrfs: fix race between block group removal and block group allocation + - cifs: add spinlock for the openFileList to cifsInodeInfo + - ceph: use ceph_evict_inode to cleanup inode's resource + - KVM: x86: optimize check for valid PAT value + - KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value + - btrfs: correctly validate compression type + - dm thin metadata: check if in fail_io mode when setting needs_check + - bcache: only clear BTREE_NODE_dirty bit when it is set + - bcache: add comments for mutex_lock(&b->write_lock) + - bcache: fix race in btree_flush_write() + - drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV + - virtio/s390: fix race on airq_areas[] + - ext4: don't perform block validity checks on the journal inode + - ext4: fix block validity checks for journal inodes using indirect blocks + - ext4: unsigned int compared against zero + - PCI: Reset both NVIDIA GPU and HDA in ThinkPad P50 workaround + - gpio: pca953x: correct type of reg_direction + - gpio: pca953x: use pca953x_read_regs instead of regmap_bulk_read + - drm/nouveau/sec2/gp102: add missing MODULE_FIRMWAREs + - powerpc/64e: Drop stale call to smp_processor_id() which hangs SMP startup + - drm/i915: Disable SAMPLER_STATE prefetching on all Gen11 steppings. + - mmc: sdhci-sprd: Fix the incorrect soft reset operation when runtime + resuming + - usb: chipidea: imx: add imx7ulp support + - usb: chipidea: imx: fix EPROBE_DEFER support during driver probe + + * Disco update: upstream stable patchset 2019-09-11 (LP: #1843622) + - dmaengine: ste_dma40: fix unneeded variable warning + - nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns + - afs: Fix the CB.ProbeUuid service handler to reply correctly + - afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u() + - fs: afs: Fix a possible null-pointer dereference in afs_put_read() + - afs: Only update d_fsdata if different in afs_d_revalidate() + - nvmet-loop: Flush nvme_delete_wq when removing the port + - nvme: fix a possible deadlock when passthru commands sent to a multipath + device + - nvme-pci: Fix async probe remove race + - soundwire: cadence_master: fix register definition for SLAVE_STATE + - soundwire: cadence_master: fix definitions for INTSTAT0/1 + - auxdisplay: panel: need to delete scan_timer when misc_register fails in + panel_attach + - dmaengine: stm32-mdma: Fix a possible null-pointer dereference in + stm32_mdma_irq_handler() + - omap-dma/omap_vout_vrfb: fix off-by-one fi value + - iommu/dma: Handle SG length overflow better + - usb: gadget: composite: Clear "suspended" on reset/disconnect + - usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt + - xen/blkback: fix memory leaks + - arm64: cpufeature: Don't treat granule sizes as strict + - i2c: rcar: avoid race when unregistering slave client + - i2c: emev2: avoid race when unregistering slave client + - drm/ast: Fixed reboot test may cause system hanged + - usb: host: fotg2: restart hcd after port reset + - tools: hv: fixed Python pep8/flake8 warnings for lsvmbus + - tools: hv: fix KVP and VSS daemons exit code + - watchdog: bcm2835_wdt: Fix module autoload + - drm/bridge: tfp410: fix memleak in get_modes() + - scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value + - drm/tilcdc: Register cpufreq notifier after we have initialized crtc + - net/tls: swap sk_write_space on close + - net: tls, fix sk_write_space NULL write when tx disabled + - ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set + - ipv6: Default fib6_type to RTN_UNICAST when not set + - net/smc: make sure EPOLLOUT is raised + - tcp: make sure EPOLLOUT wont be missed + - ipv4/icmp: fix rt dst dev null pointer dereference + - mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n + - ALSA: usb-audio: Check mixer unit bitmap yet more strictly + - ALSA: line6: Fix memory leak at line6_init_pcm() error path + - ALSA: hda - Fixes inverted Conexant GPIO mic mute led + - ALSA: seq: Fix potential concurrent access to the deleted pool + - ALSA: usb-audio: Fix invalid NULL check in snd_emuusb_set_samplerate() + - ALSA: usb-audio: Add implicit fb quirk for Behringer UFX1604 + - kvm: x86: skip populating logical dest map if apic is not sw enabled + - KVM: x86: Don't update RIP or do single-step on faulting emulation + - uprobes/x86: Fix detection of 32-bit user mode + - x86/apic: Do not initialize LDR and DFR for bigsmp + - ftrace: Fix NULL pointer dereference in t_probe_next() + - ftrace: Check for successful allocation of hash + - ftrace: Check for empty hash and comment the race with registering probes + - usb-storage: Add new JMS567 revision to unusual_devs + - USB: cdc-wdm: fix race between write and disconnect due to flag abuse + - usb: hcd: use managed device resources + - usb: chipidea: udc: don't do hardware access if gadget has stopped + - usb: host: ohci: fix a race condition between shutdown and irq + - usb: host: xhci: rcar: Fix typo in compatible string matching + - USB: storage: ums-realtek: Update module parameter description for + auto_delink_en + - mei: me: add Tiger Lake point LP device ID + - mmc: sdhci-of-at91: add quirk for broken HS200 + - mmc: core: Fix init of SD cards reporting an invalid VDD range + - stm class: Fix a double free of stm_source_device + - intel_th: pci: Add support for another Lewisburg PCH + - intel_th: pci: Add Tiger Lake support + - typec: tcpm: fix a typo in the comparison of pdo_max_voltage + - fsi: scom: Don't abort operations for minor errors + - lib: logic_pio: Fix RCU usage + - lib: logic_pio: Avoid possible overlap for unregistering regions + - lib: logic_pio: Add logic_pio_unregister_range() + - drm/amdgpu: Add APTX quirk for Dell Latitude 5495 + - drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest + - drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe() + - bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after- + free + - bus: hisi_lpc: Add .remove method to avoid driver unbind crash + - VMCI: Release resource if the work is already queued + - crypto: ccp - Ignore unconfigured CCP device on suspend/resume + - Revert "cfg80211: fix processing world regdomain when non modular" + - mac80211: fix possible sta leak + - mac80211: Don't memset RXCB prior to PAE intercept + - mac80211: Correctly set noencrypt for PAE frames + - KVM: PPC: Book3S HV: Avoid lockdep debugging in TCE realmode handlers + - KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling + - KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long + - KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI + - NFS: Clean up list moves of struct nfs_page + - NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend() + - NFS: Pass error information to the pgio error cleanup routine + - NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0 + - i2c: piix4: Fix port selection for AMD Family 16h Model 30h + - x86/ptrace: fix up botched merge of spectrev1 fix + - mt76: mt76x0u: do not reset radio on resume + - Revert "ASoC: Fail card instantiation if DAI format setup fails" + - nvmet: Fix use-after-free bug when a port is removed + - nvmet-file: fix nvmet_file_flush() always returning an error + - nvme-rdma: fix possible use-after-free in connect error flow + - nvme: fix controller removal race with scan work + - IB/mlx5: Fix implicit MR release flow + - dma-direct: don't truncate dma_required_mask to bus addressing capabilities + - riscv: fix flush_tlb_range() end address for flush_tlb_page() + - drm/scheduler: use job count instead of peek + - locking/rwsem: Add missing ACQUIRE to read_slowpath exit when queue is empty + - lcoking/rwsem: Add missing ACQUIRE to read_slowpath sleep loop + - selftests/bpf: install files test_xdp_vlan.sh + - ALSA: hda/ca0132 - Add new SBZ quirk + - KVM: x86: hyper-v: don't crash on KVM_GET_SUPPORTED_HV_CPUID when + kvm_intel.nested is disabled + - x86/mm/cpa: Prevent large page split when ftrace flips RW on kernel text + - usbtmc: more sanity checking for packet size + - mmc: sdhci-cadence: enable v4_mode to fix ADMA 64-bit addressing + - mmc: sdhci-sprd: fixed incorrect clock divider + - mmc: sdhci-sprd: add SDHCI_QUIRK2_PRESET_VALUE_BROKEN + - mms: sdhci-sprd: add SDHCI_QUIRK_BROKEN_CARD_DETECTION + - mmc: sdhci-sprd: clear the UHS-I modes read from registers + - mmc: sdhci-sprd: Implement the get_max_timeout_count() interface + - mmc: sdhci-sprd: add get_ro hook function + - drm/i915/dp: Fix DSC enable code to use cpu_transcoder instead of + encoder->type + - hsr: implement dellink to clean up resources + - hsr: fix a NULL pointer deref in hsr_dev_xmit() + - hsr: switch ->dellink() to ->ndo_uninit() + - Revert "Input: elantech - enable SMBus on new (2018+) systems" + - mld: fix memory leak in mld_del_delrec() + - net: fix skb use after free in netpoll + - net: sched: act_sample: fix psample group handling on overwrite + - net_sched: fix a NULL pointer deref in ipt action + - net: stmmac: dwmac-rk: Don't fail if phy regulator is absent + - tcp: inherit timestamp on mtu probe + - tcp: remove empty skb from write queue in error cases + - x86/boot: Preserve boot_params.secure_boot from sanitizing + - spi: bcm2835aux: unifying code between polling and interrupt driven code + - spi: bcm2835aux: remove dangerous uncontrolled read of fifo + - spi: bcm2835aux: fix corruptions for longer spi transfers + - net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ + context + - netfilter: nf_tables: use-after-free in failing rule with bound set + - tools: bpftool: fix error message (prog -> object) + - hv_netvsc: Fix a warning of suspicious RCU usage + - net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx + - Bluetooth: btqca: Add a short delay before downloading the NVM + - ibmveth: Convert multicast list size for little-endian system + - gpio: Fix build error of function redefinition + - netfilter: nft_flow_offload: skip tcp rst and fin packets + - drm/mediatek: use correct device to import PRIME buffers + - drm/mediatek: set DMA max segment size + - scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure + - scsi: target: tcmu: avoid use-after-free after command timeout + - cxgb4: fix a memory leak bug + - liquidio: add cleanup in octeon_setup_iq() + - net: myri10ge: fix memory leaks + - lan78xx: Fix memory leaks + - vfs: fix page locking deadlocks when deduping files + - cx82310_eth: fix a memory leak bug + - net: kalmia: fix memory leaks + - ibmvnic: Unmap DMA address of TX descriptor buffers after use + - net: cavium: fix driver name + - wimax/i2400m: fix a memory leak bug + - ravb: Fix use-after-free ravb_tstamp_skb + - kprobes: Fix potential deadlock in kprobe_optimizer() + - HID: cp2112: prevent sleeping function called from invalid context + - x86/boot/compressed/64: Fix boot on machines with broken E820 table + - Input: hyperv-keyboard: Use in-place iterator API in the channel callback + - Tools: hv: kvp: eliminate 'may be used uninitialized' warning + - nvme-multipath: fix possible I/O hang when paths are updated + - IB/mlx4: Fix memory leaks + - infiniband: hfi1: fix a memory leak bug + - infiniband: hfi1: fix memory leaks + - selftests: kvm: fix state save/load on processors without XSAVE + - selftests/kvm: make platform_info_test pass on AMD + - ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr() + - ceph: fix buffer free while holding i_ceph_lock in + __ceph_build_xattrs_blob() + - ceph: fix buffer free while holding i_ceph_lock in fill_inode() + - KVM: arm/arm64: Only skip MMIO insn once + - afs: Fix leak in afs_lookup_cell_rcu() + - KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity + - x86/boot/compressed/64: Fix missing initialization in + find_trampoline_placement() + - libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer + - Revert "r8152: napi hangup fix after disconnect" + - r8152: remove calling netif_napi_del + - batman-adv: Fix netlink dumping of all mcast_flags buckets + - libbpf: fix erroneous multi-closing of BTF FD + - libbpf: set BTF FD for prog only when there is supported .BTF.ext data + - netfilter: nf_flow_table: fix offload for flows that are subject to xfrm + - clk: samsung: Change signature of exynos5_subcmus_init() function + - clk: samsung: exynos5800: Move MAU subsystem clocks to MAU sub-CMU + - clk: samsung: exynos542x: Move MSCL subsystem clocks to its sub-CMU + - netfilter: nf_flow_table: conntrack picks up expired flows + - netfilter: nf_flow_table: teardown flow timeout race + - ixgbe: fix possible deadlock in ixgbe_service_task() + - nvme: Fix cntlid validation when not using NVMEoF + - RDMA/cma: fix null-ptr-deref Read in cma_cleanup + - RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message + - gpio: Fix irqchip initialization order + + * New ID in ums-realtek module breaks cardreader (LP: #1838886) // Disco + update: upstream stable patchset 2019-09-11 (LP: #1843622) + - USB: storage: ums-realtek: Whitelist auto-delink support + + * ipv4: enable route flushing in network namespaces (LP: #1836912) + - ipv4: enable route flushing in network namespaces + + * Enhanced Hardware Support - Finalize Naming (LP: #1842774) + - s390: add support for IBM z15 machines + + * CVE-2019-16714 + - net/rds: Fix info leak in rds6_inc_info_copy() + + * CVE-2019-14821 + - KVM: coalesced_mmio: add bounds checking + + -- Khalid Elmously <email address hidden> Mon, 30 Sep 2019 23:52:23 -0400 + +This bug was fixed in the package linux - 4.15.0-66.75 + +--------------- +linux (4.15.0-66.75) bionic; urgency=medium + + * bionic/linux: 4.15.0-66.75 -proposed tracker (LP: #1846131) + + * Packaging resync (LP: #1786013) + - [Packaging] update helper scripts + + * CVE-2018-21008 + - rsi: add fix for crash during assertions + + * ipv6: fix neighbour resolution with raw socket (LP: #1834465) + - ipv6: constify rt6_nexthop() + - ipv6: fix neighbour resolution with raw socket + + * run_netsocktests from net in ubuntu_kernel_selftests failed with X-4.15 + (LP: #1842023) + - SAUCE: selftests: net: replace AF_MAX with INT_MAX in socket.c + + * No sound inputs from the external microphone and headset on a Dell machine + (LP: #1842265) + - ALSA: hda - Expand pin_match function to match upcoming new tbls + - ALSA: hda - Define a fallback_pin_fixup_tbl for alc269 family + + * Add -fcf-protection=none when using retpoline flags (LP: #1843291) + - SAUCE: kbuild: add -fcf-protection=none when using retpoline flags + + * Enhanced Hardware Support - Finalize Naming (LP: #1842774) + - s390: add support for IBM z15 machines + + * Bionic update: upstream stable patchset 2019-09-24 (LP: #1845266) + - bridge/mdb: remove wrong use of NLM_F_MULTI + - cdc_ether: fix rndis support for Mediatek based smartphones + - ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()' + - isdn/capi: check message length in capi_write() + - net: Fix null de-reference of device refcount + - net: gso: Fix skb_segment splat when splitting gso_size mangled skb having + linear-headed frag_list + - net: phylink: Fix flow control resolution + - sch_hhf: ensure quantum and hhf_non_hh_weight are non-zero + - sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()' + - sctp: use transport pf_retrans in sctp_do_8_2_transport_strike + - tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR + - tipc: add NULL pointer check before calling kfree_rcu + - tun: fix use-after-free when register netdev failed + - btrfs: compression: add helper for type to string conversion + - btrfs: correctly validate compression type + - Revert "MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur" + - gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist + - gpio: fix line flag validation in linehandle_create + - gpio: fix line flag validation in lineevent_create + - Btrfs: fix assertion failure during fsync and use of stale transaction + - genirq: Prevent NULL pointer dereference in resend_irqs() + - KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl + - KVM: x86: work around leak of uninitialized stack contents + - KVM: nVMX: handle page fault in vmread + - MIPS: VDSO: Prevent use of smp_processor_id() + - MIPS: VDSO: Use same -m%-float cflag as the kernel proper + - powerpc: Add barrier_nospec to raw_copy_in_user() + - drm/meson: Add support for XBGR8888 & ABGR8888 formats + - clk: rockchip: Don't yell about bad mmc phases when getting + - mtd: rawnand: mtk: Fix wrongly assigned OOB buffer pointer issue + - PCI: Always allow probing with driver_override + - ubifs: Correctly use tnc_next() in search_dh_cookie() + - driver core: Fix use-after-free and double free on glue directory + - crypto: talitos - check AES key size + - crypto: talitos - fix CTR alg blocksize + - crypto: talitos - check data blocksize in ablkcipher. + - crypto: talitos - fix ECB algs ivsize + - crypto: talitos - Do not modify req->cryptlen on decryption. + - crypto: talitos - HMAC SNOOP NO AFEU mode requires SW icv checking. + - firmware: ti_sci: Always request response from firmware + - drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto + - Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature" + - platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to + critclk_systems DMI table + - nvmem: Use the same permissions for eeprom as for nvmem + - x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence + GCC9 build warning + - ixgbe: Prevent u8 wrapping of ITR value to something less than 10us + - x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large + to fix kexec relocation errors + - modules: fix BUG when load module with rodata=n + - modules: fix compile error if don't have strict module rwx + - HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report + - Input: elan_i2c - remove Lenovo Legion Y7000 PnpID + - powerpc/mm/radix: Use the right page size for vmemmap mapping + - USB: usbcore: Fix slab-out-of-bounds bug during device reset + - phy: renesas: rcar-gen3-usb2: Disable clearing VBUS in over-current + - media: tm6000: double free if usb disconnect while streaming + - xen-netfront: do not assume sk_buff_head list is empty in error handling + - net_sched: let qdisc_put() accept NULL pointer + - KVM: coalesced_mmio: add bounds checking + - firmware: google: check if size is valid when decoding VPD data + - serial: sprd: correct the wrong sequence of arguments + - tty/serial: atmel: reschedule TX after RX was started + - mwifiex: Fix three heap overflow at parsing element in cfg80211_ap_settings + - nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds + - ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss + - s390/bpf: fix lcgr instruction encoding + - ARM: OMAP2+: Fix omap4 errata warning on other SoCs + - ARM: dts: dra74x: Fix iodelay configuration for mmc3 + - s390/bpf: use 32-bit index for tail calls + - fpga: altera-ps-spi: Fix getting of optional confd gpio + - netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info + - NFSv4: Fix return values for nfs4_file_open() + - NFSv4: Fix return value in nfs_finish_open() + - NFS: Fix initialisation of I/O result struct in nfs_pgio_rpcsetup + - Kconfig: Fix the reference to the IDT77105 Phy driver in the description of + ATM_NICSTAR_USE_IDT77105 + - qed: Add cleanup in qed_slowpath_start() + - ARM: 8874/1: mm: only adjust sections of valid mm structures + - batman-adv: Only read OGM2 tvlv_len after buffer len check + - r8152: Set memory to all 0xFFs on failed reg reads + - x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled machines + - netfilter: nf_conntrack_ftp: Fix debug output + - NFSv2: Fix eof handling + - NFSv2: Fix write regression + - kallsyms: Don't let kallsyms_lookup_size_offset() fail on retrieving the + first symbol + - cifs: set domainName when a domain-key is used in multiuser + - cifs: Use kzfree() to zero out the password + - ARM: 8901/1: add a criteria for pfn_valid of arm + - sky2: Disable MSI on yet another ASUS boards (P6Xxxx) + - i2c: designware: Synchronize IRQs when unregistering slave client + - perf/x86/intel: Restrict period on Nehalem + - perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops + - amd-xgbe: Fix error path in xgbe_mod_init() + - tools/power x86_energy_perf_policy: Fix "uninitialized variable" warnings at + -O2 + - tools/power x86_energy_perf_policy: Fix argument parsing + - tools/power turbostat: fix buffer overrun + - net: seeq: Fix the function used to release some memory in an error handling + path + - dmaengine: ti: dma-crossbar: Fix a memory leak bug + - dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe() + - x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation + - x86/hyper-v: Fix overflow bug in fill_gva_list() + - keys: Fix missing null pointer check in request_key_auth_describe() + - iommu/amd: Flush old domains in kdump kernel + - iommu/amd: Fix race in increase_address_space() + - PCI: kirin: Fix section mismatch warning + - floppy: fix usercopy direction + - binfmt_elf: move brk out of mmap when doing direct loader exec + - tcp: Reset send_head when removing skb from write-queue + - tcp: Don't dequeue SYN/FIN-segments from write-queue + - media: technisat-usb2: break out of loop at end of buffer + - tools: bpftool: close prog FD before exit on showing a single program + - netfilter: xt_physdev: Fix spurious error message in physdev_mt_check + - ibmvnic: Do not process reset during or after device removal + - net: aquantia: fix out of memory condition on rx side + + * Bionic update: upstream stable patchset 2019-09-18 (LP: #1844558) + - ALSA: hda - Fix potential endless loop at applying quirks + - ALSA: hda/realtek - Fix overridden device-specific initialization + - ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre + - sched/fair: Don't assign runtime for throttled cfs_rq + - drm/vmwgfx: Fix double free in vmw_recv_msg() + - xfrm: clean up xfrm protocol checks + - PCI: designware-ep: Fix find_first_zero_bit() usage + - PCI: dra7xx: Fix legacy INTD IRQ handling + - vhost/test: fix build for vhost test + - batman-adv: fix uninit-value in batadv_netlink_get_ifindex() + - batman-adv: Only read OGM tvlv_len after buffer len check + - hv_sock: Fix hang when a connection is closed + - powerpc/64: mark start_here_multiplatform as __ref + - arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64 + - scripts/decode_stacktrace: match basepath using shell prefix operator, not + regex + - clk: s2mps11: Add used attribute to s2mps11_dt_match + - kernel/module: Fix mem leak in module_add_modinfo_attrs + - ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL + - {nl,mac}80211: fix interface combinations on crypto controlled devices + - x86/ftrace: Fix warning and considate ftrace_jmp_replace() and + ftrace_call_replace() + - media: stm32-dcmi: fix irq = 0 case + - modules: always page-align module section allocations + - scsi: qla2xxx: Move log messages before issuing command to firmware + - keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h + - Drivers: hv: kvp: Fix two "this statement may fall through" warnings + - remoteproc: qcom: q6v5-mss: add SCM probe dependency + - KVM: x86: hyperv: enforce vp_index < KVM_MAX_VCPUS + - KVM: x86: hyperv: consistently use 'hv_vcpu' for 'struct kvm_vcpu_hv' + variables + - drm/i915: Fix intel_dp_mst_best_encoder() + - drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLE + - drm/i915/gen9+: Fix initial readout for Y tiled framebuffers + - drm/atomic_helper: Disallow new modesets on unregistered connectors + - Drivers: hv: kvp: Fix the indentation of some "break" statements + - Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up + - drm/amd/dm: Understand why attaching path/tile properties are needed + - ARM: davinci: da8xx: define gpio interrupts as separate resources + - ARM: davinci: dm365: define gpio interrupts as separate resources + - ARM: davinci: dm646x: define gpio interrupts as separate resources + - ARM: davinci: dm355: define gpio interrupts as separate resources + - ARM: davinci: dm644x: define gpio interrupts as separate resources + - media: vim2m: use workqueue + - media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work + - drm/i915: Restore sane defaults for KMS on GEM error load + - KVM: PPC: Book3S HV: Fix race between kvm_unmap_hva_range and MMU mode + switch + - Btrfs: clean up scrub is_dev_replace parameter + - Btrfs: fix deadlock with memory reclaim during scrub + - btrfs: Remove extent_io_ops::fill_delalloc + - btrfs: Fix error handling in btrfs_cleanup_ordered_extents + - scsi: megaraid_sas: Fix combined reply queue mode detection + - scsi: megaraid_sas: Add check for reset adapter bit + - media: vim2m: only cancel work if it is for right context + - ARC: show_regs: lockdep: re-enable preemption + - ARC: mm: do_page_fault fixes #1: relinquish mmap_sem if signal arrives while + handle_mm_fault + - IB/uverbs: Fix OOPs upon device disassociation + - drm/vblank: Allow dynamic per-crtc max_vblank_count + - drm/i915/ilk: Fix warning when reading emon_status with no output + - mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies + - tpm: Fix some name collisions with drivers/char/tpm.h + - bcache: replace hard coded number with BUCKET_GC_GEN_MAX + - bcache: treat stale && dirty keys as bad keys + - KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run + - iio: adc: exynos-adc: Add S5PV210 variant + - iio: adc: exynos-adc: Use proper number of channels for Exynos4x12 + - drm/nouveau: Don't WARN_ON VCPI allocation failures + - x86/kvmclock: set offset for kvm unstable clock + - powerpc/kvm: Save and restore host AMR/IAMR/UAMOR + - mmc: renesas_sdhi: Fix card initialization failure in high speed mode + - btrfs: scrub: pass fs_info to scrub_setup_ctx + - btrfs: init csum_list before possible free + - PCI: qcom: Don't deassert reset GPIO during probe + - drm: add __user attribute to ptr_to_compat() + - CIFS: Fix error paths in writeback code + - CIFS: Fix leaking locked VFS cache pages in writeback retry + - drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set + - drm/i915: Sanity check mmap length against object size + - IB/mlx5: Reset access mask when looping inside page fault handler + - kvm: mmu: Fix overflow on kvm mmu page limit calculation + - x86/kvm: move kvm_load/put_guest_xcr0 into atomic context + - KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels + - cifs: Fix lease buffer length error + - ext4: protect journal inode's blocks using block_validity + - dm mpath: fix missing call of path selector type->end_io + - blk-mq: free hw queue's resource in hctx's release handler + - mmc: sdhci-pci: Add support for Intel ICP + - mmc: sdhci-pci: Add support for Intel CML + - dm crypt: move detailed message into debug level + - kvm: Check irqchip mode before assign irqfd + - drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2) + - drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after alloc + - Btrfs: fix race between block group removal and block group allocation + - cifs: add spinlock for the openFileList to cifsInodeInfo + - IB/hfi1: Avoid hardlockup with flushlist_lock + - apparmor: reset pos on failure to unpack for various functions + - staging: wilc1000: fix error path cleanup in wilc_wlan_initialize() + - scsi: zfcp: fix request object use-after-free in send path causing wrong + traces + - cifs: Properly handle auto disabling of serverino option + - ceph: use ceph_evict_inode to cleanup inode's resource + - KVM: x86: optimize check for valid PAT value + - KVM: VMX: Always signal #GP on WRMSR to MSR_IA32_CR_PAT with bad value + - KVM: VMX: Fix handling of #MC that occurs during VM-Entry + - KVM: VMX: check CPUID before allowing read/write of IA32_XSS + - resource: Include resource end in walk_*() interfaces + - resource: Fix find_next_iomem_res() iteration issue + - resource: fix locking in find_next_iomem_res() + - pstore: Fix double-free in pstore_mkfile() failure path + - dm thin metadata: check if in fail_io mode when setting needs_check + - drm/panel: Add support for Armadeus ST0700 Adapt + - ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips + - iommu/iova: Remove stale cached32_node + - gpio: don't WARN() on NULL descs if gpiolib is disabled + - i2c: at91: disable TXRDY interrupt after sending data + - i2c: at91: fix clk_offset for sama5d2 + - mm/migrate.c: initialize pud_entry in migrate_vma() + - iio: adc: gyroadc: fix uninitialized return code + - NFSv4: Fix delegation state recovery + - bcache: only clear BTREE_NODE_dirty bit when it is set + - bcache: add comments for mutex_lock(&b->write_lock) + - virtio/s390: fix race on airq_areas[] + - ext4: don't perform block validity checks on the journal inode + - ext4: fix block validity checks for journal inodes using indirect blocks + - ext4: unsigned int compared against zero + - powerpc/tm: Remove msr_tm_active() + + * Bionic update: upstream stable patchset 2019-09-10 (LP: #1843463) + - net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ + context + - hv_netvsc: Fix a warning of suspicious RCU usage + - net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx + - Bluetooth: btqca: Add a short delay before downloading the NVM + - ibmveth: Convert multicast list size for little-endian system + - gpio: Fix build error of function redefinition + - drm/mediatek: use correct device to import PRIME buffers + - drm/mediatek: set DMA max segment size + - cxgb4: fix a memory leak bug + - liquidio: add cleanup in octeon_setup_iq() + - net: myri10ge: fix memory leaks + - lan78xx: Fix memory leaks + - vfs: fix page locking deadlocks when deduping files + - cx82310_eth: fix a memory leak bug + - net: kalmia: fix memory leaks + - wimax/i2400m: fix a memory leak bug + - ravb: Fix use-after-free ravb_tstamp_skb + - kprobes: Fix potential deadlock in kprobe_optimizer() + - HID: cp2112: prevent sleeping function called from invalid context + - Input: hyperv-keyboard: Use in-place iterator API in the channel callback + - Tools: hv: kvp: eliminate 'may be used uninitialized' warning + - IB/mlx4: Fix memory leaks + - ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr() + - ceph: fix buffer free while holding i_ceph_lock in + __ceph_build_xattrs_blob() + - ceph: fix buffer free while holding i_ceph_lock in fill_inode() + - KVM: arm/arm64: Only skip MMIO insn once + - libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer + - spi: bcm2835aux: unifying code between polling and interrupt driven code + - spi: bcm2835aux: remove dangerous uncontrolled read of fifo + - spi: bcm2835aux: fix corruptions for longer spi transfers + - net: fix skb use after free in netpoll + - net_sched: fix a NULL pointer deref in ipt action + - net: stmmac: dwmac-rk: Don't fail if phy regulator is absent + - tcp: inherit timestamp on mtu probe + - tcp: remove empty skb from write queue in error cases + - net: sched: act_sample: fix psample group handling on overwrite + - mld: fix memory leak in mld_del_delrec() + - x86/boot: Preserve boot_params.secure_boot from sanitizing + - tools: bpftool: fix error message (prog -> object) + - scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure + - afs: Fix leak in afs_lookup_cell_rcu() + + * Bionic update: upstream stable patchset 2019-09-09 (LP: #1843338) + - dmaengine: ste_dma40: fix unneeded variable warning + - auxdisplay: panel: need to delete scan_timer when misc_register fails in + panel_attach + - iommu/dma: Handle SG length overflow better + - usb: gadget: composite: Clear "suspended" on reset/disconnect + - usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt + - xen/blkback: fix memory leaks + - i2c: rcar: avoid race when unregistering slave client + - i2c: emev2: avoid race when unregistering slave client + - drm/ast: Fixed reboot test may cause system hanged + - usb: host: fotg2: restart hcd after port reset + - tools: hv: fix KVP and VSS daemons exit code + - watchdog: bcm2835_wdt: Fix module autoload + - drm/bridge: tfp410: fix memleak in get_modes() + - scsi: ufs: Fix RX_TERMINATION_FORCE_ENABLE define value + - drm/tilcdc: Register cpufreq notifier after we have initialized crtc + - ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term + - ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit + - net/smc: make sure EPOLLOUT is raised + - tcp: make sure EPOLLOUT wont be missed + - mm/zsmalloc.c: fix build when CONFIG_COMPACTION=n + - ALSA: line6: Fix memory leak at line6_init_pcm() error path + - ALSA: seq: Fix potential concurrent access to the deleted pool + - kvm: x86: skip populating logical dest map if apic is not sw enabled + - KVM: x86: Don't update RIP or do single-step on faulting emulation + - x86/apic: Do not initialize LDR and DFR for bigsmp + - ftrace: Fix NULL pointer dereference in t_probe_next() + - ftrace: Check for successful allocation of hash + - ftrace: Check for empty hash and comment the race with registering probes + - usb-storage: Add new JMS567 revision to unusual_devs + - USB: cdc-wdm: fix race between write and disconnect due to flag abuse + - usb: chipidea: udc: don't do hardware access if gadget has stopped + - usb: host: ohci: fix a race condition between shutdown and irq + - usb: host: xhci: rcar: Fix typo in compatible string matching + - USB: storage: ums-realtek: Update module parameter description for + auto_delink_en + - uprobes/x86: Fix detection of 32-bit user mode + - mmc: sdhci-of-at91: add quirk for broken HS200 + - mmc: core: Fix init of SD cards reporting an invalid VDD range + - stm class: Fix a double free of stm_source_device + - intel_th: pci: Add support for another Lewisburg PCH + - intel_th: pci: Add Tiger Lake support + - drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest + - VMCI: Release resource if the work is already queued + - crypto: ccp - Ignore unconfigured CCP device on suspend/resume + - Revert "cfg80211: fix processing world regdomain when non modular" + - mac80211: fix possible sta leak + - KVM: PPC: Book3S: Fix incorrect guest-to-user-translation error handling + - KVM: arm/arm64: vgic: Fix potential deadlock when ap_list is long + - KVM: arm/arm64: vgic-v2: Handle SGI bits in GICD_I{S,C}PENDR0 as WI + - NFS: Clean up list moves of struct nfs_page + - NFSv4/pnfs: Fix a page lock leak in nfs_pageio_resend() + - NFS: Pass error information to the pgio error cleanup routine + - NFS: Ensure O_DIRECT reports an error if the bytes read/written is 0 + - i2c: piix4: Fix port selection for AMD Family 16h Model 30h + - x86/ptrace: fix up botched merge of spectrev1 fix + - Revert "ASoC: Fail card instantiation if DAI format setup fails" + - nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns + - afs: Fix the CB.ProbeUuid service handler to reply correctly + - dmaengine: stm32-mdma: Fix a possible null-pointer dereference in + stm32_mdma_irq_handler() + - omap-dma/omap_vout_vrfb: fix off-by-one fi value + - arm64: cpufeature: Don't treat granule sizes as strict + - tools: hv: fixed Python pep8/flake8 warnings for lsvmbus + - ipv4/icmp: fix rt dst dev null pointer dereference + - ALSA: hda - Fixes inverted Conexant GPIO mic mute led + - usb: hcd: use managed device resources + - lib: logic_pio: Fix RCU usage + - lib: logic_pio: Avoid possible overlap for unregistering regions + - lib: logic_pio: Add logic_pio_unregister_range() + - drm/amdgpu: Add APTX quirk for Dell Latitude 5495 + - drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe() + - bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after- + free + + * New ID in ums-realtek module breaks cardreader (LP: #1838886) // Bionic + update: upstream stable patchset 2019-09-09 (LP: #1843338) + - USB: storage: ums-realtek: Whitelist auto-delink support + + * TC filters are broken on Mellanox after upstream stable updates + (LP: #1842502) + - net/mlx5e: Remove redundant vport context vlan update + - net/mlx5e: Properly order min inline mode setup while parsing TC matches + - net/mlx5e: Get the required HW match level while parsing TC flow matches + - net/mlx5e: Always use the match level enum when parsing TC rule match + - net/mlx5e: Don't match on vlan non-existence if ethertype is wildcarded + + -- Khalid Elmously <email address hidden> Mon, 30 Sep 2019 23:02:24 -0400 + +Uploaded the Disco version along the upload to Bionic for SRU Team review and acceptance into proposed. + +All autopkgtests for the newly accepted linux-bluefield (5.0.0-1003.12) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +fsprotect/unknown (armhf) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-bluefield + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +All autopkgtests for the newly accepted linux-bluefield (5.0.0-1003.12) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +fsprotect/unknown (armhf) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-bluefield + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +------- Comment From <email address hidden> 2019-11-04 11:27 EDT------- +*** Bug 181316 has been marked as a duplicate of this bug. *** + +All autopkgtests for the newly accepted linux-gcp-5.3 (5.3.0-1008.9~18.04.1) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +linux-gcp-5.3/unknown (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#linux-gcp-5.3 + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +This got surpassed by a security upload while waiting for SRU Team. +I have uploaded rebased versions to -unapproved. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:3.1+dfsg-2ubuntu3.7 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.21 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +All autopkgtests for the newly accepted qemu (1:2.11+dfsg-1ubuntu7.21) for bionic have finished running. +The following regressions have been reported in tests triggered by the package: + +vagrant-mutate/1.2.0-3 (armhf) +systemd/237-3ubuntu10.31 (i386) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +------- Comment From <email address hidden> 2019-11-22 09:45 EDT------- +bionic-proposed looks good. + +All autopkgtests for the newly accepted qemu (1:3.1+dfsg-2ubuntu3.7) for disco have finished running. +The following regressions have been reported in tests triggered by the package: + +cinder/2:14.0.1-0ubuntu1 (amd64, s390x, i386, armhf, arm64, ppc64el) +systemd/240-6ubuntu5.7 (amd64) +nova/2:19.0.1-0ubuntu2.1 (armhf) +ubuntu-image/1.7+19.04ubuntu1 (s390x) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +------- Comment From <email address hidden> 2019-11-22 11:44 EDT------- +disco is also good. + +The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + +This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.21 + +--------------- +qemu (1:2.11+dfsg-1ubuntu7.21) bionic; urgency=medium + + * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: + update the z15 model name (LP: #1842774) + * d/p/u/lp-1847948-*: allow MSIX BAR mapping on VFIO in general and use that + instead of emulation on ppc64 increasing performance of e.g. NVME + passthrough (LP: #1847948) + + -- Christian Ehrhardt <email address hidden> Tue, 15 Oct 2019 11:23:23 +0200 + +This bug was fixed in the package qemu - 1:3.1+dfsg-2ubuntu3.7 + +--------------- +qemu (1:3.1+dfsg-2ubuntu3.7) disco; urgency=medium + + * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch: + update the z15 model name (LP: #1842774) + + -- Christian Ehrhardt <email address hidden> Tue, 15 Oct 2019 11:37:44 +0200 + +------- Comment From <email address hidden> 2019-12-09 06:53 EDT------- +IBM Bugzilla status -> closed, Fix Released with all requested distros + diff --git a/results/classifier/118/review/1846 b/results/classifier/118/review/1846 new file mode 100644 index 000000000..85cc353d9 --- /dev/null +++ b/results/classifier/118/review/1846 @@ -0,0 +1,85 @@ +semantic: 0.875 +mistranslation: 0.851 +hypervisor: 0.818 +graphic: 0.818 +virtual: 0.806 +user-level: 0.800 +peripherals: 0.780 +arm: 0.755 +debug: 0.748 +register: 0.740 +device: 0.729 +assembly: 0.723 +permissions: 0.708 +ppc: 0.697 +performance: 0.647 +PID: 0.640 +i386: 0.596 +architecture: 0.593 +risc-v: 0.591 +x86: 0.586 +TCG: 0.582 +VMM: 0.557 +files: 0.554 +network: 0.531 +vnc: 0.512 +boot: 0.471 +socket: 0.382 +KVM: 0.354 +kernel: 0.306 +-------------------- +debug: 0.953 +x86: 0.932 +virtual: 0.819 +user-level: 0.774 +performance: 0.652 +kernel: 0.475 +boot: 0.115 +hypervisor: 0.069 +assembly: 0.060 +register: 0.040 +i386: 0.035 +PID: 0.032 +files: 0.026 +TCG: 0.023 +device: 0.007 +semantic: 0.004 +socket: 0.004 +VMM: 0.003 +peripherals: 0.003 +risc-v: 0.002 +architecture: 0.002 +vnc: 0.002 +graphic: 0.001 +arm: 0.001 +network: 0.001 +permissions: 0.001 +mistranslation: 0.000 +KVM: 0.000 +ppc: 0.000 + +Regression in q35 avocado tests due to fix for misaligned IO access +Description of problem: +Generally I'm seeing intermittent hangs, somewhere after the clock initialisation. + +``` +[ 4.137020] ALSA device list: +[ 4.137861] No soundcards found. +[ 4.634128] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 +[ 24.085574] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: +[ 24.085712] rcu: 0-...!: (0 ticks this GP) idle=4d18/0/0x0 softirq=54/54 fqs=0 (false positive?) +[ 24.085712] (detected by 1, t=21004 jiffies, g=-1003, q=2151 ncpus=2) +[ 24.085712] Sending NMI from CPU 1 to CPUs 0: +[ 4.647507] NMI backtrace for cpu 0 +[ 4.647507] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.11 #5 +[ 4.647507] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 +[ 4.647507] RIP: 0010:amd_e400_idle+0x39/0x40 +[ 4.647507] Code: 00 e8 fb ab 0d 00 eb 07 0f 00 2d c2 7d 1d 01 fb f4 fa 31 ff e8 e8 ab 0d 00 fb c3 cc cc cc cc eb 07 0f 00 2d a9 7d 1d 01 fb f4 <c3> cc cc cc cc 66 90 bf +01 00 00 00 e8 a6 e4 06 00 65 48 8b 04 25 +``` + +In avocado the hang generally times out and the test fails. +Steps to reproduce: +See above command line. It's racy. +Additional information: + diff --git a/results/classifier/118/review/1847793 b/results/classifier/118/review/1847793 new file mode 100644 index 000000000..748078bea --- /dev/null +++ b/results/classifier/118/review/1847793 @@ -0,0 +1,312 @@ +user-level: 0.827 +register: 0.806 +virtual: 0.776 +PID: 0.775 +assembly: 0.767 +peripherals: 0.757 +device: 0.754 +debug: 0.697 +KVM: 0.686 +boot: 0.680 +files: 0.643 +arm: 0.635 +architecture: 0.623 +permissions: 0.618 +mistranslation: 0.609 +graphic: 0.608 +ppc: 0.605 +vnc: 0.590 +VMM: 0.585 +TCG: 0.570 +performance: 0.568 +socket: 0.567 +risc-v: 0.562 +x86: 0.557 +network: 0.538 +hypervisor: 0.530 +semantic: 0.520 +kernel: 0.461 +i386: 0.442 +-------------------- +virtual: 0.981 +hypervisor: 0.958 +x86: 0.805 +KVM: 0.800 +kernel: 0.433 +user-level: 0.123 +debug: 0.114 +TCG: 0.061 +files: 0.045 +register: 0.036 +PID: 0.029 +device: 0.026 +socket: 0.019 +graphic: 0.017 +boot: 0.017 +VMM: 0.014 +semantic: 0.009 +assembly: 0.005 +network: 0.004 +performance: 0.003 +peripherals: 0.003 +permissions: 0.003 +risc-v: 0.002 +ppc: 0.002 +architecture: 0.002 +vnc: 0.001 +i386: 0.001 +arm: 0.001 +mistranslation: 0.000 + +qemu 4.1.0 - Corrupt guest filesystem after new vm install + +When I install a new vm with qemu 4.1.0 all the guest filesystems are corrupt. The first boot from the install dvd iso is ok and the installer work fine. But the guest system hangs after the installer finishes and I reboot the guest. I can see the grub boot menue but the system cannot load the initramfs. + +Testet with: +- RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and / partition) +Guided install with the graphical installer, no lvm selected. +- Debian Stable/Buster (Debian uses ext4 for / and /home partition) +Guidet install with the graphical installer and default options. + +Used commandline to create the vm disk image: +qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G + +Used qemu commandline for vm installation: +#!/bin/sh +# vmtest10 Installation +# +/usr/bin/qemu-system-x86_64 -cpu SandyBridge-IBRS \ + -soundhw hda \ + -M q35 \ + -k de \ + -vga qxl \ + -machine accel=kvm \ + -m 4096 \ + -display gtk \ + -drive file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom \ + -drive file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback \ + -boot once=d,menu=off \ + -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \ + -netdev bridge,br=br0,id=vlan0 \ + -rtc base=localtime \ + -name "vmtest10" \ + -usb -device usb-tablet \ + -spice disable-ticketing \ + -device virtio-serial-pci \ + -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ + -chardev spicevmc,id=spicechannel0,name=vdagent $* + +Host OS: +Archlinux (last updated at 10.10.2019) +Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux +No libvirt in use. + + +With qemu 4.0.0 it works fine without any errors. + +Hi Claus, + Some things to try: + + a) after you quit qemu can you try qemu-img check on the qcow2 file to see if it's happy? + b) If you repeat your test using a raw image file rather than a qcow2 is it any happier? + c) How repeatable is it? If it's very repeatable it would be great if you could perform a git bisect to find which commit breaks it; we can walk you through it if you've not done it before. + +Hi David, + +a) +> qemu-img check /volumes/disk2-part2/images/vmtest10-1.qcow2 +No errors were found on the image. +24794/327680 = 7.57% allocated, 9.28% fragmented, 0.00% compressed clusters +Image end offset: 1625751552 + +> qemu-img info /volumes/disk2-part2/images/vmtest10-1.qcow2 +image: vmtest10-1.qcow2 +file format: qcow2 +virtual size: 20 GiB (21474836480 bytes) +disk size: 1.29 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +b) +The raw image file works without any errors after install and reboot. +I created the image file with: +qemu-img create -f raw /volumes/disk2-part2/images/vmtest10-1.img 20G +Changes to the qemu commandline: +-drive format=raw,file=/volumes/disk2-part2/images/vmtest10-1.img,if=virtio,media=disk,cache=writeback \ + +c) +I can always repeat this behavior since 4.1.0 is out. +I could perform a git bisect. But I need help, I've never done that before. + +OK, thanks. + This might be the same problem as https://bugs.launchpad.net/qemu/+bug/1846427 +but we'll have to see. + +For a bisect; first of all, check out qemu from git and build 4.1.0; +check to make sure this breaks. +Now, see the git bisect instructions at: +https://git-scm.com/docs/git-bisect + +do: +git bisect start +git bisect bad +git bisect good v4.0.0 + +it'll then checkout a commit somewhere in between for you; build it, and then do either + +git bisect good or git bisect bad + +and it'll pick another commit + +It'll probably take 13 builds to nail the offending commit. + +Hi Claus, + +Do you use XFS on the host? + +Max + +I can confirm exactly the same issue on Arch linux with ext4 filesystem (qemu-4.1.0). + +After downgrading from 4.1.0 => 4.0.0 everything is running normal again, no corruption detected and all qcow2 images stays healthy. + +Hi Max, from my <https://bugs.launchpad.net/qemu/+bug/1846427/comments/8>: I've seen corruption on ext4. + +The bug reported here is not about qcow2 metadata corruption, but about guest data corruption (qemu-img check reports a clean image). It’s entirely possible (and I would even say likely) that there are two different causes. + +We know about two guest data corruptions already (which appeared in 4.1), and both seem to only appear on XFS. We have fixed one, the other we don’t quite know yet. + +Therefore, I’m wondering whether this is a guest data corruption that we probably already know about (because it’s on XFS), or whether we don’t (because it isn’t). + +In any case, I would separate these two bug reports on the basis that this one here is about guest data corruption, whereas 1846427 is about qcow2 metadata corruption. + +Max + +i've seen guest data corruption and qcow2 corruption on ext4. + +i've seen one case where the guest (win10) reports corruption but qemu-img check does not, but that's the outlier, usually both guest and qemu-img report corruption. + +for me the issue seems to only be win10 guests using virtio-scsi, i've not seen it on any of 25+ linux/solaris/macos/win2019 guests no matter what device driver/cache/trim i use. + +current workaround is convert from qcow2 to raw, everything else stays the same and i have no issues. + +I suppose that the problem described in bug 1846427 can also affect guest data, so I think it makes sense to divide based on whether there are only data corruptions or both data and metadata corruptions. + +So far, I don’t know of a report of pure guest data corruptions (without qcow2 metadata being affected) that didn’t happen on XFS, so I assume there is an issue that affects both data and metadata on all filesystems (described by 1846427; Kevin has sent a patch series upstream ot address it), and another one that only affects guest data and only occurs on XFS (this one). + +Actually, there are two problems we know of on XFS: + +The first one was a bug in qemu that has been fixed upstream by b2c6f23f4a9f6d8f1b648705cd46d3713b78d6a2. People that don’t use master but the 4.1 release instead are likely to hit that problem instead of the other one. + +The second one seems to be a kernel bug. When fallocating (writing zeroes in our case) and writing to a file in parallel, the write is discarded if: +- The fallocated area begins at or after the EOF, +- The written area begins after the fallocated area, +- The write is submitted through the AIO interface (io_submit()), +- The write and the fallocate operation are submitted before either one finishes (i.e. concurrently), +- The fallocate operation finishes after the write. + +In qemu, this happens only with aio=native, and then most of the time when an FALLOC_FL_ZERO_RANGE happens after the EOF while a write after that range is ongoing. + + +Claus as the reporter didn’t use aio=native, so if he’s indeed on XFS, he can’t have hit this second bug. If he’s on XFS, he will most likely have hit the first one that’s already fixed in master. + + +Still, we need to fix the second bug. As for how… It looks to me like a kernel bug, so in qemu we can’t do anything to fix it. But we should probably work around it. Kevin has proposed making zero-writes on XFS serializing until infinity, basically (i.e. UINT64_MAX in practice). That gives us some layering problems (either the file-posix block driver needs access to the TrackedRequest to extend its length, or the generic block layer needs to know whether a file-posix node is on XFS), and it yields the question of how to detect whether the bug has been fixed in the kernel. + +Max + +I have the same (related?) issue and wanted to add my experience with it. I had 3 qemu qcow2 VM running on ArchLinux. I never used snapshots or something like it. Just normal start&shutdown. 2 of these VMs were also ArchLinux running on ext4. Both of these VMs had a data corruption inside the quest. The data being corrupted were files I had not touched in month (large tar archives). One guest was running on a SSD with discard, the other VM was running on a normal hard drive without any discard. +The last VM was a Windows 10 VM. While the VM was running fine, after "fixing" the image issues with qemu-img -r all hdd.qcow2 the Windows 10 installation was unbootable and beyond repair with normal Windows tools. + +While the VMs are running I saw these lines printed by qemu (for all VMs in question): + +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: Invalid argument + +I recreated my VMs and I now chose btrfs as a filesystem. No issues yet on the image. I also recreated the Windows 10 VM. It worked fine a couple of days. Today I checked the image, after I saw the free_clusters lines above again: + +Many many lines like this: +Leaked cluster 260703 refcount=1 reference=0 +ERROR cluster 260739 refcount=0 reference=1 +ERROR OFLAG_COPIED data cluster: l2_entry=800000038ec10000 refcount=0 + +638 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +339 leaked clusters were found on the image. +This means waste of disk space, but no harm to data. +314734/4096000 = 7.68% allocated, 26.70% fragmented, 0.00% compressed clusters +Image end offset: 21138374656 + +The installation itself still works but I don't know if there are any silently corrupted files in there. + +QEMU 4.1.0 from ArchLinux +Host-Filesystem is ext4 +Start-Parameter (the same on all VMs): + +qemu-system-x86_64 -cpu Haswell-noTSX -M q35 -enable-kvm -smp 4,cores=4,threads=1,sockets=1 -net nic,model=virtio -net user,hostname=WindowsKVM.local -drive if=none,id=hd,file=hdd.qcow2,discard=unmap -device virtio-scsi-pci,id=scsi --enable-kvm -device scsi-hd,drive=hd -m 4096 -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=./OVMF_VARS.fd -vga std -drive file=Windows10ISO/Windows.iso,index=0,media=cdrom -drive file=virtio-win-0.1.173.iso,index=1,media=cdrom -no-quit + +There is a patch for the XFS kernel driver to fix the bug: https://www.spinics.net/lists/linux-xfs/msg33429.html + +On the qemu side, we’re still discussing on how to work around the bug in the 4.2 release. + +Max + +Sorry for the delay,I was busy doing my job the last two weeks. + +I use XFS V5 on both main host (5.3.7-arch1-2-ARCH) and backup host (5.3.5-arch1-1-ARCH). + +It seems I ran in the first bug that has been fixed upstream. +With git master (git clone at 18.10.) I could not reproduce the failure on my backup host. +I installed an RedHat 7.6 VM as always and the VM works without any errors. The only thing I noticed was, the first boot after installation lasts longer as with qemu 4.0.0. + +After this I checked the archlinux repositories an found in AUR the qemu-git package. I removed the official qemu packages from my main host and installed this (qemu-git 8:v4.1.0.r1699.gf9bec78137-1). +The behavior is the same as on the backup host, the VM installation works without any errors as well as additional tasks (i. e. complete the basic installation to an full desktop installation). +The last days I used the main hosts with this package for my daily work. At the end of the day I checked the filesystems from the used existing, or new created VMs and didn't found any errors. + +May be for archlinux user who needs the 4.1.0 qemu version the qemu-git package from AUR is a possible workaround. + +Claus + + +Which filesystems does this apply to? Excludes ZFS? + + +Hi Claus, + +Thanks for the info! By now we know that the XFS bug can only be triggered with aio=native (for -drive), and since you aren’t using that, you won’t hit that. + +I suppose using git master works in the meantime, but in general of course it isn’t advisable for stability. (Yes, yes, I know, right now the released version is the broken one... :() + +4.1.1 and 4.2.0 will be released soon, which fix the qemu bug. + + +Hi Wayne, + +It applies only to XFS. There are two bugs, one in qemu 4.1.0 (will be fixed in 4.1.1 and 4.2.0), and one in XFS (we will have a workaround in 4.2.0, and I hope in 4.1.1, too). + + +Max + +Can we close this ticket now? + +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/review/1853083 b/results/classifier/118/review/1853083 new file mode 100644 index 000000000..3fa71fb99 --- /dev/null +++ b/results/classifier/118/review/1853083 @@ -0,0 +1,212 @@ +risc-v: 0.843 +permissions: 0.833 +mistranslation: 0.827 +peripherals: 0.819 +semantic: 0.818 +graphic: 0.810 +debug: 0.781 +performance: 0.777 +device: 0.777 +user-level: 0.769 +architecture: 0.754 +boot: 0.748 +register: 0.747 +network: 0.737 +PID: 0.723 +assembly: 0.705 +vnc: 0.700 +ppc: 0.684 +virtual: 0.679 +socket: 0.670 +arm: 0.640 +files: 0.610 +TCG: 0.601 +kernel: 0.590 +VMM: 0.568 +hypervisor: 0.560 +KVM: 0.426 +i386: 0.402 +x86: 0.351 +-------------------- +boot: 0.759 +TCG: 0.724 +ppc: 0.574 +debug: 0.442 +virtual: 0.163 +user-level: 0.100 +hypervisor: 0.043 +vnc: 0.031 +files: 0.018 +device: 0.014 +PID: 0.011 +kernel: 0.007 +semantic: 0.005 +socket: 0.004 +performance: 0.004 +register: 0.004 +permissions: 0.002 +network: 0.002 +architecture: 0.002 +graphic: 0.002 +assembly: 0.001 +peripherals: 0.001 +VMM: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 +arm: 0.000 +KVM: 0.000 + +qemu ppc64 4.0 boot AIX5.1 hung + +When boot AIX5.1 from cdrom device, qemu hung there, no further info is displayed and cpu consumption is high. + +Did this ever worked? + +No, this happened when I tried to install the AIX5.1 on qemu ppc64. + +No, I don't think that these old AIX versions ever worked in QEMU. You might be more or less lucky with later versions, though, see e.g.: + + https://bugs.launchpad.net/qemu/+bug/1829682 + +Anyway, when reporting bugs, please always provide the command line that you used to start QEMU, otherwise bugs are hardly reproducible. + +What I don't understand is ppc64 for IBM machine emulation, but qemu ppc64 can't support AIX most of the time, but can support Linux on power very well. + +I'm running this to start the AIX5.1 installation on qemu: +#!/bin/bash +qemu-system-ppc64 -cpu POWER8 -machine pseries -m 2048 -serial mon:stdio -hda aix-hdd.qcow2 -cdrom /Download/AIX5.1/VOLUME1.iso -prom-env boot-command='boot cdrom: -s verbose' + + +and it got: +[root@192 emu]# ./aix51 +VNC server running on ::1:5900 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8000000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + USB Keyboard + USB mouse +No console specified using screen & keyboard + + Welcome to Open Firmware + + Copyright (c) 2004, 2017 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: -s verbose from: /vdevice/v-scsi@71000003/disk@8200000000000000: ... + +and just hung there, took lots of CPU time, never proceed further. + + +AIX 5.1 is quite a bit older than POWER8, so I don't think that it will run with this processor anymore. You could try "power5" or "970fx" as CPU (maybe even the "40p" machine instead of "pseries"), but I guess it won't make a big difference - the QEMU pseries machine has been written for later operating systems in mind, there was never a big effort to get older operating systems running with it. + +Tried POWER5, but got +[root@192 emu]# ./aix51 +qemu-system-ppc64: unable to find CPU model 'POWER5' + + +[root@192 emu]# qemu-system-ppc64 --version +QEMU emulator version 4.1.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +[root@192 emu]# + + +With +qemu-system-ppc64 -cpu power5+ -machine pseries -m 2048 -serial mon:stdio -hda aix-hdd.qcow2 -cdrom /Download/AIX5.1/VOLUME1.iso -prom-env boot-command='boot cdrom: -s verbose' + +got: +VNC server running on ::1:5900 + + +SLOF ********************************************************************** +QEMU Starting + Build Date = Jul 3 2019 12:26:14 + FW Version = git-ba1ab360eebe6338 + Press "s" to enter Open Firmware. + +Populating /vdevice methods +Populating /vdevice/vty@71000000 +Populating /vdevice/nvram@71000001 +Populating /vdevice/l-lan@71000002 +Populating /vdevice/v-scsi@71000003 + SCSI: Looking for devices + 8000000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" + 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" +Populating /pci@800000020000000 + 00 0000 (D) : 1234 1111 qemu vga + 00 0800 (D) : 1033 0194 serial bus [ usb-xhci ] +Installing QEMU fb + + + +Scanning USB + XHCI: Initializing + + +( 700 ) Program Exception [ fff ] + + + R0 .. R7 R8 .. R15 R16 .. R23 R24 .. R31 +000000007dbf36f4 000000007e4594a8 0000000000000000 000000007dc06400 +000000007e669dc0 0000000000000100 0000000000000000 000000007dc0ae70 +000000007dc10700 000000007e45c000 000000007e466010 000000007e459488 +000000007e45c000 000000007dc50700 000000007dc0b040 0000200081021000 +0000000000000000 000000007e436000 0000000000008000 0000200081020040 +0000000000000fff 0000000000000000 000000000000f003 0000200081020070 +000000007e466008 0000000000000000 0000000000000006 0000000000000002 +0000000001180000 0000000000000000 000000007e66a050 000000007e459488 + + CR / XER LR / CTR SRR0 / SRR1 DAR / DSISR + 80000408 000000007dbf3650 000000007dbf366c 0000000000000000 +0000000000000000 0000000000000000 8000000000080000 00000000 + + +1 > + +Answering comment #4: +> What I don't understand is ppc64 for IBM machine emulation, but qemu ppc64 +> can't support AIX most of the time, but can support Linux on power very well. + +QEMU doesn't implement the full PAPR specification. Historically we've only +added the bits that are essential for a Linux guest to be happy. + +AIX 5.1 is fairly old and neither IBM, nor the QEMU community invested time +and effort in getting it to work under QEMU. AIX being a closed source OS +certainly didn't help things to go forward. + +Things have changed recently though. IBM added virtio drivers and some +workarounds to AIX, as well some fixes to QEMU. Latest AIX 7.2 releases +should now be able to run under QEMU with a POWER8 or newer CPU model. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1856335 b/results/classifier/118/review/1856335 new file mode 100644 index 000000000..d764e18f3 --- /dev/null +++ b/results/classifier/118/review/1856335 @@ -0,0 +1,1132 @@ +semantic: 0.926 +permissions: 0.911 +debug: 0.904 +graphic: 0.883 +register: 0.875 +performance: 0.847 +architecture: 0.844 +ppc: 0.838 +PID: 0.838 +assembly: 0.836 +device: 0.825 +peripherals: 0.817 +files: 0.806 +mistranslation: 0.805 +user-level: 0.803 +vnc: 0.803 +socket: 0.794 +kernel: 0.771 +arm: 0.752 +virtual: 0.730 +x86: 0.721 +TCG: 0.720 +risc-v: 0.700 +network: 0.677 +VMM: 0.638 +KVM: 0.582 +hypervisor: 0.517 +boot: 0.506 +i386: 0.380 +-------------------- +KVM: 0.807 +virtual: 0.202 +performance: 0.077 +hypervisor: 0.076 +x86: 0.017 +kernel: 0.012 +socket: 0.010 +architecture: 0.007 +debug: 0.005 +files: 0.005 +register: 0.004 +TCG: 0.003 +PID: 0.003 +device: 0.003 +risc-v: 0.002 +VMM: 0.002 +boot: 0.002 +semantic: 0.002 +user-level: 0.001 +assembly: 0.001 +network: 0.001 +graphic: 0.001 +peripherals: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 +ppc: 0.000 +i386: 0.000 +arm: 0.000 + +Cache Layout wrong on many Zen Arch CPUs + +AMD CPUs have L3 cache per 2, 3 or 4 cores. Currently, TOPOEXT seems to always map Cache ass if it was an 4-Core per CCX CPU, which is incorrect, and costs upwards 30% performance (more realistically 10%) in L3 Cache Layout aware applications. + +Example on a 4-CCX CPU (1950X /w 8 Cores and no SMT): + + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <topology sockets='1' cores='8' threads='1'/> + +In windows, coreinfo reports correctly: + +****---- Unified Cache 1, Level 3, 8 MB, Assoc 16, LineSize 64 +----**** Unified Cache 6, Level 3, 8 MB, Assoc 16, LineSize 64 + +On a 3-CCX CPU (3960X /w 6 cores and no SMT): + + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <topology sockets='1' cores='6' threads='1'/> + +in windows, coreinfo reports incorrectly: + +****-- Unified Cache 1, Level 3, 8 MB, Assoc 16, LineSize 64 +----** Unified Cache 6, Level 3, 8 MB, Assoc 16, LineSize 64 + + +Validated against 3.0, 3.1, 4.1 and 4.2 versions of qemu-kvm. + +With newer Qemu there is a fix (that does behave correctly) in using the dies parameter: + <qemu:arg value='cores=3,threads=1,dies=2,sockets=1'/> + +The problem is that the dies are exposed differently than how AMD does it natively, they are exposed to Windows as sockets, which means, you can't ever have a machine with more than two CCX (6 cores) as Windows only supports two sockets. (Should this be reported as a separate bug?) + +Hi, + +I've since confirmed that this bug also exist (as expected) on Linux guests, as well as Zen1 EPYC 7401 CPUs, to make sure this wasn't a problem with the detection of the newer consumer platform. + +Basically it seems (looking at the code with layman eyes) that as long as you have a topology that is dividable by 4 or 8, it will always result in the wrong topology being exposed to the guest, even when the correct option can be built (12, 24 core CPUs, although, it would be great if we could support 9 Core VM CPus as that is a reasonable use case for VMs (3 CCXs of 3 Cores for a total of 9 (or 18 SMT threads)). + +Pinging the author and committer of the TopoEXT feature / EPYC cpu model as they should probably know best how to solve this issue. + +This is the commit I am referencing: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8f4202fb1080f86958782b1fca0bf0279f67d136 + +Damir, + We normally test Linux guests here. Can you please give me exact qemu command line. Even the SMP parameters(sockets,cores,threads,dies) will also work. I will try to recreate it locally first. +Give me example what works and what does not work. + +I have recently sent few more patches to fix another bug. Please check if this makes any difference. +https://patchwork.kernel.org/cover/11272063/ +https://lore.kernel<email address hidden>/ + +This should apply cleanly on git://github.com/ehabkost/qemu.git (branch x86-next) + +Note: I will be on vacation until first week of Jan. Responses will be delayed. + +Same problem for Ryzen 9 3900X. There should be 4x L3 caches, but there are only 3. + +Same results with "host-passthrough" and "EPYC-IBPB". Windows doesn't recognize the correct L3 cache layout. + +From coreinfo.exe: + +Logical Processor to Cache Map: +**---------------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------------- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64 +********---------------- Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64 +--**-------------------- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--**-------------------- Instruction Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--**-------------------- Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64 +----**------------------ Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------------ Instruction Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------------ Unified Cache 3, Level 2, 512 KB, Assoc 8, LineSize 64 +------**---------------- Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------------- Instruction Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------------- Unified Cache 4, Level 2, 512 KB, Assoc 8, LineSize 64 +--------**-------------- Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +--------**-------------- Instruction Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +--------**-------------- Unified Cache 5, Level 2, 512 KB, Assoc 8, LineSize 64 +--------********-------- Unified Cache 6, Level 3, 16 MB, Assoc 16, LineSize 64 +----------**------------ Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------------ Instruction Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------------ Unified Cache 7, Level 2, 512 KB, Assoc 8, LineSize 64 +------------**---------- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---------- Instruction Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---------- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64 +--------------**-------- Data Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------**-------- Instruction Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------**-------- Unified Cache 9, Level 2, 512 KB, Assoc 8, LineSize 64 +----------------**------ Data Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------**------ Instruction Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------**------ Unified Cache 10, Level 2, 512 KB, Assoc 8, LineSize 64 +----------------******** Unified Cache 11, Level 3, 16 MB, Assoc 16, LineSize 64 +------------------**---- Data Cache 9, Level 1, 32 KB, Assoc 8, LineSize 64 +------------------**---- Instruction Cache 9, Level 1, 32 KB, Assoc 8, LineSize 64 +------------------**---- Unified Cache 12, Level 2, 512 KB, Assoc 8, LineSize 64 +--------------------**-- Data Cache 10, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------------**-- Instruction Cache 10, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------------**-- Unified Cache 13, Level 2, 512 KB, Assoc 8, LineSize 64 +----------------------** Data Cache 11, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------------** Instruction Cache 11, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------------** Unified Cache 14, Level 2, 512 KB, Assoc 8, LineSize 64 + + +AMD does not use dies. For AMD dies is normally set to 1. You probably have to pass dies in some other ways. Did you try the latest qemu v 5.0? Please try it. + +Qemu expects the user to configure the topology based on their requirement. + +Try replacing <qemu:arg value='cores=3,threads=1,dies=2,sockets=1'/> +with <qemu:arg value='cores=6,threads=1,dies=1,sockets=1'/> + +You can also use the numa configuration. There are multiple ways you can achieve your required configuration. + + +Damir, Example of how to use numa configuration. +-smp 16,maxcpus=16,cores=16,threads=1,sockets=1 -numa node,nodeid=0,cpus=0-7 -numa node,nodeid=1,cpus=8-15 + +This will help to put all the cores in correct L3 boundary. I strongly suggest to use the latest qemu release. + +It could be an issue of how the kernel presents the CPU topology. + +Hardware: AMD Ryzen 3900X 12 core 24 threads (SMT) +Host: Kernel 5.6.6, QEMU 4.2 + +virsh capabilities | grep "cpu id" + <cpu id='0' socket_id='0' core_id='0' siblings='0,12'/> + <cpu id='1' socket_id='0' core_id='1' siblings='1,13'/> + <cpu id='2' socket_id='0' core_id='2' siblings='2,14'/> + <cpu id='3' socket_id='0' core_id='4' siblings='3,15'/> + <cpu id='4' socket_id='0' core_id='5' siblings='4,16'/> + <cpu id='5' socket_id='0' core_id='6' siblings='5,17'/> + <cpu id='6' socket_id='0' core_id='8' siblings='6,18'/> + <cpu id='7' socket_id='0' core_id='9' siblings='7,19'/> + <cpu id='8' socket_id='0' core_id='10' siblings='8,20'/> + <cpu id='9' socket_id='0' core_id='12' siblings='9,21'/> + <cpu id='10' socket_id='0' core_id='13' siblings='10,22'/> + <cpu id='11' socket_id='0' core_id='14' siblings='11,23'/> + <cpu id='12' socket_id='0' core_id='0' siblings='0,12'/> + <cpu id='13' socket_id='0' core_id='1' siblings='1,13'/> + <cpu id='14' socket_id='0' core_id='2' siblings='2,14'/> + <cpu id='15' socket_id='0' core_id='4' siblings='3,15'/> + <cpu id='16' socket_id='0' core_id='5' siblings='4,16'/> + <cpu id='17' socket_id='0' core_id='6' siblings='5,17'/> + <cpu id='18' socket_id='0' core_id='8' siblings='6,18'/> + <cpu id='19' socket_id='0' core_id='9' siblings='7,19'/> + <cpu id='20' socket_id='0' core_id='10' siblings='8,20'/> + <cpu id='21' socket_id='0' core_id='12' siblings='9,21'/> + <cpu id='22' socket_id='0' core_id='13' siblings='10,22'/> + <cpu id='23' socket_id='0' core_id='14' siblings='11,23'/> + +See how cpu id=3 gets core id=4, and cpu id=6 gets core id=8, etc. + +cat /sys/devices/system/cpu/cpu2/topology/core_id +2 + +cat /sys/devices/system/cpu/cpu3/topology/core_id +4 + +However, the association of CPU IDs to L3 caches seems to be correct: + +echo "Level CPU list";for file in /sys/devices/system/cpu/cpu*/cache/index3; do echo $(cat $file/id) " " $(cat $file/shared_cpu_list); done | sort --version-sort +Level CPU list +0 0-2,12-14 +0 0-2,12-14 +0 0-2,12-14 +0 0-2,12-14 +0 0-2,12-14 +0 0-2,12-14 +1 3-5,15-17 +1 3-5,15-17 +1 3-5,15-17 +1 3-5,15-17 +1 3-5,15-17 +1 3-5,15-17 +2 6-8,18-20 +2 6-8,18-20 +2 6-8,18-20 +2 6-8,18-20 +2 6-8,18-20 +2 6-8,18-20 +3 9-11,21-23 +3 9-11,21-23 +3 9-11,21-23 +3 9-11,21-23 +3 9-11,21-23 +3 9-11,21-23 + +There are 4 L3 caches with the correct CPU lists (6 CPUs/threads each). + +Is it possible that this weird CPU ID enumeration is causing the confusion? + +Haven't had a chance to check out QEMU 5.0, but hope to do that today. + +Finally installed QEMU 5.0.0.154 - still the same. QEMU doesn't recognize the L3 caches and still lists 3 L3 caches instead of 4 with 3 cores/6 threads. + +Here the vm.log with the qemu command line (shortened): + +2020-05-03 18:23:38.674+0000: starting up libvirt version: 5.10.0, qemu version: 5.0.50v5.0.0-154-g2ef486e76d-dirty, kernel: 5.4.36-1-MANJARO + +-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,kernel_irqchip=on,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,invtsc=on,hypervisor=on,topoext=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vpindex,hv-synic,hv-stimer,hv-vendor-id=AuthenticAMD,hv-frequencies,hv-crash,kvm=off,host-cache-info=on,l3-cache=off \ +-m 49152 \ +-mem-prealloc \ +-mem-path /dev/hugepages/libvirt/qemu/1-win10 \ +-overcommit mem-lock=off \ +-smp 24,sockets=1,cores=12,threads=2 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=34,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot menu=off,strict=on \ + + +Hi Seiger, +I am not an expert on libvirt. I mostly use qemu command line for my test. I was able to achieve the 3960X configuration with the following command line. + +# qemu-system-x86_64 -name rhel7 -m 16384 -smp 24,cores=12,threads=2,sockets=1 -hda vdisk.qcow2 -enable-kvm -net nic -net bridge,br=virbr0,helper=/usr/libexec/qemu-bridge-helper -cpu host,+topoext -nographic -numa node,nodeid=0,cpus=0-5 -numa node,nodeid=1,cpus=6-11 -numa node,nodeid=2,cpus=12-17 -numa node,nodeid=3,cpus=18-23 + +Basically qemu does not have all the information to build the topology for every configuration. It depends on libvirt for that information. See if this combination works for you. + +Hello Babu, + +Thanks for the reply and the QEMU command line. I will try to implement it in the XML. + +So essentially what you do is to define each group of cpus and associate them with a numa node: + +-numa node,nodeid=0,cpus=0-5 -numa node,nodeid=1,cpus=6-11 -numa node,nodeid=2,cpus=12-17 -numa node,nodeid=3,cpus=18-23 + +Haven't tried it but that might work. Do you need QEMU 5.0 for this to work, or is 4.2 OK? + +Yes. Sieger. Please install 5.0 it should work fine. I am not sure about 4.2. + +Hello, + +I took a look today at the layouts when using 1950X (which previously worked, and yes, admittedly, I am using Windows / coreinfo), and any basic config (previously something simple as Sockets=1,Cores=8, Theads=1 (now also Dies=1) worked, but now, the topology presents as if all cores share L3, and that each two cores share L1C/L1D/L2, like if they were smt-siblings. I would call this a serious regression. + +I don't think using Numa Nodes is an ok way to solve this (especially not when at least for 4CCX CPUs, this worked flawlessly before), as that will make numa-aware applications start taking note of numa nodes, and possibly do wierd things (plus, it introduces more configuration where it was not needed before). + +I upgraded to QEMU emulator version 5.0.50 +Using q35-5.1 (the latest) and the following libvirt configuration: + + <memory unit="KiB">50331648</memory> + <currentMemory unit="KiB">50331648</currentMemory> + <memoryBacking> + <hugepages/> + </memoryBacking> + <vcpu placement="static">24</vcpu> + <cputune> + <vcpupin vcpu="0" cpuset="0"/> + <vcpupin vcpu="1" cpuset="12"/> + <vcpupin vcpu="2" cpuset="1"/> + <vcpupin vcpu="3" cpuset="13"/> + <vcpupin vcpu="4" cpuset="2"/> + <vcpupin vcpu="5" cpuset="14"/> + <vcpupin vcpu="6" cpuset="3"/> + <vcpupin vcpu="7" cpuset="15"/> + <vcpupin vcpu="8" cpuset="4"/> + <vcpupin vcpu="9" cpuset="16"/> + <vcpupin vcpu="10" cpuset="5"/> + <vcpupin vcpu="11" cpuset="17"/> + <vcpupin vcpu="12" cpuset="6"/> + <vcpupin vcpu="13" cpuset="18"/> + <vcpupin vcpu="14" cpuset="7"/> + <vcpupin vcpu="15" cpuset="19"/> + <vcpupin vcpu="16" cpuset="8"/> + <vcpupin vcpu="17" cpuset="20"/> + <vcpupin vcpu="18" cpuset="9"/> + <vcpupin vcpu="19" cpuset="21"/> + <vcpupin vcpu="20" cpuset="10"/> + <vcpupin vcpu="21" cpuset="22"/> + <vcpupin vcpu="22" cpuset="11"/> + <vcpupin vcpu="23" cpuset="23"/> + </cputune> + <os> + <type arch="x86_64" machine="pc-q35-5.1">hvm</type> + <loader readonly="yes" type="pflash">/usr/share/OVMF/x64/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram> + <boot dev="hd"/> + <bootmenu enable="no"/> + </os> + <features> + <acpi/> + <apic/> + <hyperv> + <relaxed state="on"/> + <vapic state="on"/> + <spinlocks state="on" retries="8191"/> + <vpindex state="on"/> + <synic state="on"/> + <stimer state="on"/> + <vendor_id state="on" value="AuthenticAMD"/> + <frequencies state="on"/> + </hyperv> + <kvm> + <hidden state="on"/> + </kvm> + <vmport state="off"/> + <ioapic driver="kvm"/> + </features> + <cpu mode="host-passthrough" check="none"> + <topology sockets="1" cores="12" threads="2"/> + <cache mode="passthrough"/> + <feature policy="require" name="invtsc"/> + <feature policy="require" name="hypervisor"/> + <feature policy="require" name="topoext"/> + <numa> + <cell id="0" cpus="0-2,12-14" memory="12582912" unit="KiB"/> + <cell id="1" cpus="3-5,15-17" memory="12582912" unit="KiB"/> + <cell id="2" cpus="6-8,18-20" memory="12582912" unit="KiB"/> + <cell id="3" cpus="9-11,21-23" memory="12582912" unit="KiB"/> + </numa> + </cpu> + +... + +/var/log/libvirt/qemu/win10.log: + +-machine pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,kernel_irqchip=on,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,invtsc=on,hypervisor=on,topoext=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vpindex,hv-synic,hv-stimer,hv-vendor-id=AuthenticAMD,hv-frequencies,hv-crash,kvm=off,host-cache-info=on,l3-cache=off \ +-m 49152 \ +-overcommit mem-lock=off \ +-smp 24,sockets=1,cores=12,threads=2 \ +-mem-prealloc \ +-mem-path /dev/hugepages/libvirt/qemu/3-win10 \ +-numa node,nodeid=0,cpus=0-2,cpus=12-14,mem=12288 \ +-numa node,nodeid=1,cpus=3-5,cpus=15-17,mem=12288 \ +-numa node,nodeid=2,cpus=6-8,cpus=18-20,mem=12288 \ +-numa node,nodeid=3,cpus=9-11,cpus=21-23,mem=12288 \ +... + +For some reason I always get l3-cache=off. + +CoreInfo.exe in Windows 10 then produces the following report (shortened): + +Logical to Physical Processor Map: +**---------------------- Physical Processor 0 (Hyperthreaded) +--*--------------------- Physical Processor 1 +---*-------------------- Physical Processor 2 +----**------------------ Physical Processor 3 (Hyperthreaded) +------**---------------- Physical Processor 4 (Hyperthreaded) +--------*--------------- Physical Processor 5 +---------*-------------- Physical Processor 6 +----------**------------ Physical Processor 7 (Hyperthreaded) +------------**---------- Physical Processor 8 (Hyperthreaded) +--------------*--------- Physical Processor 9 +---------------*-------- Physical Processor 10 +----------------**------ Physical Processor 11 (Hyperthreaded) +------------------**---- Physical Processor 12 (Hyperthreaded) +--------------------*--- Physical Processor 13 +---------------------*-- Physical Processor 14 +----------------------** Physical Processor 15 (Hyperthreaded) + +Logical Processor to Socket Map: +************************ Socket 0 + +Logical Processor to NUMA Node Map: +***---------***--------- NUMA Node 0 +---***---------***------ NUMA Node 1 +------***---------***--- NUMA Node 2 +---------***---------*** NUMA Node 3 + +Approximate Cross-NUMA Node Access Cost (relative to fastest): + 00 01 02 03 +00: 1.4 1.2 1.1 1.2 +01: 1.1 1.1 1.3 1.1 +02: 1.0 1.1 1.0 1.2 +03: 1.1 1.2 1.2 1.2 + +Logical Processor to Cache Map: +**---------------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------------- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64 +***--------------------- Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64 +--*--------------------- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--*--------------------- Instruction Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--*--------------------- Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64 +---*-------------------- Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +---*-------------------- Instruction Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +---*-------------------- Unified Cache 3, Level 2, 512 KB, Assoc 8, LineSize 64 +---***------------------ Unified Cache 4, Level 3, 16 MB, Assoc 16, LineSize 64 +----**------------------ Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------------ Instruction Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------------ Unified Cache 5, Level 2, 512 KB, Assoc 8, LineSize 64 +------**---------------- Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------------- Instruction Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------------- Unified Cache 6, Level 2, 512 KB, Assoc 8, LineSize 64 +------**---------------- Unified Cache 7, Level 3, 16 MB, Assoc 16, LineSize 64 +--------*--------------- Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +--------*--------------- Instruction Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +--------*--------------- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64 +--------*--------------- Unified Cache 9, Level 3, 16 MB, Assoc 16, LineSize 64 +---------*-------------- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +---------*-------------- Instruction Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +---------*-------------- Unified Cache 10, Level 2, 512 KB, Assoc 8, LineSize 64 +---------***------------ Unified Cache 11, Level 3, 16 MB, Assoc 16, LineSize 64 +----------**------------ Data Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------------ Instruction Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------------ Unified Cache 12, Level 2, 512 KB, Assoc 8, LineSize 64 +------------**---------- Data Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---------- Instruction Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---------- Unified Cache 13, Level 2, 512 KB, Assoc 8, LineSize 64 +------------***--------- Unified Cache 14, Level 3, 16 MB, Assoc 16, LineSize 64 +--------------*--------- Data Cache 9, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------*--------- Instruction Cache 9, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------*--------- Unified Cache 15, Level 2, 512 KB, Assoc 8, LineSize 64 +---------------*-------- Data Cache 10, Level 1, 32 KB, Assoc 8, LineSize 64 +---------------*-------- Instruction Cache 10, Level 1, 32 KB, Assoc 8, LineSize 64 +---------------*-------- Unified Cache 16, Level 2, 512 KB, Assoc 8, LineSize 64 +---------------*-------- Unified Cache 17, Level 3, 16 MB, Assoc 16, LineSize 64 +----------------**------ Data Cache 11, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------**------ Instruction Cache 11, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------**------ Unified Cache 18, Level 2, 512 KB, Assoc 8, LineSize 64 +----------------**------ Unified Cache 19, Level 3, 16 MB, Assoc 16, LineSize 64 +------------------**---- Data Cache 12, Level 1, 32 KB, Assoc 8, LineSize 64 +------------------**---- Instruction Cache 12, Level 1, 32 KB, Assoc 8, LineSize 64 +------------------**---- Unified Cache 20, Level 2, 512 KB, Assoc 8, LineSize 64 +------------------***--- Unified Cache 21, Level 3, 16 MB, Assoc 16, LineSize 64 +--------------------*--- Data Cache 13, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------------*--- Instruction Cache 13, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------------*--- Unified Cache 22, Level 2, 512 KB, Assoc 8, LineSize 64 +---------------------*-- Data Cache 14, Level 1, 32 KB, Assoc 8, LineSize 64 +---------------------*-- Instruction Cache 14, Level 1, 32 KB, Assoc 8, LineSize 64 +---------------------*-- Unified Cache 23, Level 2, 512 KB, Assoc 8, LineSize 64 +---------------------*** Unified Cache 24, Level 3, 16 MB, Assoc 16, LineSize 64 +----------------------** Data Cache 15, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------------** Instruction Cache 15, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------------** Unified Cache 25, Level 2, 512 KB, Assoc 8, LineSize 64 + +Logical Processor to Group Map: +************************ Group 0 + + +The above result is even further away from the actual L3 cache configuration. + +So numatune doesn't produce the expected outcome. + + +Same problem here on 5.0 and 3900x (3 cores per CCX). And as stated before - declaring NUMA nodes is definitely not the right solution if the aim is to emulate the host CPU as close as possible. + +The problem is that disabled cores are not taken into account.. ALL Zen2 CPUs have L3 cache group per CCX and every CCX has 4 cores, the problem is that some cores in each CCX (1 for 6 and 12-core CPUs, 2 for 3100) are disabled for some models, but they still use their core ids (as can be seen in virsh capabilities | grep "cpu id" output in above comments). Looking at target/i386/cpu.c:5529, this is not taken into account. + +Maybe the cleanest way to fix this is to emulate the host topology by also skipping disabled core ids in the VM? That way, die offset will actually match the real host CPU topology... + +A workaround for Linux VMs is to disable CPUs (and setting their number/pinnings accordingly, e.g. every 4th (and 3rd for 3100) core is going to be 'dummy' and disabled system-wide) by e.g. echo 0 > /sys/devices/system/cpu/cpu3/online + +No good workaround for Windows VMs exists, as far as I know - the best you can do is setting affinity to specific process(es) and avoid the 'dummy' CPUs, but I am not aware of any possibility to disable specific CPUs (only limiting the overall number). + +Hi Jan, + +Problem for me now is why does every config (I can figure out) now result in SMT on/L3 across all cores which is obviously never true on Zen except if you have only less than 4 cores, 8 cores should always result in 2 L3 Caches, and so should 16 Threads /w 8+SMT. This worked in my initial post. + +Latest qemu has removed all the hard coded configurations for AMD. It is leaving everything to customize. One way is to configure is using numa nodes. This will make sure cpus under one numa node share same L3. Then pin the correct host cpus to guest cpus using vcpupin. I would change this -numa node,nodeid=0,cpus=0-2,cpus=12-14,mem=12288 to -numa node,nodeid=0,cpus=0-2,cpus=3-5,mem=12288. Then have vcpupin map the correct host cpu to guest cpu. Check if this works for you. Can you please post lscpu output from host for everybody's understanding? + + +No, creating artificial NUMA nodes is, simply put, never a good solution for CPUs that operate as a single NUMA node - which is the case for all Zen2 CPUs (except maybe EPYCs? not sure about those). + +You may workaround the L3 issue that way, but hit many new bugs/problems by introducing multiple NUMA nodes, _especially_ on Windows VMs, because that OS has crappy NUMA handling and multitude of bugs related to it - which was one of the major reasons why even Zen2 Threadrippers are now single NUMA node (e.g. https://www.servethehome.com/wp-content/uploads/2019/11/AMD-Ryzen-Threadripper-3960X-Topology.png ). + +The host CPU architecture should be replicated as closely as possible on the VM and for Zen2 CPUs with 4 cores per CCX, _this already works perfectly_ - there are no problems on 3300X/3700(X)/3800X/3950X/3970X/3990X. + +There is, unfortunately, no way to customize/specify the "disabled" CPU cores in QEMU, and therefore no way to emulate 1 NUMA node + L3 cache per 2/3 cores - only to passthrough the cache config from host, which is unfortunately not done correctly for CPUs with disabled cores (but again, works perfectly for CPUs with all 4 cores enabled per CCX). + +lscpu: +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +Address sizes: 43 bits physical, 48 bits virtual +CPU(s): 24 +On-line CPU(s) list: 0-23 +Thread(s) per core: 2 +Core(s) per socket: 12 +Socket(s): 1 +NUMA node(s): 1 +Vendor ID: AuthenticAMD +CPU family: 23 +Model: 113 +Model name: AMD Ryzen 9 3900X 12-Core Processor +Stepping: 0 +Frequency boost: enabled +CPU MHz: 2972.127 +CPU max MHz: 3800.0000 +CPU min MHz: 2200.0000 +BogoMIPS: 7602.55 +Virtualization: AMD-V +L1d cache: 384 KiB +L1i cache: 384 KiB +L2 cache: 6 MiB +L3 cache: 64 MiB +NUMA node0 CPU(s): 0-23 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Not affected +Vulnerability Mds: Not affected +Vulnerability Meltdown: Not affected +Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp +Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization +Vulnerability Spectre v2: Mitigation; Full AMD retpoline, IBPB conditional, STIBP conditional, RSB filling +Vulnerability Tsx async abort: Not affected +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 nonsto + p_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 mi + salignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase b + mi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru + wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca + + +But the important thing has already been posted here in previous comments - notice the skipped core ids belonging to the disabled cores: + +virsh capabilities | grep "cpu id": +<cpu id='0' socket_id='0' core_id='0' siblings='0,12'/> +<cpu id='1' socket_id='0' core_id='1' siblings='1,13'/> +<cpu id='2' socket_id='0' core_id='2' siblings='2,14'/> +<cpu id='3' socket_id='0' core_id='4' siblings='3,15'/> +<cpu id='4' socket_id='0' core_id='5' siblings='4,16'/> +<cpu id='5' socket_id='0' core_id='6' siblings='5,17'/> +<cpu id='6' socket_id='0' core_id='8' siblings='6,18'/> +<cpu id='7' socket_id='0' core_id='9' siblings='7,19'/> +<cpu id='8' socket_id='0' core_id='10' siblings='8,20'/> +<cpu id='9' socket_id='0' core_id='12' siblings='9,21'/> +<cpu id='10' socket_id='0' core_id='13' siblings='10,22'/> +<cpu id='11' socket_id='0' core_id='14' siblings='11,23'/> +<cpu id='12' socket_id='0' core_id='0' siblings='0,12'/> +<cpu id='13' socket_id='0' core_id='1' siblings='1,13'/> +<cpu id='14' socket_id='0' core_id='2' siblings='2,14'/> +<cpu id='15' socket_id='0' core_id='4' siblings='3,15'/> +<cpu id='16' socket_id='0' core_id='5' siblings='4,16'/> +<cpu id='17' socket_id='0' core_id='6' siblings='5,17'/> +<cpu id='18' socket_id='0' core_id='8' siblings='6,18'/> +<cpu id='19' socket_id='0' core_id='9' siblings='7,19'/> +<cpu id='20' socket_id='0' core_id='10' siblings='8,20'/> +<cpu id='21' socket_id='0' core_id='12' siblings='9,21'/> +<cpu id='22' socket_id='0' core_id='13' siblings='10,22'/> +<cpu id='23' socket_id='0' core_id='14' siblings='11,23'/> + +Damir: +Hm, must be some misconfiguration, then. My config for Linux VMs to utilize 3 out of the 4 CCXs. Important parts of the libvirt domain XML: + + <vcpu placement="static">24</vcpu> + <iothreads>1</iothreads> + <cputune> + <vcpupin vcpu="0" cpuset="3"/> + <vcpupin vcpu="1" cpuset="15"/> + <vcpupin vcpu="2" cpuset="4"/> + <vcpupin vcpu="3" cpuset="16"/> + <vcpupin vcpu="4" cpuset="5"/> + <vcpupin vcpu="5" cpuset="17"/> + <vcpupin vcpu="6" cpuset="0,12"/> + <vcpupin vcpu="7" cpuset="0,12"/> + <vcpupin vcpu="8" cpuset="6"/> + <vcpupin vcpu="9" cpuset="18"/> + <vcpupin vcpu="10" cpuset="7"/> + <vcpupin vcpu="11" cpuset="19"/> + <vcpupin vcpu="12" cpuset="8"/> + <vcpupin vcpu="13" cpuset="20"/> + <vcpupin vcpu="14" cpuset="0,12"/> + <vcpupin vcpu="15" cpuset="0,12"/> + <vcpupin vcpu="16" cpuset="9"/> + <vcpupin vcpu="17" cpuset="21"/> + <vcpupin vcpu="18" cpuset="10"/> + <vcpupin vcpu="19" cpuset="22"/> + <vcpupin vcpu="20" cpuset="11"/> + <vcpupin vcpu="21" cpuset="23"/> + <vcpupin vcpu="22" cpuset="0,12"/> + <vcpupin vcpu="23" cpuset="0,12"/> + <emulatorpin cpuset="1,13"/> + <iothreadpin iothread="1" cpuset="2,14"/> + </cputune> + <os> + <type arch="x86_64" machine="pc-q35-5.0">hvm</type> + <loader readonly="yes" type="pflash">/usr/share/ovmf/x64/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/ccxtest-clone_VARS.fd</nvram> + </os> +. +. +. + <qemu:commandline> + <qemu:arg value="-cpu"/> + <qemu:arg value="host,topoext=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,host-cache-info=on,-amd-stibp"/> + </qemu:commandline> + +The CPUs with cpuset="0,12" are disabled once booted. The host-cache-info=on is the part that makes sure that the cache config is passed to the VM (but unfortunately does not take disabled cores into account, which results in incorrect config). The qemu:commandline is added because I need to add -amd-stibp, otherwise I wouldn't be able to boot. This overrides most parts in the <cpu> XML part. + +"The CPUs with cpuset="0,12" are disabled once booted. The host-cache-info=on is the part that makes sure that the cache config is passed to the VM (but unfortunately does not take disabled cores into account, which results in incorrect config). The qemu:commandline is added because I need to add -amd-stibp, otherwise I wouldn't be able to boot. This overrides most parts in the <cpu> XML part." + +Is there a XML equivalent for host-cache-info=on ? + +Will that work with model EPYC-IBPB as well? + +Sieger, I am not an expert on XML. So, I dont know. Qemu probably cannot handle disabled cores. I am still trying to learn more about this problem. + +With regard to Jan's comment earlier and the virsh capabilities listing the cores and siblings, also note the following lines from virsh capabilities for a 3900X CPU: + + <cache> + <bank id='0' level='3' type='both' size='16' unit='MiB' cpus='0-2,12-14'/> + <bank id='1' level='3' type='both' size='16' unit='MiB' cpus='3-5,15-17'/> + <bank id='2' level='3' type='both' size='16' unit='MiB' cpus='6-8,18-20'/> + <bank id='3' level='3' type='both' size='16' unit='MiB' cpus='9-11,21-23'/> + </cache> + +virsh capabilities is perfectly able to identify the L3 cache structure and associate the right cpus. It would be ideal to just use the above output inside the libvirt domain configuration to "manually" define the L3 cache, or something to that effect on the qemu command line. + +Users could then decide to pin only part of the cpus, usually a multiple of 6 (in the case of the 3900X) to align with the CCX. + +I'm now on kernel 5.6.11 and QEMU v5.0.0.r533.gdebe78ce14-1 (from Arch Linux AUR qemu-git), running q35-5.1. I will try the host-passthrough with host-cache-info=on option Jan posted. Question - is host-cache-info=on the same as <cache mode="passthrough"/> under <cpu mode=host-passthrough...? + +<cache mode="passthrough"/> + +adds "host-cache-info=on,l3-cache=off" + +to the qemu -cpu args + +I believe l3-cache=off is useless with host-cache-info=on + +So <cache mode="passthrough"/> should do what you want. + +Thanks Jan. I had some new hardware/software issues combined with the QEMU 5.0.. issues that had my Windows VM crash after some minutes. + +I totally overlooked the following: + <vcpupin vcpu="6" cpuset="0,12"/> + <vcpupin vcpu="7" cpuset="0,12"/> + +So I guess you posted to answer to this: https://www.reddit.com/r/VFIO/comments/erwzrg/think_i_found_a_workaround_to_get_l3_cache_shared/ + +As it's late, I'll try tomorrow. Sorry for all the confusion but I had a real tough time with this Ryzen build. + +Jan, I tried your suggestion but it didn't make a difference. Here is my current setup: + +h/w: AMD Ryzen 9 3900X +kernel: 5.4 +QEMU: 5.0.0-6 +Chipset selection: Q35-5.0 + +Configuration: host-passthrough, cache enabled + +Use CoreInfo.exe inside Windows. The problem is this: + +Logical Processor to Cache Map: +**---------------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------------- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64 +********---------------- Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64 + +The last line above should be as follows: + +******------------------ Unified Cache 0, Level 3, 16 MB, Assoc 16, LineSize 64 + +The cache is supposed to be associated with 3 cores a 2 threads in group 0. Yet it shows 8 (2x4) vcpus inside a cache that is associated with the next group. + +In total, I always get 3 L3 caches instead of 4 L4 caches for my 12 cores / 24 threads. Also see my next post. + + +This is the CPU cache layout as shown by lscpu -a -e + +CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ + 0 0 0 0 0:0:0:0 yes 3800.0000 2200.0000 + 1 0 0 1 1:1:1:0 yes 3800.0000 2200.0000 + 2 0 0 2 2:2:2:0 yes 3800.0000 2200.0000 + 3 0 0 3 3:3:3:1 yes 3800.0000 2200.0000 + 4 0 0 4 4:4:4:1 yes 3800.0000 2200.0000 + 5 0 0 5 5:5:5:1 yes 3800.0000 2200.0000 + 6 0 0 6 6:6:6:2 yes 3800.0000 2200.0000 + 7 0 0 7 7:7:7:2 yes 3800.0000 2200.0000 + 8 0 0 8 8:8:8:2 yes 3800.0000 2200.0000 + 9 0 0 9 9:9:9:3 yes 3800.0000 2200.0000 + 10 0 0 10 10:10:10:3 yes 3800.0000 2200.0000 + 11 0 0 11 11:11:11:3 yes 3800.0000 2200.0000 + 12 0 0 0 0:0:0:0 yes 3800.0000 2200.0000 + 13 0 0 1 1:1:1:0 yes 3800.0000 2200.0000 + 14 0 0 2 2:2:2:0 yes 3800.0000 2200.0000 + 15 0 0 3 3:3:3:1 yes 3800.0000 2200.0000 + 16 0 0 4 4:4:4:1 yes 3800.0000 2200.0000 + 17 0 0 5 5:5:5:1 yes 3800.0000 2200.0000 + 18 0 0 6 6:6:6:2 yes 3800.0000 2200.0000 + 19 0 0 7 7:7:7:2 yes 3800.0000 2200.0000 + 20 0 0 8 8:8:8:2 yes 3800.0000 2200.0000 + 21 0 0 9 9:9:9:3 yes 3800.0000 2200.0000 + 22 0 0 10 10:10:10:3 yes 3800.0000 2200.0000 + 23 0 0 11 11:11:11:3 yes 3800.0000 2200.0000 + +I was trying to allocate cache using the cachetune feature in libvirt, but it turns out to be either misleading or much too complicated to be usable. Here is what I tried: + + <vcpu placement="static">24</vcpu> + <cputune> + <vcpupin vcpu="0" cpuset="0"/> + <vcpupin vcpu="1" cpuset="12"/> + <vcpupin vcpu="2" cpuset="1"/> + <vcpupin vcpu="3" cpuset="13"/> + <vcpupin vcpu="4" cpuset="2"/> + <vcpupin vcpu="5" cpuset="14"/> + <vcpupin vcpu="6" cpuset="3"/> + <vcpupin vcpu="7" cpuset="15"/> + <vcpupin vcpu="8" cpuset="4"/> + <vcpupin vcpu="9" cpuset="16"/> + <vcpupin vcpu="10" cpuset="5"/> + <vcpupin vcpu="11" cpuset="17"/> + <vcpupin vcpu="12" cpuset="6"/> + <vcpupin vcpu="13" cpuset="18"/> + <vcpupin vcpu="14" cpuset="7"/> + <vcpupin vcpu="15" cpuset="19"/> + <vcpupin vcpu="16" cpuset="8"/> + <vcpupin vcpu="17" cpuset="20"/> + <vcpupin vcpu="18" cpuset="9"/> + <vcpupin vcpu="19" cpuset="21"/> + <vcpupin vcpu="20" cpuset="10"/> + <vcpupin vcpu="21" cpuset="22"/> + <vcpupin vcpu="22" cpuset="11"/> + <vcpupin vcpu="23" cpuset="23"/> + <cachetune vcpus="0-2,12-14"> + <cache id="0" level="3" type="both" size="16" unit="MiB"/> + <monitor level="3" vcpus="0-2,12-14"/> + </cachetune> + <cachetune vcpus="3-5,15-17"> + <cache id="1" level="3" type="both" size="16" unit="MiB"/> + <monitor level="3" vcpus="3-5,15-17"/> + </cachetune> + <cachetune vcpus="6-8,18-20"> + <cache id="2" level="3" type="both" size="16" unit="MiB"/> + <monitor level="3" vcpus="6-8,18-20"/> + </cachetune> + <cachetune vcpus="9-11,21-23"> + <cache id="3" level="3" type="both" size="16" unit="MiB"/> + <monitor level="3" vcpus="9-11,21-23"/> + </cachetune> + </cputune> + +Unfortunately it gives the following error when I try to start the VM: + +Error starting domain: internal error: Missing or inconsistent resctrl info for memory bandwidth allocation + +I have resctrl mounted like this: + +mount -t resctrl resctrl /sys/fs/resctrl + +This error leads to the following description on how to allocate memory bandwith: https://software.intel.com/content/www/us/en/develop/articles/use-intel-resource-director-technology-to-allocate-memory-bandwidth.html + +I think this is over the top and perhaps I'm trying the wrong approach. All I can say is that every suggestion I've seen and tried so far has led me to one conclusion: QEMU does NOT support the L3 cache layout of the new ZEN 2 arch CPUs such as the Ryzen 9 3900X. + +h-sieger, +that is a misunderstanding, read my comment carefully again: +"A workaround for Linux VMs is to disable CPUs (and setting their number/pinnings accordingly, e.g. every 4th (and 3rd for 3100) core is going to be 'dummy' and disabled system-wide) by e.g. echo 0 > /sys/devices/system/cpu/cpu3/online + +No good workaround for Windows VMs exists, as far as I know - the best you can do is setting affinity to specific process(es) and avoid the 'dummy' CPUs, but I am not aware of any possibility to disable specific CPUs (only limiting the overall number)." + +I do NOT have a fix - only a very ugly workaround for Linux guests only - I cannot fix the cache layout, but on Linux, I can get around that by adding dummy CPUs that I then disable in the guest during startup, so they are not used - effectively making sure that only the correct 6 vCPUs / 3 cores are used. On Windows, you cannot do that, AFAIK. + +Thanks for clarifying, Jan. + +In the meantime I tried a number of so-called solutions published on Reddit and other places, none of which seems to work. + +So if I understand it correctly, there is currently no solution to the incorrect l3 cache layout for Zen architecture CPUs. At best a workaround for Linux guests. + +I hope somebody is looking into that. + +Thanks for clarifying, Jan. + +In the meantime I tried a number of so-called solutions published on Reddit and other places, none of which seems to work. + +So if I understand it correctly, there is currently no solution to the incorrect l3 cache layout for Zen architecture CPUs. At best a workaround for Linux guests. + +I hope somebody is looking into that. + +The problem is caused by the fact that with Ryzen CPUs with disabled cores, the APIC IDs are not sequential on host - in order for cache topology to be configured properly, there is a 'hole' in APIC ID and core ID numbering (I have added full output of cpuid for my 3900X). Unfortunately, adding holes to the numbering is the only way to achieve what is needed for 3 cores per CCX as CPUID Fn8000_001D_EAX NumSharingCache parameter rounds to powers of two (for Ryzen 3100 with 2 cores per CCX, lowering NumSharingCache should also work, correctly setting the L3 cache cores with their IDs still being sequential). + +A small hack in x86_apicid_from_topo_ids() in include/hw/i386/topology.h can introduce a correct numbering (at least if you do not have epyc set as your cpu, then _epyc variant of the functions are used). But to fix this properly will probably require some thought - maybe introduce the ability to assign APIC IDs directly somehow? Or the ability to specify the 'holes' somehow in the -smt param, or maybe -cpu host,topoext=on should do this automatically? I don't know... + +e.g. For 3 core per CCX CPUs, to fix this, at include/hw/i386/topology.h:220 change: + +(topo_ids->core_id << apicid_core_offset(topo_info)) | + +to + +((topo_ids->core_id + (topo_ids->core_id / 3)) << apicid_core_offset(topo_info)) | + + +The cache topology is now correct (-cpu host,topoext=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,host-cache-info=on -smp 18,sockets=1,dies=1,cores=9,threads=2), even in Windows: + +Logical Processor to Cache Map: +**---------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64 +******------------ Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64 +--**-------------- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--**-------------- Instruction Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--**-------------- Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64 +----**------------ Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------ Instruction Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------ Unified Cache 3, Level 2, 512 KB, Assoc 8, LineSize 64 +------**---------- Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------- Instruction Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------- Unified Cache 4, Level 2, 512 KB, Assoc 8, LineSize 64 +------******------ Unified Cache 5, Level 3, 16 MB, Assoc 16, LineSize 64 +--------**-------- Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +--------**-------- Instruction Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +--------**-------- Unified Cache 6, Level 2, 512 KB, Assoc 8, LineSize 64 +----------**------ Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------ Instruction Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------ Unified Cache 7, Level 2, 512 KB, Assoc 8, LineSize 64 +------------**---- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---- Instruction Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64 +------------****** Unified Cache 9, Level 3, 16 MB, Assoc 16, LineSize 64 + + + +@Jan: this coreinfo output looks good. + +I finally managed to get the core /cache alignment right, I believe: + + <vcpu placement="static" current="24">32</vcpu> + <vcpus> + <vcpu id="0" enabled="yes" hotpluggable="no"/> + <vcpu id="1" enabled="yes" hotpluggable="yes"/> + <vcpu id="2" enabled="yes" hotpluggable="yes"/> + <vcpu id="3" enabled="yes" hotpluggable="yes"/> + <vcpu id="4" enabled="yes" hotpluggable="yes"/> + <vcpu id="5" enabled="yes" hotpluggable="yes"/> + <vcpu id="6" enabled="no" hotpluggable="yes"/> + <vcpu id="7" enabled="no" hotpluggable="yes"/> + <vcpu id="8" enabled="yes" hotpluggable="yes"/> + <vcpu id="9" enabled="yes" hotpluggable="yes"/> + <vcpu id="10" enabled="yes" hotpluggable="yes"/> + <vcpu id="11" enabled="yes" hotpluggable="yes"/> + <vcpu id="12" enabled="yes" hotpluggable="yes"/> + <vcpu id="13" enabled="yes" hotpluggable="yes"/> + <vcpu id="14" enabled="no" hotpluggable="yes"/> + <vcpu id="15" enabled="no" hotpluggable="yes"/> + <vcpu id="16" enabled="yes" hotpluggable="yes"/> + <vcpu id="17" enabled="yes" hotpluggable="yes"/> + <vcpu id="18" enabled="yes" hotpluggable="yes"/> + <vcpu id="19" enabled="yes" hotpluggable="yes"/> + <vcpu id="20" enabled="yes" hotpluggable="yes"/> + <vcpu id="21" enabled="yes" hotpluggable="yes"/> + <vcpu id="22" enabled="no" hotpluggable="yes"/> + <vcpu id="23" enabled="no" hotpluggable="yes"/> + <vcpu id="24" enabled="yes" hotpluggable="yes"/> + <vcpu id="25" enabled="yes" hotpluggable="yes"/> + <vcpu id="26" enabled="yes" hotpluggable="yes"/> + <vcpu id="27" enabled="yes" hotpluggable="yes"/> + <vcpu id="28" enabled="yes" hotpluggable="yes"/> + <vcpu id="29" enabled="yes" hotpluggable="yes"/> + <vcpu id="30" enabled="no" hotpluggable="yes"/> + <vcpu id="31" enabled="no" hotpluggable="yes"/> + </vcpus> + <cputune> + <vcpupin vcpu="0" cpuset="0"/> + <vcpupin vcpu="1" cpuset="12"/> + <vcpupin vcpu="2" cpuset="1"/> + <vcpupin vcpu="3" cpuset="13"/> + <vcpupin vcpu="4" cpuset="2"/> + <vcpupin vcpu="5" cpuset="14"/> + <vcpupin vcpu="8" cpuset="3"/> + <vcpupin vcpu="9" cpuset="15"/> + <vcpupin vcpu="10" cpuset="4"/> + <vcpupin vcpu="11" cpuset="16"/> + <vcpupin vcpu="12" cpuset="5"/> + <vcpupin vcpu="13" cpuset="17"/> + <vcpupin vcpu="16" cpuset="6"/> + <vcpupin vcpu="17" cpuset="18"/> + <vcpupin vcpu="18" cpuset="7"/> + <vcpupin vcpu="19" cpuset="19"/> + <vcpupin vcpu="20" cpuset="8"/> + <vcpupin vcpu="21" cpuset="20"/> + <vcpupin vcpu="24" cpuset="9"/> + <vcpupin vcpu="25" cpuset="21"/> + <vcpupin vcpu="26" cpuset="10"/> + <vcpupin vcpu="27" cpuset="22"/> + <vcpupin vcpu="28" cpuset="11"/> + <vcpupin vcpu="29" cpuset="23"/> + </cputune> + +... + <cpu mode="host-passthrough" check="none"> + <topology sockets="1" dies="1" cores="16" threads="2"/> + <cache mode="passthrough"/> + + +The Windows Coreinfo output is this: + +Logical to Physical Processor Map: +**---------------- Physical Processor 0 (Hyperthreaded) +--**-------------- Physical Processor 1 (Hyperthreaded) +----**------------ Physical Processor 2 (Hyperthreaded) +------**---------- Physical Processor 3 (Hyperthreaded) +--------**-------- Physical Processor 4 (Hyperthreaded) +----------**------ Physical Processor 5 (Hyperthreaded) +------------**---- Physical Processor 6 (Hyperthreaded) +--------------**-- Physical Processor 7 (Hyperthreaded) +----------------** Physical Processor 8 (Hyperthreaded) + +Logical Processor to Socket Map: +****************** Socket 0 + +Logical Processor to NUMA Node Map: +****************** NUMA Node 0 + +No NUMA nodes. + +Logical Processor to Cache Map: +**---------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 +**---------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64 +******------------ Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64 +--**-------------- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--**-------------- Instruction Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 +--**-------------- Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64 +----**------------ Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------ Instruction Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 +----**------------ Unified Cache 3, Level 2, 512 KB, Assoc 8, LineSize 64 +------**---------- Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------- Instruction Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 +------**---------- Unified Cache 4, Level 2, 512 KB, Assoc 8, LineSize 64 +------******------ Unified Cache 5, Level 3, 16 MB, Assoc 16, LineSize 64 +--------**-------- Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +--------**-------- Instruction Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64 +--------**-------- Unified Cache 6, Level 2, 512 KB, Assoc 8, LineSize 64 +----------**------ Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------ Instruction Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64 +----------**------ Unified Cache 7, Level 2, 512 KB, Assoc 8, LineSize 64 +------------**---- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---- Instruction Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64 +------------**---- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64 +------------****** Unified Cache 9, Level 3, 16 MB, Assoc 16, LineSize 64 +--------------**-- Data Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------**-- Instruction Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64 +--------------**-- Unified Cache 10, Level 2, 512 KB, Assoc 8, LineSize 64 +----------------** Data Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------** Instruction Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64 +----------------** Unified Cache 11, Level 2, 512 KB, Assoc 8, LineSize 64 + +Logical Processor to Group Map: +****************** Group 0 + + +Haven't been able to test if it performs as expected. Need to do that. + +Of course it would be great if QEMU was patched to recognize correct CCX alignment as I'm not sure if and what will be the penalty of this weird setup. + +Yep, I read the Reddit thread, had no idea this was possible. + +Still, both solutions are ugly workarounds and it would be nice to fix this properly. But at least I don't have to patch and compile QEMU on my own anymore. + +h-sieger, +Your XML gave me very significant performance gains. +Is there any way to do this with more than 24 assigned cores? + + +@sanjaybmd + +I'm glad to read that it worked for you. In fact, since I posted the XML I didn't have the time to do benchmarking, now my motherboard is dead and I have to wait for repair/replacement. + +Do you have any data to quantify the performance gain? + +As to the number of cores, you will notice that my 3900X has only 12 physical cores, that is 24 threads. Yet I assigned 32 vcpus in total. 8 of them are disabled. This is to align the vcpus to the actual CCX topology of 3 cores per CCX. + +QEMU thinks the cores per CCX should be a multiple of 2, e.g. 2, 4, etc. cores. So I assign 4 cores = 8 vcpus, and disable 2 vcpus to simulate the actual topology. + +If your CPU has more cores, you could scale it up. Be aware that the 3950X should not have this issue as it has 4 cores per CCX, if I remember correctly. + +Note: I took this idea from a Reddit post (see link somewhere above). + +h-sieger, +I did some testing with geekbench 5: + +baseline multicore score = 12733 +https://browser.geekbench.com/v5/cpu/3069626 + +score with <cache="passthrough"> option = 12775 +https://browser.geekbench.com/v5/cpu/3069415 + +best score with your xml above = 16960 +https://browser.geekbench.com/v5/cpu/3066003 + +I'm running a 3960x and it is 3 cores per CCX so your xml above works well. I'm just now learning about all this so I'm still trying to figure out how to modify your xml to assign more cores. Anyway, I'm getting better performance out of my Windows 10 VM now assigning 24 vcpu as opposed to the 32 that I was assigning before! +By the way, I tried to email you directly because I'm not sure this is appropriate discussion for this bug report but I could not create an account on your website (captcha was malfunctioning). Hope you you can fix that soon. + + +Sanjay, + +You can just increase the number of vcpus, such as: + +<vcpu placement="static" current="48">64</vcpu> + +then continue to define the vcpus: + + <vcpu id="32" enabled="yes" hotpluggable="yes"/> + <vcpu id="33" enabled="yes" hotpluggable="yes"/> + <vcpu id="34" enabled="yes" hotpluggable="yes"/> + <vcpu id="35" enabled="yes" hotpluggable="yes"/> + <vcpu id="36" enabled="yes" hotpluggable="yes"/> + <vcpu id="37" enabled="yes" hotpluggable="yes"/> + <vcpu id="38" enabled="no" hotpluggable="yes"/> + <vcpu id="39" enabled="no" hotpluggable="yes"/> + <vcpu id="40" enabled="yes" hotpluggable="yes"/> + <vcpu id="41" enabled="yes" hotpluggable="yes"/> + <vcpu id="42" enabled="yes" hotpluggable="yes"/> + <vcpu id="43" enabled="yes" hotpluggable="yes"/> + <vcpu id="44" enabled="yes" hotpluggable="yes"/> + <vcpu id="45" enabled="yes" hotpluggable="yes"/> + <vcpu id="46" enabled="no" hotpluggable="yes"/> + <vcpu id="47" enabled="no" hotpluggable="yes"/> + <vcpu id="48" enabled="yes" hotpluggable="yes"/> + <vcpu id="49" enabled="yes" hotpluggable="yes"/> + <vcpu id="50" enabled="yes" hotpluggable="yes"/> + <vcpu id="51" enabled="yes" hotpluggable="yes"/> + <vcpu id="52" enabled="yes" hotpluggable="yes"/> + <vcpu id="53" enabled="yes" hotpluggable="yes"/> + <vcpu id="54" enabled="no" hotpluggable="yes"/> + <vcpu id="55" enabled="no" hotpluggable="yes"/> + <vcpu id="56" enabled="yes" hotpluggable="yes"/> + <vcpu id="57" enabled="yes" hotpluggable="yes"/> + <vcpu id="58" enabled="yes" hotpluggable="yes"/> + <vcpu id="59" enabled="yes" hotpluggable="yes"/> + <vcpu id="60" enabled="yes" hotpluggable="yes"/> + <vcpu id="61" enabled="yes" hotpluggable="yes"/> + <vcpu id="62" enabled="no" hotpluggable="yes"/> + <vcpu id="63" enabled="no" hotpluggable="yes"/> + +(6x enabled=yes, then 2x enabled=no.) + +You will get more vcpu ids than you have threads, but since you disable 16 out of 64, you will have 48 active. + +vcpupin should continue as follows: + + <vcpupin vcpu="32" cpuset="24"/> + <vcpupin vcpu="33" cpuset="36"/> + <vcpupin vcpu="34" cpuset="25"/> + <vcpupin vcpu="35" cpuset="37"/> + <vcpupin vcpu="36" cpuset="26"/> + <vcpupin vcpu="37" cpuset="38"/> + <vcpupin vcpu="40" cpuset="27"/> + <vcpupin vcpu="41" cpuset="39"/> + <vcpupin vcpu="42" cpuset="28"/> + <vcpupin vcpu="43" cpuset="40"/> + <vcpupin vcpu="44" cpuset="29"/> + <vcpupin vcpu="45" cpuset="41"/> + <vcpupin vcpu="48" cpuset="30"/> + <vcpupin vcpu="49" cpuset="42"/> + <vcpupin vcpu="50" cpuset="31"/> + <vcpupin vcpu="51" cpuset="43"/> + <vcpupin vcpu="52" cpuset="32"/> + <vcpupin vcpu="53" cpuset="44"/> + <vcpupin vcpu="56" cpuset="33"/> + <vcpupin vcpu="57" cpuset="45"/> + <vcpupin vcpu="58" cpuset="34"/> + <vcpupin vcpu="59" cpuset="46"/> + <vcpupin vcpu="60" cpuset="35"/> + <vcpupin vcpu="61" cpuset="47"/> + +This is if you pin all vcpus to the VM, which may not be the best thing to do. The maximum number of vcpus you can pin on a Threadripper 3960X are 48. + +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/review/1856549 b/results/classifier/118/review/1856549 new file mode 100644 index 000000000..d433a6482 --- /dev/null +++ b/results/classifier/118/review/1856549 @@ -0,0 +1,175 @@ +TCG: 0.811 +hypervisor: 0.756 +vnc: 0.751 +peripherals: 0.751 +VMM: 0.750 +graphic: 0.748 +PID: 0.732 +KVM: 0.723 +debug: 0.704 +performance: 0.693 +permissions: 0.692 +virtual: 0.666 +ppc: 0.654 +register: 0.651 +arm: 0.644 +risc-v: 0.635 +semantic: 0.626 +x86: 0.612 +assembly: 0.583 +architecture: 0.566 +files: 0.558 +user-level: 0.556 +device: 0.555 +network: 0.542 +kernel: 0.540 +socket: 0.540 +boot: 0.513 +i386: 0.399 +mistranslation: 0.361 +-------------------- +files: 0.751 +hypervisor: 0.154 +semantic: 0.131 +register: 0.121 +assembly: 0.107 +x86: 0.091 +peripherals: 0.068 +TCG: 0.058 +virtual: 0.051 +debug: 0.037 +performance: 0.030 +i386: 0.026 +kernel: 0.024 +VMM: 0.023 +KVM: 0.018 +boot: 0.013 +device: 0.012 +architecture: 0.012 +permissions: 0.009 +arm: 0.008 +PID: 0.008 +user-level: 0.006 +ppc: 0.004 +vnc: 0.004 +network: 0.003 +mistranslation: 0.003 +risc-v: 0.003 +graphic: 0.002 +socket: 0.001 + +qemu-4.2.0/hw/misc/mac_via.c: 2 * bad test ? + +1. + +qemu-4.2.0/hw/misc/mac_via.c:417:27: style: Expression is always false because 'else if' condition matches previous condition at line 412. [multiCondition] + + } else if ((m->data_out & 0xf3) == 0xa1) { +... + } else if ((m->data_out & 0xf3) == 0xa1) { + +2. + +qemu-4.2.0/hw/misc/mac_via.c:467:27: style: Expression is always false because 'else if' condition matches previous condition at line 463. [multiCondition] + +Duplicate. + +gcc compiler flag -Wduplicated-cond will catch this kind of problem. + +You might want to switch it on in your builds. It has been available for over a year. + + +On 12/16/19 12:58 PM, dcb wrote: +> gcc compiler flag -Wduplicated-cond will catch this kind of problem. + +Interesting, thanks for sharing! + +> +> You might want to switch it on in your builds. It has been available for +> over a year. +> + + + +This code seems to emulate a RTC device connected via I2C to the VIA chipset. + +This might be the expected code (simply looking at this file, without checking the datasheet): +-- >8 -- +--- a/hw/misc/mac_via.c ++++ b/hw/misc/mac_via.c +@@ -409,7 +409,7 @@ static void via1_rtc_update(MacVIAState *m) + } else if (m->data_out == 0x8d) { /* seconds register 3 */ + m->data_in = (time >> 24) & 0xff; + m->data_in_cnt = 8; +- } else if ((m->data_out & 0xf3) == 0xa1) { ++ } else if ((m->data_out & 0xf3) == 0xa3) { + /* PRAM address 0x10 -> 0x13 */ + int addr = (m->data_out >> 2) & 0x03; + m->data_in = v1s->PRAM[addr]; +@@ -460,7 +460,7 @@ static void via1_rtc_update(MacVIAState *m) + } else if (m->cmd == 0x35) { + /* Write Protect register */ + m->wprotect = m->data_out & 1; +- } else if ((m->cmd & 0xf3) == 0xa1) { ++ } else if ((m->cmd & 0xf3) == 0xa3) { + /* PRAM address 0x10 -> 0x13 */ + int addr = (m->cmd >> 2) & 0x03; + v1s->PRAM[addr] = m->data_out; +--- + +This file won a "/* TODO port to I2CBus */" comment :) + +I think VIA RTC access method has been implemented earlier (Classic Mac, 1984-1989) than the I2C specification, so I'm not sure we can/should port this to an I2C bus. + +Specs are (from Apple Macintosh Family Hardware Reference Chapter 2, Classi Macitosh Processor and Control) + +z0000001 Seconds register 0 (lowest-order byte) +z0000101 Seconds register 1 +z0001001 Seconds register 2 +z0001101 Seconds register 3 (highest-order byte) +00110001 Test register (write-only) +00110101 Write-Protect Register (write-only) +z010aa01 RAM address 100aa ($10-$13) (first 20 bytes only) +z1aaaa01 RAM address 0aaaa ($00-$0F) (first 20 bytes only) +z0111aaa Extended memory designator and sector number + (Macintohs 512K enhanced and Macintosh plus only) + +For a read request, z=1, for a write z=0 +The letter a indicates bits whose value depend on what parameter RAM byte you want to address + +So I think the mask/values should be: + +diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c +index f3f130ad96cc..7402cf3f1ee8 100644 +--- a/hw/misc/mac_via.c ++++ b/hw/misc/mac_via.c +@@ -414,7 +414,7 @@ static void via1_rtc_update(MacVIAState *m) + int addr = (m->data_out >> 2) & 0x03; + m->data_in = v1s->PRAM[addr]; + m->data_in_cnt = 8; +- } else if ((m->data_out & 0xf3) == 0xa1) { ++ } else if ((m->data_out & 0xc3) == 0xc1) { + /* PRAM address 0x00 -> 0x0f */ + int addr = (m->data_out >> 2) & 0x0f; + m->data_in = v1s->PRAM[addr]; +@@ -460,11 +460,11 @@ static void via1_rtc_update(MacVIAState *m) + } else if (m->cmd == 0x35) { + /* Write Protect register */ + m->wprotect = m->data_out & 1; +- } else if ((m->cmd & 0xf3) == 0xa1) { ++ } else if ((m->cmd & 0xf3) == 0x21) { + /* PRAM address 0x10 -> 0x13 */ + int addr = (m->cmd >> 2) & 0x03; + v1s->PRAM[addr] = m->data_out; +- } else if ((m->cmd & 0xf3) == 0xa1) { ++ } else if ((m->cmd & 0xc3) == 0x41) { + /* PRAM address 0x00 -> 0x0f */ + int addr = (m->cmd >> 2) & 0x0f; + v1s->PRAM[addr] = m->data_out; + + +Patch posted: https://<email address hidden>/msg666836.html + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b2619c158ab5 + diff --git a/results/classifier/118/review/1857143 b/results/classifier/118/review/1857143 new file mode 100644 index 000000000..ed5d7077c --- /dev/null +++ b/results/classifier/118/review/1857143 @@ -0,0 +1,93 @@ +user-level: 0.918 +hypervisor: 0.875 +virtual: 0.872 +boot: 0.838 +architecture: 0.825 +performance: 0.816 +VMM: 0.796 +graphic: 0.793 +KVM: 0.754 +device: 0.751 +PID: 0.738 +debug: 0.736 +vnc: 0.735 +kernel: 0.727 +x86: 0.720 +risc-v: 0.720 +mistranslation: 0.710 +socket: 0.699 +files: 0.690 +assembly: 0.688 +peripherals: 0.685 +semantic: 0.677 +ppc: 0.674 +arm: 0.673 +network: 0.663 +register: 0.652 +TCG: 0.640 +i386: 0.638 +permissions: 0.635 +-------------------- +virtual: 0.983 +hypervisor: 0.843 +x86: 0.808 +kernel: 0.161 +boot: 0.071 +KVM: 0.065 +i386: 0.039 +TCG: 0.030 +VMM: 0.030 +debug: 0.027 +user-level: 0.023 +files: 0.021 +register: 0.019 +socket: 0.015 +device: 0.013 +PID: 0.010 +arm: 0.006 +network: 0.005 +ppc: 0.004 +performance: 0.004 +semantic: 0.003 +architecture: 0.003 +vnc: 0.003 +assembly: 0.003 +graphic: 0.001 +peripherals: 0.001 +risc-v: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +VMs won't boot from external snapshots on qemu 4.2 + +After upgrading from qemu 4.1.1-1 to 4.2.0-1, VMs that were set to use an external snapshot as their disk failed to boot. + +Depending on the guest OS and other VM settings the boot fails and you get either the "Boot failed: not a bootable drive" message or the grub rescue shell or the EFI shell. Downgrading back to qemu 4.1 allows the VMs to boot from the external snapshots without any problem and the disk images doesn't appear to be corrupted afterwards. + +From my testing this bug is easily reproducible. Create a VM, install a guest os, confirm that the VM boots the guest os without problems, shutdown the VM, create an external snapshot of the VM disk, set the VM to boot from the snapshot, try to boot the VM with qemu 4.2 and see it fail, try to boot it with qemu 4.1 and see it succeed. + +In my case, to test that this bug is reproducible, I used virt-manager to install Xubuntu 19.10 on a qcow2 disk image, and then used qemu-img create -f qcow2 -b base_image.qcow2 snapshot_image.qcow2 to create the external snapshot and edited the xml in virt-manager to point the VM's disk to snapshot_image.qcow2. It failed to boot with qemu 4.2, but it was working fine with 4.1. + +I booted this test VM off a live distro using the virtual CDROM and fdisk can't seem to find a partition table on the VM disk when qemu 4.2 is used, with 4.1 it can see the partition table just fine. + +Internal snapshots don't seem to have this problem. + +I'm using Archlinux, virt-manager 2.2.1-2, libvirt 5.10.0-1, qemu 4.2.0-1. + +This is due to the new way of configuring block devices in 4.2. + +You'll need to create your snapshots correctly by using the '-F' +parameter of qemu-img create. + +Full details here: + +https://www.redhat.com/archives/libvirt-users/2019-December/msg00016.html + + + +I've rebased all my snapshots using '-F' and now everything boots properly. + +Thank you. + +Since everything now boots fine for you, I think we can close this ticket now, right? If not, feel free to open again. + diff --git a/results/classifier/118/review/1858046 b/results/classifier/118/review/1858046 new file mode 100644 index 000000000..878897f6d --- /dev/null +++ b/results/classifier/118/review/1858046 @@ -0,0 +1,109 @@ +architecture: 0.846 +performance: 0.727 +device: 0.723 +arm: 0.705 +files: 0.661 +ppc: 0.648 +debug: 0.624 +user-level: 0.582 +semantic: 0.547 +kernel: 0.524 +register: 0.480 +permissions: 0.476 +socket: 0.474 +PID: 0.458 +boot: 0.457 +hypervisor: 0.454 +graphic: 0.441 +network: 0.422 +mistranslation: 0.417 +peripherals: 0.401 +vnc: 0.395 +risc-v: 0.374 +TCG: 0.332 +VMM: 0.309 +assembly: 0.305 +virtual: 0.296 +KVM: 0.192 +x86: 0.158 +i386: 0.091 +-------------------- +debug: 0.989 +arm: 0.933 +user-level: 0.571 +hypervisor: 0.259 +virtual: 0.054 +kernel: 0.029 +TCG: 0.022 +performance: 0.021 +files: 0.016 +PID: 0.010 +architecture: 0.007 +network: 0.004 +device: 0.003 +semantic: 0.003 +register: 0.003 +assembly: 0.002 +graphic: 0.002 +socket: 0.002 +vnc: 0.001 +peripherals: 0.001 +ppc: 0.001 +permissions: 0.001 +boot: 0.001 +risc-v: 0.000 +VMM: 0.000 +x86: 0.000 +mistranslation: 0.000 +i386: 0.000 +KVM: 0.000 + +qemu-aarch64 hangs on cptofs during a build of NixOS SD card image + +First, thank you for this incredible project. + +While following this guide to build my own image of NixOS: https://nixos.wiki/wiki/NixOS_on_ARM#Compiling_through_QEMU on ARM Aarch64. + +I encountered a very strange behavior, qemu is correctly used and build most of the binaries until it executes this exact line over qemu: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-ext4-fs.nix#L55 + +At this step, the qemu process goes to 100 % of CPU, hangs in a certain syscall I don't know which one (according to strace & gdb which has no symbols so breaking and looking the backtrace was useless). + +According to iotop, no I/O was done. + +And it spent all its time in this syscall during more than 10 hours, which looks anomalous to me. + +I attach some of my CPU info: + +model : 142 +model name : Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz +stepping : 10 +microcode : 0x96 +cpu MHz : 3107.071 +cache size : 8192 KB + +I'm using a ThinkPad T480 to perform those builds, I'm uncertain of how to debug further this issue, I discussed this with some people over #nixos-aarch64 and they told me they didn't know how to debug it further too. + +I tried all with this package: https://aur.archlinux.org/packages/qemu-arm-static/ — I'm currently compiling qemu-git to see if it happens on upstream too. Will comment when it's done. + +Thank you in advance! + +Update: compiling qemu upstream & using the latest version didn't change anything. + + +I don't know if this is an instance of user emulation limitations due to missing syscalls. + +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/review/1859359 b/results/classifier/118/review/1859359 new file mode 100644 index 000000000..92b831db2 --- /dev/null +++ b/results/classifier/118/review/1859359 @@ -0,0 +1,154 @@ +semantic: 0.887 +permissions: 0.875 +peripherals: 0.874 +ppc: 0.873 +register: 0.870 +mistranslation: 0.870 +device: 0.863 +assembly: 0.861 +graphic: 0.856 +PID: 0.846 +virtual: 0.838 +arm: 0.836 +architecture: 0.833 +files: 0.832 +user-level: 0.827 +hypervisor: 0.818 +performance: 0.818 +TCG: 0.817 +vnc: 0.809 +network: 0.805 +risc-v: 0.803 +debug: 0.799 +socket: 0.794 +KVM: 0.778 +kernel: 0.777 +boot: 0.769 +VMM: 0.762 +x86: 0.662 +i386: 0.602 +-------------------- +user-level: 0.168 +debug: 0.052 +assembly: 0.052 +semantic: 0.041 +hypervisor: 0.034 +files: 0.022 +x86: 0.018 +architecture: 0.017 +virtual: 0.014 +TCG: 0.014 +device: 0.013 +kernel: 0.013 +i386: 0.012 +peripherals: 0.011 +register: 0.009 +arm: 0.007 +ppc: 0.005 +performance: 0.004 +network: 0.003 +PID: 0.002 +risc-v: 0.002 +socket: 0.002 +boot: 0.002 +vnc: 0.002 +permissions: 0.001 +mistranslation: 0.001 +graphic: 0.001 +VMM: 0.001 +KVM: 0.000 + +xHCI and event ring handling + +I believe that the Event Ring handling in QEMU is not correct. For example, an Event Ring may have multiple segments. However, the code in xhci_write_event() (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l645), starting with line 668, seems to only support a single segment. + +Also, QEMU is sending a spurious interrupt after the Guest writes to the ERDP register due to the fact that the address written does not match the current index. This is because the index is incremented after sending the event. The xHCI specification states in section 5.5.2.3.3 "When software finishes processing an Event TRB, it will write the address of that Event TRB to the ERDP." + +Since xhci_write_event() has already incremented the index pointer (intr->er_ep_idx), the check at line 3098 (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c;hb=HEAD#l3090) no longer is valid. + +I have not studied QEMU's code enough yet to offer a patch. However, this should be a simple fix. + +intr->er_ep_idx++; +if (intr->er_ep_idx >= intr->er_table[intr->er_segment].er_size) { + intr->er_ep_idx = 0; + intr->er_segment++; + if (intr->er_segment >= intr->er_table_size) { + intr->er_segment = 0; + intr->er_pcs = !intr->er_pcs; + } +} + +Being sure to incorporate this new segment member into the above code (possibly as shown) as well as change the lines at 665 to use the new segment member of the structure, and of course in the initialization portion of the event ring. + +As for the spurious interrupt at line 3101, a new member will need to be added to the code to keep track of the last inserted ED (TRB) into the Event Ring and then of course checking against this new member, not the now newly incremented member. + +I have sent an email to the author listed at the top of the file as well, not sure if this is proper bug reporting etiquette or not. + +Thank you. + +I failed to note above that the HCSPARAMS2 register does indeed limit the count of segments in the Event Ring. I guess as long as you never change this value from one (1) you will be okay. + +However, the spurious interrupt stuff still stands as a bug. + +Thank you, +Ben + +Please note that the current code reports zero (0) + +https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c#l2737 + +Bits 7:4 is this limit and the current code has these bits as zero. + + +My apologizes. I forgot that it was 2^ERSTMAX. I really need to get some sleep :-) + +qemu behavior matches linux guest driver expectations on erdp writes, I don't think we have a bug there. + +And, yes, qemu doesn't support multiple segments and correctly says so in the capabilities registers. + +The xHCI specification states that after processing the Event TRB, software is to write the address of that TRB to the xHC_INTERRUPTER_DEQUEUE. QEMU currently checks this value written and compares it to its own current pointer, which is now incremented to the next available TRB, therefore not matching. When finding that it does not match, it sends another interrupt. + +On receiving this interrupt, software will see this interrupt as a mismatch in cycle bits and simply write the address of the last processed Event TRB to the xHC_INTERRUPTER_DEQUEUE and return again. QEMU will then again check the address and find again that it is a mismatch, again firing the interrupt. This causes an infinite loop and will halt the USB. + +I do believe this to be in error. + +However, it is up to the majority, which seams to be a Linux based majority, so if it works on Linux, if it isn't broken, why fix it. + +As for the multiple segments in the Event Ring, this was more of a request than a bug report. Sorry for the miss representation on that part. + +Thank you, +Ben + +The part you're missing is in section 4.9.4. + +> System software shall advance the Event Ring Dequeue Pointer by writing the address of the last +processed Event TRB to the Event Ring Dequeue Pointer (ERDP) register. Note, the “last processed +Event TRB” includes the case where software detects a Cycle bit mismatch when evaluating an Event +TRB and the ring is empty. + +So the bug is in your code, because it's supposed to check the next TRB, find the cycle bit mismatch, and *that* qualifies as "processing" it, and then it should write *that* address to the ERDP, which is going to equal the actual last valid TRB's address + 1 (modulo wraparound), which is exactly what qemu expects, and what Linux does too. + +Hi Hector, guys, + +I think I have found my/the error: + +xHCI, version 1.0, Page 136: +"Note: The detection of a Cycle bit mismatch in an Event TRB processed + by software indicates the location of the xHC Event Ring Enqueue Pointer + and that the Event Ring is empty. Software shall write the ERDP with the + address of this TRB to indicate that it has processed all Events in the + ring." + +It does not state to advance the Consumer's internal Dequeue pointer. +Just the register is mentioned. + +This is my error. I thought that it implied to advance the Consumer's +internal Dequeue Pointer as well. (Implied being the big word here) + +Sorry for the bother. It was my error. It took me a bit of (re)reading +and a little more work to find that it was/is indeed my error. + +Sorry and thank you for your time, +Ben + + diff --git a/results/classifier/118/review/1859989 b/results/classifier/118/review/1859989 new file mode 100644 index 000000000..5344c8481 --- /dev/null +++ b/results/classifier/118/review/1859989 @@ -0,0 +1,112 @@ +semantic: 0.814 +graphic: 0.792 +permissions: 0.769 +risc-v: 0.752 +register: 0.744 +debug: 0.739 +user-level: 0.738 +assembly: 0.735 +mistranslation: 0.727 +virtual: 0.710 +arm: 0.710 +architecture: 0.707 +performance: 0.701 +device: 0.690 +VMM: 0.686 +peripherals: 0.685 +TCG: 0.679 +vnc: 0.676 +hypervisor: 0.673 +boot: 0.672 +network: 0.669 +PID: 0.667 +socket: 0.631 +files: 0.613 +ppc: 0.594 +KVM: 0.571 +kernel: 0.535 +i386: 0.529 +x86: 0.365 +-------------------- +virtual: 0.039 +user-level: 0.036 +files: 0.010 +register: 0.009 +debug: 0.008 +x86: 0.007 +hypervisor: 0.006 +PID: 0.005 +semantic: 0.005 +TCG: 0.004 +socket: 0.003 +vnc: 0.003 +VMM: 0.003 +i386: 0.003 +device: 0.003 +risc-v: 0.002 +peripherals: 0.002 +network: 0.002 +graphic: 0.002 +arm: 0.002 +ppc: 0.002 +architecture: 0.002 +boot: 0.002 +performance: 0.001 +kernel: 0.001 +mistranslation: 0.001 +permissions: 0.001 +assembly: 0.001 +KVM: 0.000 + +qemu-img has broken output with large snapshot names + +On Qemu 4.1.1 the output of snalshots breaks if the chosen state name is too long: + +# qemu-img snapshot -l /mnt/local/some_image.qcow2 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 online_provider_with_dhcp747 MiB 2020-01-15 12:05:01 00:00:45.873 + +Prior to 4.1.1 this used to work with extra tabs for the VM SIZE values. The collision is also disabling us from using a regex on top of this input to detect the snapshot. + +Hi, + +When did this work last for you? I tried every .0 release down to 2.12.0, and all showed this kind of broken output. (I wasn’t able to compile 2.11.0 and earlier.) + +Here was my test case: + +$ ./qemu-img create -f qcow2 foo.qcow2 64M +Formatting 'foo.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16 +$ ./qemu-img snapshot -c foofoofoofoofoofoofoofoofoofoo foo.qcow2 +$ ./qemu-img snapshot -l foo.qcow2 +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foofoofoofoofoofoofoofoofoofoo 0 2020-01-17 10:53:17 00:00:00.000 +$ ./qemu-img --version +qemu-img version 2.12.0 (v2.12.0) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Max + +I’ve just seen that launchpad collapses the spaces in the snapshot... All I can say is that diff tells me the output from 2.12.0 and 4.1.1 is exactly the same, with only one difference: 2.12.0 prints the VM SIZE as “0” (without a unit), whereas 4.1.1 prints “0 B”. + +But now I just realized you probably mean that there is no space between the snapshot name and the VM state size in your example. OK, I thought you meant the fact that the headers are not aligned to the table body columns. + +That seems to be because the size is printed in a 7-wide field, which isn’t sufficient for three-digit sizes with unit prefixes; so “747 MiB” is not prefixed by a space. I think de38b5005e9 is to blame which which (from what I can tell) effectively changed the output from using SI prefixes to IEC prefixes (which requires one more character), adds a space before and a “B” after the prefix (another two additional characters), and by always printing three digits, which may require a decimal point (so another character). But it didn’t grow the field width. So I think we should do that. + +Max + +Hi Max, + +It last worked in (previous version we used): +[root@c15 ~]# qemu-img --version +qemu-img version 3.1.1 (qemu-3.1.1-2.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Yes, unfortunately Launchpad doesn't seem to support any literal formatting which is why I tried to use the ``` to signal this. I will attach some images from both version to counter this effect and make it clearer to you where the problem is which is indeed in the clash between the state name and the size. The IEC prefixes were something new and we could handle that but not the lack of space which is new in this version we tried. + +Sent a patch: https://lists.nongnu.org/archive/html/qemu-block/2020-01/msg00376.html + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=804359b8b90f + diff --git a/results/classifier/118/review/1860759 b/results/classifier/118/review/1860759 new file mode 100644 index 000000000..bb9fec992 --- /dev/null +++ b/results/classifier/118/review/1860759 @@ -0,0 +1,197 @@ +user-level: 0.825 +TCG: 0.821 +KVM: 0.790 +hypervisor: 0.790 +vnc: 0.759 +x86: 0.748 +VMM: 0.745 +peripherals: 0.745 +risc-v: 0.732 +virtual: 0.727 +mistranslation: 0.721 +i386: 0.713 +permissions: 0.702 +ppc: 0.697 +device: 0.615 +register: 0.613 +graphic: 0.612 +debug: 0.605 +arm: 0.601 +files: 0.588 +network: 0.581 +boot: 0.566 +semantic: 0.565 +performance: 0.562 +PID: 0.556 +socket: 0.548 +assembly: 0.548 +architecture: 0.544 +kernel: 0.528 +-------------------- +x86: 0.994 +KVM: 0.940 +hypervisor: 0.918 +virtual: 0.913 +debug: 0.823 +kernel: 0.599 +register: 0.119 +TCG: 0.081 +VMM: 0.047 +files: 0.040 +user-level: 0.036 +device: 0.036 +socket: 0.032 +PID: 0.031 +boot: 0.025 +performance: 0.009 +peripherals: 0.004 +architecture: 0.004 +assembly: 0.004 +semantic: 0.003 +permissions: 0.003 +ppc: 0.002 +graphic: 0.002 +risc-v: 0.001 +i386: 0.001 +network: 0.001 +vnc: 0.001 +arm: 0.000 +mistranslation: 0.000 + +[REGRESSION] option `-snapshot` ignored with blockdev + +After upgrade of qemu 3.1.0 → 4.2.0 I found that running with libvirt doesn't honor `-snapshot` option anymore. I.e. disk images get modified. +Using `-hda` option honors `-snapshot` + +So I made a test case without libvirt. Testcase using 4.2.0: + +> qemu -hda tmp-16G.img -cdrom regular-rescue-latest-x86_64.iso -m 2G + +This works fine and tmp-16G.img stays unmodified. + +But: +> /usr/bin/qemu-system-x86_64 -name guest=test-linux,debug-threads=on -S -machine pc-i440fx-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Broadwell-noTSX,vme=on,ss=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,xsaveopt=on,pdpe1gb=on,abm=on -m 2048 -overcommit mem-lock=off -smp 3,sockets=3,cores=1,threads=1 -uuid d32a9191-f51d-4fae-a419-b73d85b49198 -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/regular-rescue-latest-x86_64.iso\",\"node-name\":\"libvirt-2-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-2-format\",\"read-only\":true,\"driver\":\"raw\",\"file\":\"libvirt-2-storage\"} -device ide-cd,bus=ide.0,unit=0,drive=libvirt-2-format,id=ide0-0-0,bootindex=1 -blockdev \{\"driver\":\"file\",\"filename\":\"/tmp/tmp-2G.img\",\"node-name\":\"libvirt-1-storage\",\"auto-read-only\":true,\"discard\":\"unmap\"} -blockdev \{\"node-name\":\"libvirt-1-format\",\"read-only\":false,\"driver\":\"qcow2\",\"file\":\"libvirt-1-storage\",\"backing\":null} -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-1-format,id=virtio-disk0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:ab:d8:29,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -snapshot -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +This modifies tmp-16G.img. + +JFYI, I know that snapshot=on option should be used. But `-snapshot` option exists and must work. +Also libvirt doesn't yet support it: https://bugzilla.redhat.com/show_bug.cgi?id=508662 + + +Hi, + +I don’t know much about libvirt, but I would have thought that any manual modification of the qemu command line isn’t supported and might always break. + +Anyway, from a QEMU POV, -snapshot only works with -drive (this includes -hda, etc.). It doesn’t work with -blockdev. I can see that this isn’t documented for -snapshot, but basically whenever -blockdev is used, the user assumes full responsibility for the block graph (or at least that particular subgraph). We cannot enable snapshot functionality then. + +So this can’t be fixed in qemu, as -snapshot doesn’t make sense for -blockdev. This behavior should be documented, though. + +As for libvirt, I don’t know. I would be surprised if it had a guarantee for keeping manual qemu command line additions working, and I can’t imagine that it would scan the XML for “legacy” qemu parameters and interpret them itself (which it would need to do to keep -snapshot working for -blockdev). + +Max + +Max, thanks a lot for the explanation. +Do you mean that snapshot-ing isn't possible totally for blockdev? Then I +guess some libvirt users are in trouble :(( +Actually I didn't quite caught the reason why a blockdev supports backing +but not {backing to a file on /tmp then promptly deleted} ? What's the +technical difference? + + +On 1/24/20 4:41 AM, Ildar wrote: +> Max, thanks a lot for the explanation. +> Do you mean that snapshot-ing isn't possible totally for blockdev? Then I +> guess some libvirt users are in trouble :(( +> Actually I didn't quite caught the reason why a blockdev supports backing +> but not {backing to a file on /tmp then promptly deleted} ? What's the +> technical difference? +> + +On 1/24/20 4:05 AM, Max Reitz wrote: +> +> +> I don’t know much about libvirt, but I would have thought that any +> manual modification of the qemu command line isn’t supported and might +> always break. +> +> Anyway, from a QEMU POV, -snapshot only works with -drive (this includes +> -hda, etc.). It doesn’t work with -blockdev. I can see that this isn’t +> documented for -snapshot, but basically whenever -blockdev is used, the +> user assumes full responsibility for the block graph (or at least that +> particular subgraph). We cannot enable snapshot functionality then. + +Libvirt has never produced a qemu command line containing '-snapshot'. +Part of this is that libvirt wants to control SELinux settings, and +letting qemu create a temporary overlay in /tmp in order to implement +-snapshot does not play nicely with libvirt pre-creating all files that +qemu is allowed to access. + +The fact that you were able to manually add -snapshot to your qemu +command line with older libvirt using -drive (I'm assuming you were also +not using libvirt's SELinux support, because if you were, qemu would +have been unable to create/access the temporary wrapper in /tmp), is a +nice hack. But since modern qemu has declared -snapshot to be +unsupported with -blockdev, and modern libvirt has switched to +-blockdev, I claim that this is not a qemu bug, but a libvirt feature +request. + +That said, libvirt has had a vision for a design for implementing the +equivalent of -drive -snapshot: the <transient/> sub-element added to +the domain/disk/source/driver element has been documented for a long time: + +https://libvirt.org/formatdomain.html +"transient + If present, this indicates that changes to the device contents +should be reverted automatically when the guest exits. With some +hypervisors, marking a disk transient prevents the domain from +participating in migration or snapshots. Since 0.9.5 " + +However, no one has yet implemented it for libvirt's qemu driver. Part +of our reluctance has been that we knew that implementing it would +require libvirt to precreate the wrapper file on every guest start, and +it is only very recently that we've even had enough functionality in +libvirt's qemu driver coupled with new qemu commands to create qcow2 +images using QMP rather than having to shell out to qemu-img. And part +of it is that there was no point in implementing something to work with +-drive, when we knew we had to rework everything for -blockdev anyways. +But now that the work in libvirt to switch to -blockdev is done, it +should be a lot easier to implement PROPER support for the <transient/> +tag, at least for -blockdev usage. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Thank a lot for the detailed answer. Surely it's worth discussing qemu here +leaving libvirt for RH bugzilla. + +> But since modern qemu has declared -snapshot to be unsupported with +-blockdev, and modern libvirt has switched to -blockdev, I claim that this +is not a qemu bug, but a libvirt feature request. + +I'm convinced this isn't qemu's bug. And everything you wrote is +well-justified. Yet, one question left unanswered: +> Do you mean that snapshot-ing isn't possible totally for blockdev? +> Actually I didn't quite caught the reason why a blockdev supports backing +but not {backing to a file on /tmp then promptly deleted} ? What's the +technical difference? + +Thanks! + + +Hi, + +The technical difference is that -blockdev requires you (the user or management software) to create all block graph nodes explicitly. -drive snapshot=on implicitly creates a qcow2 node above the actual disk image (and that node points to a temporary image in /tmp). So because it’s implicit and not explicit, it can’t work with -blockdev. + +With -blockdev, the user has to create this temporary overlay, open it in qemu (with blockdev-add or -blockdev), and then delete it. + +Max + +this answers the whole question. Thanks a lot. closing + + +Internal implementation details aside, from the user PoV it is a *very* serious issue. If -snapshot can't be applied automatically, maybe qemu should warn or better fail if -snapshot is used together with -blockdev. + diff --git a/results/classifier/118/review/1861404 b/results/classifier/118/review/1861404 new file mode 100644 index 000000000..8a0ff5f56 --- /dev/null +++ b/results/classifier/118/review/1861404 @@ -0,0 +1,270 @@ +mistranslation: 0.825 +debug: 0.819 +user-level: 0.812 +virtual: 0.811 +assembly: 0.797 +architecture: 0.797 +files: 0.788 +ppc: 0.786 +device: 0.782 +graphic: 0.773 +PID: 0.773 +performance: 0.769 +x86: 0.769 +register: 0.766 +risc-v: 0.761 +TCG: 0.752 +socket: 0.740 +network: 0.740 +VMM: 0.731 +kernel: 0.731 +semantic: 0.730 +arm: 0.729 +permissions: 0.726 +hypervisor: 0.724 +KVM: 0.709 +boot: 0.708 +peripherals: 0.697 +vnc: 0.697 +i386: 0.401 +-------------------- +x86: 0.787 +user-level: 0.251 +debug: 0.225 +files: 0.074 +TCG: 0.053 +kernel: 0.035 +register: 0.032 +virtual: 0.026 +PID: 0.024 +VMM: 0.017 +semantic: 0.014 +assembly: 0.013 +architecture: 0.010 +hypervisor: 0.007 +performance: 0.005 +device: 0.004 +i386: 0.004 +socket: 0.004 +boot: 0.003 +mistranslation: 0.003 +peripherals: 0.002 +ppc: 0.002 +risc-v: 0.002 +network: 0.002 +graphic: 0.001 +vnc: 0.001 +permissions: 0.001 +KVM: 0.001 +arm: 0.000 + +AVX instruction VMOVDQU implementation error for YMM registers + +Hi, + +Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. + +The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). +It works with XMM registers (16 bytes) though. + +See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. + +``` +user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror + +user@ubuntu ~/Qemu % ./ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F + +user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). + +Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. + + +``` +static void gen_sse(CPUX86State *env, DisasContext *s, int b, + target_ulong pc_start, int rex_r) +{ + [...] + case 0x26f: /* movdqu xmm, ea */ + if (mod != 3) { + gen_lea_modrm(env, s, modrm); + gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); + } else { + [...] +``` + +``` +static inline void gen_ldo_env_A0(DisasContext *s, int offset) +{ + int mem_index = s->mem_index; + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); + tcg_gen_addi_tl(s->tmp0, s->A0, 8); + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); +} +``` + + + +Note: Qemu has been built with the following commands: +``` +% ./configure --target-list=x86_64-linux-user && make +OR +% ./configure --target-list=x86_64-linux-user --enable-avx2 && make +``` + +On Friday, January 31, 2020, Alex Bennée <email address hidden> wrote: + +> ** Tags added: tcg testcase +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1861404 +> +> Title: +> AVX instruction VMOVDQU implementation error for YMM registers +> +> +If I remember well, there is no support for AVX instructions in linux-user +mode. + +If that is true, how come handling of unsupported instruction went that far? + +Did you try other AVX instructions? + +Aleksandar + + + + +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> Tested with Qemu 4.2.0, and with git version +> bddff6f6787c916b0e9d63ef9e4d442114257739. +> +> The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers +> (32 bytes). +> It works with XMM registers (16 bytes) though. +> +> See the attached test case `ymm.c`: when copying from memory-to-ymm0 +> and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the +> first 16 of the total 32 bytes. +> +> ``` +> user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror +> +> user@ubuntu ~/Qemu % ./ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 +> 18 19 1A 1B 1C 1D 1E 1F +> +> user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 +> 00 00 00 00 00 00 00 00 +> ``` +> +> This seems to be because in `translate.c > gen_sse()`, the case +> handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always +> performs a 16 bytes copy using two 8 bytes load and store operations +> (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). +> +> Instead, the `gen_ldo_env_A0` function should generate a copy with a +> size corresponding to the used register. +> +> +> ``` +> static void gen_sse(CPUX86State *env, DisasContext *s, int b, +> target_ulong pc_start, int rex_r) +> { +> [...] +> case 0x26f: /* movdqu xmm, ea */ +> if (mod != 3) { +> gen_lea_modrm(env, s, modrm); +> gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); +> } else { +> [...] +> ``` +> +> ``` +> static inline void gen_ldo_env_A0(DisasContext *s, int offset) +> { +> int mem_index = s->mem_index; +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(0))); +> tcg_gen_addi_tl(s->tmp0, s->A0, 8); +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(1))); +> } +> ``` +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1861404/+subscriptions +> +> + + +Because the sse code is sloppy, and it was interpreted +as the sse instruction movdqu. + +AVX support was coded for GSoC last year, + +https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +but it has not been completely reviewed and committed. + +There is no support for AVX in master. + +Thanks for your answers. + +I thought the fact that there was not any warning/exception meant that VMOVDQU was supported, but if it's mistakenly interpreted as MOVDQU then I understand. + +I read the mailing list messages on the AVX GSoC you point out, but couldn't find any branch where this work is located. Is there a non-released version of this that can be tested? + +If I understand correctly, Qemu (or more precisely TCG) supports x86 SIMD instructions up to SSE4.1, but not AVX/AVX2/AVX-512? + +Thanks. + +Hi, + +I also noticed that the 4.2.0 release changelog mentions support for some AVX512 instructions. + +https://wiki.qemu.org/ChangeLog/4.2#x86 +``` +Support for AVX512 BFloat16 extensions. +``` + +Is this support in TCG or in another component? +If so, it would mean that TCG support some AVX512 instructions but not AVX. + +Also, allow me to ask again, where can I find the work of last year's GSoC on AVX support for TCG? + +> AVX support was coded for GSoC last year, +> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +Thanks. + +The "AVX512 BFloat16" patch is for KVM support. + +As for finding the GSoC work, please follow that link, +and the ones buried inside that. There are hundreds +of patches involved. + + +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/132 + + diff --git a/results/classifier/118/review/1861551 b/results/classifier/118/review/1861551 new file mode 100644 index 000000000..e2931fe84 --- /dev/null +++ b/results/classifier/118/review/1861551 @@ -0,0 +1,115 @@ +architecture: 0.890 +device: 0.878 +register: 0.869 +peripherals: 0.845 +graphic: 0.834 +semantic: 0.829 +assembly: 0.813 +hypervisor: 0.806 +permissions: 0.800 +debug: 0.798 +performance: 0.794 +user-level: 0.790 +arm: 0.790 +virtual: 0.786 +KVM: 0.776 +PID: 0.773 +kernel: 0.763 +TCG: 0.758 +files: 0.741 +socket: 0.740 +VMM: 0.730 +ppc: 0.724 +vnc: 0.723 +x86: 0.715 +boot: 0.710 +network: 0.705 +mistranslation: 0.684 +risc-v: 0.622 +i386: 0.580 +-------------------- +hypervisor: 0.336 +files: 0.195 +TCG: 0.188 +debug: 0.068 +virtual: 0.062 +kernel: 0.053 +PID: 0.050 +register: 0.044 +semantic: 0.042 +VMM: 0.039 +x86: 0.025 +device: 0.016 +performance: 0.015 +architecture: 0.008 +user-level: 0.007 +KVM: 0.006 +network: 0.006 +vnc: 0.006 +peripherals: 0.004 +boot: 0.004 +risc-v: 0.004 +permissions: 0.003 +socket: 0.003 +ppc: 0.003 +i386: 0.003 +arm: 0.003 +assembly: 0.002 +graphic: 0.001 +mistranslation: 0.001 + +Errors while compiling source + +OS type: Mac OS X 10.11.6 +List of errors: +qemu-io-cmds.c:837:5: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration] + clock_gettime(CLOCK_MONOTONIC, &t1); + ^ +qemu-io-cmds.c:837:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t1); + ^ +qemu-io-cmds.c:843:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +qemu-io-cmds.c:970:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t1); + ^ +qemu-io-cmds.c:972:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +qemu-io-cmds.c:1184:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t1); + ^ +qemu-io-cmds.c:1194:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +qemu-io-cmds.c:1306:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t1); + ^ +qemu-io-cmds.c:1308:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +qemu-io-cmds.c:1351:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +qemu-io-cmds.c:1383:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +qemu-io-cmds.c:1518:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &ctx->t1); + ^ +qemu-io-cmds.c:1663:23: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &ctx->t1); + ^ +qemu-io-cmds.c:1885:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t1); + ^ +qemu-io-cmds.c:1887:19: error: use of undeclared identifier 'CLOCK_MONOTONIC' + clock_gettime(CLOCK_MONOTONIC, &t2); + ^ +1 warning and 14 errors generated. +make: *** [qemu-io-cmds.o] Error 1 + +Hi. The CLOCK_MONOTONIC facility was added in OSX 10.12; the version of OSX you're using is too old to build QEMU on, I'm afraid. QEMU's policy is to support the last two releases of OSX, so at the moment that's 10.14 and 10.15. Compiling on older versions might work, but it also might not, as you've discovered. + + diff --git a/results/classifier/118/review/1863247 b/results/classifier/118/review/1863247 new file mode 100644 index 000000000..653c4bc5c --- /dev/null +++ b/results/classifier/118/review/1863247 @@ -0,0 +1,80 @@ +architecture: 0.921 +register: 0.753 +device: 0.668 +graphic: 0.540 +semantic: 0.501 +kernel: 0.468 +performance: 0.452 +risc-v: 0.396 +mistranslation: 0.393 +socket: 0.384 +network: 0.383 +arm: 0.366 +x86: 0.352 +vnc: 0.341 +ppc: 0.316 +debug: 0.315 +virtual: 0.310 +i386: 0.294 +files: 0.269 +boot: 0.254 +assembly: 0.250 +user-level: 0.242 +VMM: 0.207 +hypervisor: 0.206 +permissions: 0.194 +KVM: 0.178 +peripherals: 0.175 +PID: 0.162 +TCG: 0.091 +-------------------- +architecture: 0.606 +register: 0.400 +assembly: 0.296 +debug: 0.261 +hypervisor: 0.041 +TCG: 0.017 +files: 0.014 +virtual: 0.008 +semantic: 0.005 +kernel: 0.005 +VMM: 0.004 +network: 0.004 +user-level: 0.003 +performance: 0.002 +KVM: 0.002 +device: 0.002 +risc-v: 0.002 +PID: 0.002 +peripherals: 0.001 +vnc: 0.001 +boot: 0.001 +socket: 0.001 +graphic: 0.001 +permissions: 0.001 +arm: 0.000 +mistranslation: 0.000 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +AArch64 EXT instruction for V register does not clear MSB side bits + +On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. + +Example +ext v0.16b, v1.16b v2.16b, 8 + +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. + +Yep. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=78cedfabd53b + + +Thank you for bug fix. +I found trn1, trn2, zip1, zip2, uz1, uz2 instructions seem to have same bug. + +All of those, and tbl, tbx, ins, are fixed in the three subsequent commits. + diff --git a/results/classifier/118/review/1863685 b/results/classifier/118/review/1863685 new file mode 100644 index 000000000..a27d3018b --- /dev/null +++ b/results/classifier/118/review/1863685 @@ -0,0 +1,95 @@ +register: 0.850 +architecture: 0.793 +hypervisor: 0.777 +virtual: 0.753 +debug: 0.729 +peripherals: 0.720 +arm: 0.692 +semantic: 0.658 +mistranslation: 0.656 +performance: 0.607 +device: 0.596 +user-level: 0.537 +kernel: 0.523 +ppc: 0.405 +graphic: 0.384 +vnc: 0.359 +risc-v: 0.353 +network: 0.346 +permissions: 0.345 +socket: 0.339 +assembly: 0.324 +VMM: 0.316 +KVM: 0.247 +PID: 0.228 +boot: 0.220 +i386: 0.213 +x86: 0.195 +files: 0.188 +TCG: 0.164 +-------------------- +arm: 0.996 +debug: 0.962 +virtual: 0.139 +register: 0.069 +hypervisor: 0.060 +architecture: 0.036 +kernel: 0.021 +files: 0.013 +user-level: 0.011 +semantic: 0.005 +performance: 0.004 +TCG: 0.004 +network: 0.004 +assembly: 0.003 +device: 0.003 +peripherals: 0.003 +KVM: 0.002 +VMM: 0.002 +boot: 0.001 +socket: 0.001 +PID: 0.001 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.001 +graphic: 0.001 +permissions: 0.001 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +ARM: HCR.TSW traps are not implemented + +On 32-bit and 64-bit ARM platforms, setting HCR.TSW is supposed to "Trap data or unified cache maintenance instructions that operate by Set/Way." Quoting the ARM manual: + +If EL1 is using AArch64 state, accesses to DC ISW, DC CSW, DC CISW are trapped to EL2, reported using EC syndrome value 0x18. +If EL1 is using AArch32 state, accesses to DCISW, DCCSW, DCCISW are trapped to EL2, reported using EC syndrome value 0x03. + +However, QEMU does not trap those instructions/registers. This was tested on the branch master of the git repo. + +Patch posted: +https://<email address hidden>/ + +Thanks for the quick turn around! I tested both your patches together (it's useful to have both to emulate set/way flushing inside a guest) and I am getting something unexpected. At some point, we are trapping on an access to DACR but ESR_EL2 doesn't seem to make a lot of sense: 0xfe00dc0. I am running a 32-bit Linux inside a VM. + +Decoding it: Rt is set to 0xe which is LR_usr. Also, this is a read operation. So, essentially the guest seems to try to set DACR to LR_usr which seems unreasonable. + +It could be an issue with the hypervisor on my side (I am running some custom code). But, it's not obvious to me and the code behaves fine on bare-metal. Is there a chance that ESR is not populated correctly? + +In any case, I do see traps for set/way instructions so, from that point of view, the patch is good. + + + +Sorry, I meant the operation is a write (TVM is on). The result of the operation is setting DACR to 0 so the guest stops progressing after that. + +Anyway, since the issue could also be on my side, I don't want to block you with this. + +I can't think of any reason that DACR would have an incorrect +register value. It would be treated as any other system register, +and there's only one code path involved. + +Makes sense. Debugging is on me then :) Both patches behave as expected, thanks! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1803d2713b29 + diff --git a/results/classifier/118/review/1863710 b/results/classifier/118/review/1863710 new file mode 100644 index 000000000..b1da18132 --- /dev/null +++ b/results/classifier/118/review/1863710 @@ -0,0 +1,80 @@ +architecture: 0.911 +arm: 0.774 +mistranslation: 0.741 +graphic: 0.706 +device: 0.691 +semantic: 0.636 +kernel: 0.595 +virtual: 0.566 +performance: 0.554 +network: 0.548 +user-level: 0.527 +hypervisor: 0.429 +x86: 0.412 +permissions: 0.409 +socket: 0.409 +i386: 0.395 +ppc: 0.323 +files: 0.322 +PID: 0.307 +debug: 0.300 +boot: 0.296 +register: 0.286 +vnc: 0.261 +risc-v: 0.259 +KVM: 0.253 +peripherals: 0.229 +VMM: 0.213 +TCG: 0.163 +assembly: 0.124 +-------------------- +virtual: 0.870 +user-level: 0.781 +debug: 0.734 +hypervisor: 0.720 +TCG: 0.126 +x86: 0.096 +performance: 0.031 +kernel: 0.030 +PID: 0.013 +files: 0.011 +device: 0.011 +VMM: 0.009 +register: 0.006 +i386: 0.005 +boot: 0.005 +peripherals: 0.004 +network: 0.003 +arm: 0.003 +semantic: 0.003 +socket: 0.002 +architecture: 0.002 +ppc: 0.002 +risc-v: 0.002 +assembly: 0.001 +vnc: 0.001 +graphic: 0.001 +KVM: 0.000 +mistranslation: 0.000 +permissions: 0.000 + +qemu 4.2 does not process discard(trim) commands + +I'm using Arch Linux with qemu 4.2 and blktrace to monitor discard commands as they are sent to the hardware. Blktrace shows nothing as the VM is trimming the SSDs. + +I downgraded to qemu 4.1.1 and blktrace shows lots of discard commands as the VM is trimming. + +Kernel version is 5.5.4. + +Attached is the libvirt xml. + + + + + +How did you start QEMU? Does this still happen with the latest version of QEMU? + +I mean: Please provide the QEMU command line parameters ... is this also reproducible without libvirt? ... otherwise it might also be a problem in libvirt instead... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1864955 b/results/classifier/118/review/1864955 new file mode 100644 index 000000000..7ba5007cd --- /dev/null +++ b/results/classifier/118/review/1864955 @@ -0,0 +1,112 @@ +user-level: 0.958 +mistranslation: 0.957 +permissions: 0.900 +semantic: 0.897 +graphic: 0.861 +virtual: 0.861 +performance: 0.837 +PID: 0.763 +ppc: 0.748 +device: 0.742 +socket: 0.720 +peripherals: 0.713 +debug: 0.707 +files: 0.700 +VMM: 0.684 +register: 0.676 +arm: 0.651 +architecture: 0.596 +assembly: 0.585 +kernel: 0.577 +network: 0.540 +hypervisor: 0.526 +x86: 0.520 +vnc: 0.510 +boot: 0.489 +risc-v: 0.473 +TCG: 0.378 +i386: 0.352 +KVM: 0.346 +-------------------- +permissions: 0.918 +TCG: 0.651 +PID: 0.520 +socket: 0.273 +hypervisor: 0.187 +semantic: 0.151 +files: 0.145 +risc-v: 0.092 +kernel: 0.085 +VMM: 0.075 +device: 0.050 +boot: 0.037 +x86: 0.034 +register: 0.033 +ppc: 0.022 +KVM: 0.020 +network: 0.016 +vnc: 0.014 +virtual: 0.013 +user-level: 0.007 +debug: 0.005 +i386: 0.004 +arm: 0.002 +assembly: 0.001 +peripherals: 0.001 +architecture: 0.001 +performance: 0.001 +mistranslation: 0.001 +graphic: 0.001 + +bundle QEMU installer with HAXM accelerator for Windows + +As you probably know HAXM is an accelerator for Windows. + +https://www.qemu.org/2017/11/22/haxm-usage-windows/ + +Currently it is required to first install QEMU and then install HAXM. + +For a better out of the box user experience on the Windows platform it would be nice if QEMU and HAXM would be installed by the same installer. + +Apparently HAXM uses the BSD 3-Clause License with the 3rd clause that "prohibits others from using the name of the project or its contributors to promote derived products without written consent." + +I think licensing is a non-issue. + +That is probably a quote from the github license summary at https://github.com/intel/haxm/blob/master/LICENSE + +> A permissive license similar to the BSD 2-Clause License, but with a 3rd clause that prohibits others from using the name of the project or its contributors to promote derived products without written consent. + +I would ignore whatever github says "This is not legal advice. Learn more about repository licenses." Their summary might have good intentions but cause confusion. Only github mentions "project". The actual license text does not. + +The actual text of the third clause in the license being: + +> Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. + +This should be easy to comply with. + +One could would wrap that clause into quotes (") to put it into a google search engine. + +This clause is OSI approved since included in BSD-3-Clause license: + +https://opensource.org/licenses/BSD-3-Clause + +Debian takes being Free / Libre / Open Source very serious too. Search term: + +> site:debian.org "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." + +https://ftp-master.debian.org/licenses/good/bsd/ + +FSF also does not have an issue with it. + +> site:fsf.org "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." + +3 authorities don't have an issue with modified BSD license (without advertising clause). + +Rather, the QEMU installer doesn't need to have HAXM in its file name. + +It may or may not be good idea to make HAXM an opt-in or opt-out in the installer. I'd argue opt-out if anything. But ideally for usability there is no need to mention HAXM. Things would just work out of the box. + +As a role model for usability I'd recommend VirtualBox. Their installer also doesn't ask/show "enable acceleration" or "VirtualBox includes QEMU" or other components in prominent places. + +The QEMU project itself does not provide any binaries for Windows, so I'm closing this ticket now. There are several people who provide binaries for Windows, so if you want to get one of these changed, please get in touch with the corresponding person who offers that binary instead. + diff --git a/results/classifier/118/review/1865252 b/results/classifier/118/review/1865252 new file mode 100644 index 000000000..db5d58482 --- /dev/null +++ b/results/classifier/118/review/1865252 @@ -0,0 +1,96 @@ +user-level: 0.980 +semantic: 0.951 +mistranslation: 0.897 +PID: 0.884 +boot: 0.867 +permissions: 0.850 +device: 0.846 +files: 0.831 +peripherals: 0.825 +network: 0.823 +architecture: 0.819 +vnc: 0.816 +ppc: 0.813 +socket: 0.809 +hypervisor: 0.790 +graphic: 0.787 +performance: 0.787 +kernel: 0.786 +VMM: 0.738 +register: 0.737 +arm: 0.728 +KVM: 0.712 +i386: 0.692 +risc-v: 0.691 +debug: 0.676 +TCG: 0.675 +x86: 0.668 +assembly: 0.663 +virtual: 0.594 +-------------------- +x86: 0.328 +hypervisor: 0.319 +network: 0.165 +register: 0.138 +virtual: 0.108 +semantic: 0.104 +TCG: 0.056 +files: 0.055 +risc-v: 0.030 +PID: 0.019 +boot: 0.011 +device: 0.009 +socket: 0.007 +VMM: 0.006 +user-level: 0.005 +ppc: 0.003 +permissions: 0.003 +vnc: 0.002 +kernel: 0.002 +architecture: 0.002 +peripherals: 0.001 +assembly: 0.001 +debug: 0.001 +graphic: 0.001 +i386: 0.001 +performance: 0.001 +mistranslation: 0.000 +KVM: 0.000 +arm: 0.000 + +QEMU Windows Portable Version (with HAXM accelerator and QEMU GUI) + +Please consider providing a QEMU Windows portable [1] [2] [3] version on official qemu.org. + +Reasons: + +* This would improve usability, the out of the box user experience of laymen (non-technical) users. +* Linux distributions could add the QEMU Windows portable to their installer / live ISO images (and the DVD's autorun.inf). Users who are still running on the Windows platform could be having an easy path to try out a Linux distribution by running int inside QEMU. I've seen that in many some years ago. Was running Windows. Just open the DVD drive in Windows explorer, double click and QEMU (shipped with the ISO) booted the ISO. + +Ideally EMU Windows portable version would be bundled with: + +* the [QEMU HAXM accelerator] by default. Related ticket: [5] +* a QEMU GUI by default. Related ticket: [6] + + +[1] When I say "Windows Portable" I mean "USB portable". [4] + +[2] A compress archive (zip or so) which after extraction can be executed without further installation / setup required. As far I know [https://portableapps.com portableapps.com] is the most popular project of that kind. + +[3] QEMU might already be portable or mostly portable. See: + +* https://portableapps.com/search/node/QEMU +* https://www.google.com/search?hl=en&q=site%3Aportableapps.com%20QEMU%20portable +* https://www.portablefreeware.com/?id=640 +* https://willhaley.com/blog/simple-portable-linux-qemu-vm-usb/ + +But not sure above projects are still maintained. Would be certainly better if official qemu.org would be providing a QEMU Windows portable version. + +[4] Or more generally "can be run on any external storage medium on any Windows [10] computer. + +[5] https://bugs.launchpad.net/qemu/+bug/1864955 + +[6] https://bugs.launchpad.net/qemu/+bug/1865248 + +QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. I'm sorry, but as far as I know there is currently nobody working on such a topic, and opening a ticket like this won't make it happen without some new contributor to step up to do the job. Thus I'm closing this ticket now. Feel free to re-open if you know someone who could contribute this feature. + diff --git a/results/classifier/118/review/1866577 b/results/classifier/118/review/1866577 new file mode 100644 index 000000000..f329c903d --- /dev/null +++ b/results/classifier/118/review/1866577 @@ -0,0 +1,78 @@ +architecture: 0.949 +device: 0.894 +graphic: 0.810 +ppc: 0.793 +debug: 0.740 +network: 0.689 +semantic: 0.640 +socket: 0.583 +register: 0.576 +performance: 0.568 +PID: 0.513 +vnc: 0.491 +TCG: 0.485 +mistranslation: 0.476 +arm: 0.435 +risc-v: 0.328 +files: 0.313 +boot: 0.311 +kernel: 0.297 +user-level: 0.288 +i386: 0.238 +VMM: 0.202 +permissions: 0.179 +peripherals: 0.178 +x86: 0.141 +virtual: 0.126 +hypervisor: 0.046 +KVM: 0.017 +assembly: 0.011 +-------------------- +ppc: 0.980 +debug: 0.917 +user-level: 0.564 +TCG: 0.089 +files: 0.056 +register: 0.036 +virtual: 0.016 +PID: 0.013 +hypervisor: 0.012 +device: 0.010 +semantic: 0.009 +performance: 0.007 +architecture: 0.005 +assembly: 0.005 +network: 0.004 +boot: 0.004 +kernel: 0.004 +socket: 0.003 +peripherals: 0.003 +arm: 0.002 +VMM: 0.002 +permissions: 0.001 +graphic: 0.001 +risc-v: 0.001 +x86: 0.001 +vnc: 0.000 +KVM: 0.000 +mistranslation: 0.000 +i386: 0.000 + +powerpc-none-eabi-gdb.exe GDB 9.1 with QEMU 4.2 gdb-stub comes with Reply contains invalid hex digit 79 + +I am using powerpc-none-eabi-gdb with qemu 4.2, but it comes with +the following error: + +undefinedC:\CI-Tools\msys64\powerpc-none-eabi\usr\local\bin\powerpc-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. + +```Not implemented stop reason (assuming exception): undefined``` +The target architecture is assumed to be powerpc:603 + +``` +Reply contains invalid hex digit 79 +``` + +Which parameters do you use to run QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1866870 b/results/classifier/118/review/1866870 new file mode 100644 index 000000000..ed88f55c7 --- /dev/null +++ b/results/classifier/118/review/1866870 @@ -0,0 +1,878 @@ +mistranslation: 0.887 +user-level: 0.874 +semantic: 0.872 +permissions: 0.861 +virtual: 0.858 +debug: 0.838 +graphic: 0.835 +peripherals: 0.809 +hypervisor: 0.803 +ppc: 0.802 +kernel: 0.801 +assembly: 0.790 +register: 0.783 +device: 0.783 +risc-v: 0.780 +x86: 0.779 +boot: 0.774 +PID: 0.773 +architecture: 0.770 +arm: 0.766 +socket: 0.759 +KVM: 0.757 +VMM: 0.754 +vnc: 0.750 +network: 0.748 +TCG: 0.742 +performance: 0.741 +files: 0.669 +i386: 0.615 +-------------------- +KVM: 0.923 +hypervisor: 0.730 +kernel: 0.331 +virtual: 0.178 +x86: 0.035 +debug: 0.025 +files: 0.022 +socket: 0.007 +TCG: 0.007 +semantic: 0.007 +device: 0.006 +performance: 0.006 +PID: 0.006 +register: 0.005 +boot: 0.004 +user-level: 0.003 +i386: 0.002 +ppc: 0.002 +architecture: 0.002 +assembly: 0.001 +arm: 0.001 +permissions: 0.001 +VMM: 0.001 +peripherals: 0.001 +graphic: 0.001 +risc-v: 0.001 +vnc: 0.001 +network: 0.001 +mistranslation: 0.000 + +KVM Guest pauses after upgrade to Ubuntu 20.04 + +As outlined here: https://bugs.launchpad.net/qemu/+bug/1813165/comments/15 + +After upgrade, all KVM guests are in a default pause state. Even after forcing them off via virsh, and restarting them the guests are paused. + +These Guests are not nested. + +A lot of diganostic information are outlined in the previous bug report link provided. The solution mentioned in previous report had been allegedly integrated into the downstream updates. + + + +Hi tstrike, +thanks for the report. +I have slightly modified the description and changed the bug tasks accordingly for you. + +I first checked the related known fixes from the old case that is linked. +Just in case if we might miss one in Ubuntu 20.04 that you are using. + + +Kernel: +=> https://marc.info/?l=kvm&m=155085391830663&w=2 +Tested and verified https://bugs.launchpad.net/qemu/+bug/1813165/comments/13 +This got upstream and is in: +$ git describe --contains ad7dc69aeb231 +v5.0-rc8~1^2~2 +That we'd clearly have in Focal being on 5.4 + +qemu +https://git.qemu.org/?p=qemu.git;a=commit;h=9c1f8f4493e8355d0e48f7d1eebdf86893ba082d +Other fixes related to the topic are in qemu 2.8 + +On seabios disabling of SMM +- https://bugzilla.redhat.com/show_bug.cgi?id=1378006 +- https://bugzilla.redhat.com/show_bug.cgi?id=1464654#c21 +The following is from >=1.12.0-1 (was enabled by default before) +There is a small (for old qemu) and large binary (new qemu): + 42 build/bios.bin: + 43 # A stripped-down version of bios, to fit in 128Kb, for qemu <= 1.7 + 44 »···$(call build-bios,bios,QEMU=y ROM_SIZE=128 PVSCSI=n BOOTSPLASH=n XEN=n USB_OHCI=n USB_XHCI=n USB_UAS=n SDCARD=n TCGBIOS=n MPT_SCSI=n NVME=n USE_SMM=n VGAHOOKS=n) + 45 build/bios-256k.bin: + 46 »···$(call build-bios,bios,QEMU=y ROM_SIZE=256) + +Note: if we are out of options we could try testing to set USE_SMM=n here, but lets check other details first. + +But as already explained on the linked bug 1813165: +"If you're seeing "KVM internal error. Suberror: 1" it can be multiple things, not necessarily the same bug." + +Copied here from the other bug about the system setup that is in use: + +L0 DistroRelease: Ubuntu 20.04 on Kernel Linux 5.4.0-14-generic x86_64 +L1 3 guests Windows 10, Centos 8 +No L2s +No guests are enabled for UEFI Boot + +libvirt: 6.0.0-0ubuntu4 +qemu 1:4.2-3ubuntu1 + +Issue triggers without nesting (ensured via modprobe kvm_intel nested=) + +@tstrike - can you trigger the same issue with all your guests? +You list Windows and Centos guests, does it triggers with Centos as well or only the Windows guests? +Also if you have a chance (just to be sure) does it trigger with an Ubuntu guest as well? This would help for people retrying not using a case that doesn't even trigger in your setup. + +@tstrike - you seem to hit this while starting your guest through libvirt. +Could you please attach your guest XML so that we can try to recreate this case? + $ virsh dumpxml <guestname> +That will help when trying to recreate your case. + +@tstrike +It would also be helpful to get your qemu commandline as well as any further messages qemu might have reported. +You'll find that in the per guest log file at: + $ cat /var/log/libvirt/qemu/<guestname>.log + +If you could report all that here that should be useful for everyone tracking this bug. + +@tstrike: finally for the sake of apparmor denials or any other odd error that might be mentioned in there attaching the output of `dmesg` on your host might be useful as well. + +Christian, + +Thanks for getting my report in the proper syntax. I would be extremely happy to follow through on the tasks you laid out to me. Give me about 3 hours and I will update the report with the items requested. + + + + + + + + + + + + + +Thank you @tstrike: + +In your logs I see a bunch of qemu warnings right at the beginning: +2020-02-12T15:09:37.773025Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-02-12T15:09:37.773107Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-02-12T15:09:37.774800Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-02-12T15:09:37.774821Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-02-12T15:09:38.024821Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control + +And then a crash like: +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + +Reproduced via attempt to install KVM Guest F31 Server on Ubuntu 20.04 (bare metal) + +I tried with a guest XML matching yours (other than disk setup). +I didn't get those errors you reported even when using your config. + + +Notable differences to my default - your guest has: +- a rather old chip type (Penryn is a 2007 chip) +- a rather old machine type (uses xenial which matches ~pc-i440fx-2.5) +This probably based on when the system was created. +But since you also have the same issues on the windows guest which has the modern: + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <cpu mode='host-model' check='partial'/> +So this isn't a route we need to go down... + + +Note: I tried this on kernel 5.4.0-14-generic with some common not too old & not too new chips +- Intel(R) Xeon(R) CPU E5-2620 +- AMD Opteron(tm) Processor 4226 + +Then I remembered that you followed to disable nesting and after all vmx-* you see in the warnings could be related. + +I ran this and restarted my guests: +# sudo rmmod kvm_intel +# sudo modprobe kvm_intel nested=0 +or +# sudo rmmod kvm_amd +# sudo modprobe kvm_amd nested=0 + +Even then I didn't get the same warnings or crashes you got. + +FYI: maybe related (similar symptom - which could be anything as we know, but still worth a link): https://bugzilla.redhat.com/show_bug.cgi?id=1718584 + +Thanks Boris for chiming in! +Maybe it is something in the guest (or the way virt-manager sets things up) after all - will install an F31 via virt-manager as well ... + +I've got the same issue starting guest via virt-install even with serial console. + +I fetched +https://download.fedoraproject.org/pub/fedora/linux/releases/31/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-31-1.9.iso + +And installed it on Ubuntu 20.04 via virt-manager (keeping all things on its default). + +- New +- Local Media +- select ISO (Autodetects F31) +- Forward, Forward, Forward, Finish + +Now warnings: +sudo cat /var/log/libvirt/qemu/fedora31.log | grep warning +<empty> + +And it just works, the installer is on the graphical UI and waiting for me. + +@Boris - in your log I've seen that you also got the Penryn cpu which I find odd. +"-cpu Penryn,vme=on,vmx=on,x2apic=on,tsc-deadline=on,xsave=on,hypervisor=on,arat=on,tsc-adjust=on,arch-capabilities=on,skip-l1dfl-vmentry=on \" +Assuming you also only used default I wonder how it got to that, maybe the reason for that is the same reason that eventually triggers the error. +But virt-manager/libvirt would usually just do a best-fit (for me Haswell-noTSX-IBRS). + + +@Boris and @tstrike Could you both please report: +$ virsh capabilities +$ virsh domcapabilities +$ sudo qemu-system-x86_64 --enable-kvm --nographic --nodefaults -S -qmp-pretty stdio +{"execute":"qmp_capabilities"} +{"execute":"query-cpu-definitions"} +Note: the command seems to hang as you are on QMP, then just enter the two commands below one by one. This will add "qemu's explanation why a given cpu is usable or not" + + + + + +This particular command seems to hang on: + +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] + +I tried to execute (thinking I was in a shell): + +{"execute":"qmp_capabilities"} +{"execute":"query-cpu-definitions"} + + +I might have misinterpreted what you wanted me to do. + +Thanks a lot . I will do it at my earliest convenience this night. Haswell i4770 is installed on small server 32 GB. Department's policy doesn't allow me to test Ubuntu whichever release on bare metal. I could test only on outdated CPU's box and it seems to be a core reason. + +Done on Penryn's box + +Thanks Boris! + +@tstrike - is your system also "really an old penryn" or is it something newer? +Maybe share /proc/cpuinfo? + +tstrike39@islandhealthcenter-media:~$ sudo cat /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2416.548 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 1 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2010.620 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 2 +cpu cores : 4 +apicid : 2 +initial apicid : 2 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 2 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 2419.534 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 1 +cpu cores : 4 +apicid : 1 +initial apicid : 1 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + +processor : 3 +vendor_id : GenuineIntel +cpu family : 6 +model : 23 +model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz +stepping : 10 +microcode : 0xa0b +cpu MHz : 1988.790 +cache size : 3072 KB +physical id : 0 +siblings : 4 +core id : 3 +cpu cores : 4 +apicid : 3 +initial apicid : 3 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm +bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit +bogomips : 5303.23 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +power management: + + + +It detects host as Penryn as well for @tstrike. +Which is fine if it is a chip of around that era. +He reported to have an "Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz" +And for that chip the detection and chip used might be correct. + +So to summarize all repro fails, but on Penryn ERA chips 2/2 cases trigger the bug. + +I wonder if one that wants to reproduce needs a system with such a chip as well then to test and trigger this. + +There should be plenty of people on CC as this is mirrored to qemu-devel due to the upstream qemu task. Is there an microarchitectural x86 specialist that knows if the chips of that generation have some special issues in regard to VMX that might explain what we see here? + +It would be great if everyone could ask around for more systems with chips of that era. +Maybe we can further bisect which work and which will fail. + +I tried launching a focal vm on a focal host, and the vm launched but is in a paused state. + +Attached is its log. + +This is on an old E660 intel core system. + +/proc/cpuinfo + + +I also have these two apparmor denied messages in dmesg: +[ 1380.529549] audit: type=1400 audit(1584023445.093:139): apparmor="DENIED" operation="open" profile="libvirt-aa346a1d-8caa-4c55-bef9-c3acbe17bdac" name="/" pid=19712 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 +[ 1380.529856] audit: type=1400 audit(1584023445.093:140): apparmor="DENIED" operation="open" profile="libvirt-aa346a1d-8caa-4c55-bef9-c3acbe17bdac" name="/sys/bus/nd/devices/" pid=19712 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 + + +And one last bit of info, this system booted with mitigations=off. + +virsh capabilities + +virsh domcapabilities + +AppArmor is completely disabled on my server. + +After changing cpu to <cpu mode='host-model'/>: + + +I got this log (still in a paused state): +char device redirected to /dev/pts/3 (label charserial0) +2020-03-12T15:06:22.560159Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-vnmi-pending [bit 22] +2020-03-12T15:06:22.560708Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-secondary-ctls [bit 31] +2020-03-12T15:06:22.560971Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-apicv-xapic [bit 0] +2020-03-12T15:06:22.561208Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48DH).vmx-vnmi [bit 5] +2020-03-12T15:06:22.561392Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + + +By using host-model Andreas also was able to get the same signature: + +2020-03-12T15:06:22.560159Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-vnmi-pending [bit 22] +2020-03-12T15:06:22.560708Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-secondary-ctls [bit 31] +2020-03-12T15:06:22.560971Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-apicv-xapic [bit 0] +2020-03-12T15:06:22.561208Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48DH).vmx-vnmi [bit 5] +2020-03-12T15:06:22.561392Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + +So the warnings seem to depend a bit on which chip type we try to be to the guest. +We can ignore them for now. + +What stays is the emulation error on this kind of chip. +I'll try to write up some tests to check different qemu and kernel levels to further corner what we are looking at. + +Penryn's architecture confirmed + + +Seems to work fine on i4790 (Haswell) box. + +Yeah @Boris - it really seems to be an issue bound to the Merom/Penryn processor generation. + +I asked Andreas to check through some kernels and qemu versions so that we maybe eventually can consider bisecting something. But that will take a bit of time. + +Of course everyone able to spend some time can consider checking a few kernels of [1] as well (probably the easiest test to begin with). + +Still if there is an x86-microarchitecture expert out there that say "ah penryn, I know we added/dropped ... " please speak up :-) + +[1]: https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D + +The vmx things make me wonder about a fix Paolo did a while ago for enabling inidivudal vmx features rather than vmx as a whole; but I can't remember if that was a kernel or qemu fix. + +One thing I notice, that may be a red-herring, all of the machine code in the errors are 'f3 0f 1e fb' which is the new 'endbr32' security instruction - but that's really a rep nop, that I thought old instructions can handle anyway?? + +Andreas was so kind to try kenels 4.4, 4.15 and 5.6 all fail (with qemu 4.2) +He then tried Eoan (qemu 4.0) and Focal (qemu 4.2). +4.0 worked and 4.2 failed. + +We will set up a bisect run on Monday and hopefully find the offending change. + +@David - I agree that the messages might be a red-herring, but to be sure was that fix between 4.0 and 4.2? + +I think the one I was thinking of is 0723cc8a5558c94388db75ae1f4991314914edd3 which is in a 4.2.0 rc +and there was 2605188240f939fa9ae9353f53a0985620b34769 - but that's a different crash to what you have. + +So hmm. + + +Thanks David! + +While bisecting on upstream git with just "-cpu Penryn" we have seen that it always works there. +So it might be an interaction with some Ubuntu build/packaging/configure detail together with these old chips. + +While we still can't be sure if the VMX warnings are a red-herring chances are that only "-cpu Penryn,vmx=on" will trigger the issue - Andreas will test and bisect with that once he is back online - we will see if that is any different. + +I'll also build a Ubuntu'esque 4.2 with the Penryn changes of [1] reverted just to complete the interim picture of our testing. That is available for testing at [2]. Further I added a Ubuntu build with rather crude reverts of almost all VMX related 4.2 changes. + +[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=0723cc8a5558c94388db75ae1f4991314914edd3 +[2]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1866870-qemu-penryn-crash +[3]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1866870-qemu-penryn-crash-fullreverts + +No luck when testing [2]. Reports are attached + +Log file for f31wks guest + +Verification new packages to be installed + + + +The package from the PPA failed the same way for me: + +ubuntu@f1:~$ qemu-system-x86_64 --enable-kvm -cpu Penryn,vmx=on -m 512 --nodefaults --nographic +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.sse4.1 [bit 19] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 +^Cqemu-system-x86_64: terminating on signal 2 + +ubuntu@f1:~$ qemu-system-x86_64 --help 2>&1|head -n 1 +QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu3~ppa1) +ubuntu@f1:~$ + + +Also crashed with the packages from the other ppa: + +ubuntu@f1:~$ qemu-system-x86_64 --help 2>&1|head -n 1 +QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu3~exp1) + +ubuntu@f1:~$ qemu-system-x86_64 --enable-kvm -cpu Penryn,vmx=on -m 512 --nodefaults --nographic +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.sse4.1 [bit 19] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 + + +ubuntu@f1:~$ apt-cache policy qemu-kvm +qemu-kvm: + Installed: 1:4.2-3ubuntu3~exp1 + Candidate: 1:4.2-3ubuntu3~exp1 + Version table: + *** 1:4.2-3ubuntu3~exp1 500 + 500 http://ppa.launchpad.net/paelzer/bug-1866870-qemu-penryn-crash-fullreverts/ubuntu focal/main amd64 Packages + 100 /var/lib/dpkg/status + 1:4.2-3ubuntu2 500 + 500 http://br.archive.ubuntu.com/ubuntu focal/main amd64 Packages + + +Ok, upstream tag v4.2.0 and these configure options reproduced the crash: + +export LDFLAGS="-Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed" +export CFLAGS="-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g" + +Full configure output: https://paste.ubuntu.com/p/Tzq6pDWD9R/ + +$ ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -cpu Penryn,vmx=on -m 512 --nodefaults --nographic +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.sse4.1 [bit 19] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-vnmi-pending [bit 22] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48EH).vmx-secondary-ctls [bit 31] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-apicv-xapic [bit 0] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48BH).vmx-wbinvd-exit [bit 6] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48DH).vmx-vnmi [bit 5] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] +KVM internal error. Suberror: 1 +emulation failure +EAX=00000000 EBX=00000000 ECX=000086d4 EDX=00000000 +ESI=00000000 EDI=00000000 EBP=000086d4 ESP=00006d7c +EIP=00007acf EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 ffffffff 00809300 +CS =f000 000f0000 ffffffff 00809b00 +SS =0000 00000000 ffffffff 00809300 +DS =0000 00000000 ffffffff 00809300 +FS =0000 00000000 ffffffff 00809300 +GS =0000 00000000 ffffffff 00809300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 000f6200 00000037 +IDT= 00000000 000003ff +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=b8 90 d9 00 00 66 e8 6b f7 ff ff 66 b8 0a 00 00 00 e9 61 f2 <f3> 0f 1e fb 66 57 66 56 66 53 66 53 66 89 c7 67 66 89 14 24 66 89 ce 66 e8 15 f8 ff ff 88 +^Cqemu-system-x86_64: terminating on signal 2 + + +I've tested smoe more cmbinations and found that I van have v4.2 work on focal. +Eventually I have realized that when I install start the qemu from Ubuntu not only that but also the formerly working build of v4.2.0 from git start to fail (without rebuilding). + +A bit of package bisect later I found seabios to be related. +Focal is at 1.13.0-1 +Eoan is at 1.12.0-1 + +After I knew that I verified and found it really only triggers on seabios 1.13.0. + +With 1.13 I was also able to break the qemu v4.0.0 git build on eoan. +As well as the packaged qemu in Eoan. + +So it seems we are actually looking for a problem of seabios (instead of qemu) with the Penryn chip. + +I'll look at their changelog and bisect that tomorrow as time permits + +I wanted to make sure why different qemu configs make it trigger or not, and after finding seabios to be related the candidates were obvious. + +Default config gets us: +BIOS directory /usr/local/share/qemu + +The long conf had: +--firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu + +Adding that to the short config which had most things disabled made it break as well. +Since it has much less moving parts having most other features disabled I'll continue to use that. + + +With that confirmed I checked if I can just point to a bios to break it, and indeed adding + -bios /root/seabios_1.12.0-1/usr/share/seabios/bios.bin + -bios /root/seabios_1.13.0-1/usr/share/seabios/bios.bin +respectively is a make or break change. + + + +As a next step I reproduced the error with seabios rel-1.13.0 from https://review.coreboot.org/seabios.git. +It crashes as well. + +But to make this puzzle even more interesting rel-1.12.0 from the same git crashes as well. +I wonder where this trip might end, from qemu to seabios to ... compiler? + +Turns out 1.12 is a fairly old build and the working version in Ubuntu was from in Disco, therefore about a year ago. +=> https://launchpad.net/ubuntu/+source/seabios/1.12.0-1/+build/16284605 + +Therefore I built it in Eoan and even Disco. +As an overview: +Disco: gcc 4:8.3.0-1ubuntu3 binutils 2.32-7ubuntu4 +Eoan: gcc 4:9.2.1-3.1ubuntu1 binutils 2.33-2ubuntu1.2 +Focal: gcc 4:9.2.1-3.1ubuntu1 binutils 2.34-4ubuntu1 + +I ended up with these binaries to test: +./git-built-in-eoan/rel-1.12/bios.bin Breaks +./git-built-in-eoan/rel-1.13/bios.bin Breaks +./git-built-in-disco/rel-1.13/bios.bin Works +./git-built-in-disco/rel-1.12/bios.bin Works +./git-built-in-focal/head/bios.bin Breaks +./git-built-in-focal/rel-1.12/bios.bin Breaks +./git-built-in-focal/rel-1.13/bios.bin Breaks +./packaging/disco-seabios_1.12.0-1/bios.bin Works +./packaging/focal-seabios_1.13.0-1/bios.bin Breaks + +To summarize: +- qemu breaks on chips of the Penryn generation +- it only breaks if the seabios bios is executed +- does not really depend on seabios or qemu version +- but it depends on seabios build environment + +That's getting more fun :-) +You could look at whether seabios's config works out hte same in the two environments, or whether something makes use of new build flags - try looking at the gcc lines that are invoked in the good/bad cases and see if they're passing any options that the other doesn't. + + +Starting from the Disco build env that I had I changed the packages + +Step #1 binutils: +Unpacking binutils-x86-64-linux-gnu (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... +Unpacking libbinutils:amd64 (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... +Unpacking binutils (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... +Unpacking binutils-common:amd64 (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ... + +=> Still working + +Step #2 gcc: +Unpacking libubsan1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libtsan0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking gcc-9-base:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libstdc++6:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libquadmath0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking liblsan0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libitm1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libgomp1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libcc1-0:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libatomic1:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libasan5:amd64 (9.2.1-9ubuntu2) over (9.1.0-2ubuntu2~19.04) ... +Unpacking libgcc1:amd64 (1:9.2.1-9ubuntu2) over (1:9.1.0-2ubuntu2~19.04) ... +Unpacking libisl21:amd64 (0.21-2) ... +Unpacking cpp-9 (9.2.1-9ubuntu2) ... +Unpacking libgcc-9-dev:amd64 (9.2.1-9ubuntu2) ... +Unpacking gcc-9 (9.2.1-9ubuntu2) ... +Unpacking libstdc++-9-dev:amd64 (9.2.1-9ubuntu2) ... +Unpacking g++-9 (9.2.1-9ubuntu2) ... +Unpacking g++ (4:9.2.1-3.1ubuntu1) over (4:8.3.0-1ubuntu3) ... +Unpacking gcc (4:9.2.1-3.1ubuntu1) over (4:8.3.0-1ubuntu3) ... +Unpacking cpp (4:9.2.1-3.1ubuntu1) over (4:8.3.0-1ubuntu3) ... + +=> now it is breaking + +One thing that we have seen to cause breakage in other cases was the new default to enable: + -fcf-protection + +The code already carries quite a bunch of similar "no" rules: +COMMONCFLAGS += $(call cc-option,$(CC),-nopie,) +COMMONCFLAGS += $(call cc-option,$(CC),-fno-pie,) +COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector,) +COMMONCFLAGS += $(call cc-option,$(CC),-fno-stack-protector-all,) +COMMONCFLAGS += $(call cc-option,$(CC),-fstack-check=no,) +COMMONCFLAGS += $(call cc-option,$(CC),-Wno-address-of-packed-member,) + +Lets add to that: +COMMONCFLAGS += $(call cc-option,$(CC),-fcf-protection=none,) + +=> That made it work \o/ ! + +I *think* it's the cf-protection that's adding the endbr32 instructions that I spotted as being the failing instruction each time; but I don't understand why they would be CPU type specific. + +Sent to seabios for their consideration: +=> https://<email address hidden>/thread/IXAWMA2HWW75LSR3NBBYQKWT3TI5WVVP/ + +I deleted the experimental PPAs that we had and created a new one with a new seabios: +=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3982 + +An MP is open to fix this in Focal: +=> https://code.launchpad.net/~paelzer/ubuntu/+source/seabios/+git/seabios/+merge/380881 + +This bug was fixed in the package seabios - 1.13.0-1ubuntu1 + +--------------- +seabios (1.13.0-1ubuntu1) focal; urgency=medium + + * d/p/lp-1866870-build-use-fcf-protection-none-when-available.patch + fix breakage on older chips due to fcf-protection (LP: #1866870) + + -- Christian Ehrhardt <email address hidden> Thu, 19 Mar 2020 13:10:10 +0100 + +Can I just apt update && apt upgrade to get this fix or do I need to patch? + +apt-get will be enough once it's published, and looks like it just was published. + +Works for me. F31 KVM guest is installing on Q9550 box. + +I can confirm that this bug has been fixed (zapped). Thank you all for your hard work and determination. A job well done indeed! As a former programmer I love you all's zeal for attacking this bug. + +As a side note, knowing what you all go through, I always look things up, walk through at least level 1 stuff and provide logfiles. I hope what little I did, help you all resolve this. + +Again my thanks, and I believe is this is where we say, "Please close the bug marked SOLVED". + +Thank you Boris and Tstrike for the report and your help. +It was a great bug to identify and fix before the release of 20.04, I appreciate you using (and hereby testing) it ahead of time! + +Hello! +Unfortunately the bug has apparently reappeared. I have a Windows 10 running in a VM, which after my today's "apt upgrade" goes into pause mode after a few seconds of running time. + +Tail output of my /var/log/libvirt/qemu/win10.log +char device redirected to /dev/pts/1 (label charserial0) +2020-05-05T08:53:23.733051Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-05T08:53:23.733122Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-05T08:53:23.736093Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12] +2020-05-05T08:53:23.736110Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13] +2020-05-05T08:54:04.912098Z qemu-system-x86_64: terminating on signal 15 from pid 1593 (/usr/sbin/libvirtd) +2020-05-05 08:54:05.112+0000: shutting down, reason=destroyed + + +Apt upgraded packages (from /var/log/apt/history.log): +Start-Date: 2020-05-05 09:32:02 +Commandline: apt upgrade +Requested-By: andreas (1000) +Install: linux-image-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-modules-extra-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-headers-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-modules-5.4.0-29-generic:amd64 (5.4.0-29.33, automatic), linux-headers-5.4.0-29:amd64 (5.4.0-29.33, automatic) +Upgrade: linux-headers-generic:amd64 (5.4.0.28.33, 5.4.0.29.34), linux-libc-dev:amd64 (5.4.0-28.32, 5.4.0-29.33), linux-image-generic:amd64 (5.4.0.28.33, 5.4.0.29.34), linux-generic:amd64 (5.4.0.28.33, 5.4.0.29.34) +End-Date: 2020-05-05 09:33:11 + + +Kind regards, + Andreas + +Hi Andreas, +so the only upgrade you did to trigger this for you was to bump the kernel from 5.4.0-28.33 to 5.4.0-29.34 - nothing else? I have not (yet?) heard other similar reports, but it might be just too early? +At least on my system for now things still work with the new kernel like before. + +I'd recommend filing a new bug, refer to this one as maybe being related and adding the following right away: +- kernel version (you have this here I know) +- qemu/libvirt/seabios/ovmf version (if you don't mind just attach `dpkg -l`) +- guest XML (if using libvirt) otherwise the qemu command-line +- add a cross check and report what happens with other guests configs (e.g. non windows, using + another bios as the former issue was tied to seabios, use different guest CPU types) +- the full /var/log/apt/history.log +- a date when you last started the VM successfully (not just still-had-it-running, but started it) + and the date when it started to fail (probably yesterday then I guess) + +Hi Christian. + +Just filed bug: #1877052 + +Same issue here. I've upgraded my IBM Power ppc64le system to ubuntu 20.04. Now I'm trying to create KVM VMs and whatever I'm doing, the VM is created but before any installation step starts, it's falling into "paused" mode. When trying to resume it, I get: +" +Error unpausing domain: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required +" + +Any workaround ? Do I need to reinstall Ubuntu 18.04 ? + +Fabrice: That's probably a different error given that this lp seems to be with x86 vmx flags. +Check your /var/log/libvirt/qemu/ on the host to see if there's a particular error shown in the destination qemu after migration. + +David: Indeed ! How stupid I am. I missed the root cause inside QUEMU log file. This was clear enough... +error: kvm run failed Device or resource busy +This is probably because your SMT is enabled. + +So I switch SMT (Power Simultaneous Multi-Threading) off and now it's OK; VMs are running and installing. + +It had been years since I last touched KVM on Power and I lost my reflexes. +So please forget my precedent comment telling I had the same issue on Power platform. It was similar symptoms but not the same problem. + diff --git a/results/classifier/118/review/1868527 b/results/classifier/118/review/1868527 new file mode 100644 index 000000000..519ccbc24 --- /dev/null +++ b/results/classifier/118/review/1868527 @@ -0,0 +1,91 @@ +architecture: 0.850 +debug: 0.649 +semantic: 0.608 +graphic: 0.596 +virtual: 0.550 +performance: 0.547 +device: 0.527 +arm: 0.404 +mistranslation: 0.403 +risc-v: 0.378 +PID: 0.310 +ppc: 0.305 +assembly: 0.296 +hypervisor: 0.288 +permissions: 0.268 +vnc: 0.262 +x86: 0.245 +register: 0.245 +user-level: 0.213 +socket: 0.207 +TCG: 0.196 +i386: 0.194 +peripherals: 0.185 +network: 0.174 +boot: 0.152 +kernel: 0.152 +VMM: 0.138 +KVM: 0.086 +files: 0.071 +-------------------- +arm: 0.952 +debug: 0.416 +TCG: 0.365 +virtual: 0.230 +architecture: 0.091 +user-level: 0.068 +files: 0.044 +kernel: 0.035 +register: 0.021 +semantic: 0.011 +performance: 0.011 +device: 0.010 +hypervisor: 0.009 +VMM: 0.009 +vnc: 0.008 +PID: 0.008 +socket: 0.004 +assembly: 0.003 +risc-v: 0.003 +network: 0.003 +peripherals: 0.002 +boot: 0.001 +permissions: 0.001 +x86: 0.001 +graphic: 0.001 +i386: 0.001 +KVM: 0.000 +mistranslation: 0.000 +ppc: 0.000 + +alignment may overlap the TLB flags + +Hi, +In QEMU-4.2.0, or git-9b26a610936deaf436af9b7e39e4b7f0a35e4409, alignment may overlap the TLB flags. +For example, the alignment: MO_ALIGN_32, + MO_ALIGN_32 = 5 << MO_ASHIFT, +and the TLB flag: TLB_DISCARD_WRITE +#define TLB_DISCARD_WRITE (1 << (TARGET_PAGE_BITS_MIN - 6)) + +then, in the function "get_alignment_bits", the assert may fail: + +#if defined(CONFIG_SOFTMMU) + /* The requested alignment cannot overlap the TLB flags. */ + tcg_debug_assert((TLB_FLAGS_MASK & ((1 << a) - 1)) == 0); +#endif + +However, the alignment of MO_ALIGN_32 is not used for now, so the assert cannot be triggered in current version. Anyway it seems like a potential conflict. + +That is of course completely dependent on the target page size. So, yes, a target with a very small page size cannot use large alignments. The assert makes sure. + +Is this comment simply by inspection, or did you have an actual bug to report? + +This is an inspection yet. +For ARM SMMU simulation, TARGET_PAGE_BITS_MIN is 10. All low bits of the TLB virtual address are used up by TLB flags and alignment flags. It's a little crowded. +/* + * ARMv7 and later CPUs have 4K pages minimum, but ARMv5 and v6 + * have to support 1K tiny pages. + */ +# define TARGET_PAGE_BITS_VARY +# define TARGET_PAGE_BITS_MIN 10 + diff --git a/results/classifier/118/review/1868617 b/results/classifier/118/review/1868617 new file mode 100644 index 000000000..ff7a5aae4 --- /dev/null +++ b/results/classifier/118/review/1868617 @@ -0,0 +1,98 @@ +mistranslation: 0.884 +files: 0.835 +device: 0.817 +user-level: 0.809 +semantic: 0.793 +performance: 0.763 +graphic: 0.753 +register: 0.737 +ppc: 0.728 +kernel: 0.719 +socket: 0.717 +PID: 0.676 +network: 0.671 +debug: 0.647 +peripherals: 0.646 +architecture: 0.634 +risc-v: 0.633 +VMM: 0.630 +permissions: 0.623 +boot: 0.582 +vnc: 0.577 +x86: 0.575 +i386: 0.570 +hypervisor: 0.562 +assembly: 0.561 +arm: 0.551 +TCG: 0.550 +KVM: 0.505 +virtual: 0.473 +-------------------- +virtual: 0.120 +TCG: 0.104 +x86: 0.077 +files: 0.073 +hypervisor: 0.031 +debug: 0.025 +user-level: 0.018 +semantic: 0.015 +i386: 0.008 +network: 0.007 +PID: 0.007 +device: 0.006 +register: 0.005 +socket: 0.005 +arm: 0.004 +ppc: 0.004 +risc-v: 0.004 +architecture: 0.003 +boot: 0.003 +VMM: 0.002 +performance: 0.002 +vnc: 0.002 +kernel: 0.002 +peripherals: 0.001 +permissions: 0.001 +assembly: 0.001 +graphic: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +multiseat: route different spice tablet events to distinct vdagents + +docs/multiseat.txt says: + +> Note on spice: Spice handles multihead just fine. But it can't do +> multiseat. For tablet events the event source is sent to the spice +> agent. But qemu can't figure it, so it can't do input routing. +> Fixing this needs a new or extended input interface between +> libspice-server and qemu. For keyboard events it is even worse: The +> event source isn't included in the spice protocol, so the wire +> protocol must be extended to support this. + +I'm not sure exactly what "can't figure it" means, but it looks to me like qemu can't route incoming tablet events from a spice client to distinct vdagent channels. + +I think this part of the process can be fixed within qemu. I've reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to address the issues with the keyboard interface at the protocol level. + +Here are two different ways i can think of to potentially solve this (i'm not qemu hacker, feel free to correct me or propose a better solution): + + - the spicevmc chardev's "name" parameter could be used to identify the agent numerically (e.g. "vdagent:1" instead of "vdagent") + + - the -device virtserialport could identify whether it is connected via a multiseat PCI bridge (pci-bridge-seat) and group it with the other monitor from there. + +Is one of these approaches preferable? + +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 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/review/1870098 b/results/classifier/118/review/1870098 new file mode 100644 index 000000000..a7469119d --- /dev/null +++ b/results/classifier/118/review/1870098 @@ -0,0 +1,101 @@ +semantic: 0.892 +mistranslation: 0.854 +performance: 0.765 +device: 0.743 +ppc: 0.728 +graphic: 0.719 +virtual: 0.660 +user-level: 0.656 +vnc: 0.629 +socket: 0.626 +architecture: 0.596 +network: 0.596 +files: 0.581 +VMM: 0.579 +hypervisor: 0.578 +kernel: 0.566 +arm: 0.565 +risc-v: 0.558 +i386: 0.554 +permissions: 0.550 +boot: 0.541 +PID: 0.531 +TCG: 0.526 +register: 0.514 +debug: 0.492 +KVM: 0.466 +x86: 0.463 +assembly: 0.291 +peripherals: 0.267 +-------------------- +hypervisor: 0.069 +TCG: 0.062 +debug: 0.034 +files: 0.030 +virtual: 0.020 +device: 0.014 +PID: 0.012 +kernel: 0.009 +socket: 0.008 +risc-v: 0.006 +ppc: 0.005 +VMM: 0.005 +semantic: 0.004 +boot: 0.004 +network: 0.004 +i386: 0.004 +arm: 0.003 +user-level: 0.003 +KVM: 0.003 +register: 0.003 +x86: 0.003 +vnc: 0.002 +architecture: 0.002 +assembly: 0.002 +performance: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +graphic: 0.000 + +[block/vpc] dynamic disk header: off-by-one error for "num_bat_entries" + +In current qemu versions (observed in 5.0.0-rc1 as well as 2833ad487cfff7dc33703e4731b75facde1c561e), disk headers for dynamic VPCs are written with an incorrect "block allocation table entries" value. + +https://www.microsoft.com/en-us/download/details.aspx?id=23850 (the corresponding spec) states that: + +"Max Table Entries +This field holds the maximum entries present in the BAT. This should be equal to the number of blocks in the disk (that is, the disk size divided by the block size)." + +Inside the qemu code, the value is "disk size divided by the block size *plus one*". + +Calculating "num_bat_entries" as "total_sectors/(block_size / 512)" *should* fix the issue. + +Is there any actual bug resulting from this that you're observing? As I read the spec, having a longer BAT is merely unconventional, not strictly wrong. So if another application fails to deal with such images, it's probably a bug in that application. + +Of course, I can't see a reason for making the BAT longer than necessary either. We do, however, need to round up if the disk size is not a multiple of the image block size. So I think what it really should be is: + +num_bat_entries = DIV_ROUND_UP(total_sectors, block_size / 512) + +If you agree, please let me know if I should submit a patch or if you would like to do that yourself. (See https://wiki.qemu.org/Contribute/SubmitAPatch) + +Ah, sorry, I failed to mention this: Due to this bug, qemu currently cannot create VHDs that are suitable for upload to Azure (because Azure expects disks that are aligned exactly to 1MB). + +If it would not be too much trouble for you to submit the patch, I would appreciate that a lot. I've never submitted a patch to qemu and the contribution doc reads somewhat complex, so I'm a bit concerned about dragging a very small patch out longer than strictly necessary. + +Thanks a lot! + +As I don't have your email address, I could not CC you on the patch email. Can you please verify if the following patch on the mailing list fixes your problem? + +https://lists.gnu.org/archive/html/qemu-block/2020-04/msg00086.html + +Thanks a lot for looking into it! + +Yes, we were able to verify that this patch does fix the problem. + +Many thanks! + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3f6de653b946 + + diff --git a/results/classifier/118/review/1870331 b/results/classifier/118/review/1870331 new file mode 100644 index 000000000..c7b9e1084 --- /dev/null +++ b/results/classifier/118/review/1870331 @@ -0,0 +1,138 @@ +architecture: 0.846 +socket: 0.830 +files: 0.770 +permissions: 0.751 +arm: 0.749 +network: 0.747 +register: 0.741 +peripherals: 0.733 +PID: 0.731 +device: 0.722 +user-level: 0.713 +assembly: 0.700 +kernel: 0.690 +risc-v: 0.672 +TCG: 0.663 +performance: 0.657 +graphic: 0.626 +debug: 0.612 +ppc: 0.609 +hypervisor: 0.601 +x86: 0.565 +semantic: 0.562 +boot: 0.560 +vnc: 0.555 +VMM: 0.547 +virtual: 0.509 +KVM: 0.503 +mistranslation: 0.498 +i386: 0.454 +-------------------- +ppc: 0.960 +debug: 0.879 +virtual: 0.129 +x86: 0.050 +semantic: 0.047 +files: 0.042 +TCG: 0.041 +network: 0.034 +boot: 0.030 +device: 0.027 +register: 0.016 +performance: 0.015 +PID: 0.013 +hypervisor: 0.010 +user-level: 0.009 +assembly: 0.009 +peripherals: 0.007 +socket: 0.006 +architecture: 0.006 +risc-v: 0.006 +VMM: 0.003 +vnc: 0.003 +graphic: 0.002 +kernel: 0.002 +permissions: 0.002 +i386: 0.001 +arm: 0.001 +mistranslation: 0.001 +KVM: 0.001 + +default nic device created even though supplied by configfile + +QEMU emulator version 4.1.94 + +Documentation states that qemu will create a default nic as long as not explicitly forbidden (-nic none) or defined ( e.g. -nic <options>). + +Observation: +Even though qemu-system-ppc is started with "-readconfig" (which defines a nic), another nic gets created. When additionally suppling "-nic none", only the nic of the config file is created. +As matter of fact, if all items that are defined in config file are supplied as command line arguments, no further nic is created. + +Expectation: +When a nic is defined in config file, the default guest-nic should not get created. +That would match behavior when all items, defined in config file are supplied as command line arguments. + + +Attached config file. + +(qemu) info pci + Bus 0, device 0, function 0: + Host bridge: PCI device 1057:0002 + PCI subsystem 1af4:1100 + id "" + Bus 0, device 1, function 0: + VGA controller: PCI device 1234:1111 + PCI subsystem 1af4:1100 + BAR0: 32 bit prefetchable memory at 0x80000000 [0x80ffffff]. + BAR2: 32 bit memory at 0x81000000 [0x81000fff]. + BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. + id "" + Bus 0, device 2, function 0: + Ethernet controller: PCI device 10ec:8029 + PCI subsystem 1af4:1100 + IRQ 23. + BAR0: I/O at 0x1000 [0x10ff]. + BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe]. + id "" + Bus 0, device 3, function 0: + Ethernet controller: PCI device 10ec:8029 + PCI subsystem 1af4:1100 + IRQ 24. + BAR0: I/O at 0x1100 [0x11ff]. + BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe]. + id "" + + + +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/review/1871270 b/results/classifier/118/review/1871270 new file mode 100644 index 000000000..74143faa8 --- /dev/null +++ b/results/classifier/118/review/1871270 @@ -0,0 +1,109 @@ +user-level: 0.825 +peripherals: 0.709 +register: 0.695 +graphic: 0.685 +device: 0.653 +permissions: 0.640 +semantic: 0.624 +virtual: 0.617 +PID: 0.607 +risc-v: 0.596 +network: 0.581 +architecture: 0.572 +debug: 0.566 +files: 0.564 +hypervisor: 0.559 +VMM: 0.552 +performance: 0.539 +socket: 0.527 +mistranslation: 0.522 +arm: 0.521 +ppc: 0.512 +TCG: 0.495 +kernel: 0.486 +boot: 0.474 +vnc: 0.452 +assembly: 0.415 +KVM: 0.409 +x86: 0.408 +i386: 0.332 +-------------------- +virtual: 0.974 +hypervisor: 0.837 +arm: 0.079 +x86: 0.061 +debug: 0.028 +peripherals: 0.025 +files: 0.018 +TCG: 0.010 +device: 0.010 +PID: 0.009 +register: 0.008 +user-level: 0.008 +kernel: 0.007 +semantic: 0.006 +VMM: 0.005 +socket: 0.005 +network: 0.004 +assembly: 0.003 +KVM: 0.003 +risc-v: 0.002 +boot: 0.002 +permissions: 0.002 +architecture: 0.002 +ppc: 0.002 +i386: 0.002 +vnc: 0.002 +graphic: 0.002 +performance: 0.002 +mistranslation: 0.000 + +[Feature Request] add usbredir device reset blacklist options support to allow macOS guest to iOS device usbredir + +Description of problem: +Currently, when a iOS device is redirected to a macOS VM, it falls into a reset-not-found loop. +Version-Release number of selected component (if applicable): +latest +How reproducible: +100% +Steps to Reproduce: + + +Connect an iOS device to Ubuntu 18.04.2 LTS (I believe it is the same for any distro.) + + +Connect virt-manager/virt-viewer to a macOS VM through SPICE (I am using OSX 10.15 Catalina) + + +Attempt to redirect the iOS device (iPad in my case) to the VM through usb redirection. + + +Actual results: +For any odd number of attempt, the guest macOS will send a reset to the iOS device which causes the host to reset the USB connection in the host side. In the UI, it will be displayed as a successful connection for a few seconds before it disconnects. After this, the iOS device will reconnect itself, but via a different device name /dev/bus/usb/x/y+1. +For any even number of attempt, when I select the iOS device in the virt-manager/virt-viewer UI, the connection will not success and instead a LIBUSB_ERROR_NOT_FOUND error will be provided. Then the UI will reload and get the new device name of the iOS device, falling into the behavior of the aforementioned odd number of attempt. +Expected results: +The macOS detects the iOS device and connects to it happily. +Additional info: +It seems that this bug has been first identified as in https://bugs.freedesktop.org/show_bug.cgi?id=100149, for a Samsung Android device, which the developers of SPICE applied a hotfix in https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirhost/usbredirhost.c#L147. However, there were no settings available for users to fix it. +A similar bug that also consists of a macOS guest/iOS device pair, but instead of being usbredir, is usb-host, has been identified and patched in https://github.com/qemu/qemu/commit/ba4c735b4fc74e309ce4b2551d258e442ef513a5, which is further modified into https://github.com/qemu/qemu/blame/146aa0f104bb3bf88e43c4082a0bfc4bbda4fbd8/hw/usb/host-libusb.c#L1486. Following such patch, I have attempted to apply such patch at host-side in https://github.com/michaellee8/qemu/blob/master/hw/usb/redirect.c (not correctly formatted currently, pls ignore it atm), however I discovered that this is not enough since it is also a SPICE issue, which resolves to virt-manager/virt-viewer. +This is probably a cross-project issue between qemu, spice (usbredir) and virt-manager/virt-viewer, which would some effort to coordinate a solution. However a working solution for this problem would probably benefits a lot of users whom relies on connecting a mobile device into a VM, for purposes like easier mobile development. Considering the report for the Samsung Android Device on a PC use case, such issue is probably cross-OS/cross-device. + +cross-references: +- https://bugzilla.redhat.com/show_bug.cgi?id=1821518 +- https://bugzilla.redhat.com/show_bug.cgi?id=1821517 +- https://gitlab.freedesktop.org/spice/usbredir/-/issues/10 + +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 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/review/1872 b/results/classifier/118/review/1872 new file mode 100644 index 000000000..ab9f59b08 --- /dev/null +++ b/results/classifier/118/review/1872 @@ -0,0 +1,61 @@ +architecture: 0.884 +device: 0.722 +performance: 0.712 +debug: 0.606 +mistranslation: 0.414 +semantic: 0.401 +graphic: 0.395 +arm: 0.349 +PID: 0.349 +files: 0.284 +permissions: 0.251 +boot: 0.223 +KVM: 0.192 +VMM: 0.168 +network: 0.164 +peripherals: 0.160 +vnc: 0.148 +TCG: 0.142 +ppc: 0.133 +virtual: 0.132 +register: 0.100 +kernel: 0.072 +hypervisor: 0.066 +x86: 0.061 +socket: 0.059 +risc-v: 0.051 +assembly: 0.017 +user-level: 0.014 +i386: 0.003 +-------------------- +user-level: 0.429 +files: 0.180 +debug: 0.128 +architecture: 0.035 +TCG: 0.023 +VMM: 0.021 +virtual: 0.015 +assembly: 0.012 +register: 0.010 +semantic: 0.008 +ppc: 0.007 +PID: 0.005 +performance: 0.002 +risc-v: 0.002 +network: 0.002 +graphic: 0.001 +device: 0.001 +KVM: 0.001 +hypervisor: 0.001 +permissions: 0.001 +peripherals: 0.000 +arm: 0.000 +boot: 0.000 +socket: 0.000 +mistranslation: 0.000 +kernel: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 + +When I compile package , I will report 'Could not open'/lib64/ld musl arch64. so. 1 ': No such file or directory diff --git a/results/classifier/118/review/1872113 b/results/classifier/118/review/1872113 new file mode 100644 index 000000000..bbd2bb4f7 --- /dev/null +++ b/results/classifier/118/review/1872113 @@ -0,0 +1,229 @@ +ppc: 0.897 +permissions: 0.866 +register: 0.863 +device: 0.857 +hypervisor: 0.851 +arm: 0.839 +TCG: 0.837 +peripherals: 0.830 +assembly: 0.830 +risc-v: 0.825 +performance: 0.815 +vnc: 0.806 +KVM: 0.805 +network: 0.803 +semantic: 0.794 +debug: 0.792 +PID: 0.790 +virtual: 0.787 +VMM: 0.783 +architecture: 0.783 +files: 0.781 +graphic: 0.767 +socket: 0.741 +user-level: 0.735 +x86: 0.682 +mistranslation: 0.674 +kernel: 0.585 +boot: 0.536 +i386: 0.371 +-------------------- +debug: 0.205 +files: 0.119 +TCG: 0.068 +PID: 0.038 +user-level: 0.034 +semantic: 0.033 +hypervisor: 0.032 +virtual: 0.018 +register: 0.017 +risc-v: 0.011 +kernel: 0.010 +VMM: 0.009 +ppc: 0.004 +boot: 0.004 +device: 0.004 +vnc: 0.003 +performance: 0.002 +assembly: 0.002 +i386: 0.002 +KVM: 0.002 +graphic: 0.002 +architecture: 0.002 +x86: 0.002 +socket: 0.002 +network: 0.002 +permissions: 0.001 +peripherals: 0.001 +arm: 0.001 +mistranslation: 0.001 + +qemu docs fails to build with Sphinx 3.0.x + +We've just updated Sphinx to version 3.0.1 and qemu fails to build the docs with this version. + +Here's the relevant section in the build log. + +CONFDIR="/etc/qemu" /usr/bin/sphinx-build-3 -W -b html -D version=4.2.92 -D release="4.2.92 (qemu-5.0.0-0.rc2.0.1.mga8)" -d .doctrees/devel-html /home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/devel docs/devel +Running Sphinx v3.0.1 +making output directory... done +building [mo]: targets for 0 po files that are out of date +building [html]: targets for 14 source files that are out of date +updating environment: [new config] 14 added, 0 changed, 0 removed +reading sources... [ 7%] bitops +reading sources... [ 14%] decodetree +reading sources... [ 21%] index +reading sources... [ 28%] kconfig +reading sources... [ 35%] loads-stores +reading sources... [ 42%] memory +reading sources... [ 50%] migration +reading sources... [ 57%] reset +reading sources... [ 64%] s390-dasd-ipl +reading sources... [ 71%] secure-coding-practices +reading sources... [ 78%] stable-process +reading sources... [ 85%] tcg +reading sources... [ 92%] tcg-plugins +reading sources... [100%] testing + + +Warning, treated as error: +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:3:Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct MemoryListener + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 21] + struct MemoryListener + ---------------------^ + +make: *** [Makefile:1095: docs/devel/index.html] Error 2 +make: *** Waiting for unfinished jobs.... + +I found this commit for memory.h that includes the section that faults. +https://github.com/qemu/qemu/commit/5d248213180749e674fbccbacc6ee9c38499abb3#diff-d892cbf314945b44699534cc1de4ebbd + +You can see the whol build log here. +https://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20200410161120.tv.duvel.699/log/qemu-5.0.0-0.rc2.0.1.mga8/build.0.20200410161338.log + +System: Mageia Cauldron + +Hmm, that's not ideal. The C is valid C which the compiler accepts, so I'm not sure what Sphinx is complaining about, and I don't have a system with that new a version of Sphinx. + +It does suggest that we ought to make our configure --enable-werror/--disable-werror (and the code that makes the default be disable for releases) control Sphinx's warnings-as-errors option as well as the compiler's, which would at least mean that for released versions the build doesn't fail entirely on Sphinx warnings. + + +One of our packaging gurus make a small change that removed the error fails option. + +# Don't treat warnings as errors when building docs with sphinx +sed -i -e '/SPHINX_BUILD/s/-W//' Makefile + +The build completes now, however there are still errors. + +CONFDIR="/etc/qemu" /usr/bin/sphinx-build-3 -b html -D version=4.2.92 -D release="4.2.92 (qemu-5.0.0-0.rc2.0.1.mga8)" -d .doctrees/devel-html /home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/devel docs/devel +Running Sphinx v3.0.1 +making output directory... done +building [mo]: targets for 0 po files that are out of date +building [html]: targets for 14 source files that are out of date +updating environment: [new config] 14 added, 0 changed, 0 removed +reading sources... [ 7%] bitops +reading sources... [ 14%] decodetree +reading sources... [ 21%] index +reading sources... [ 28%] kconfig +reading sources... [ 35%] loads-stores +reading sources... [ 42%] memory +reading sources... [ 50%] migration +reading sources... [ 57%] reset +reading sources... [ 64%] s390-dasd-ipl +reading sources... [ 71%] secure-coding-practices +reading sources... [ 78%] stable-process +reading sources... [ 85%] tcg +reading sources... [ 92%] tcg-plugins +reading sources... [100%] testing + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:3: WARNING: Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct MemoryListener + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 21] + struct MemoryListener + ---------------------^ + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:428: WARNING: Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct AddressSpace + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 19] + struct AddressSpace + -------------------^ + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:673: WARNING: Type must be either just a name or a typedef-like declaration. +If just a name: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6] + struct MemoryRegionSection + ------^ +If typedef-like declaration: + Error in declarator or parameters + Invalid C declaration: Expected identifier in nested name. [error at 26] + struct MemoryRegionSection + --------------------------^ + +/home/iurt/rpmbuild/BUILD/qemu-5.0.0-rc2/docs/../include/exec/memory.h:834: WARNING: Error in declarator or parameters +Invalid C declaration: Expecting "," or ")" in parameters, got "EOF". [error at 208] + void memory_region_init_resizeable_ram (MemoryRegion * mr, struct Object * owner, const char * name, uint64_t size, uint64_t max_size, void (*resized) (const char*, uint64_t length, void *host, Error ** errp) + ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^ +looking for now-outdated files... none found +pickling environment... done +checking consistency... done +preparing documents... done +writing output... [ 7%] bitops +writing output... [ 14%] decodetree +writing output... [ 21%] index +writing output... [ 28%] kconfig +writing output... [ 35%] loads-stores +writing output... [ 42%] memory +writing output... [ 50%] migration +writing output... [ 57%] reset +writing output... [ 64%] s390-dasd-ipl +writing output... [ 71%] secure-coding-practices +writing output... [ 78%] stable-process +writing output... [ 85%] tcg +writing output... [ 92%] tcg-plugins +writing output... [100%] testing + +generating indices... genindexdone +writing additional pages... searchdone +copying static files... ... done +copying extra files... done +dumping search index in English (code: en)... done +dumping object inventory... done +build succeeded, 4 warnings. + +The HTML pages are in docs/devel. + +I'm a bit confused: you say "however there are still errors" but the build log you quote ends with "build succeeded, 4 warnings" and it looks like it has indeed just produced warnings and continued. + + +You are right. Wrong choice of words. + +However, the change is a breaking change from Sphinx. + +See https://github.com/sphinx-doc/sphinx/issues/7457#issuecomment-612413080 + +I've sent a proposed fix to the list: +https://<email address hidden>/ + + +The upstream fix for this is now in 5.0-rc3 and will be in the final 5.0 release. + diff --git a/results/classifier/118/review/1872790 b/results/classifier/118/review/1872790 new file mode 100644 index 000000000..8139f664d --- /dev/null +++ b/results/classifier/118/review/1872790 @@ -0,0 +1,131 @@ +user-level: 0.826 +TCG: 0.706 +vnc: 0.701 +risc-v: 0.699 +mistranslation: 0.691 +register: 0.689 +hypervisor: 0.685 +peripherals: 0.663 +x86: 0.635 +KVM: 0.619 +device: 0.615 +ppc: 0.608 +VMM: 0.608 +performance: 0.590 +arm: 0.531 +semantic: 0.530 +debug: 0.520 +virtual: 0.517 +assembly: 0.504 +graphic: 0.503 +permissions: 0.501 +architecture: 0.501 +boot: 0.492 +kernel: 0.481 +files: 0.469 +socket: 0.450 +PID: 0.445 +network: 0.440 +i386: 0.399 +-------------------- +virtual: 0.984 +debug: 0.977 +hypervisor: 0.972 +x86: 0.941 +kernel: 0.369 +PID: 0.132 +KVM: 0.045 +register: 0.027 +device: 0.027 +TCG: 0.016 +files: 0.013 +boot: 0.012 +user-level: 0.011 +socket: 0.009 +semantic: 0.007 +architecture: 0.004 +assembly: 0.003 +VMM: 0.003 +network: 0.003 +graphic: 0.002 +performance: 0.002 +peripherals: 0.001 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +ppc: 0.001 +i386: 0.001 +mistranslation: 0.001 +arm: 0.000 + +empty qcow2 + +I plugged multiple qcow2 to a Windows guest. On the Windows disk manager all disks are listed perfectly, with their data, their real space, I even can explore all files on the Explorer, all cool + +On third party disk manager (all of them), I only have the C:\ HDD who act normally, all the other plugged qcow2 are seen as fully unallocated, so I can't manipulate them + +I want to move some partitions, create others, but on Windows disk manager I can't extend or create partition and on third party I didn't see the partitions at all + +Even guestfs doesn't recognize any partition table `libguestfs: error: inspect_os: /dev/sda: not a partitioned device` + +It sounds like maybe these disks have been partitioned in a format that only Windows understands. Can you tell me what the windows disk manager claims the partition table format to be? + +If you still think that maybe there's a QEMU bug, please give more details: + +- host kernel version + +- qemu version + +- qemu command line + +- how were these qcow2 files created? + +- What version of qcow2 file does `qemu-img info` say they are? + +- What version of windows? (10?) + +- Can you name one of the third party disk managers so we can try to reproduce it? + + +WDM claims it to be a MBR + +Linux 5.6.14 + +QEMU 5.0.0-6 + +`nobody 19023 109 21.1 7151512 3462300 ? Sl 13:18 0:32 /usr/bin/qemu-system-x86_64 -name guest=win10machine,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-win10machine/master-key.aes -machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Haswell-noTSX,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,arch-capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-vmentry=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 4096 -overcommit mem-lock=off -smp 2,sockets=2,cores=1,threads=1 -uuid db88f5fc-47f0-439c-9192-a5991df2d8f8 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=34,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev {"driver":"file","filename":"/home/user/nvme0n1/p1/win10.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-3-format","read-only":false,"driver":"qcow2","file":"libvirt-3-storage","backing":null} -device ide-hd,bus=ide.0,drive=libvirt-3-format,id=sata0-0-0,bootindex=1 -blockdev {"driver":"file","filename":"/home/user/nvme0n1/p1/dump1.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device ide-hd,bus=ide.1,drive=libvirt-2-format,id=sata0-0-1 -blockdev {"driver":"file","filename":"/home/user/nvme0n1/p1/dump2.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null} -device ide-hd,bus=ide.2,drive=libvirt-1-format,id=sata0-0-2 -netdev tap,fd=36,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:b5:3a:ca,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on` + +The qcow2 of the guest was created in VMM and the qcow2 that I can't manipulate was created with (if I remember well) something like `qemu-img convert /dev/sda2 -O image.qcow2` from a Windows physical machine + +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +W10 + +All the managers that i've tried were the same, but you can try for example MiniTool or EaseUS + +WDM claims it to be a MBR + +Linux 5.6.14 + +QEMU 5.0.0-6 + +`nobody 19023 109 21.1 7151512 3462300 ? Sl 13:18 0:32 /usr/bin/qemu-system-x86_64 -name guest=win10machine,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-4-win10machine/master-key.aes -machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Haswell-noTSX,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,arch-capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-vmentry=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 4096 -overcommit mem-lock=off -smp 2,sockets=2,cores=1,threads=1 -uuid db88f5fc-47f0-439c-9192-a5991df2d8f8 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=34,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev {"driver":"file","filename":"/home/user/nvme0n1/p1/win10.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-3-format","read-only":false,"driver":"qcow2","file":"libvirt-3-storage","backing":null} -device ide-hd,bus=ide.0,drive=libvirt-3-format,id=sata0-0-0,bootindex=1 -blockdev {"driver":"file","filename":"/home/user/nvme0n1/p1/dump1.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device ide-hd,bus=ide.1,drive=libvirt-2-format,id=sata0-0-1 -blockdev {"driver":"file","filename":"/home/user/nvme0n1/p1/dump2.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null} -device ide-hd,bus=ide.2,drive=libvirt-1-format,id=sata0-0-2 -netdev tap,fd=36,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:b5:3a:ca,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on` + +The qcow2 of the guest was created in VMM and the qcow2 that I can't manipulate was created with (if I remember well) something like `qemu-img convert -f raw /dev/sda2 -O image.qcow2` from a Windows physical machine + +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +W10 + +All the managers that i've tried were the same, but you can try for example MiniTool or EaseUS + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1874504 b/results/classifier/118/review/1874504 new file mode 100644 index 000000000..61fb570e6 --- /dev/null +++ b/results/classifier/118/review/1874504 @@ -0,0 +1,92 @@ +mistranslation: 0.908 +graphic: 0.762 +semantic: 0.639 +device: 0.584 +debug: 0.552 +peripherals: 0.428 +performance: 0.400 +kernel: 0.398 +architecture: 0.321 +virtual: 0.260 +PID: 0.254 +ppc: 0.224 +hypervisor: 0.190 +network: 0.186 +user-level: 0.172 +permissions: 0.167 +register: 0.145 +x86: 0.120 +socket: 0.119 +i386: 0.111 +assembly: 0.086 +risc-v: 0.084 +boot: 0.080 +arm: 0.059 +vnc: 0.056 +VMM: 0.055 +TCG: 0.049 +files: 0.029 +KVM: 0.018 +-------------------- +debug: 0.982 +virtual: 0.623 +device: 0.224 +performance: 0.112 +user-level: 0.081 +peripherals: 0.076 +TCG: 0.033 +files: 0.025 +register: 0.024 +kernel: 0.022 +hypervisor: 0.015 +PID: 0.012 +assembly: 0.009 +architecture: 0.007 +x86: 0.007 +semantic: 0.006 +boot: 0.005 +ppc: 0.004 +graphic: 0.003 +permissions: 0.002 +socket: 0.002 +network: 0.002 +arm: 0.002 +VMM: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +i386: 0.000 +KVM: 0.000 +vnc: 0.000 + +VFIO passthrough spits out thousands of messages + +started qemu as: +sudo qemu-system-sparc64 -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB + +messages received thousands of times: + +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu has granularity incompatible with target AS +qemu-system-sparc64: -device vfio-pci,host=0b:05.0,x-no-mmap=on,bus=pciB: iommu map to non memory area 4079c000 + +qemu version (think telling a lie as sure its 5.0) +QEMU emulator version 4.2.92 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +pci device being passed through: + +0b:05.0 Display controller [0380]: 3DLabs Permedia II 2D+3D [3d3d:0009] (rev 01) + Subsystem: Tech-Source Permedia II 2D+3D [1227:0006] + Flags: medium devsel, IRQ 11 + Memory at 83000000 (32-bit, non-prefetchable) [disabled] [size=128K] + Memory at 82800000 (32-bit, non-prefetchable) [disabled] [size=8M] + Memory at 82000000 (32-bit, non-prefetchable) [disabled] [size=8M] + Expansion ROM at 83020000 [disabled] [size=64K] + Capabilities: <access denied> + Kernel driver in use: vfio-pci + + + +Is this a regression? Can you please bisect to the first commit where it happened? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1875819 b/results/classifier/118/review/1875819 new file mode 100644 index 000000000..56b02fb81 --- /dev/null +++ b/results/classifier/118/review/1875819 @@ -0,0 +1,68 @@ +mistranslation: 0.953 +semantic: 0.604 +graphic: 0.566 +network: 0.546 +device: 0.541 +architecture: 0.395 +user-level: 0.354 +virtual: 0.315 +TCG: 0.276 +PID: 0.243 +x86: 0.240 +performance: 0.219 +socket: 0.205 +permissions: 0.200 +files: 0.169 +peripherals: 0.166 +register: 0.154 +arm: 0.152 +hypervisor: 0.149 +boot: 0.149 +debug: 0.138 +ppc: 0.100 +i386: 0.099 +risc-v: 0.086 +kernel: 0.082 +vnc: 0.049 +VMM: 0.042 +assembly: 0.033 +KVM: 0.013 +-------------------- +virtual: 0.231 +files: 0.078 +TCG: 0.076 +network: 0.043 +semantic: 0.020 +peripherals: 0.017 +VMM: 0.017 +user-level: 0.012 +x86: 0.010 +kernel: 0.010 +PID: 0.008 +assembly: 0.007 +device: 0.007 +ppc: 0.007 +boot: 0.006 +risc-v: 0.005 +debug: 0.005 +register: 0.003 +performance: 0.003 +architecture: 0.003 +graphic: 0.003 +arm: 0.002 +i386: 0.002 +permissions: 0.002 +hypervisor: 0.002 +socket: 0.002 +vnc: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +[Feature request] prebuilt testing docker images + +Instead of building qemu:docker images locally, we should pull the one built from Travis/Shippable/GitLab by default, and build it only when manually requested. + +GitLab has ability to host container images per project and also can build them during CI runs. So I'd suggest that we create GitLab CI jobs that build & publish each of the images under tests/docker on the master branch. + +I think this has been done now, so I'm closing this ticket. + diff --git a/results/classifier/118/review/1876568 b/results/classifier/118/review/1876568 new file mode 100644 index 000000000..9378b4059 --- /dev/null +++ b/results/classifier/118/review/1876568 @@ -0,0 +1,92 @@ +architecture: 0.880 +arm: 0.788 +user-level: 0.764 +graphic: 0.738 +device: 0.713 +risc-v: 0.660 +semantic: 0.657 +PID: 0.620 +register: 0.592 +performance: 0.588 +files: 0.584 +mistranslation: 0.573 +hypervisor: 0.565 +network: 0.559 +assembly: 0.548 +permissions: 0.533 +socket: 0.530 +i386: 0.518 +virtual: 0.513 +VMM: 0.510 +TCG: 0.504 +vnc: 0.460 +peripherals: 0.459 +ppc: 0.458 +kernel: 0.454 +x86: 0.436 +debug: 0.389 +boot: 0.382 +KVM: 0.377 +-------------------- +arm: 0.964 +user-level: 0.817 +hypervisor: 0.258 +TCG: 0.149 +debug: 0.133 +semantic: 0.065 +virtual: 0.059 +files: 0.038 +architecture: 0.021 +network: 0.016 +PID: 0.013 +risc-v: 0.011 +device: 0.009 +kernel: 0.007 +register: 0.006 +boot: 0.005 +socket: 0.005 +vnc: 0.004 +VMM: 0.004 +performance: 0.003 +ppc: 0.002 +permissions: 0.002 +assembly: 0.001 +peripherals: 0.001 +graphic: 0.001 +x86: 0.000 +i386: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +"semtimedop" implementation missing in qemu? + +I was trying to do an ARMv6 cross compile with qemu-user-static when I ran into this: + +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/326884620#L1596 + +I was close to giving up when I found the following: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36 + +Most important comment may be this one: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36#issuecomment-610626796 + +> The "correct" way to fix this does seem to be to implement semtimedop in qemu. + +I don't know how much involved the people, discussing there, are in the qemu development but I thought it may be a good idea to bring this to your attention. If this is already fixed (I haven't found any bug about "semtimedop"), then please just close this one and tell me in which version the fix will be included. + +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 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/review/1877794 b/results/classifier/118/review/1877794 new file mode 100644 index 000000000..72a3d88e3 --- /dev/null +++ b/results/classifier/118/review/1877794 @@ -0,0 +1,78 @@ +user-level: 0.946 +ppc: 0.921 +graphic: 0.877 +x86: 0.856 +performance: 0.855 +device: 0.788 +peripherals: 0.764 +architecture: 0.721 +semantic: 0.687 +debug: 0.670 +kernel: 0.663 +files: 0.639 +permissions: 0.574 +PID: 0.529 +socket: 0.499 +mistranslation: 0.446 +register: 0.441 +boot: 0.440 +arm: 0.431 +TCG: 0.423 +network: 0.413 +VMM: 0.388 +vnc: 0.386 +virtual: 0.375 +risc-v: 0.369 +assembly: 0.281 +hypervisor: 0.268 +KVM: 0.097 +i386: 0.073 +-------------------- +debug: 0.964 +x86: 0.734 +user-level: 0.695 +ppc: 0.379 +virtual: 0.112 +TCG: 0.083 +assembly: 0.042 +semantic: 0.024 +performance: 0.013 +kernel: 0.012 +PID: 0.010 +files: 0.008 +VMM: 0.008 +register: 0.006 +hypervisor: 0.006 +architecture: 0.005 +network: 0.004 +device: 0.002 +KVM: 0.002 +graphic: 0.002 +boot: 0.001 +socket: 0.001 +vnc: 0.001 +mistranslation: 0.001 +peripherals: 0.001 +permissions: 0.000 +risc-v: 0.000 +arm: 0.000 +i386: 0.000 + +Constant Folding on 64-bit Subtraction causes SIGILL on linux-user glxgears ppc64le to x86_64 by way of generating bad shift instruction with c=-1 + +Hello, I've been recently working on my own little branch of QEMU implementing the drm IOCTLs, when I discovered that glxgears seems to crash in GLXSwapBuffers(); with a SIGILL. I investigated this for about 2 weeks, manually trying to trace the call stack, only to find that we seemingly crash in a bad shift instruction. Originally intended to be an shr_i64 generated to an RLDICL, we end up with an all ones(-1) c value, which gets thrown to the macro for generating the MB, and replaces the instruction with mostly ones. This new instruction, FFFFFFE0 is invalid on ppc64le, and crashes in a host SIGILL in codegen_buffer. I tried to see if the output of translate.c had this bad instruction, but all I got were two (shr eax, cl) instructions, and upon creating a test program with shr (eax, cl) in it, nothing happened. Then figuring that there was nothing actually wrong with the instruction in the first place, I turned my eye to the optimizer, and completely disabled constant folding for arithmetic instructions. This seemed to actually resolve the issue, and then I slowly enabled constant folding again on various instructions only to find that enabling not on the shifts, but on subtraction seemed to cause the bug to reappear. I am bewildered and frankly at this point I'm not sure I have a chance in hell of figuring out what causes it, so I'm throwing it here. + +Which version of qemu and glxgears do you use? + +Tested with qemu-4.2 and qemu-5.0 and debian/sid mesa-utils-8.4.0-1+b1 and it works fine. + +I'm on 5.0-rc4 add a few patches implementing a subset of drm/amdgpu support, with mesa-utils 8.4.0-1. Important note I guess: I can't get the crash to trigger under llvmpipe/softrast, I can only get it on RadeonSI. I valgrind'd qemu only to not find anything on the host-side. I'm 99% sure this isn't a memory corruption bug from my patches, anyway, and it's not replicable on upstream qemu because DRM simply isn't functional. (Oh dear, I think I might be on my own until I can get this stuff upstreamed.) + +QEMU has been selected to have a GSoC intern to work on new ioctl(): +https://wiki.qemu.org/Google_Summer_of_Code_2020#Extend_linux-user_syscalls_and_ioctls + +Perhaps he can help you by working on DRM ioctl()? +Perhaps you can send an RFC series to the QEMU mailing list? + +I'm marking this invalid and moving on because it isn't replicable on upstream due to the lack of DRM support and because I'll probably just figure it out myself. (if anyone has somewhere better than tcg/README.md to learn TCG implementation details, I would appreciate it. + diff --git a/results/classifier/118/review/1878348 b/results/classifier/118/review/1878348 new file mode 100644 index 000000000..cab676bdd --- /dev/null +++ b/results/classifier/118/review/1878348 @@ -0,0 +1,155 @@ +semantic: 0.846 +assembly: 0.840 +arm: 0.818 +register: 0.817 +graphic: 0.813 +architecture: 0.808 +permissions: 0.804 +user-level: 0.802 +device: 0.794 +peripherals: 0.789 +debug: 0.787 +files: 0.765 +risc-v: 0.763 +hypervisor: 0.760 +virtual: 0.758 +PID: 0.753 +mistranslation: 0.737 +kernel: 0.737 +x86: 0.729 +ppc: 0.710 +VMM: 0.687 +performance: 0.686 +KVM: 0.686 +network: 0.684 +socket: 0.656 +TCG: 0.656 +boot: 0.641 +vnc: 0.628 +i386: 0.410 +-------------------- +x86: 0.883 +hypervisor: 0.097 +user-level: 0.097 +files: 0.069 +kernel: 0.037 +TCG: 0.023 +virtual: 0.021 +debug: 0.016 +register: 0.015 +VMM: 0.008 +ppc: 0.008 +semantic: 0.007 +PID: 0.006 +performance: 0.004 +network: 0.004 +KVM: 0.003 +assembly: 0.003 +device: 0.003 +socket: 0.003 +risc-v: 0.002 +vnc: 0.002 +architecture: 0.002 +boot: 0.002 +i386: 0.001 +graphic: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 + +--static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540) + +Hi, + +Since commit 5010cec2bc87dafab39b3913c8ca91f88df9c540, building qemu fails when configured with --static (eg ../configure --target-list=x86_64-softmmu,x86_64-linux-user --enable-debug --static). + +On ubuntu 16.04, it fails to find -lffi and -lselinux. + +After I apt-get install libffi-dev libselinux1-dev, the build still fails: +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_pre_save': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:29: undefined reference to `_TRACE_DBUS_VMSTATE_PRE_SAVE_DSTATE' +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_post_load': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:52: undefined reference to `_TRACE_DBUS_VMSTATE_POST_LOAD_DSTATE' +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_loading': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:75: undefined reference to `_TRACE_DBUS_VMSTATE_LOADING_DSTATE' +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_saving': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:98: undefined reference to `_TRACE_DBUS_VMSTATE_SAVING_DSTATE' +collect2: error: ld returned 1 exit status + +I'm not able to reproduce your problem. + +Are you able to reproduce the problem if you cleanup your build directory (make distclean)? + +Right, after a make distclean + configure, I managed to complete the build after installing libffi-dev libselinux1-dev. + +However, I think there's a bug in configure: it should either complain when these packages are missing, or disable the module that needs them. + +Without libffi-dev and libselinux1-dev, the build fails with: + LINK x86_64-softmmu/qemu-system-x86_64 +/usr/bin/ld: cannot find -lselinux +/usr/bin/ld: cannot find -lffi + + +Semi-officially, QEMU only aims to support static linking with usermode emulators, not system mode emulators. I'm not sure we make that clear anywhere in the docs, or configure script. We should probably print a warning from configure if using --static in combination with system emulators, that this is an untested scenario and users are responsible for figuring out any problems they hit such as missing libraries at link time. + +In particular it is a known limitation that the configure checks for pre-requisite libraries only validate existence of the shared libraries, and make no attempt to look for the static variant, and it was decided not to fix that. + + +I think it's largely that many distros ship pkg-config files which are just broken for the static linking case -- so configure tests "does pkg-config say this will work for static linking", and pkg-config says "yes, that will work", and then it doesn't. If you care about trying to get this to be more reliable you'd want to investigate all of these and file bugs upstream with your distro and get them fixed... + + +OK I wasn't aware that static linking was not supported by system emulators, thanks for the heads-up. I've updated our build scripts not to use static link, so you can close this PR unless you want to keep track that configure needs improvements. + +Thanks. + + +For the record, previous attempt to fix: +https://<email address hidden>/msg624142.html +and identical conclusion: +https://<email address hidden>/msg624164.html + + +Maybe --static should be ignored for system emulators and accepted for user-mode emulators? +That would enable to have a single build, otherwise if we want both, we'd need to configure & build QEMU twice. + + +Some people want the system emulation to be statically linked, which is why we don't refuse to do it entirely; and static vs not changes a bunch of stuff like CFLAGS which we assume to be common across the whole build. So if you want some statically linked binaries and some not statically linked, then yes, you should configure and build twice. (Use separate build directories, one for each config.) + + +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 older bugs 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. + +Thank you and sorry for the inconvenience. + + +FWIW, a configure line that works for me for static system-emulation builds on Ubuntu 18.04 with QEMU 6.0 is: + +'../../configure' '--target-list=arm-softmmu' '--enable-debug' '--static' '--disable-tools' '--disable-sdl' '--disable-gtk' '--disable-vnc' '--disable-virtfs' '--disable-attr' '--disable-libiscsi' '--disable-libnfs' '--disable-libusb' '--disable-opengl' '--disable-numa' '--disable-usb-redir' '--disable-bzip2' '--audio-drv-list=' '--disable-guest-agent' '--disable-vte' '--disable-mpath' '--disable-libudev' '--disable-vhost-user' '--disable-curl' + + +I have re-tested at commit d45a5270d075ea589f0b0ddcf963a5fea1f500ac, and the build succeeded, so it looks like the problem has been fixed. + + diff --git a/results/classifier/118/review/1878413 b/results/classifier/118/review/1878413 new file mode 100644 index 000000000..90db8454c --- /dev/null +++ b/results/classifier/118/review/1878413 @@ -0,0 +1,103 @@ +user-level: 0.909 +graphic: 0.772 +performance: 0.759 +device: 0.710 +kernel: 0.670 +ppc: 0.634 +semantic: 0.575 +architecture: 0.571 +permissions: 0.554 +peripherals: 0.551 +mistranslation: 0.508 +register: 0.501 +socket: 0.487 +network: 0.458 +PID: 0.430 +vnc: 0.390 +files: 0.359 +assembly: 0.355 +boot: 0.343 +TCG: 0.342 +debug: 0.340 +VMM: 0.308 +arm: 0.302 +risc-v: 0.299 +i386: 0.286 +x86: 0.277 +hypervisor: 0.269 +KVM: 0.203 +virtual: 0.100 +-------------------- +virtual: 0.189 +kernel: 0.067 +TCG: 0.049 +x86: 0.028 +debug: 0.026 +register: 0.016 +files: 0.016 +arm: 0.013 +PID: 0.013 +network: 0.007 +user-level: 0.007 +semantic: 0.004 +hypervisor: 0.004 +permissions: 0.004 +socket: 0.003 +architecture: 0.003 +performance: 0.003 +device: 0.003 +ppc: 0.002 +boot: 0.002 +risc-v: 0.002 +peripherals: 0.001 +assembly: 0.001 +i386: 0.001 +graphic: 0.001 +VMM: 0.001 +vnc: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +/proc/sys/fs/binfmt_misc/ empty even though binfmt_misc is loaded + +_apksigner_ uses binfmt to execute via _jarwrapper_, since it is a JAR. We have a test suite that relies on _apksigner_ working. It was running fine in Ubuntu/bionic. Since it was pegged to LTS, it got upgraded to Ubuntu/focal and it stopped working. This is likely because /proc/sys/fs/binfmt_misc/ is totally empty. The "binfmt_misc" kernel module shows as loaded: + +$ grep binfmt /proc/modules +binfmt_misc 20480 1 - Live 0xffffffffc0452000 + +This relies on binfmt support in gitlab.com's CI runner setup, based on Docker. binfmt works in containers there, for example on Ubuntu/bionic: +https://gitlab.com/fdroid/fdroidserver/-/jobs/516857857 + +Something in Ubuntu/focal broke this when running focal in the container on the same Docker host runners: +https://gitlab.com/fdroid/fdroidserver/-/jobs/547148092 + +Debian's ci.debian.net lxc runners also have a similar problem, it might be related: +https://salsa.debian.org/ci-team/debian-ci-config/-/issues/1 + +The binfmt_misc filesystem must be mounted on /proc/sys/fs/binfmt_misc to work. + +$ mount|grep ^binfmt_misc +binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) + + +From my experience, that mounting happens automatically once +binfmt-support is installed. At least that is the case on the +Ubuntu/bionic jobs and on my own Debian machines. Did something change +so that now it must be manually mounted? + + +It seems in the focal container, binfmt_misc doesn't get setup properly: +https://gitlab.com/eighthave/fdroidserver/-/jobs/550962360 + +$ grep binfmt /proc/modules +binfmt_misc 20480 1 - Live 0xffffffffc0461000 +$ mount | grep binfmt_misc || mount binfmt_misc /proc/sys/fs/binfmt_misc +mount: /proc/sys/fs/binfmt_misc: special device binfmt_misc does not exist. +$ + +Ok, your hint lead me to the fix: + +$ mount | grep binfmt_misc || mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc + +I guess this mounting was somehow happening automatically before, but now it seems that it is handled by systemd in a user system. But a container usually doesn't run systemd. + diff --git a/results/classifier/118/review/1878628 b/results/classifier/118/review/1878628 new file mode 100644 index 000000000..28166c8cf --- /dev/null +++ b/results/classifier/118/review/1878628 @@ -0,0 +1,79 @@ +user-level: 0.853 +device: 0.816 +graphic: 0.760 +network: 0.747 +register: 0.724 +PID: 0.709 +socket: 0.693 +vnc: 0.683 +files: 0.676 +architecture: 0.676 +ppc: 0.643 +mistranslation: 0.575 +semantic: 0.574 +performance: 0.558 +VMM: 0.552 +boot: 0.501 +arm: 0.501 +risc-v: 0.480 +permissions: 0.447 +debug: 0.439 +kernel: 0.424 +TCG: 0.387 +peripherals: 0.366 +x86: 0.339 +i386: 0.284 +hypervisor: 0.250 +virtual: 0.244 +KVM: 0.176 +assembly: 0.106 +-------------------- +kernel: 0.726 +x86: 0.230 +files: 0.072 +TCG: 0.057 +debug: 0.057 +i386: 0.035 +user-level: 0.031 +register: 0.007 +virtual: 0.005 +PID: 0.004 +semantic: 0.003 +device: 0.002 +network: 0.002 +performance: 0.001 +hypervisor: 0.001 +assembly: 0.001 +VMM: 0.001 +architecture: 0.001 +boot: 0.001 +KVM: 0.001 +graphic: 0.001 +ppc: 0.001 +peripherals: 0.001 +socket: 0.001 +arm: 0.001 +permissions: 0.000 +risc-v: 0.000 +vnc: 0.000 +mistranslation: 0.000 + +linux-user/mmap build failure using Clang 10 + +When building with Clang 10 on Fedora 32, we get: + + CC linux-user/mmap.o + linux-user/mmap.c:720:49: error: result of comparison 'unsigned long' > 18446744073709551615 is always false [-Werror,-Wtautological-type-limit-compare] + if ((unsigned long)host_addr + new_size > (abi_ulong)-1) { + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~ + +Suggested fix: Use -Wno-tautological-type-limit-compare in configure: + +https://<email address hidden>/msg699808.html + + +Patch posted: +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00856.html + +Merged as commit aabab96797a7d61989c25a7ca2b094591bbc74f9. + diff --git a/results/classifier/118/review/1878651 b/results/classifier/118/review/1878651 new file mode 100644 index 000000000..41bdc278d --- /dev/null +++ b/results/classifier/118/review/1878651 @@ -0,0 +1,171 @@ +user-level: 0.868 +peripherals: 0.836 +KVM: 0.831 +vnc: 0.804 +risc-v: 0.804 +hypervisor: 0.796 +performance: 0.784 +x86: 0.784 +graphic: 0.776 +ppc: 0.771 +TCG: 0.766 +register: 0.764 +arm: 0.762 +mistranslation: 0.756 +virtual: 0.749 +permissions: 0.748 +files: 0.747 +VMM: 0.741 +i386: 0.737 +device: 0.736 +assembly: 0.733 +architecture: 0.722 +semantic: 0.703 +debug: 0.702 +PID: 0.700 +kernel: 0.688 +socket: 0.686 +boot: 0.680 +network: 0.665 +-------------------- +kernel: 0.863 +x86: 0.561 +user-level: 0.325 +network: 0.296 +TCG: 0.223 +files: 0.213 +semantic: 0.153 +VMM: 0.105 +hypervisor: 0.104 +i386: 0.101 +performance: 0.069 +virtual: 0.067 +PID: 0.057 +KVM: 0.032 +device: 0.027 +ppc: 0.020 +vnc: 0.017 +risc-v: 0.014 +architecture: 0.013 +register: 0.012 +socket: 0.011 +assembly: 0.010 +debug: 0.009 +arm: 0.005 +boot: 0.003 +peripherals: 0.002 +graphic: 0.002 +permissions: 0.002 +mistranslation: 0.001 + +Assertion failure in e1000e_write_to_rx_buffers + +Hello, +While fuzzing, I found an input which triggers an assertion failure in e1000e_write_to_rx_buffers: +/home/alxndr/Development/qemu/hw/net/e1000e_core.c:1424: void e1000e_write_to_rx_buffers(E1000ECore *, hwaddr (*)[4], e1000e_ba_state *, const char *, dma_addr_t): Assertion `bastate->cur_idx < MAX_PS_BUFFERS' failed. +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff685742f in __assert_fail_base (fmt=0x7ffff69bdb48 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x555557f691e0 <str> "bastate->cur_idx < MAX_PS_BUFFERS", file=0x555557f5a080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x590, function=<optimized out>) at assert.c:92 +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557f691e0 <str> "bastate->cur_idx < MAX_PS_BUFFERS", file=0x555557f5a080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x590, function=0x555557f69240 <__PRETTY_FUNCTION__.e1000e_write_to_rx_buffers> "void e1000e_write_to_rx_buffers(E1000ECore *, hwaddr (*)[4], e1000e_ba_state *, const char *, dma_addr_t)") at assert.c:101 +#4 0x0000555556f8fbcd in e1000e_write_to_rx_buffers (core=0x7fffee07c4e0, ba=0x7fffffff8860, bastate=0x7fffffff88a0, data=0x7fffe61b8021 "", data_len=0x2000) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1424 +#5 0x0000555556f82f14 in e1000e_write_packet_to_guest (core=0x7fffee07c4e0, pkt=0x61100004b900, rxr=0x7fffffff8d10, rss_info=0x7fffffff8d30) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582 +#6 0x0000555556f80960 in e1000e_receive_iov (core=0x7fffee07c4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#7 0x0000555556f7d457 in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#8 0x0000555556f64738 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#9 0x0000555556f63f0e in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#10 0x0000555556f650e5 in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#11 0x0000555556fb026a in e1000e_tx_pkt_send (core=0x7fffee07c4e0, tx=0x7fffee09c748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#12 0x0000555556faebf6 in e1000e_process_tx_desc (core=0x7fffee07c4e0, tx=0x7fffee09c748, dp=0x7fffffff9520, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#13 0x0000555556fadfa8 in e1000e_start_xmit (core=0x7fffee07c4e0, txr=0x7fffffff9720) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#14 0x0000555556fa308b in e1000e_set_tdt (core=0x7fffee07c4e0, index=0xe06, val=0x563) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#15 0x0000555556f84d7e in e1000e_core_write (core=0x7fffee07c4e0, addr=0x438, val=0x563, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#16 0x0000555556f79497 in e1000e_mmio_write (opaque=0x7fffee079800, addr=0x438, val=0x563, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#17 0x00005555564938b5 in memory_region_write_accessor (mr=0x7fffee07c110, addr=0x438, value=0x7fffffff9d90, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#18 0x000055555649328a in access_with_adjusted_size (addr=0x438, value=0x7fffffff9d90, size=0x2, access_size_min=0x4, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x7fffee07c110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#19 0x0000555556491df6 in memory_region_dispatch_write (mr=0x7fffee07c110, addr=0x438, data=0x563, op=MO_16, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#20 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000037820, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x2, addr1=0x438, l=0x2, mr=0x7fffee07c110) at /home/alxndr/Development/qemu/exec.c:3137 +#21 0x00005555562bbad9 in flatview_write (fv=0x606000037820, addr=0xe1020023, attrs=..., buf=0x61900009ba80, len=0x417) at /home/alxndr/Development/qemu/exec.c:3177 +#22 0x00005555562bb609 in address_space_write (as=0x6080000027a0, addr=0xe1020023, attrs=..., buf=0x61900009ba80, len=0x417) at /home/alxndr/Development/qemu/exec.c:3268 +#23 0x0000555556488c07 in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60400001e210) at /home/alxndr/Development/qemu/qtest.c:567 +#24 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#25 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffc9e0 "e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305\n-M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic\n002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055\360U", size=0x1f2) at /home/alxndr/Development/qemu/qtest.c:722 +#26 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001d50, buf=0x7fffffffc9e0 "e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305\n-M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic\n002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055\360U", len=0x1f2) at /home/alxndr/Development/qemu/chardev/char.c:183 +#27 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001d50, buf=0x7fffffffc9e0 "e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305\n-M pc-q35-5.0 -device sdhci-pci,sd-spec-version=3 -device sd-card,drive=mydrive -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive -nographic -nographic\n002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055\360U", len=0x1f2) at /home/alxndr/Development/qemu/chardev/char.c:195 +#28 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001d50) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#29 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002b780, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001d50) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#30 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#31 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#32 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x39c63cc8) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#33 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#34 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#35 0x0000555557a6a29d in main (argc=0x13, argv=0x7fffffffe0e8, envp=0x7fffffffe188) at /home/alxndr/Development/qemu/softmmu/main.c:49 + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1020618 0x14 0x0000d0ff2d05575f215e1b0000000000d0ff2d05 +write 0x27 0x800c 0x08004500feffffff00007b06f +write 0x1b8006 0x8001 0x2f0 +write 0xe1020023 0x417 0x0002e10000000006ffcf055e2d1b0002e10000000006ffd1055e2d1b0002e10000000006ffd3055e2d1b0002e10000000006ffd5055e2d1b0002e10000000006ffd7055e2d1b0002e10000000006ffd9055e2d1b0002e10000000006ffdb055e2d1b0002e10000000006ffdd055e2d1b0002e10000000006ffdf055e2d1b0002e10000000006ffe1055e2d1b0002e10000000006ffe3055e2d1b0002e10000000006ffe5055e2d1b0002e10000000006ffe7055e2d1b0002e10000000006ffe9055e2d1b0002e10000000006ffeb055e2d1b0002e10000000006ffed055e2d1b0002e10000000006ffef055e2d1b0002e10000000006fff1055e2d1b0002e10000000006fff3055e2d1b0002e10000000006fff5055e2d1b0002e10000000006fff7055e2d1b0002e10000000006fff9055e2d1b0002e10000000006fffb055e2d1b0002e10000000006fffd055e2d1b0002e10000000006ffff055e2d1b0002e10000000006ff01055e2d1b0002e10000000006ff03055e2d1b0002e10000000006ff05055e2d1b0002e10000000006ff07055e2d1b0002e10000000006ff09055e2d1b0002e10000000006ff0b055e2d1b0002e10000000006ff0d055e2d1b0002e10000000006ff0f055e2d1b0002e10000000006ff11055e2d1b0002e10000000006ff13055e2d1b0002e10000000006ff15055e2d1b0002e10000000006ff17055e2d1b0002e10000000006ff19055e2d1b0002e10000000006ff1b055e2d1b0002e10000000006ff1d055e2d1b0002e10000000006ff1f055e2d1b0002e10000000006ff21055e2d1b0002e10000000006ff23055e2d1b0002e10000000006ff25055e2d1b0002e10000000006ff27055e2d1b0002e10000000006ff29055e2d1b0002e10000000006ff2b055e2d1b0002e10000000006ff2d055e2d1b0002e10000000006ff2f055e2d1b0002e10000000006ff31055e2d1b0002e10000000006ff33055e2d1b0002e10000000006ff35055e2d1b0002e10000000006ff37055e2d1b0002e10000000006ff39055e2d1b0002e10000000006ff3b055e2d1b0002e10000000006ff3d055e2d1b0002e10000000006ff3f055e2d1b0002e10000000006ff41055e2d1b0002e10000000006ff43055e2d1b0002e10000000006ff45055e2d1b0002e10000000006ff47055e2d1b0002e10000000006ff49055e2d1b0002e10000000006ff4b055e2d1b0002e10000000006ff4d055e2d1b0002e10000000006ff4f055e2d1b0002e10000000006ff51055e2d1b0002e10000000006ff53055e2d1b0002e10000000006ff55055e2d1b0002e10000000006ff57055e2d1b0002e10000000006ff59055e2d1b0002e10000000006ff5b055e2d1b0002e10000000006ff5d055e2d1b0002e10000000006ff5f055e2d1b0002e10000000006ff61055e2d1b0002e10000000006ff6305 +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex + + + +This was reported by OSS-Fuzz as Issue 27389 +Here is a minimized reproducer: + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none\ + -machine accel=qtest -m 512M -machine q35 -nodefaults \ +-device e1000e,netdev=net0 -netdev user,id=net0 -qtest stdio +outl 0xcf8 0x80000811 +outl 0xcfc 0xc600 +outl 0xcf8 0x80000813 +outl 0xcfc 0x9d +outl 0xcf8 0x80000801 +outl 0xcfc 0x16000000 +write 0x9dc6500a 0x2 0x2080 +write 0x9dc6011a 0x2 0x1040 +write 0x9dc60120 0x1 0xa0 +write 0x9dc60102 0x2 0x4e04 +outl 0xcf8 0x80000811 +outl 0xcfc 0x5ac600 +write 0x5ac6042a 0x2 0x00ff +write 0x5ac60402 0x2 0x020 +write 0x10 0x1 0xff +write 0x11 0x1 0x01 +write 0x19 0x1 0xe7 +write 0x1b 0x1 0x11 +write 0x20b 0x1 0x08 +write 0x20d 0x1 0x15 +write 0xac7 0x1 0x10 +write 0x5ac6043a 0x1 0x10 +EOF + +While the crash with the original reproducer seems to be gone, the minimized reproducer from comment #2 still triggers this issue. Setting to "Confirmed". + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/537 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/118/review/1880332 b/results/classifier/118/review/1880332 new file mode 100644 index 000000000..a58c07715 --- /dev/null +++ b/results/classifier/118/review/1880332 @@ -0,0 +1,97 @@ +architecture: 0.867 +graphic: 0.843 +ppc: 0.795 +permissions: 0.714 +device: 0.705 +arm: 0.694 +performance: 0.667 +socket: 0.667 +network: 0.662 +PID: 0.660 +debug: 0.617 +files: 0.563 +mistranslation: 0.558 +user-level: 0.532 +x86: 0.531 +vnc: 0.516 +kernel: 0.513 +semantic: 0.508 +register: 0.498 +i386: 0.474 +VMM: 0.471 +risc-v: 0.470 +boot: 0.465 +hypervisor: 0.465 +peripherals: 0.456 +TCG: 0.429 +KVM: 0.401 +virtual: 0.397 +assembly: 0.240 +-------------------- +assembly: 0.777 +debug: 0.684 +register: 0.116 +files: 0.060 +virtual: 0.044 +TCG: 0.040 +user-level: 0.015 +PID: 0.015 +arm: 0.011 +network: 0.010 +kernel: 0.008 +hypervisor: 0.008 +performance: 0.005 +risc-v: 0.004 +socket: 0.003 +device: 0.003 +architecture: 0.002 +semantic: 0.002 +ppc: 0.002 +graphic: 0.002 +peripherals: 0.002 +boot: 0.001 +permissions: 0.001 +vnc: 0.001 +VMM: 0.001 +x86: 0.001 +mistranslation: 0.000 +i386: 0.000 +KVM: 0.000 + +Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) + +I've come across a very specific situation, but I'm sure it could be replicated in other cases. + +In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. + +I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted. + + + +This is a compiler bug affecting (at least) libcrypto.so.1.1: + + 179d90: d503233f paciasp + 179d94: a9bb7bfd stp x29, x30, [sp, #-80]! +... + 17a400: d50323bf autiasp + 17a404: f84507fd ldr x29, [sp], #80 + 17a408: d65f03c0 ret + +The PAC happens with the initial sp: + + X30=0000005501de55fc SP=00000055018477a0 + +while the AUTH happens with the decremented sp: + + X30=0011005501de55fc SP=0000005501847750 + +Since the salt (sp) is different for the two operations, the +authorization should and does fail: + + X30=0020005501de55fc + +Note bit 53 is now set in x30, which is the error indication. + +The compiler must move the authiasp down below the ldr pop. + + diff --git a/results/classifier/118/review/1881249 b/results/classifier/118/review/1881249 new file mode 100644 index 000000000..e1ec09a18 --- /dev/null +++ b/results/classifier/118/review/1881249 @@ -0,0 +1,126 @@ +architecture: 0.890 +device: 0.798 +register: 0.763 +performance: 0.731 +arm: 0.661 +ppc: 0.658 +mistranslation: 0.652 +files: 0.606 +permissions: 0.580 +peripherals: 0.563 +kernel: 0.531 +assembly: 0.510 +graphic: 0.506 +hypervisor: 0.485 +vnc: 0.475 +boot: 0.461 +network: 0.418 +semantic: 0.418 +PID: 0.406 +risc-v: 0.404 +socket: 0.398 +debug: 0.393 +x86: 0.392 +user-level: 0.373 +virtual: 0.275 +TCG: 0.273 +VMM: 0.257 +KVM: 0.238 +i386: 0.216 +-------------------- +arm: 0.951 +architecture: 0.738 +hypervisor: 0.435 +kernel: 0.396 +KVM: 0.234 +TCG: 0.123 +virtual: 0.077 +files: 0.070 +register: 0.067 +VMM: 0.035 +debug: 0.027 +PID: 0.020 +boot: 0.019 +device: 0.015 +socket: 0.014 +semantic: 0.009 +assembly: 0.007 +network: 0.007 +performance: 0.005 +vnc: 0.005 +user-level: 0.004 +permissions: 0.003 +peripherals: 0.003 +risc-v: 0.002 +graphic: 0.001 +mistranslation: 0.001 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +CPU fetch from unpopulated ROM on reset + +Some architectures fetch the $PC/$SP register as vectors in memory, usually ROM. +The CPU reset() handler is called before the ROM code is populated, resulting in fetching incorrect PC/SP. + +Architectures affected: +- M68K +- RX +- ARM M-profile + +Different comments from Peter Maydell regarding this issue: + +- https://<email address hidden>/msg683768.html + +"We should be able to do this with the new 3-phase +reset API : the rom loader reset should happen in phase 2, +and the Arm CPU should only load the new PC and SP in +phase 3." + +- https://<email address hidden>/msg686480.html + +"The expectation at the moment is that the board code should +register a reset function with qemu_register_reset() which +calls cpu_reset(). Relying on doing a reset in realize won't +work for the case where there's a QEMU system reset, because +we don't re-init/realize everything, we just call all the +reset hooks. + +If m68k reads pc/sp from memory on reset you'll probably run +into the same reset-ordering vs hw/cpu/loader.c that Arm M-profile +has; we currently work around that in the arm reset function." + +- https://<email address hidden>/msg683856.html + +Related (invalidated thus rejected) series: + +- https://<email address hidden>/msg683763.html + +"Support device reset handler priority configuration" + +This series adds support for configuring device reset handler priority, and +uses it to ensure that the ARMv7-M CPU reset handler is invoked after the ROM +reset handler. + +- https://<email address hidden>/msg686413.html + +"Avoid latent bug calling cpu_reset() on uninitialized vCPU" + +cpu_reset() might modify architecture-specific fields allocated +by qemu_init_vcpu(). To avoid bugs similar to the one fixed in +commit 00d0f7cb66 when introducing new architectures, move the +cpu_reset() calls after qemu_init_vcpu(). + +I had an initial look at fixing this for arm via 3-phase reset, but ran into the problem that currently CPU reset is triggered via a qemu_register_reset() hook, and qemu_register_reset() itself does not have a 3-phase reset API, so the reset hook for resetting the CPUs will end up doing all 3 phases of reset for the CPU before the reset hook for reset-from-sysbus-root does all 3 phases for other devices. (I forget whether rom-data-copy happens via sysbus reset or is its own qemu_register_reset hook, but either way the same issue applies.) + +One approach to this would be to add 3-phase support to qemu_register_reset(), I guess. + + + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/236 + + diff --git a/results/classifier/118/review/1881648 b/results/classifier/118/review/1881648 new file mode 100644 index 000000000..dc5c4a195 --- /dev/null +++ b/results/classifier/118/review/1881648 @@ -0,0 +1,91 @@ +mistranslation: 0.848 +semantic: 0.819 +graphic: 0.816 +device: 0.767 +PID: 0.733 +ppc: 0.730 +network: 0.688 +performance: 0.653 +files: 0.642 +socket: 0.593 +architecture: 0.581 +kernel: 0.570 +user-level: 0.568 +hypervisor: 0.552 +register: 0.547 +boot: 0.544 +i386: 0.525 +TCG: 0.522 +vnc: 0.519 +x86: 0.508 +permissions: 0.456 +virtual: 0.442 +risc-v: 0.440 +VMM: 0.428 +arm: 0.416 +KVM: 0.414 +debug: 0.350 +peripherals: 0.318 +assembly: 0.271 +-------------------- +virtual: 0.244 +hypervisor: 0.215 +TCG: 0.112 +ppc: 0.106 +performance: 0.102 +semantic: 0.096 +register: 0.090 +debug: 0.076 +files: 0.075 +x86: 0.073 +PID: 0.059 +user-level: 0.054 +risc-v: 0.050 +device: 0.043 +boot: 0.034 +VMM: 0.031 +i386: 0.027 +kernel: 0.025 +network: 0.023 +socket: 0.022 +vnc: 0.020 +peripherals: 0.020 +arm: 0.016 +KVM: 0.016 +assembly: 0.005 +architecture: 0.005 +permissions: 0.004 +graphic: 0.004 +mistranslation: 0.001 + +`qemu-img info` reports an incorrect actual-size when the underlying posix filesystem has transparent compression + +qemu-img info reports the same thing as `du`*1024: + +$ qemu-img info --output json ./my.qcow2 | jq '."actual-size"' +558619648 + +$ du ./my.qcow2 +545527 ./my.qcow2 + +$ echo $((558619648 / 545527)) +1024 + +and this is correct in terms of bytes on disk, but due to transparent compression implemented by the filesystem, it is not the actual byte count: + +$ du -h --apparent-size ./my.qcow2 +1346568192 my.qcow2 + +But that’s the point of that field, to show the amount of space used by the image on the host. + +The man page documents it as: “disk size: How much space the image file occupies on the host file system (may be shown as 0 if this information is unavailable, e.g. because there is no file system)”, and the QAPI definition of ImageInfo documents the actual-size field as “actual size on disk in bytes of the image”. + +So it is documented as and intended to be the number of bytes used, not the length of the file. + +Max + +This bug has been reported on the Ubuntu ISO testing tracker. + +A list of all reports related to this bug can be found here: +http://iso.qa.ubuntu.com/qatracker/reports/bugs/1881648 + diff --git a/results/classifier/118/review/1882241 b/results/classifier/118/review/1882241 new file mode 100644 index 000000000..8a2cec198 --- /dev/null +++ b/results/classifier/118/review/1882241 @@ -0,0 +1,175 @@ +risc-v: 0.843 +files: 0.829 +user-level: 0.815 +register: 0.809 +device: 0.798 +performance: 0.794 +boot: 0.786 +virtual: 0.783 +mistranslation: 0.779 +assembly: 0.747 +architecture: 0.736 +peripherals: 0.727 +vnc: 0.721 +permissions: 0.715 +semantic: 0.713 +PID: 0.710 +arm: 0.708 +network: 0.701 +graphic: 0.694 +ppc: 0.661 +VMM: 0.661 +debug: 0.644 +TCG: 0.644 +KVM: 0.626 +socket: 0.605 +hypervisor: 0.604 +x86: 0.539 +kernel: 0.536 +i386: 0.454 +-------------------- +virtual: 0.988 +x86: 0.962 +KVM: 0.703 +files: 0.421 +hypervisor: 0.245 +vnc: 0.052 +kernel: 0.021 +VMM: 0.015 +user-level: 0.013 +boot: 0.012 +debug: 0.010 +TCG: 0.009 +register: 0.008 +PID: 0.008 +risc-v: 0.007 +device: 0.004 +network: 0.004 +semantic: 0.004 +socket: 0.003 +ppc: 0.002 +performance: 0.001 +graphic: 0.001 +assembly: 0.001 +permissions: 0.001 +architecture: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +i386: 0.000 +arm: 0.000 + +file transfer over cifs to 64bit guest corrupts large files + +qemu 4.0 compiled fom source. +vm called by +qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay + +copying large files eg 2.4gb or reading them on a cifs mount in the guest causes corruption every time. For smaller files 40-60mb corruption is more than 50% of the time. tested by md5sum on cifs server, or on host machine vs. on guest vm. +corruption is seen only with 64bit guest using cifs with i82551 emulated network device +ie. 32bit guest using cifs with i82551 emulated network device gives no corruption. + +changing the emulated device to vmxnet3 removes the data corruption (see below) + +qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay + +this corruption is repeatable. ie. I created new vm, call using top example, installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then run md5sum "filecopied" +the md5sum is different every time. copy same file to the host, or to a 32bit guest with the same virtual network device and bridge and md5sums are correct. The host pysical network adapter is +lspci|grep Ether +1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11) + +physically connected via gigabit ethernet to cifs server (via gigabit switch) + +On Fri, Jun 05, 2020 at 12:30:39PM -0000, timsoft wrote: +> Public bug reported: +> +> qemu 4.0 compiled fom source. +> vm called by +> qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net nic,macaddr=02:00:00:11:11:17,model=i82551 -net bridge,br=br0 -enable-kvm -k en-gb -display vnc=:3 -monitor telnet:localhost:7103,server,nowait,nodelay +> +> copying large files eg 2.4gb or reading them on a cifs mount in the guest causes corruption every time. For smaller files 40-60mb corruption is more than 50% of the time. tested by md5sum on cifs server, or on host machine vs. on guest vm. +> corruption is seen only with 64bit guest using cifs with i82551 emulated network device +> ie. 32bit guest using cifs with i82551 emulated network device gives no corruption. +> +> changing the emulated device to vmxnet3 removes the data corruption (see +> below) +> +> qemu-system-x86_64 -cpu qemu64 -smp 4 -m 4G -drive +> file=/data/images/slack14.2_64bit_test.qcow2,format=qcow2 -cdrom +> /mnt/smb1/slackware/iso/slackware64-14.2-install-dvd.iso -boot c -net +> nic,macaddr=02:00:00:11:11:17,model=vmxnet3 -net bridge,br=br0 -enable- +> kvm -k en-gb -display vnc=:3 -monitor +> telnet:localhost:7103,server,nowait,nodelay +> +> this corruption is repeatable. ie. I created new vm, call using top example, installed 64bit linux, mounted cifs share and copied 2.4gb file to /tmp then run md5sum "filecopied" +> the md5sum is different every time. copy same file to the host, or to a 32bit guest with the same virtual network device and bridge and md5sums are correct. The host pysical network adapter is +> lspci|grep Ether +> 1e:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11) +> +> physically connected via gigabit ethernet to cifs server (via gigabit +> switch) + +Not a solution but some comments: + +1. As a sanity-check you could try "nc <guest-ip> 1234 </path/to/file" on + the host and "nc -l -p 1234 >/tmp/file" in the guest. Netcat simply + sends/receives data over a TCP connection (it's a much simpler test + than CIFS). Is the checksum okay? + +2. I don't know the CIFS network protocol, but if Wireshark can dissect + it then you could compare the flows between the vmxnet3 and the + i82551. This is only feasible if Wireshark can produce an unencrypted + conversation and the CIFS protocol doesn't have many protocol header + fields that differ between two otherwise identical sessions. + +3. virtio-net is the most widely used and high-performance NIC model. + Other emulated NIC models are mainly there for very old guests that + lack virtio guest drivers. + + +thanks for the suggestion. I tried using netcat (nc) to transfer a large file from host to guest, and also from fileserver to guest with the problematic i82551 emulated network adapter on the host and the files transfered reliably. (correct md5sum 3 out of 3 attempts) +I also tried md5sum of the same file mounted on the guest fs as before and it still corrupts the data. +this seems to imply there is something in the cifs implementation which reacts adversly with this particular combination of virtual network hardware, the fact it works with the vmxnet3 emulated card, would support that conclusion. + +On Wed, Jun 17, 2020 at 02:55:55PM -0000, timsoft wrote: +> thanks for the suggestion. I tried using netcat (nc) to transfer a large file from host to guest, and also from fileserver to guest with the problematic i82551 emulated network adapter on the host and the files transfered reliably. (correct md5sum 3 out of 3 attempts) +> I also tried md5sum of the same file mounted on the guest fs as before and it still corrupts the data. +> this seems to imply there is something in the cifs implementation which reacts adversly with this particular combination of virtual network hardware, the fact it works with the vmxnet3 emulated card, would support that conclusion. + +I'm not sure if someone will look into it because the eepro100 +(i82551) NIC device is old an not used much nowadays. + +However, if someone does decide to investigate and wants to brainstorm +debugging ideas or needs help, feel free to contact me. + + +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 older bugs 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/review/1882350 b/results/classifier/118/review/1882350 new file mode 100644 index 000000000..dcfee42b1 --- /dev/null +++ b/results/classifier/118/review/1882350 @@ -0,0 +1,155 @@ +user-level: 0.905 +peripherals: 0.877 +device: 0.873 +architecture: 0.867 +risc-v: 0.856 +assembly: 0.849 +KVM: 0.846 +semantic: 0.843 +PID: 0.829 +mistranslation: 0.824 +performance: 0.815 +VMM: 0.806 +permissions: 0.805 +register: 0.789 +TCG: 0.778 +virtual: 0.776 +kernel: 0.775 +arm: 0.770 +files: 0.764 +ppc: 0.757 +boot: 0.754 +x86: 0.748 +debug: 0.743 +hypervisor: 0.727 +graphic: 0.719 +vnc: 0.675 +network: 0.674 +i386: 0.628 +socket: 0.598 +-------------------- +virtual: 0.987 +KVM: 0.753 +hypervisor: 0.599 +user-level: 0.406 +peripherals: 0.378 +debug: 0.163 +files: 0.068 +boot: 0.067 +VMM: 0.063 +device: 0.051 +TCG: 0.050 +x86: 0.038 +register: 0.031 +PID: 0.024 +i386: 0.012 +socket: 0.010 +kernel: 0.008 +risc-v: 0.008 +semantic: 0.007 +arm: 0.006 +architecture: 0.006 +network: 0.005 +vnc: 0.005 +ppc: 0.004 +assembly: 0.003 +performance: 0.003 +graphic: 0.003 +permissions: 0.002 +mistranslation: 0.002 + +it always create sdx device when I configure ide device with hdx name + +I have configured 2 ide disks with name starting with hd, but when the vm boots up, it shows disks whose name starting with sd. + +1. ide disks in vm xml: + + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/data3_raw.qcow2'/> + <target dev='hdc' bus='ide'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/data2.qcow2'/> + <target dev='hdb' bus='ide'/> + </disk> + + +2. in VM: + +sda 8:0 0 2G 0 disk +sdb 8:16 0 1G 0 disk + + +3. from vm.log: + +le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev t + + +4. rpm info: (I got the same issue on 2 diff envs) +(1) env1 +qemu-kvm-1.5.3-105 +libvirt-3.2.0-14.el7 +(2) env2 +libvirt-5.9.0-1.el8 +qemu-4.1.0-1.el8 + +On 6/6/20 5:50 AM, marshell wrote: +> Public bug reported: +> +> I have configured 2 ide disks with name starting with hd, but when the +> vm boots up, it shows disks whose name starting with sd. + +This looks more like a libvirt question than a qemu one. + +> +> 1. ide disks in vm xml: +> +> <disk type='file' device='disk'> +> <driver name='qemu' type='raw'/> +> <source file='/data3_raw.qcow2'/> +> <target dev='hdc' bus='ide'/> +> </disk> +> <disk type='file' device='disk'> +> <driver name='qemu' type='qcow2'/> +> <source file='/data2.qcow2'/> +> <target dev='hdb' bus='ide'/> +> </disk> + +The name that libvirt chooses to identify disks from the host +perspective is independent... + +> +> +> 2. in VM: +> +> sda 8:0 0 2G 0 disk +> sdb 8:16 0 1G 0 disk + +...from what the guest OS chooses to use. Although there are many +situations where a Linux guest will pick the same names as libvirt chose +on the host side based on the transport (such as SCSI or virtio), there +is no guarantee that this is always the case, nor that your guest is +always running Linux as its OS. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Thanks a lot for the reply. + + +But from the cmdline of qemu, we can see as following, libvirt passed "-device" option with "ide-hd, bus=ide.0" to qemu. I am wondering why qemu received this option, but it is still dealing it as scsi bus device instead of ide bus device, since with "lssci" cmd, we can see the ide disk we configured in xml. + +>3. from vm.log: + +>le=/data2.qcow2,format=qcow2,if=none,id=drive-ide0-0-1 -device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 >-drive file=/data3_raw.qcow2,format=raw,if=none,id=drive-ide0-1-0 -device ide-hd,bus=ide.1,unit=0,drive=drive-ide0-1->0,id=ide0-1-0 -netdev t + +Which kernel / linux distro are you using in the guest? Can you spot something related in the output of "dmesg" in the guest? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1883784 b/results/classifier/118/review/1883784 new file mode 100644 index 000000000..2064d8b79 --- /dev/null +++ b/results/classifier/118/review/1883784 @@ -0,0 +1,108 @@ +assembly: 0.972 +architecture: 0.946 +ppc: 0.940 +performance: 0.917 +graphic: 0.881 +user-level: 0.819 +semantic: 0.818 +risc-v: 0.760 +peripherals: 0.747 +files: 0.736 +permissions: 0.724 +device: 0.696 +TCG: 0.659 +register: 0.655 +PID: 0.654 +mistranslation: 0.631 +VMM: 0.627 +network: 0.625 +hypervisor: 0.601 +kernel: 0.584 +KVM: 0.570 +debug: 0.566 +vnc: 0.551 +arm: 0.536 +boot: 0.516 +x86: 0.495 +i386: 0.490 +socket: 0.469 +virtual: 0.406 +-------------------- +ppc: 0.475 +hypervisor: 0.077 +virtual: 0.066 +TCG: 0.045 +files: 0.042 +user-level: 0.032 +debug: 0.028 +semantic: 0.013 +assembly: 0.012 +PID: 0.012 +performance: 0.007 +kernel: 0.007 +network: 0.007 +device: 0.005 +boot: 0.005 +architecture: 0.004 +register: 0.004 +risc-v: 0.003 +peripherals: 0.002 +arm: 0.002 +vnc: 0.002 +socket: 0.002 +permissions: 0.002 +graphic: 0.001 +VMM: 0.001 +x86: 0.001 +mistranslation: 0.001 +KVM: 0.000 +i386: 0.000 + +[ppc64le] qemu behavior differs from ppc64le hardware + +I have some code which passes my test suite on PPC64LE hardware when compiled with GCC 10, but the saem binary fails with both qemu-ppc64le 4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing). + +I'm not getting any errors about illegal instructions or anything, like that; the results are just silently different on qemu. + +I've generated a reduced test case, which is attached along with the binaries (both are the same code, one is just statically linked). They should execute successufully on PPC64LE hardware, but on qemu they hit a __builtin_abort (because the computed value doesn't match the expected value). + +Without being familiar with PPC assembly I'm not sure what else I can do, but if there is anything please let me know. + + + +Did you try to run it in a qemu-system-ppc64 guest? +It would help to know if it is a tcg or a linux-user bug. + +I just ran the provided binaries on a qemu-system-ppc64 version 5.0-5 from Debian Bullseye and they also aborted there + +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 older bugs 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/review/1884507 b/results/classifier/118/review/1884507 new file mode 100644 index 000000000..ce82b8ae7 --- /dev/null +++ b/results/classifier/118/review/1884507 @@ -0,0 +1,96 @@ +mistranslation: 0.890 +semantic: 0.875 +peripherals: 0.798 +device: 0.636 +performance: 0.478 +graphic: 0.469 +user-level: 0.444 +ppc: 0.383 +PID: 0.343 +virtual: 0.329 +kernel: 0.303 +x86: 0.290 +architecture: 0.283 +boot: 0.282 +hypervisor: 0.276 +vnc: 0.258 +register: 0.240 +permissions: 0.230 +risc-v: 0.224 +i386: 0.210 +debug: 0.207 +network: 0.202 +TCG: 0.198 +arm: 0.196 +socket: 0.196 +assembly: 0.194 +VMM: 0.159 +KVM: 0.139 +files: 0.092 +-------------------- +semantic: 0.348 +user-level: 0.320 +hypervisor: 0.319 +kernel: 0.282 +x86: 0.272 +virtual: 0.225 +TCG: 0.187 +VMM: 0.070 +KVM: 0.067 +risc-v: 0.051 +arm: 0.044 +debug: 0.036 +boot: 0.028 +i386: 0.025 +files: 0.019 +device: 0.016 +PID: 0.013 +architecture: 0.011 +ppc: 0.010 +register: 0.009 +socket: 0.006 +vnc: 0.005 +peripherals: 0.004 +performance: 0.004 +graphic: 0.003 +network: 0.003 +permissions: 0.002 +assembly: 0.001 +mistranslation: 0.001 + +'none' machine should use 'none' display option + +As the 'none' machine doesn't have any peripheral (except CPU cores) +it is pointless to start a display. + +'-M none' should imply '-display none'. + +Could be as simple as setting MachineClass->default_display = "none" ... have you tried whether that's working as expected? + +Actually, thinking about this twice, I think you made a wrong assumption here. "-display" is about the GUI backend that should be used. "-M" is about the emulated hardware. The emulated hardware options should never influence the host backend options. And it is e.g. perfectly valid to use the "none" machine as CPU instruction simulator in a GTK window, so it does not make sense to force the disablement the GUI in that case. + +> I think you made a wrong assumption here. "-display" is +> about the GUI backend that should be used. "-M" is about +> the emulated hardware. The emulated hardware options +> should never influence the host backend options. + +Aright. What confuses me is having serial0/parallel0 chardevs +initialized when using the none-machine. I realized when +looking at your suggestion in comment #1 that the chardevs +(among other hardware related things) are initialized in +qemu_init(). + +I started testing using: + + bool is_none_machine = !strcmp(machine_class->name, + MACHINE_TYPE_NAME("none")); + +and disabling blocks of code with: + + if (!is_none_machine) { + ... + } + +then planned to update this ticket description but you beat +me. I'll open a different issue. + diff --git a/results/classifier/118/review/1884719 b/results/classifier/118/review/1884719 new file mode 100644 index 000000000..dd0dafe71 --- /dev/null +++ b/results/classifier/118/review/1884719 @@ -0,0 +1,640 @@ +user-level: 0.923 +risc-v: 0.905 +register: 0.851 +hypervisor: 0.851 +mistranslation: 0.845 +peripherals: 0.792 +permissions: 0.772 +architecture: 0.742 +PID: 0.737 +device: 0.736 +ppc: 0.729 +assembly: 0.716 +x86: 0.716 +graphic: 0.713 +performance: 0.688 +arm: 0.686 +TCG: 0.638 +virtual: 0.632 +semantic: 0.626 +vnc: 0.550 +files: 0.524 +VMM: 0.503 +boot: 0.462 +debug: 0.430 +KVM: 0.388 +network: 0.358 +socket: 0.352 +kernel: 0.243 +i386: 0.172 +-------------------- +user-level: 0.707 +virtual: 0.575 +architecture: 0.051 +arm: 0.019 +x86: 0.015 +TCG: 0.014 +files: 0.014 +debug: 0.012 +hypervisor: 0.010 +PID: 0.010 +kernel: 0.010 +semantic: 0.008 +network: 0.006 +device: 0.005 +performance: 0.005 +register: 0.004 +risc-v: 0.004 +boot: 0.003 +socket: 0.003 +peripherals: 0.003 +VMM: 0.002 +graphic: 0.002 +permissions: 0.002 +vnc: 0.002 +mistranslation: 0.001 +KVM: 0.001 +i386: 0.001 +assembly: 0.001 +ppc: 0.001 + +Function not implemented when using libaio + +Hello + +I experience "Function not implemented" errors when trying to use Linux libaio library in foreign architecture, e.g. aarch64. + +I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! + + +Here are the steps to reproduce the issue: + +1) On x86_64 machine register QEMU: + + `docker run -it --rm --privileged multiarch/qemu-user-static --reset --credential yes --persistent yes` + +2) Start a Docker image with foreign CPU architecture, e.g. aarch64 + + `docker run -it arm64v8/centos:8 bash` + +3) Inside the Docker container install GCC and libaio + + `yum install gcc libaio libaio-devel` + +4) Compile the following C program + +``` +#include <stdio.h> +#include <errno.h> +#include <libaio.h> +#include <stdlib.h> + +struct io_control { + io_context_t ioContext; +}; + +int main() { + int queueSize = 10; + + struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); + if (theControl == NULL) { + printf("theControl is NULL"); + return 123; + } + + int res = io_queue_init(queueSize, &theControl->ioContext); + io_queue_release(theControl->ioContext); + free(theControl); + printf("res is: %d", res); +} +``` + + ``` + cat > test.c + [PASTE THE CODE ABOVE HERE] + ^D + ``` + + `gcc test.c -o out -laio && ./out` + + +When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. + +But when executed on Docker image with foreign/emulated CPU architecture it prints `res is: -38` (ENOSYS). `man io_queue_init` says that error ENOSYS is returned when "Not implemented." + +Environment: + +QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +Container application: Docker +Output of `docker --version`: + +``` +Client: + Version: 19.03.8 + API version: 1.40 + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 23:42:35 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: + Engine: + Version: 19.03.8 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 22:48:33 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.3.3-0ubuntu2 + GitCommit: + runc: + Version: spec: 1.0.1-dev + GitCommit: + docker-init: + Version: 0.18.0 + GitCommit: +``` + +Same happens with Ubuntu (arm64v8/ubuntu:focal). + +I've tried to `strace` it but : + +``` +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +/usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +/usr/bin/strace: detach: waitpid(112): No child processes +/usr/bin/strace: Process 112 detached +``` + +Here are the steps to reproduce the problem with strace: + + ``` + docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash + + yum install -y strace` + + strace echo Test + ``` + +Note: I used --privileged, disabled seccomp and apparmor, and added all capabilities + +Disabling security solves the "Permission denied" problem but then comes the "Not implemented" one. + + +Any idea what could be the problem and how to work it around ? +I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. + +Thank you! +Martin + +On Tue, Jun 23, 2020 at 07:39:58AM -0000, Martin Grigorov wrote: +> Public bug reported: + +CCing Filip and Laurent, who may be interested in adding Linux AIO +syscalls to qemu-user. + +> +> Hello +> +> I experience "Function not implemented" errors when trying to use Linux +> libaio library in foreign architecture, e.g. aarch64. +> +> I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +> I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! +> +> +> Here are the steps to reproduce the issue: +> +> 1) On x86_64 machine register QEMU: +> +> `docker run -it --rm --privileged multiarch/qemu-user-static --reset +> --credential yes --persistent yes` +> +> 2) Start a Docker image with foreign CPU architecture, e.g. aarch64 +> +> `docker run -it arm64v8/centos:8 bash` +> +> 3) Inside the Docker container install GCC and libaio +> +> `yum install gcc libaio libaio-devel` +> +> 4) Compile the following C program +> +> ``` +> #include <stdio.h> +> #include <errno.h> +> #include <libaio.h> +> #include <stdlib.h> +> +> struct io_control { +> io_context_t ioContext; +> }; +> +> int main() { +> int queueSize = 10; +> +> struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); +> if (theControl == NULL) { +> printf("theControl is NULL"); +> return 123; +> } +> +> int res = io_queue_init(queueSize, &theControl->ioContext); +> io_queue_release(theControl->ioContext); +> free(theControl); +> printf("res is: %d", res); +> } +> ``` +> +> ``` +> cat > test.c +> [PASTE THE CODE ABOVE HERE] +> ^D +> ``` +> +> `gcc test.c -o out -laio && ./out` +> +> +> When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. +> +> But when executed on Docker image with foreign/emulated CPU architecture +> it prints `res is: -38` (ENOSYS). `man io_queue_init` says that error +> ENOSYS is returned when "Not implemented." +> +> Environment: +> +> QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +> Container application: Docker +> Output of `docker --version`: +> +> ``` +> Client: +> Version: 19.03.8 +> API version: 1.40 +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 23:42:35 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> +> Server: +> Engine: +> Version: 19.03.8 +> API version: 1.40 (minimum version 1.12) +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 22:48:33 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> containerd: +> Version: 1.3.3-0ubuntu2 +> GitCommit: +> runc: +> Version: spec: 1.0.1-dev +> GitCommit: +> docker-init: +> Version: 0.18.0 +> GitCommit: +> ``` +> +> Same happens with Ubuntu (arm64v8/ubuntu:focal). +> +> I've tried to `strace` it but : +> +> ``` +> /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +> /usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +> /usr/bin/strace: detach: waitpid(112): No child processes +> /usr/bin/strace: Process 112 detached +> ``` +> +> Here are the steps to reproduce the problem with strace: +> +> ``` +> docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash +> +> yum install -y strace` +> +> strace echo Test +> ``` +> +> Note: I used --privileged, disabled seccomp and apparmor, and added all +> capabilities +> +> Disabling security solves the "Permission denied" problem but then comes +> the "Not implemented" one. +> +> +> Any idea what could be the problem and how to work it around ? +> I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. +> +> Thank you! +> Martin +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1884719 +> +> Title: +> Function not implemented when using libaio +> +> Status in QEMU: +> New +> +> Bug description: +> Hello +> +> I experience "Function not implemented" errors when trying to use +> Linux libaio library in foreign architecture, e.g. aarch64. +> +> I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +> I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! +> +> +> Here are the steps to reproduce the issue: +> +> 1) On x86_64 machine register QEMU: +> +> `docker run -it --rm --privileged multiarch/qemu-user-static +> --reset --credential yes --persistent yes` +> +> 2) Start a Docker image with foreign CPU architecture, e.g. aarch64 +> +> `docker run -it arm64v8/centos:8 bash` +> +> 3) Inside the Docker container install GCC and libaio +> +> `yum install gcc libaio libaio-devel` +> +> 4) Compile the following C program +> +> ``` +> #include <stdio.h> +> #include <errno.h> +> #include <libaio.h> +> #include <stdlib.h> +> +> struct io_control { +> io_context_t ioContext; +> }; +> +> int main() { +> int queueSize = 10; +> +> struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); +> if (theControl == NULL) { +> printf("theControl is NULL"); +> return 123; +> } +> +> int res = io_queue_init(queueSize, &theControl->ioContext); +> io_queue_release(theControl->ioContext); +> free(theControl); +> printf("res is: %d", res); +> } +> ``` +> +> ``` +> cat > test.c +> [PASTE THE CODE ABOVE HERE] +> ^D +> ``` +> +> `gcc test.c -o out -laio && ./out` +> +> +> When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. +> +> But when executed on Docker image with foreign/emulated CPU +> architecture it prints `res is: -38` (ENOSYS). `man io_queue_init` +> says that error ENOSYS is returned when "Not implemented." +> +> Environment: +> +> QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +> Container application: Docker +> Output of `docker --version`: +> +> ``` +> Client: +> Version: 19.03.8 +> API version: 1.40 +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 23:42:35 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> +> Server: +> Engine: +> Version: 19.03.8 +> API version: 1.40 (minimum version 1.12) +> Go version: go1.13.8 +> Git commit: afacb8b7f0 +> Built: Wed Mar 11 22:48:33 2020 +> OS/Arch: linux/amd64 +> Experimental: false +> containerd: +> Version: 1.3.3-0ubuntu2 +> GitCommit: +> runc: +> Version: spec: 1.0.1-dev +> GitCommit: +> docker-init: +> Version: 0.18.0 +> GitCommit: +> ``` +> +> Same happens with Ubuntu (arm64v8/ubuntu:focal). +> +> I've tried to `strace` it but : +> +> ``` +> /usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +> /usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +> /usr/bin/strace: detach: waitpid(112): No child processes +> /usr/bin/strace: Process 112 detached +> ``` +> +> Here are the steps to reproduce the problem with strace: +> +> ``` +> docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash +> +> yum install -y strace` +> +> strace echo Test +> ``` +> +> Note: I used --privileged, disabled seccomp and apparmor, and added +> all capabilities +> +> Disabling security solves the "Permission denied" problem but then +> comes the "Not implemented" one. +> +> +> Any idea what could be the problem and how to work it around ? +> I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. +> +> Thank you! +> Martin +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1884719/+subscriptions +> + + +ptrace() is not implemented, + +it's why we use gdb server rather than gdb and we use QEMU_STRACE variable rather than strace command. + +You can test it works with: + + QEMU_STRACE= bash -c "echo Test" + +Could you try to execute your test program with it: + + QEMU_STRACE= ./out + + + +The not-implemented syscalls are: + +... +276 io_setup(10,274877981280,33,274877981296,274877981280,274877981184) = -1 errno=38 (Function not implemented) +276 io_destroy(0,274877981280,33,274877981296,274877981280,274877981184) = -1 errno=38 (Function not implemented) +... + +Executing `QEMU_STRACE= ./out` here gives: + + +259 brk(NULL) = 0x0000000000421000 +259 uname(0x40008003d8) = 0 +259 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,AT_SYMLINK_NOFOLLOW|0x50) = -1 errno=2 (No such file or directory) +259 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3 +259 fstat(3,0x00000040007ff960) = 0 +259 mmap(NULL,13646,PROT_READ,MAP_PRIVATE,3,0) = 0x0000004000843000 +259 close(3) = 0 +259 openat(AT_FDCWD,"/lib64/libaio.so.1",O_RDONLY|O_CLOEXEC) = 3 +259 read(3,0x7ffb20,832) = 832 +259 fstat(3,0x00000040007ff9b0) = 0 +259 mmap(NULL,131096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x0000004000847000 +259 mprotect(0x0000004000849000,118784,PROT_NONE) = 0 +259 mmap(0x0000004000866000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x0000004000866000 +259 mmap(0x0000004000867000,24,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x0000004000867000 +259 close(3) = 0 +259 openat(AT_FDCWD,"/lib64/libc.so.6",O_RDONLY|O_CLOEXEC) = 3 +259 read(3,0x7ffb00,832) = 832 +259 fstat(3,0x00000040007ff990) = 0 +259 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000004000868000 +259 mmap(NULL,1527680,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x000000400086a000 +259 mprotect(0x00000040009c3000,77824,PROT_NONE) = 0 +259 mmap(0x00000040009d6000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x15c000) = 0x00000040009d6000 +259 mmap(0x00000040009dc000,12160,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x00000040009dc000 +259 close(3) = 0 +259 mprotect(0x00000040009d6000,16384,PROT_READ) = 0 +259 mprotect(0x0000004000866000,4096,PROT_READ) = 0 +259 mprotect(0x000000000041f000,4096,PROT_READ) = 0 +259 mprotect(0x0000004000840000,4096,PROT_READ) = 0 +259 munmap(0x0000004000843000,13646) = 0 +259 brk(NULL) = 0x0000000000421000 +259 brk(0x0000000000442000) = 0x0000000000442000 +259 brk(NULL) = 0x0000000000442000 +259 io_setup(10,4330144,4330160,4330144,274886726560,511) = -1 errno=38 (Function not implemented) +259 io_destroy(0,274886726560,38,274886726560,511,512) = -1 errno=38 (Function not implemented) +259 fstat(1,0x0000004000800388) = 0 +259 write(1,0x4212c0,11)res is: -38 = 11 +259 exit_group(0) + + +Thanks for looking into this issue, Laurent Vivier! + + + +Could I help somehow to resolve this issue ? + +Martin, + +do you want to propose some patches to fix the problem? + +Thanks + +Laurent, + +I am not familiar with the internals of QEMU but if you point me to the source code of similar functionality I could try! + +Thanks! + +Martin, + +after a first look, I can see that asynchronicity introduces more complexity in QEMU than usual ... + +I'm going to try to write the patches. I will ask you some help to test them. + +I've already implemented io_setup and io_destroy, but io_submit introduces more complexity because we can only cleanup qemu internal buffers when the I/O are done. To do that we need to intercept events at io_getevents level. + + +I will push my patches here: + +https://github.com/vivier/qemu/commits/linux-user-libaio + +Thank you for working on this, Laurent! +Just let me know and I will test your changes! + +Hey Laurent! + +I know it is the summer holidays season! +I just wanted to ask you whether I should test your branch or you have more planned work ? + + + +The code in my branch has two problems: + +- it doesn't work if the host is 64bit and the target 32bit (because the context id returned by the host is in fact a virtual address and the data type is long, so the context_id (host long) doesn't fit in target context_id (target long). + +- I played with some stress tests and at some points it crashes. + +I don't have enough time to work on this for the moment. + +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 older bugs 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. + + +Bug has been re-opened here: +https://gitlab.com/qemu-project/qemu/-/issues/210 +Thanks for copying it over, Martin! + diff --git a/results/classifier/118/review/1885719 b/results/classifier/118/review/1885719 new file mode 100644 index 000000000..a082376ba --- /dev/null +++ b/results/classifier/118/review/1885719 @@ -0,0 +1,88 @@ +mistranslation: 0.922 +socket: 0.913 +register: 0.892 +network: 0.868 +graphic: 0.845 +kernel: 0.831 +semantic: 0.790 +device: 0.760 +ppc: 0.749 +arm: 0.712 +virtual: 0.706 +architecture: 0.683 +permissions: 0.657 +vnc: 0.637 +files: 0.624 +PID: 0.607 +debug: 0.558 +assembly: 0.525 +risc-v: 0.522 +x86: 0.509 +performance: 0.457 +VMM: 0.418 +i386: 0.385 +boot: 0.343 +TCG: 0.301 +KVM: 0.280 +hypervisor: 0.234 +peripherals: 0.161 +user-level: 0.101 +-------------------- +debug: 0.690 +x86: 0.622 +TCG: 0.228 +files: 0.132 +risc-v: 0.043 +kernel: 0.035 +virtual: 0.034 +PID: 0.023 +hypervisor: 0.023 +arm: 0.017 +semantic: 0.013 +device: 0.011 +register: 0.011 +ppc: 0.008 +user-level: 0.008 +i386: 0.007 +boot: 0.003 +network: 0.003 +socket: 0.002 +VMM: 0.002 +permissions: 0.002 +architecture: 0.002 +performance: 0.002 +vnc: 0.002 +assembly: 0.001 +peripherals: 0.001 +graphic: 0.001 +KVM: 0.000 +mistranslation: 0.000 + +qemu/target/nios2/helper.c:261:20: style:inconclusive: Found duplicate branches for 'if' and 'else' + +Source code is + + } else if (address >= 0x80000000) { + /* Kernel virtual page */ + return cpu_nios2_handle_virtual_page(cs, address, rw, mmu_idx); + } else { + /* User virtual page */ + return cpu_nios2_handle_virtual_page(cs, address, rw, mmu_idx); + } + +Which version of QEMU did you use here? Apparently it was an older version, since that code has been removed more than a year ago already: + + https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0137c93ff8cbcebf + +Please make sure to use the latest release of QEMU when reporting bugs. Thanks! + +>Which version of QEMU did you use here? + +git trunk. I have no idea why Richard's patch isn't in my current version +and I am disinclined to find out why. + +Any further work by me on qemu looks somewhat doubtful. Have fun ! + + + + diff --git a/results/classifier/118/review/1886076 b/results/classifier/118/review/1886076 new file mode 100644 index 000000000..e72838652 --- /dev/null +++ b/results/classifier/118/review/1886076 @@ -0,0 +1,112 @@ +risc-v: 0.963 +ppc: 0.894 +performance: 0.877 +architecture: 0.877 +device: 0.849 +vnc: 0.847 +PID: 0.822 +graphic: 0.810 +VMM: 0.781 +semantic: 0.764 +kernel: 0.749 +register: 0.748 +files: 0.745 +hypervisor: 0.728 +peripherals: 0.722 +user-level: 0.719 +socket: 0.714 +permissions: 0.713 +arm: 0.674 +x86: 0.652 +network: 0.650 +boot: 0.641 +assembly: 0.566 +i386: 0.548 +TCG: 0.540 +debug: 0.517 +KVM: 0.517 +virtual: 0.482 +mistranslation: 0.442 +-------------------- +risc-v: 0.767 +assembly: 0.706 +permissions: 0.184 +debug: 0.096 +files: 0.075 +kernel: 0.039 +virtual: 0.039 +performance: 0.029 +register: 0.022 +TCG: 0.021 +architecture: 0.019 +VMM: 0.018 +PID: 0.012 +semantic: 0.011 +hypervisor: 0.010 +user-level: 0.007 +device: 0.007 +vnc: 0.005 +boot: 0.004 +socket: 0.003 +peripherals: 0.002 +mistranslation: 0.001 +graphic: 0.001 +network: 0.001 +KVM: 0.001 +i386: 0.001 +ppc: 0.000 +x86: 0.000 +arm: 0.000 + +risc-v pmp implementation error + +QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab + + +RISC-V PMP implementation is not correct on QEMU. + +When an access is granted there is no more PMP check on the 4KB memory range of the accessed location. +A cache flush is needed in order to force a PMP check on next access to this 4KB memory range. +A correct implementation would be to grant access to the maximum allowed area around the accessed location within the 4KB memory range. + +For instance, if PMP is configured to block all accesses from 0x80003000 to 0x800037FF and from 0x80003C00 to 0x80003FFF: +1st case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Then a read access is done @0x80003400 --> access OK while it must be blocked! +2nd case: + 1) A read access is done @0x80003900 --> access OK as expected + 2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");) + 3) A read access is done @0x80003400 --> access blocked as expected + +Analysis: + After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to 0x80003FFF into a TLB entry. + Then no more PMP check is done from 0x80003000 to 0x80003FFF until the TLB is flushed. +What should be done: + Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry. + +The 4KB range is the default size of a TLB page on QEMU for RISCV. +The minimum size that can be set is 64Bytes. However the PMP granularity can be as low as 4Bytes. + +I tested a quick fix and PMP is working as expected. +The quick fix consist in replacing this line: +tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot, mmu_idx, TARGET_PAGE_SIZE); +By this one in target/riscv/cpu_helper.c: +tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size); + +This quick fix has to be optimized in order to consume less HW resources, as explained at the beginning. + + + +Nicolas, + +to be reviewed your patch must be sent to <email address hidden> + +This should be fixed once the current RISC-V branch is merged into master. + +You can see the patch that fixes this here: https://<email address hidden><email address hidden>/ + +I'm marking this as fix committed, although the fix isn't yet in master it's in the RISC-V tree and will be in master soon. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/af3fc195e3c8e98b + diff --git a/results/classifier/118/review/1886225 b/results/classifier/118/review/1886225 new file mode 100644 index 000000000..6a3c1bbff --- /dev/null +++ b/results/classifier/118/review/1886225 @@ -0,0 +1,81 @@ +i386: 0.940 +architecture: 0.905 +virtual: 0.872 +graphic: 0.864 +mistranslation: 0.852 +device: 0.811 +user-level: 0.808 +semantic: 0.766 +network: 0.750 +x86: 0.724 +VMM: 0.713 +performance: 0.711 +arm: 0.706 +hypervisor: 0.705 +files: 0.687 +vnc: 0.670 +risc-v: 0.665 +PID: 0.656 +ppc: 0.647 +register: 0.645 +kernel: 0.623 +permissions: 0.590 +socket: 0.588 +TCG: 0.585 +boot: 0.567 +debug: 0.520 +assembly: 0.509 +peripherals: 0.449 +KVM: 0.323 +-------------------- +virtual: 0.983 +x86: 0.586 +i386: 0.123 +files: 0.064 +hypervisor: 0.027 +TCG: 0.027 +user-level: 0.021 +VMM: 0.018 +network: 0.015 +semantic: 0.010 +kernel: 0.009 +KVM: 0.008 +PID: 0.008 +debug: 0.005 +permissions: 0.004 +boot: 0.004 +register: 0.003 +socket: 0.002 +architecture: 0.002 +device: 0.002 +ppc: 0.002 +assembly: 0.001 +graphic: 0.001 +peripherals: 0.001 +risc-v: 0.001 +performance: 0.001 +arm: 0.001 +vnc: 0.000 +mistranslation: 0.000 + +[Feature request] Oracle Solaris 11.4 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 + +Some people have interest in building QEMU on Solaris: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg01429.html + +To help them it would be useful to have a Solaris VM. + +Solaris is not open anymore, so I don't think that you can get a distributable VM so easily. + +I'm closing this since it's very unlikely that we get a Solaris VM image, since they are not available for free, as far as I know. Maybe somebody could contribute an illumos-based image one day, but that's nothing that we have to track in the bug tracker, I think. + diff --git a/results/classifier/118/review/1886811 b/results/classifier/118/review/1886811 new file mode 100644 index 000000000..6e33fd862 --- /dev/null +++ b/results/classifier/118/review/1886811 @@ -0,0 +1,144 @@ +user-level: 0.866 +architecture: 0.842 +register: 0.838 +risc-v: 0.820 +device: 0.813 +virtual: 0.802 +mistranslation: 0.800 +graphic: 0.799 +assembly: 0.797 +semantic: 0.795 +peripherals: 0.784 +performance: 0.783 +PID: 0.783 +files: 0.780 +ppc: 0.779 +network: 0.776 +arm: 0.774 +permissions: 0.769 +boot: 0.763 +KVM: 0.762 +debug: 0.758 +VMM: 0.746 +vnc: 0.740 +socket: 0.731 +TCG: 0.731 +x86: 0.727 +kernel: 0.702 +hypervisor: 0.675 +i386: 0.619 +-------------------- +arm: 0.878 +kernel: 0.660 +hypervisor: 0.403 +virtual: 0.132 +debug: 0.101 +files: 0.054 +architecture: 0.045 +boot: 0.042 +PID: 0.026 +TCG: 0.014 +ppc: 0.013 +user-level: 0.010 +register: 0.010 +device: 0.007 +semantic: 0.006 +socket: 0.005 +network: 0.005 +performance: 0.004 +assembly: 0.002 +peripherals: 0.002 +permissions: 0.002 +VMM: 0.002 +vnc: 0.002 +graphic: 0.001 +x86: 0.001 +mistranslation: 0.001 +risc-v: 0.000 +KVM: 0.000 +i386: 0.000 + +systemd complains Failed to enqueue loopback interface start request: Operation not supported + +This symptom seems similar to +https://bugs.launchpad.net/qemu/+bug/1823790 + +Host Linux: Debian 11 Bullseye (testing) on x84-64 architecture +qemu version: latest git of git commit hash eb2c66b10efd2b914b56b20ae90655914310c925 +compiled with "./configure --static --disable-system" + +Down stream bug report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964289 +Bug report (closed) to systemd: https://github.com/systemd/systemd/issues/16359 + +systemd in armhf and armel (both little endian 32-bit) containers fail to start with +Failed to enqueue loopback interface start request: Operation not supported + +How to reproduce on Debian (and probably Ubuntu): +mmdebstrap --components="main contrib non-free" --architectures=armhf --variant=important bullseye /var/lib/machines/armhf-bullseye +systemd-nspawn -D /var/lib/machines/armhf-bullseye -b + +When "armhf" architecture is replaced with "mips" (32-bit big endian) or "ppc64" +(64-bit big endian), the container starts up fine. + +The same symptom is also observed with "powerpc" (32-bit big endian) architecture. + +It would help to know which operation is not supported. + +Could you get the coredump? +Is it possible to run the operation with "QEMU_STRACE" set in the environment? +Normally loop ioctls are supported. + +But it seems the following ones are not implemented in QEMU: LOOP_SET_CAPACITY, LOOP_SET_DIRECT_IO, LOOP_SET_BLOCK_SIZE. + +It seems systemd is trying to use RTM_SETLINK. + +Could you try this patch: + +diff --git a/linux-user/fd-trans.c b/linux-user/fd-trans.c +index c0687c52e62b..b09b5b7c13e0 100644 +--- a/linux-user/fd-trans.c ++++ b/linux-user/fd-trans.c +@@ -1200,6 +1200,7 @@ static abi_long target_to_host_data_route(struct nlmsghdr *nlh) + break; + case RTM_NEWLINK: + case RTM_DELLINK: ++ case RTM_SETLINK: + if (nlh->nlmsg_len >= NLMSG_LENGTH(sizeof(*ifi))) { + ifi = NLMSG_DATA(nlh); + ifi->ifi_type = tswap16(ifi->ifi_type); + + +> It seems systemd is trying to use RTM_SETLINK. +> Could you try this patch: + +Yes, you are right! +With the patch, I am able to boot containers of +Debian Bullseye of armhf and armel architectures!! + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1887606 + +Fixed here: + +65b261a63a48 linux-user: add netlink RTM_SETLINK command +https://git.qemu.org/?p=qemu.git;a=commit;h=65b261a63a48fbb3b11193361d4ea0c38a3c3dfd + +qemu (1:5.0-5ubuntu3) groovy; urgency=medium + +has the merge with this fix: + + - linux-user-add-netlink-RTM_SETLINK-command.patch (Closes: #964289) + + +@Ryutaroh - could you test [1] if it gets you around this bug (1886811) and if bug 1890881 is present in focal as well? + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4197 + +To fully work this also needs the fix for bug 1890881 as identified there. + +SRU need the bug 1890881 fix to be really helpful, but the dependency chain of that is not SRUable. +See: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1890881/comments/17 + +Users (of this valid but rare use case) can either use Groovy which will fix this or wait until Openstack Victoria will make it available for Focal via the Ubuntu Cloud Archive [1]. + +[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive + diff --git a/results/classifier/118/review/1887309 b/results/classifier/118/review/1887309 new file mode 100644 index 000000000..5e93ec23e --- /dev/null +++ b/results/classifier/118/review/1887309 @@ -0,0 +1,372 @@ +user-level: 0.839 +mistranslation: 0.711 +peripherals: 0.697 +risc-v: 0.683 +hypervisor: 0.670 +register: 0.667 +virtual: 0.650 +VMM: 0.644 +x86: 0.631 +TCG: 0.622 +KVM: 0.620 +performance: 0.607 +graphic: 0.603 +ppc: 0.602 +device: 0.592 +debug: 0.563 +arm: 0.556 +i386: 0.550 +boot: 0.549 +permissions: 0.532 +vnc: 0.531 +semantic: 0.522 +architecture: 0.496 +assembly: 0.491 +files: 0.484 +PID: 0.471 +socket: 0.437 +kernel: 0.428 +network: 0.406 +-------------------- +i386: 0.999 +x86: 0.997 +debug: 0.792 +kernel: 0.129 +TCG: 0.126 +virtual: 0.102 +user-level: 0.083 +assembly: 0.077 +files: 0.076 +performance: 0.061 +PID: 0.057 +device: 0.049 +hypervisor: 0.040 +register: 0.020 +semantic: 0.019 +VMM: 0.017 +boot: 0.014 +architecture: 0.012 +graphic: 0.007 +KVM: 0.007 +risc-v: 0.006 +socket: 0.006 +peripherals: 0.004 +vnc: 0.004 +ppc: 0.003 +network: 0.003 +permissions: 0.002 +mistranslation: 0.001 +arm: 0.000 + +Floating-point exception in ide_set_sector + +Hello, +Here is a reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ + -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ + -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ + -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ + -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +outw 0x176 0x3538 +outl 0xcf8 0x80000903 +outl 0xcfc 0x184275c +outb 0x376 0x2f +outb 0x376 0x0 +outw 0x176 0xa1a4 +outl 0xcf8 0x80000920 +outb 0xcfc 0xff +outb 0xf8 0x9 +EOF + +The stack-trace: +==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) + #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 + #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 + #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 + #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 + #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 + #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 + #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 + #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 + #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 + #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 + #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) + #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 + #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 + #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 + #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 + #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 + #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) + +With -trace ide* + +12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +[R +0.024963] outw 0x176 0x3538 +12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +OK +[S +0.025002] OK +[R +0.025012] outl 0xcf8 0x80000903 +OK +[S +0.025018] OK +[R +0.025026] outl 0xcfc 0x184275c +OK +[S +0.025210] OK +[R +0.025219] outb 0x376 0x2f +12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +OK +[S +0.025229] OK +[R +0.025234] outb 0x376 0x0 +12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +OK +[S +0.025240] OK +[R +0.025246] outw 0x176 0xa1a4 +12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +OK +[S +0.025265] OK +[R +0.025270] outl 0xcf8 0x80000920 +OK +[S +0.025274] OK +[R +0.025279] outb 0xcfc 0xff +OK +[S +0.025443] OK +[R +0.025451] outb 0xf8 0x9 +12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +OK +[S +0.025724] OK +UndefinedBehaviorSanitizer:DEADLYSIGNAL +==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) + +-Alex + +On 200712 2025, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> Here is a reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ +> -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ +> -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ +> -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ +> -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +> outw 0x176 0x3538 +> outl 0xcf8 0x80000903 +> outl 0xcfc 0x184275c +> outb 0x376 0x2f +> outb 0x376 0x0 +> outw 0x176 0xa1a4 +> outl 0xcf8 0x80000920 +> outb 0xcfc 0xff +> outb 0xf8 0x9 +> EOF +> +> The stack-trace: +> ==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) +> #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 +> #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 +> #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 +> #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 +> #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 +> #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 +> #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 +> #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 +> #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 +> #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 +> #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 +> #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) +> +> With -trace ide* +> +> 12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +> [R +0.024963] outw 0x176 0x3538 +> 12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +> OK +> [S +0.025002] OK +> [R +0.025012] outl 0xcf8 0x80000903 +> OK +> [S +0.025018] OK +> [R +0.025026] outl 0xcfc 0x184275c +> OK +> [S +0.025210] OK +> [R +0.025219] outb 0x376 0x2f +> 12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +> OK +> [S +0.025229] OK +> [R +0.025234] outb 0x376 0x0 +> 12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +> OK +> [S +0.025240] OK +> [R +0.025246] outw 0x176 0xa1a4 +> 12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +> OK +> [S +0.025265] OK +> [R +0.025270] outl 0xcf8 0x80000920 +> OK +> [S +0.025274] OK +> [R +0.025279] outb 0xcfc 0xff +> OK +> [S +0.025443] OK +> [R +0.025451] outb 0xf8 0x9 +> 12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +> OK +> [S +0.025724] OK +> UndefinedBehaviorSanitizer:DEADLYSIGNAL +> ==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) +> +> -Alex +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1887309 +> +> Title: +> Floating-point exception in ide_set_sector +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> Here is a reproducer: +> cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\ +> -qtest null -nographic -vga qxl -qtest stdio -nodefaults\ +> -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\ +> -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\ +> -device ide-cd,drive=drive0 -device ide-hd,drive=drive1 +> outw 0x176 0x3538 +> outl 0xcf8 0x80000903 +> outl 0xcfc 0x184275c +> outb 0x376 0x2f +> outb 0x376 0x0 +> outw 0x176 0xa1a4 +> outl 0xcf8 0x80000920 +> outb 0xcfc 0xff +> outb 0xf8 0x9 +> EOF +> +> The stack-trace: +> ==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513) +> #0 0x556783603fdc in ide_set_sector /home/alxndr/Development/qemu/hw/ide/core.c:626:26 +> #1 0x556783603fdc in ide_dma_cb /home/alxndr/Development/qemu/hw/ide/core.c:883:9 +> #2 0x55678349d74d in dma_complete /home/alxndr/Development/qemu/dma-helpers.c:120:9 +> #3 0x55678349d74d in dma_blk_cb /home/alxndr/Development/qemu/dma-helpers.c:138:9 +> #4 0x556783962f25 in blk_aio_complete /home/alxndr/Development/qemu/block/block-backend.c:1402:9 +> #5 0x556783962f25 in blk_aio_complete_bh /home/alxndr/Development/qemu/block/block-backend.c:1412:5 +> #6 0x556783ac030f in aio_bh_call /home/alxndr/Development/qemu/util/async.c:136:5 +> #7 0x556783ac030f in aio_bh_poll /home/alxndr/Development/qemu/util/async.c:164:13 +> #8 0x556783a9a863 in aio_dispatch /home/alxndr/Development/qemu/util/aio-posix.c:380:5 +> #9 0x556783ac1b4c in aio_ctx_dispatch /home/alxndr/Development/qemu/util/async.c:306:5 +> #10 0x7f4f1c0fe9ed in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed) +> #11 0x556783acdccb in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 +> #12 0x556783acdccb in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 +> #13 0x556783acdccb in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 +> #14 0x5567833613e5 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 +> #15 0x556783a07a4d in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 +> #16 0x7f4f1ac84e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 +> #17 0x5567830a9089 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089) +> + +This adds a check to avoid the FPE, but I don't know how to properly +report the error, and whether this is the correct place to add this +check. + +diff --git a/hw/ide/core.c b/hw/ide/core.c +index d997a78e47..c191d74ca6 100644 +--- a/hw/ide/core.c ++++ b/hw/ide/core.c +@@ -622,7 +622,7 @@ void ide_set_sector(IDEState *s, int64_t sector_num) + s->hob_lcyl = sector_num >> 32; + s->hob_hcyl = sector_num >> 40; + } +- } else { ++ } else if (s->heads && s->sectors){ + cyl = sector_num / (s->heads * s->sectors); + r = sector_num % (s->heads * s->sectors); + s->hcyl = cyl >> 8; + +> With -trace ide* +> +> 12163@1594585516.671265:ide_reset IDEstate 0x56162a269058 +> [R +0.024963] outw 0x176 0x3538 +> 12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a269058; cmd 0x35 +> OK +> [S +0.025002] OK +> [R +0.025012] outl 0xcf8 0x80000903 +> OK +> [S +0.025018] OK +> [R +0.025026] outl 0xcfc 0x184275c +> OK +> [S +0.025210] OK +> [R +0.025219] outb 0x376 0x2f +> 12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x2f; bus 0x56162a268c00 +> OK +> [S +0.025229] OK +> [R +0.025234] outb 0x376 0x0 +> 12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x00; bus 0x56162a268c00 +> OK +> [S +0.025240] OK +> [R +0.025246] outw 0x176 0xa1a4 +> 12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058 +> 12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88 +> 12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 0x56162a268c88; cmd 0xa1 +> OK +> [S +0.025265] OK +> [R +0.025270] outl 0xcf8 0x80000920 +> OK +> [S +0.025274] OK +> [R +0.025279] outb 0xcfc 0xff +> OK +> [S +0.025443] OK +> [R +0.025451] outb 0xf8 0x9 +> 12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 cmd=DMA READ +> OK +> [S +0.025724] OK +> UndefinedBehaviorSanitizer:DEADLYSIGNAL +> ==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163) +> +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1887309/+subscriptions +> + + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05528.html + +New proposal: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg06974.html + +(The root cause is that SRST is not handled correctly.) + +More analysis in the replies to Philippe's patch: https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05949.html + +Merged upstream: + +55adb3c45620c31f29978f209e2a44a08d34e2da +4ac4e7281a2dd1ca5158812198c4d2cbacf2ae25 +b45bcd81e05dea2781f2164ca1c9dd86069502ea +1a9925e3390b6adf1125e3abaa17c80ca012bede + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/review/1887318 b/results/classifier/118/review/1887318 new file mode 100644 index 000000000..cb7cf2801 --- /dev/null +++ b/results/classifier/118/review/1887318 @@ -0,0 +1,144 @@ +mistranslation: 0.915 +performance: 0.804 +semantic: 0.779 +socket: 0.725 +files: 0.719 +device: 0.691 +network: 0.680 +TCG: 0.662 +graphic: 0.652 +user-level: 0.629 +ppc: 0.626 +arm: 0.574 +PID: 0.569 +permissions: 0.554 +architecture: 0.526 +debug: 0.496 +register: 0.447 +vnc: 0.430 +boot: 0.406 +peripherals: 0.404 +kernel: 0.388 +hypervisor: 0.385 +assembly: 0.369 +VMM: 0.340 +risc-v: 0.340 +KVM: 0.267 +virtual: 0.250 +x86: 0.223 +i386: 0.199 +-------------------- +debug: 0.060 +hypervisor: 0.053 +files: 0.049 +network: 0.045 +register: 0.043 +PID: 0.033 +user-level: 0.030 +virtual: 0.027 +TCG: 0.021 +x86: 0.016 +socket: 0.013 +VMM: 0.012 +semantic: 0.011 +device: 0.010 +performance: 0.007 +permissions: 0.007 +boot: 0.006 +risc-v: 0.004 +architecture: 0.004 +vnc: 0.003 +kernel: 0.003 +assembly: 0.002 +peripherals: 0.002 +i386: 0.002 +graphic: 0.001 +ppc: 0.001 +mistranslation: 0.001 +KVM: 0.001 +arm: 0.001 + +impossible to install in OSX Yosemite 10.10.5 + +the Brew method has glib problems, glib is impossible to install. +the MacPorts method has a very long .log file. + + + +console log + +i installed Xcode 6.3 as recommended by MacPorts +"better than 6.1" +for Yosemite + + +https://github.com/Homebrew/brew/issues/7667 + +https://security.stackexchange.com/questions/232445/https-connection-to-specific-sites-fail-with-curl-on-macos + +This is a Cat & Mouse game... +Catch 22... + +its Not a Brew problemm +is Not a glib problem, +is not a git problem, +so we dont care... +its an Apple problem, +Apple does Not care. + +End of Story. + +QEMU only supports the two most recent versions of macOS (see https://www.qemu.org/docs/master/system/build-platforms.html). Support for older versions has been removed (see https://git.qemu.org/?p=qemu.git;a=commitdiff;h=483644c25b93236001), so if you still want to use QEMU on such an old system, you better use an older version of QEMU instead. + + +On Jul 12, 2020, at 10:02 PM, <email address hidden> wrote: + +> Message: 6 +> Date: Mon, 13 Jul 2020 00:17:30 -0000 +> From: JuanPabloCuervo <email address hidden> +> To: <email address hidden> +> Subject: [Bug 1887318] [NEW] impossible to install in OSX Yosemite +> 10.10.5 +> Message-ID: +> +> <<email address hidden> +> al.com> +> +> Content-Type: text/plain; charset="utf-8" +> +> Public bug reported: +> +> the Brew method has glib problems, glib is impossible to install. +> the MacPorts method has a very long .log file. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "main.log" +> https://bugs.launchpad.net/bugs/1887318/+attachment/5392136/ +> +files/main.log +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1887318 +> +> Title: +> impossible to install in OSX Yosemite 10.10.5 +> +> Status in QEMU: +> New +> +> Bug description: +> the Brew method has glib problems, glib is impossible to install. +> the MacPorts method has a very long .log file. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1887318/+subscriptions + +This is why we need installer files for QEMU. They make life so much +easier than building from source. + + + diff --git a/results/classifier/118/review/1887641 b/results/classifier/118/review/1887641 new file mode 100644 index 000000000..715dbedfe --- /dev/null +++ b/results/classifier/118/review/1887641 @@ -0,0 +1,103 @@ +user-level: 0.931 +architecture: 0.919 +boot: 0.905 +register: 0.895 +device: 0.895 +PID: 0.894 +arm: 0.887 +risc-v: 0.885 +permissions: 0.885 +graphic: 0.880 +socket: 0.874 +performance: 0.862 +ppc: 0.859 +assembly: 0.855 +semantic: 0.847 +hypervisor: 0.844 +peripherals: 0.842 +files: 0.837 +debug: 0.820 +network: 0.810 +vnc: 0.806 +TCG: 0.805 +KVM: 0.802 +kernel: 0.790 +VMM: 0.789 +mistranslation: 0.788 +virtual: 0.736 +x86: 0.703 +i386: 0.634 +-------------------- +virtual: 0.918 +boot: 0.790 +ppc: 0.783 +user-level: 0.776 +TCG: 0.587 +hypervisor: 0.410 +register: 0.254 +PID: 0.219 +debug: 0.201 +device: 0.168 +kernel: 0.168 +socket: 0.161 +files: 0.149 +x86: 0.098 +semantic: 0.093 +VMM: 0.052 +peripherals: 0.037 +network: 0.032 +architecture: 0.022 +performance: 0.022 +vnc: 0.019 +risc-v: 0.015 +permissions: 0.011 +assembly: 0.008 +graphic: 0.008 +i386: 0.003 +KVM: 0.003 +mistranslation: 0.002 +arm: 0.001 + +PCI bus not available for hda + +I'm trying to boot Mac OS 9.2.2 image in order to install it on a qcow disk image. I'm using Linux Mint MATE 20 and QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.3). When I boot, I've got this error message and boot fails : + +$ /usr/bin/qemu-system-ppc -monitor stdio -soundhw hda -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -drive file="/home/david/.aqemu/iMacG3_hard_disk_HDA.img",if=ide,index=0 -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99 +QEMU 4.2.0 monitor - type 'help' for more information +(qemu) qemu-system-ppc: PCI bus not available for hda + +MLas OS 9.2.2 ISO is here if you need to test : https://infolib.re/tests/OS9General.iso + +On Wed, 15 Jul 2020, InfoLibre wrote: +> Public bug reported: +> +> I'm trying to boot Mac OS 9.2.2 image in order to install it on a qcow +> disk image. I'm using Linux Mint MATE 20 and QEMU emulator version 4.2.0 +> (Debian 1:4.2-3ubuntu6.3). When I boot, I've got this error message and +> boot fails : +> +> $ /usr/bin/qemu-system-ppc -monitor stdio -soundhw hda -k fr -machine +> accel=tcg -m 512 -cdrom +> /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -drive +> file="/home/david/.aqemu/iMacG3_hard_disk_HDA.img",if=ide,index=0 +> -virtfs +> local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 +> -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 +> -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name +> "Debian + LXDE sur iMac G3" -M mac99 +> QEMU 4.2.0 monitor - type 'help' for more information +> (qemu) qemu-system-ppc: PCI bus not available for hda + +You have several problems in your command line. For one you have -cdrom +debian-10.0.0-powerpc-NETINST-1.iso insead of MacOS-9.2.2.iso but your +problem is the -soundhw hda option. Just remove this as it does not make +sense to add Intel HDA audio to a Macintosh and it won't work. Sound is +not currently supported in QEMU for MacOS guest yet, if you want +experimental build with sound support for running MacOS see forum at +emaculation.com. + + +Sorry, I made a mistake, I'm trying to boot PowerPC Debian edition, not Mac OS 9.2.2. I removed the sound card and it boots now. Thank uou very much for your help. + +How to close this bug report ??? + diff --git a/results/classifier/118/review/1888303 b/results/classifier/118/review/1888303 new file mode 100644 index 000000000..8e51397ac --- /dev/null +++ b/results/classifier/118/review/1888303 @@ -0,0 +1,114 @@ +architecture: 0.833 +performance: 0.711 +kernel: 0.675 +user-level: 0.669 +x86: 0.667 +files: 0.648 +peripherals: 0.633 +socket: 0.629 +permissions: 0.628 +device: 0.625 +arm: 0.615 +network: 0.610 +graphic: 0.599 +debug: 0.595 +virtual: 0.590 +hypervisor: 0.568 +risc-v: 0.559 +semantic: 0.546 +mistranslation: 0.517 +PID: 0.513 +ppc: 0.498 +i386: 0.493 +boot: 0.491 +TCG: 0.479 +vnc: 0.477 +assembly: 0.473 +register: 0.439 +VMM: 0.437 +KVM: 0.418 +-------------------- +debug: 0.919 +x86: 0.200 +user-level: 0.098 +virtual: 0.046 +PID: 0.024 +performance: 0.009 +TCG: 0.009 +register: 0.006 +files: 0.005 +kernel: 0.003 +hypervisor: 0.003 +architecture: 0.003 +semantic: 0.003 +network: 0.002 +device: 0.002 +socket: 0.002 +assembly: 0.001 +VMM: 0.001 +graphic: 0.001 +boot: 0.001 +vnc: 0.001 +peripherals: 0.000 +permissions: 0.000 +arm: 0.000 +mistranslation: 0.000 +risc-v: 0.000 +KVM: 0.000 +ppc: 0.000 +i386: 0.000 + +Intermittent buggines with user mode emulation of x86-64 on aarch64 + +QEMU Version: 5.0.0 +./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static + +Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm + +aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages. + +On aarch64 machine, invoke: + +./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile + +Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data. + +But, about once every 10 times, it will not sefault and will continue working just fine forever. + +The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault. + +This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem. + +As another interesting data point - with dynamically linked qemu-x86_64, when it doesn't work, the process is consuming about 140% of CPU. On a successful run, the process is consuming about 30% of CPU. + +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/review/1888714 b/results/classifier/118/review/1888714 new file mode 100644 index 000000000..b2765e75f --- /dev/null +++ b/results/classifier/118/review/1888714 @@ -0,0 +1,126 @@ +user-level: 0.910 +permissions: 0.881 +virtual: 0.873 +mistranslation: 0.867 +performance: 0.863 +register: 0.861 +graphic: 0.858 +debug: 0.848 +device: 0.841 +files: 0.834 +arm: 0.832 +architecture: 0.830 +peripherals: 0.830 +semantic: 0.829 +assembly: 0.801 +i386: 0.798 +ppc: 0.796 +x86: 0.792 +VMM: 0.788 +TCG: 0.788 +hypervisor: 0.781 +PID: 0.780 +vnc: 0.778 +network: 0.777 +kernel: 0.772 +KVM: 0.763 +boot: 0.759 +socket: 0.757 +risc-v: 0.646 +-------------------- +i386: 0.999 +x86: 0.998 +kernel: 0.675 +user-level: 0.252 +debug: 0.186 +files: 0.177 +performance: 0.035 +assembly: 0.024 +semantic: 0.017 +virtual: 0.016 +register: 0.015 +hypervisor: 0.012 +TCG: 0.008 +PID: 0.007 +ppc: 0.004 +device: 0.004 +KVM: 0.002 +VMM: 0.002 +risc-v: 0.002 +architecture: 0.002 +boot: 0.001 +socket: 0.001 +permissions: 0.001 +network: 0.001 +graphic: 0.001 +peripherals: 0.000 +vnc: 0.000 +mistranslation: 0.000 +arm: 0.000 + +Memory Leak in hpet_timer results in unusable machine + +Fair warning: this might be specific to QTest (specifically its clock_step) command. This reproducer only works with -accel qtest. Build with --enable-sanitizers to exit once we hit 1G RSS. + +export ASAN_OPTIONS=hard_rss_limit_mb=1000 +cat << EOF | ./i386-softmmu/qemu-system-i386 -nographic \ +-nodefaults -qtest stdio -accel qtest +writeq 0xfed0000e 0x15151515151515f1 +clock_step +clock_step +clock_step +clock_step +writeq 0xfed00100 0x5e90c5be00ff5e9e +writeq 0xfed00109 0xffffe0ff5cfec0ff +clock_step +EOF + +On my machine it takes around 10 seconds to reach the RSS limit. + +Unfortunately, I can't find a way to tell ASAN to log each malloc to figure out whats going on, but running the original fuzzing test case with the libfuzzer -trace_malloc=2 flag, I found that the allocations happen here: + +MALLOC[130968] 0x60300069ac90 32 + #0 0x55fa3f615851 in __sanitizer_print_stack_trace (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2683851) + #1 0x55fa3f55fe88 in fuzzer::PrintStackTrace() (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x25cde88) + #2 0x55fa3f5447d6 in fuzzer::MallocHook(void const volatile*, unsigned long) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x25b27d6) + #3 0x55fa3f61bbb7 in __sanitizer::RunMallocHooks(void const*, unsigned long) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2689bb7) + #4 0x55fa3f596d75 in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2604d75) + #5 0x55fa3f596f7a in __asan::asan_calloc(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*) (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x2604f7a) + #6 0x55fa3f60d173 in calloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-fuzz-i386+0x267b173) + #7 0x7fb300737548 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54548) + #8 0x55fa40157689 in async_run_on_cpu /home/alxndr/Development/qemu/cpus-common.c:163:10 + #9 0x55fa409fab83 in hpet_timer /home/alxndr/Development/qemu/hw/timer/hpet.c:376:9 + #10 0x55fa416a5751 in timerlist_run_timers /home/alxndr/Development/qemu/util/qemu-timer.c:572:9 + #11 0x55fa3fcfdac4 in qtest_clock_warp /home/alxndr/Development/qemu/softmmu/cpus.c:507:9 + #12 0x55fa3fd65c35 in qtest_process_command /home/alxndr/Development/qemu/softmmu/qtest.c:665:9 + #13 0x55fa3fd5e128 in qtest_process_inbuf /home/alxndr/Development/qemu/softmmu/qtest.c:710:9 + #14 0x55fa3fd5de67 in qtest_server_inproc_recv /home/alxndr/Development/qemu/softmmu/qtest.c:817:9 + #15 0x55fa4142b64b in qtest_sendf /home/alxndr/Development/qemu/tests/qtest/libqtest.c:424:5 + #16 0x55fa4142c482 in qtest_clock_step_next /home/alxndr/Development/qemu/tests/qtest/libqtest.c:864:5 + #17 0x55fa414b12d1 in general_fuzz /home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:581:17 + +It doesn't look like we ever exit out of the loop in timerlist_run_timers, ie timer_list->active_timers is always True. + + +Info From GDB: +#0 0x0000555558070d31 in address_space_stl_internal (as=0x55555f0e8f20 <address_space_memory>, addr=0x0, val=0x0, attrs=..., result=0x0, endian=DEVICE_LITTLE_ENDIAN) at /home/alxndr/Development/qemu/memory_ldst.inc.c:323 +#1 0x0000555558071339 in address_space_stl_le (as=0x55555f0e8f20 <address_space_memory>, addr=0x0, val=0x0, attrs=..., result=0x0) at /home/alxndr/Development/qemu/memory_ldst.inc.c:357 +#2 0x000055555a6a6f95 in update_irq (timer=0x61f0000005b8, set=0x1) at /home/alxndr/Development/qemu/hw/timer/hpet.c:210 +#3 0x000055555a6ae55f in hpet_timer (opaque=0x61f0000005b8) at /home/alxndr/Development/qemu/hw/timer/hpet.c:386 +#4 0x000055555c03d178 in timerlist_run_timers (timer_list=0x60b0000528f0) at /home/alxndr/Development/qemu/util/qemu-timer.c:572 +#5 0x000055555c03d6b5 in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at /home/alxndr/Development/qemu/util/qemu-timer.c:586 +#6 0x0000555558c3d0c4 in qtest_clock_warp (dest=0x3461864) at /home/alxndr/Development/qemu/softmmu/cpus.c:507 + + +-Alex + +Still reproduces with the current git version (commit 7fe7fae8b48e3f9c647) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/538 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/118/review/1888964 b/results/classifier/118/review/1888964 new file mode 100644 index 000000000..619b28e7c --- /dev/null +++ b/results/classifier/118/review/1888964 @@ -0,0 +1,132 @@ +semantic: 0.875 +graphic: 0.867 +user-level: 0.855 +permissions: 0.842 +performance: 0.810 +mistranslation: 0.778 +virtual: 0.762 +register: 0.749 +assembly: 0.727 +debug: 0.726 +boot: 0.724 +ppc: 0.704 +arm: 0.687 +architecture: 0.684 +hypervisor: 0.653 +peripherals: 0.649 +PID: 0.648 +device: 0.640 +risc-v: 0.635 +TCG: 0.606 +kernel: 0.563 +files: 0.561 +VMM: 0.498 +network: 0.486 +socket: 0.457 +x86: 0.456 +KVM: 0.380 +vnc: 0.341 +i386: 0.282 +-------------------- +virtual: 0.969 +boot: 0.914 +debug: 0.819 +graphic: 0.111 +files: 0.059 +hypervisor: 0.059 +TCG: 0.027 +PID: 0.025 +device: 0.018 +performance: 0.017 +user-level: 0.012 +VMM: 0.008 +kernel: 0.008 +register: 0.007 +socket: 0.007 +x86: 0.004 +semantic: 0.004 +architecture: 0.004 +peripherals: 0.003 +network: 0.003 +risc-v: 0.003 +KVM: 0.003 +assembly: 0.002 +i386: 0.001 +ppc: 0.001 +vnc: 0.001 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.000 + +Segfault using GTK display with dmabuf (iGVT-g) on Wayland + +When using... + a) Intel virtualized graphics (iGVT-g) with dmabuf output + b) QEMU's GTK display with GL output enabled (-display gtk,gl=on) + c) A Wayland compositor (Sway in my case) +a segfault occurs at some point on boot (I guess as soon as the guest starts using the virtual graphics card?) + +The origin is the function dpy_gl_scanout_dmabuf in ui/console.c, where it calls + con->gl->ops->dpy_gl_scanout_dmabuf(con->gl, dmabuf); +However, the ops field (struct DisplayChangeListenerOps) does not have dpy_gl_scanout_dmabuf set because it is set to dcl_gl_area_ops which does not have dpy_gl_scanout_dmabuf set. +Only dcl_egl_ops has dpy_gl_scanout_dmabuf set. +Currently, the GTK display uses EGL on X11 displays, but GtkGLArea on Wayland. This can be observed in early_gtk_display_init() in ui/gtk.c, where it says (simplified code): + +if (opts->has_gl && opts->gl != DISPLAYGL_MODE_OFF) { + if (GDK_IS_WAYLAND_DISPLAY(gdk_display_get_default())) { + gtk_use_gl_area = true; + gtk_gl_area_init(); + } else { + DisplayGLMode mode = opts->has_gl ? opts->gl : DISPLAYGL_MODE_ON; + gtk_egl_init(mode); + } +} + +To reproduce the findings above, add this assertion to dpy_gl_scanout_dmabuf: + assert(con->gl->ops->dpy_gl_scanout_dmabuf); +This will make the segfault turn into an assertion failure. + +A workaround is to force QEMU to use GDK's X11 backend (using GDK_BACKEND=x11). + +Note: This might be a duplicate of 1775011, however the information provided in that bug report is not sufficient to make the assertion. + +QEMU version: b0ce3f021e0157e9a5ab836cb162c48caac132e1 (from Git master branch) +OS: Arch Linux, Kernel Version 5.17.0-1 + +Relevant flags of the QEMU invocation: +qemu-system-x86_64 \ + -vga none \ + -device vfio-pci-nohotplug,sysfsdev="$GVT_DEV",romfile="${ROMFILE}",display=on,x-igd-opregion=on,ramfb=on \ + -display gtk,gl=on + +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/review/189 b/results/classifier/118/review/189 new file mode 100644 index 000000000..8efd759b3 --- /dev/null +++ b/results/classifier/118/review/189 @@ -0,0 +1,61 @@ +architecture: 0.947 +device: 0.848 +network: 0.756 +performance: 0.636 +graphic: 0.415 +semantic: 0.332 +peripherals: 0.210 +debug: 0.207 +assembly: 0.207 +virtual: 0.189 +hypervisor: 0.169 +permissions: 0.147 +mistranslation: 0.140 +arm: 0.121 +boot: 0.120 +ppc: 0.103 +user-level: 0.100 +files: 0.073 +PID: 0.064 +register: 0.057 +vnc: 0.037 +VMM: 0.027 +socket: 0.018 +i386: 0.016 +risc-v: 0.013 +x86: 0.011 +kernel: 0.009 +TCG: 0.005 +KVM: 0.003 +-------------------- +x86: 0.886 +device: 0.756 +peripherals: 0.696 +performance: 0.347 +user-level: 0.302 +debug: 0.262 +i386: 0.144 +virtual: 0.131 +files: 0.034 +semantic: 0.011 +socket: 0.005 +register: 0.005 +graphic: 0.004 +network: 0.004 +TCG: 0.004 +assembly: 0.003 +PID: 0.003 +architecture: 0.002 +kernel: 0.002 +hypervisor: 0.002 +boot: 0.001 +VMM: 0.001 +risc-v: 0.000 +mistranslation: 0.000 +KVM: 0.000 +arm: 0.000 +vnc: 0.000 +permissions: 0.000 +ppc: 0.000 + +Intel GVT-g works in X11, segfaults in wayland diff --git a/results/classifier/118/review/1890152 b/results/classifier/118/review/1890152 new file mode 100644 index 000000000..8ae4e1284 --- /dev/null +++ b/results/classifier/118/review/1890152 @@ -0,0 +1,118 @@ +mistranslation: 0.818 +register: 0.801 +virtual: 0.801 +performance: 0.795 +user-level: 0.782 +device: 0.779 +semantic: 0.765 +architecture: 0.752 +graphic: 0.740 +arm: 0.735 +peripherals: 0.724 +files: 0.720 +boot: 0.717 +assembly: 0.709 +debug: 0.707 +TCG: 0.701 +network: 0.692 +permissions: 0.665 +hypervisor: 0.664 +socket: 0.663 +PID: 0.662 +risc-v: 0.661 +KVM: 0.648 +kernel: 0.643 +x86: 0.632 +VMM: 0.597 +ppc: 0.590 +vnc: 0.559 +i386: 0.504 +-------------------- +i386: 0.996 +x86: 0.991 +debug: 0.571 +virtual: 0.368 +user-level: 0.341 +files: 0.336 +device: 0.233 +TCG: 0.148 +network: 0.122 +assembly: 0.078 +performance: 0.060 +PID: 0.048 +register: 0.030 +semantic: 0.030 +kernel: 0.020 +hypervisor: 0.010 +VMM: 0.007 +socket: 0.006 +ppc: 0.005 +boot: 0.004 +graphic: 0.003 +architecture: 0.003 +permissions: 0.002 +risc-v: 0.002 +peripherals: 0.002 +KVM: 0.002 +mistranslation: 0.001 +vnc: 0.001 +arm: 0.000 + +malloc 0xff0000030 bytes with vmxnet3 + +Hello, +This reproducer causes vmxnet3 to malloc 0xff0000030 bytes + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x3e 0x1 0x05 +write 0x28 0x1 0xe1 +write 0x29 0x1 0xfe +write 0x2a 0x1 0xff +write 0x2b 0x1 0xff +write 0x2c 0x1 0xff +write 0x2d 0x1 0xff +write 0x2e 0x1 0xff +write 0x2f 0x1 0xff +write 0x31c 0x1 0xff +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + + + +================================================================= +==25727==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0xff0000030 bytes + #0 0x56476a43731d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/i386-softmmu/qemu-system-i386+0x2bba31d) + #1 0x7fca345a8500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x56476c616312 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1504:5 + #3 0x56476c6101ba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #4 0x56476c60d30f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #5 0x56476b11d383 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #6 0x56476b11c827 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x56476b11a446 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #8 0x56476a4cb696 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x56476a4b3eb6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x56476a4b39d7 in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x56476b1c4614 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #12 0x56476b1bbc18 in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x56476b1ba8a5 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x56476e063f03 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x56476e064087 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x56476e078373 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x56476e1cc734 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7fca345a2897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + + +-Alex + +Chronogically speaking #1913873 is a duplicate of #1890152... + diff --git a/results/classifier/118/review/1891748 b/results/classifier/118/review/1891748 new file mode 100644 index 000000000..dcb945349 --- /dev/null +++ b/results/classifier/118/review/1891748 @@ -0,0 +1,165 @@ +mistranslation: 0.866 +semantic: 0.864 +peripherals: 0.858 +risc-v: 0.858 +debug: 0.839 +user-level: 0.825 +performance: 0.815 +boot: 0.811 +device: 0.807 +arm: 0.806 +VMM: 0.783 +PID: 0.774 +kernel: 0.764 +assembly: 0.756 +socket: 0.754 +KVM: 0.753 +architecture: 0.745 +hypervisor: 0.728 +graphic: 0.727 +register: 0.722 +ppc: 0.719 +virtual: 0.716 +files: 0.709 +permissions: 0.686 +vnc: 0.683 +TCG: 0.631 +network: 0.589 +x86: 0.571 +i386: 0.386 +-------------------- +arm: 0.984 +virtual: 0.574 +user-level: 0.207 +hypervisor: 0.165 +files: 0.071 +debug: 0.020 +register: 0.011 +TCG: 0.006 +permissions: 0.006 +PID: 0.005 +kernel: 0.004 +device: 0.004 +network: 0.003 +performance: 0.003 +socket: 0.002 +boot: 0.002 +semantic: 0.002 +VMM: 0.001 +architecture: 0.001 +vnc: 0.001 +peripherals: 0.001 +assembly: 0.001 +ppc: 0.001 +risc-v: 0.001 +graphic: 0.001 +x86: 0.000 +KVM: 0.000 +i386: 0.000 +mistranslation: 0.000 + +qemu-arm-static 5.1 can't run gcc + +Issue discovered while trying to build pikvm (1) + +Long story short: when using qemu-arm-static 5.1, gcc exits whith message: + +Allocating guest commpage: Operation not permitted + + +when using qemu-arm-static v5.0, gcc "works" + +Steps to reproduce will follow + +(1) https://github.com/pikvm/pikvm/blob/master/pages/building_os.md + +Steps to reproduce + +1. Download and extract attached tarball. + +$ make # will build the docker container + +$ make run # will enter the container + +# once in the container, run + +# /qemu-arm-static-50 /bin/bash /runme.sh + + + + +Additional info, + +error message text ( "Allocating guest commpage" ) found in this commit: + + +https://fossies.org/diffs/qemu/5.0.0_vs_5.1.0-rc0/linux-user/elfload.c-diff.html + +Anyone? Seriously, the problem really exists and we even made a case that reproduces it. Someone please take a look at this. + +Plz take a look at this issue please. + +This has been fixed in mainline, probably commit +8ef618859c379fdce81c91bc93e0574e36ea76ff. + + +Released with QEMU v5.2.0. + +I'm still seeing this with qemu 5.2.0 + +armv7a-softfp-linux-gnueabi-gcc -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -Wl,-O1 -Wl,--as-needed glibc-test.c -o glibc-test +Allocating guest commpage: Operation not permitted + + + +$ qemu-arm --version +qemu-arm version 5.2.0 (Debian 1:5.2+dfsg-6) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +I’m seeing this error on a totally different file: + +I’ve made a short test program (hello world-ish) and compiled it with the OpenWrt toolchain but added -static so I can run it on the host using qemu-user-arm: + +$ STAGING_DIR=$PWD/staging_dir PATH=staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.5.0_musl_eabi/bin:$PATH arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -mfloat-abi=hard -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -static x.c +$ ./a.out +Allocating guest commpage: Operation not permitted + + +Heh, even if I omit -static … + +It works with sudo, but that can’t be the fix… + +Could you check the result of "sysctl vm.mmap_min_addr" + +65536 is the value that works for me. + +@aurent-vivier Checked. +This value does not affect the bug, after changing it, I still get an error. + +Anyone? + +I've been unable to replicate the crash with any of the instructions here. Certainly all the statically compiled unit tests work and I've just done a build of QEMU in an emulated Debian Buster (Armel) docker image. + +Okay, what do you think this problem might be related to? I'm glad your tests are working, but I'm definitely not the only one with this problem. + +I think the output of "sysctl vm" could help to identify which parameter is involved in the problem. You can also compare the output of "sudo sysctl vm" and "sysctl vm" + +In my case, sudo does not affect this bug. My output in attachements. + +Sup? + +Okay, it was found experimentally that the problem is reproduced if vm.mmap_min_addr is greater than 53249. If from 0 to 53249 - everything works. What can this be related to? + +I mean [0...52348] is working. + +Sorry, an error in previous message. + +Fixed and detailed diagnostics: + +[0 ... 53248] - working +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted + +Can confirm this bug on fresh Linux Arch and Debian Linux installation. +I need just nothing to reproduce it: Just install fresh arch and do steps described in comment #1 + diff --git a/results/classifier/118/review/1893667 b/results/classifier/118/review/1893667 new file mode 100644 index 000000000..f381f3a79 --- /dev/null +++ b/results/classifier/118/review/1893667 @@ -0,0 +1,99 @@ +architecture: 0.826 +graphic: 0.702 +device: 0.681 +performance: 0.632 +user-level: 0.556 +files: 0.549 +permissions: 0.542 +semantic: 0.525 +PID: 0.500 +network: 0.448 +mistranslation: 0.430 +socket: 0.395 +register: 0.392 +vnc: 0.362 +kernel: 0.356 +arm: 0.355 +ppc: 0.337 +boot: 0.331 +peripherals: 0.327 +risc-v: 0.323 +VMM: 0.310 +i386: 0.265 +TCG: 0.262 +hypervisor: 0.256 +debug: 0.253 +virtual: 0.244 +x86: 0.242 +KVM: 0.213 +assembly: 0.084 +-------------------- +arm: 0.961 +virtual: 0.175 +TCG: 0.048 +architecture: 0.044 +debug: 0.030 +files: 0.012 +register: 0.011 +hypervisor: 0.008 +user-level: 0.007 +kernel: 0.005 +network: 0.004 +PID: 0.004 +ppc: 0.003 +device: 0.002 +semantic: 0.002 +socket: 0.002 +x86: 0.001 +performance: 0.001 +boot: 0.001 +VMM: 0.001 +risc-v: 0.001 +i386: 0.001 +vnc: 0.001 +graphic: 0.001 +peripherals: 0.001 +permissions: 0.000 +assembly: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +Btrfs commands don't work when using user-space emulation of other architectures + +Description of problem: +When doing cross-arch builds with mock, it uses qemu-user-static under the hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that btrfs(8) commands work correctly. + +This is especially important for being able to do cross-arch image builds. + +How reproducible: +Always (on Fedora 33 with qemu-5.1.0-2.fc33) + +Steps to Reproduce: + +$ sudo dnf install mock qemu-user-static wget +$ sudo usermod -a -G mock $USER +$ newgrp mock +$ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux +$ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img && mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol create /foo/subvol && umount /foo && losetup -d /dev/loop9' + + +Actual results: +Fails with errors like "ERROR: cannot create subvolume: Function not implemented" + +Expected results: +Succeeds and creates subvolumes properly. + +Additional info: +There is a patch series from a few days ago to add support for many btrfs ioctls which could fix this... + +https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html + +Laurent, I am assuming that the commits here: +https://gitlab.com/qemu-project/qemu/-/commits/master?utf8=%E2%9C%93&search=Filip+Bozuta + +are sufficient to mark this issue as Fix Committed. It looks like the Downstream bug tracker for Fedora has marked the related bug as CLOSED ERRATA already. + +If I'm wrong, please reopen. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/review/1895305 b/results/classifier/118/review/1895305 new file mode 100644 index 000000000..81ae4bbe3 --- /dev/null +++ b/results/classifier/118/review/1895305 @@ -0,0 +1,113 @@ +x86: 0.907 +architecture: 0.838 +performance: 0.823 +ppc: 0.814 +user-level: 0.807 +device: 0.792 +graphic: 0.782 +files: 0.762 +mistranslation: 0.677 +kernel: 0.667 +socket: 0.662 +debug: 0.654 +register: 0.629 +semantic: 0.611 +permissions: 0.596 +boot: 0.559 +risc-v: 0.550 +network: 0.539 +PID: 0.515 +peripherals: 0.499 +vnc: 0.493 +arm: 0.468 +VMM: 0.447 +hypervisor: 0.445 +virtual: 0.443 +TCG: 0.367 +i386: 0.345 +KVM: 0.326 +assembly: 0.249 +-------------------- +user-level: 0.334 +x86: 0.270 +virtual: 0.072 +files: 0.052 +debug: 0.045 +TCG: 0.044 +network: 0.025 +hypervisor: 0.021 +register: 0.018 +PID: 0.018 +arm: 0.012 +performance: 0.010 +device: 0.003 +socket: 0.003 +kernel: 0.003 +semantic: 0.003 +vnc: 0.002 +architecture: 0.002 +VMM: 0.002 +permissions: 0.002 +boot: 0.002 +graphic: 0.001 +peripherals: 0.001 +assembly: 0.001 +ppc: 0.001 +risc-v: 0.001 +KVM: 0.001 +i386: 0.000 +mistranslation: 0.000 + +pthread_cancel fails with "RT33" with musl libc + +From my testing it seems that QEMU built against musl libc crashes on pthread_cancel cancel calls - if the binary is also built with musl libc. + +Minimal sample: + +#include <pthread.h> +#include <stdio.h> +#include <unistd.h> +void* threadfunc(void* ignored) { + while (1) { + pause(); + } + return NULL; +} +int main() { + pthread_t thread; + pthread_create(&thread, NULL, &threadfunc, NULL); + sleep(1); + pthread_cancel(thread); + printf("OK, alive\n"); +} + +In an Alpine Linux aarch64 chroot (on an x86_64 host) the binary will just output RT33 and has exit code 161. + +Using qemu-aarch64 on an x86_64 host results in the output (fish shell) + fish: “qemu-aarch64-static ./musl-stat…” terminated by signal Unknown (Unknown) +or (bash) + Real-time signal 2 + +and exit code 164. + +It doesn't matter whether the binary is linked dynamically or static. You can see my test results in the following table: + +| | QEMU glibc | QEMU musl | +|----------------------|------------|-----------| +| binary glibc dynamic | ✓ | ✓ | +| binary glibc static | ✓ | ✓ | +| binary musl dynamic | ✓ | ✗ | +| binary musl static | ✓ | ✗ | + +Both QEMU builds are v5.1.0 (glibc v2.32 / musl v1.2.1) + +I've uploaded all my compile and test commands (plus a script to conveniently run them all) to https://github.com/z3ntu/qemu-pthread_cancel . It also includes the built binaries if needed. The test script output can be found at https://github.com/z3ntu/qemu-pthread_cancel/blob/master/results.txt + +Further links: +- https://gitlab.com/postmarketOS/pmaports/-/issues/190#note_141902075 +- https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1970 + +This was a downstream regression in Alpine caused by an attempt to make older Go binaries work under emulation. We have reverted the patch there. + +Ok, thanks, since this was a regressin in Alpine, I'm marking the bug as closed here. + diff --git a/results/classifier/118/review/1896561 b/results/classifier/118/review/1896561 new file mode 100644 index 000000000..23d7567a8 --- /dev/null +++ b/results/classifier/118/review/1896561 @@ -0,0 +1,119 @@ +user-level: 0.896 +semantic: 0.879 +hypervisor: 0.867 +virtual: 0.862 +mistranslation: 0.850 +graphic: 0.847 +permissions: 0.846 +peripherals: 0.836 +register: 0.818 +risc-v: 0.817 +arm: 0.816 +performance: 0.810 +ppc: 0.806 +TCG: 0.805 +KVM: 0.804 +PID: 0.791 +VMM: 0.791 +assembly: 0.788 +vnc: 0.782 +socket: 0.779 +architecture: 0.774 +debug: 0.767 +network: 0.765 +x86: 0.741 +device: 0.730 +boot: 0.717 +files: 0.714 +kernel: 0.700 +i386: 0.551 +-------------------- +virtual: 0.776 +user-level: 0.349 +debug: 0.129 +TCG: 0.096 +VMM: 0.040 +files: 0.034 +boot: 0.032 +x86: 0.031 +hypervisor: 0.030 +device: 0.027 +graphic: 0.022 +PID: 0.017 +socket: 0.016 +network: 0.015 +register: 0.012 +semantic: 0.009 +peripherals: 0.008 +architecture: 0.007 +kernel: 0.006 +vnc: 0.005 +performance: 0.003 +permissions: 0.003 +assembly: 0.002 +i386: 0.001 +arm: 0.001 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +EFI GOP Mode 1366x768 + +When using the EFI firmware from https://www.kraxel.org/repos/jenkins/edk2/ (https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20200919.1453.g7faece6985.noarch.rpm) (OVMF-pure-efi.fd and OVMF_VARS-pure-efi.fd) then using the GOP, setting the mode to 1366x768, QEMU uses a width of 1360 instead. + +I am using QEMU for windows (https://qemu.weilnetz.de/) on a Windows 10 machine. + +To verify, while in the EFI firmware loaded code (within BOOTx64.EFI) and before ExitBootServices(), I choose the 1360x768 mode. I then took notice of where the host window was and how many pixels it occupied. I then reset the emulation (without quitting) and chose the 1366x768 mode. QEMU set the host window to the exact same width as the 1360 mode. i.e.: The same exact pixels where shown in the host background. The window did not expand the extra 6 pixels. + +I allowed the firmware to run its course to my test environment when using mode 1366x768, all pixels are 6 pixels off to the right. i.e.: 6 pixels down the Frame Buffer. If my test environment changes its HORZ WIDTH and PIXELS PER SCANLINE to 1360 while using this (1366x768) mode, the display is correct. + +This told me that it could be a few things. +1) Since most (I didn't check them all) of the other modes have the width value's bits 2:0 clear, mode 1366x768 is the only mode the EDK2 firmware has with a width where bits 2:0 are not zero. Could EDK2 or QEMU (which for the Windows version may use SDL2 so it must be considered here) be clearing these bits? The value of 1366 when clearing bits 2:0 is 1360. + +2) Could there be a typo in the code EDK2 where the width should have been 1366? +(I went looking at both QEMU (for Windows) and EDK2 and after looking at many lines of code, I could not find anywhere where this might happen. + +By the way, in /ui/sdl2-2d.c (QEMU Windows version only?), there is a typo in a comment, missing the second 'e': + +Line 156: * the native ones. Thes are the ones I have tested. + +3) Could EDK2 be sending 1360 instead of 1366? +4) Could QEMU (passing it on to SDL2 in SDL_SetWindowSize()?) be destroying the value (bottom three bits)? + +Anyway, using the latest version of the EDK2 from the URL listed above, choosing the 1366x768 mode, does not set QEMU (for Windows) to 1366 pixels in width. + +Ben + +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/review/1898011 b/results/classifier/118/review/1898011 new file mode 100644 index 000000000..06ae6c162 --- /dev/null +++ b/results/classifier/118/review/1898011 @@ -0,0 +1,142 @@ +semantic: 0.835 +graphic: 0.785 +peripherals: 0.745 +virtual: 0.722 +performance: 0.688 +hypervisor: 0.682 +debug: 0.678 +mistranslation: 0.669 +user-level: 0.662 +arm: 0.658 +permissions: 0.638 +risc-v: 0.623 +network: 0.609 +architecture: 0.608 +TCG: 0.576 +files: 0.573 +register: 0.568 +ppc: 0.567 +kernel: 0.554 +socket: 0.553 +PID: 0.546 +assembly: 0.538 +vnc: 0.532 +VMM: 0.487 +device: 0.485 +x86: 0.468 +KVM: 0.466 +boot: 0.447 +i386: 0.253 +-------------------- +performance: 0.776 +hypervisor: 0.649 +x86: 0.229 +debug: 0.055 +virtual: 0.042 +kernel: 0.038 +TCG: 0.015 +user-level: 0.014 +VMM: 0.010 +architecture: 0.006 +register: 0.006 +assembly: 0.006 +files: 0.005 +PID: 0.005 +KVM: 0.005 +boot: 0.004 +device: 0.003 +semantic: 0.003 +arm: 0.002 +permissions: 0.002 +risc-v: 0.002 +ppc: 0.002 +vnc: 0.001 +network: 0.001 +graphic: 0.001 +socket: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +i386: 0.000 + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM + +Run this program: + +#include <sys/mman.h> +#include <stdio.h> +int main() { + for (int i = 30; i <= 44; i++) { + fprintf(stderr, "trying 2**%d\n", i); + mmap((void*)0x600000000000,1ULL << i, + PROT_NONE, + MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0); + } +} + +(tried qemu-x86_64 and qemu-aarch64, 4.2.1 and trunk/5.1.50) + +On each iteration qemu will consume 2x more physical RAM, +e.g. when mapping 2^42 it will have RSS of 16Gb. + +On normal linux it works w/o consuming much RAM, due to MAP_NORESERVE. + +Also: qemu -strace prints 0 instead of the correct size starting from size=2^32 +and prints -2147483648 for size=2^31. + +mmap(0x0000600000000000,1073741824,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,-2147483648,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,0,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +Without actually looking, an allocation of 2**42 (4PB) requires +2**30 (1G) pages, and thus 1G page table entries, so 16GB memory +allocation sounds about right for qemu's internal page table allocation. + +We need to change data structures for representing guest memory, +probably akin to the kernel's VMAs. + +The problem occurs for example with any program which was compiled with the address sanitizer. + +A simple hello program compiled with "gcc -fsanitize=address hello.c" is sufficient to show the problem. Just run it with "qemu-x86_64 a.out". It will be killed by the Linux kernel OOM handler even on a server with 64 GB RAM. + +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. + + +Still an issue, yes. + + +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/290 + + diff --git a/results/classifier/118/review/1898215 b/results/classifier/118/review/1898215 new file mode 100644 index 000000000..49b830a8e --- /dev/null +++ b/results/classifier/118/review/1898215 @@ -0,0 +1,145 @@ +semantic: 0.924 +graphic: 0.915 +permissions: 0.903 +assembly: 0.893 +debug: 0.892 +user-level: 0.891 +register: 0.889 +virtual: 0.885 +arm: 0.870 +architecture: 0.856 +PID: 0.854 +device: 0.849 +mistranslation: 0.837 +peripherals: 0.833 +files: 0.823 +VMM: 0.807 +boot: 0.805 +network: 0.804 +hypervisor: 0.798 +TCG: 0.795 +performance: 0.788 +socket: 0.783 +kernel: 0.767 +vnc: 0.760 +risc-v: 0.756 +KVM: 0.747 +ppc: 0.737 +x86: 0.566 +i386: 0.337 +-------------------- +debug: 0.509 +x86: 0.362 +files: 0.102 +PID: 0.070 +virtual: 0.030 +TCG: 0.023 +kernel: 0.019 +VMM: 0.017 +device: 0.016 +hypervisor: 0.013 +i386: 0.013 +register: 0.012 +semantic: 0.006 +performance: 0.006 +graphic: 0.004 +architecture: 0.004 +network: 0.003 +user-level: 0.003 +peripherals: 0.003 +socket: 0.002 +permissions: 0.002 +boot: 0.002 +vnc: 0.001 +assembly: 0.001 +KVM: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +arm: 0.000 +ppc: 0.000 + +[git][archlinux]Build process is busted in spice-display.c + +Linux distribution: Archlinux. Crash log added is based on a build from scratch. + +Gcc version: 10.2.0 + +Configure options used: + +configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --extra-ldflags="$LDFLAGS" \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + --enable-slirp=system \ + --enable-xfsctl \ + --audio-drv-list="pa alsa sdl" + +Crash log: + +../ui/spice-display.c: In function 'interface_client_monitors_config': +../ui/spice-display.c:682:25: error: 'VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE' undeclared (first use in this function); did you mean 'VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS'? + 682 | if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS +../ui/spice-display.c:682:25: note: each undeclared identifier is reported only once for each function it appears in +../ui/spice-display.c:683:13: error: unknown type name 'VDAgentMonitorMM' + 683 | VDAgentMonitorMM *mm = (void *)&mc->monitors[mc->num_of_monitors]; + | ^~~~~~~~~~~~~~~~ +../ui/spice-display.c:684:37: error: request for member 'width' in something not a structure or union + 684 | info.width_mm = mm[head].width; + | ^ +../ui/spice-display.c:685:38: error: request for member 'height' in something not a structure or union + 685 | info.height_mm = mm[head].height; + | ^ +make: *** [Makefile.ninja:2031: libcommon.fa.p/ui_spice-display.c.o] Error 1 +make: *** Waiting for unfinished jobs.... + +Full build log with make V=1. + +This is a bug in the spice-server meson build system: +https://gitlab.freedesktop.org/spice/spice/-/commit/37fd91a51f52cdc1b55d3ce41e6ce6db348b986c + +Most likely they will end up bumping the version to 0.15, so we may want to update the condition in qemu. + +Already reported to Arch: + +https://bugs.archlinux.org/task/68061 + +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. + + +Fix released + diff --git a/results/classifier/118/review/1899 b/results/classifier/118/review/1899 new file mode 100644 index 000000000..ad6bbc995 --- /dev/null +++ b/results/classifier/118/review/1899 @@ -0,0 +1,101 @@ +architecture: 0.802 +arm: 0.761 +graphic: 0.749 +kernel: 0.642 +device: 0.598 +peripherals: 0.587 +semantic: 0.571 +performance: 0.570 +hypervisor: 0.549 +boot: 0.508 +PID: 0.503 +socket: 0.422 +ppc: 0.414 +x86: 0.402 +network: 0.370 +mistranslation: 0.365 +debug: 0.357 +permissions: 0.351 +user-level: 0.313 +risc-v: 0.298 +TCG: 0.290 +register: 0.287 +VMM: 0.275 +assembly: 0.271 +vnc: 0.260 +files: 0.213 +KVM: 0.209 +i386: 0.174 +virtual: 0.157 +-------------------- +debug: 0.983 +kernel: 0.836 +virtual: 0.670 +hypervisor: 0.611 +assembly: 0.522 +boot: 0.439 +architecture: 0.107 +TCG: 0.028 +files: 0.025 +register: 0.020 +PID: 0.017 +semantic: 0.011 +performance: 0.008 +device: 0.007 +VMM: 0.006 +KVM: 0.005 +socket: 0.004 +user-level: 0.004 +graphic: 0.003 +risc-v: 0.002 +vnc: 0.002 +network: 0.001 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +ppc: 0.000 +arm: 0.000 +x86: 0.000 +i386: 0.000 + +AArch64: Wrong SCR_EL3 after turning on secondary cores via PSCI +Description of problem: +The system fails to boot when using "direct kernel boot" with EL3 enabled. After the guest OS enables secondary cores via PSCI, those have an incorrectly set up `SCR_EL3`. When the OS then executes an intruction which traps into (QEMU provided fake) EL3, the core ends up in an endless loop of "Undefined Instruction" exceptions. + +This is nicely visible with `-serial stdio -append "earlycon=pl011,0x9000000 console=/dev/ttyAMA0" -d int`: + +```plaintext +[ 0.173173][ T1] smp: Bringing up secondary CPUs ... +(...) +Taking exception 11 [Hypervisor Call] on CPU 0 +...from EL1 to EL2 +...with ESR 0x16/0x5a000000 +...handled as PSCI call +Taking exception 5 [IRQ] on CPU 0 +...from EL1 to EL1 +...with ESR 0x16/0x5a000000 +...with ELR 0xffffa9ff8b593438 +...to EL1 PC 0xffffa9ff8aa11280 PSTATE 0x3c5 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffa9ff8b593438 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0x41f7832c +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL1 to EL3 +...with ESR 0x18/0x62300882 +...with ELR 0xffffa9ff8aa3d0d8 +...to EL3 PC 0x400 PSTATE 0x3cd +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL3 to EL3 +...with ESR 0x0/0x2000000 +...with ELR 0x400 +...to EL3 PC 0x200 PSTATE 0x3cd +(repeats forever, CPU 1 is stuck) +``` +Steps to reproduce: +1. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 1 -kernel linux` works +2. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 2 -kernel linux` does not +Additional information: +The setup for `SCR_EL3` is done by `do_cpu_reset` in hw/arm/boot.c, but this is only called on full system reset. The PSCI call ends up in `arm_set_cpu_on_async_work` (target/arm/arm-powerctl.c) which calls `cpu_reset`. This clears `SCR_EL3` to the architectural reset value, not the one needed for direct kernel boot. + +`arm_set_cpu_on_async_work` has code for `SCR_HCE`, but none of the other flags handled by `do_cpu_reset`. It would probably work after copying all of `do_cpu_reset` into `arm_set_cpu_on_async_work`, but that seems wrong. I prepared a patch which makes `do_cpu_reset` public such that `arm_set_cpu_on_async_work` can call it (works here), but I'm not sure whether that's the right way. + +CC @pm215 diff --git a/results/classifier/118/review/1900918 b/results/classifier/118/review/1900918 new file mode 100644 index 000000000..0847e69e7 --- /dev/null +++ b/results/classifier/118/review/1900918 @@ -0,0 +1,78 @@ +mistranslation: 0.991 +device: 0.834 +semantic: 0.820 +peripherals: 0.715 +performance: 0.700 +architecture: 0.697 +x86: 0.668 +ppc: 0.645 +graphic: 0.642 +user-level: 0.622 +permissions: 0.588 +PID: 0.574 +kernel: 0.570 +assembly: 0.569 +virtual: 0.487 +hypervisor: 0.461 +network: 0.458 +debug: 0.429 +register: 0.419 +socket: 0.416 +i386: 0.377 +arm: 0.358 +risc-v: 0.316 +files: 0.293 +KVM: 0.281 +boot: 0.278 +vnc: 0.277 +VMM: 0.233 +TCG: 0.229 +-------------------- +x86: 0.883 +device: 0.371 +debug: 0.328 +kernel: 0.187 +files: 0.058 +hypervisor: 0.055 +virtual: 0.054 +user-level: 0.040 +peripherals: 0.036 +architecture: 0.031 +TCG: 0.030 +VMM: 0.028 +ppc: 0.023 +semantic: 0.023 +PID: 0.022 +register: 0.018 +performance: 0.010 +risc-v: 0.007 +boot: 0.005 +KVM: 0.005 +i386: 0.004 +socket: 0.003 +assembly: 0.003 +arm: 0.002 +vnc: 0.002 +permissions: 0.002 +network: 0.002 +graphic: 0.001 +mistranslation: 0.001 + +PXB devices + +release: 4c41341af76cfc85b5a6c0f87de4838672ab9f89 + +qdev_device_add() will search for the "closest" bus possible, and bail out early if that bus is a root bus. pxb devices are considered root buses and so if you either +1. Add a PCI device on the QEMU command line *after* a pxb device, or +2. Add an integrated PCI device (like a watchdog) + +#1: -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 -device ahci,id=sata0,addr=0x8 +#2: -watchdog i6300esb -device pxb-pcie,id=cxl.0,bus=pcie.0,bus_nr=52 + +The PXB will get selected as the bus (instead of the real root bus) and this will cause an assertion failure with the message like "qemu-system-x86_64: -device ahci,id=sata0,addr=0x8: PCI: Only PCI/PCIe bridges can be plugged into pxb-pcie" + +I think this is relatively solvable in the code base by determining if a bus is an expander, and skipping it if so. However, I wonder if it makes more sense to just allow expanders to have endpoint devices. + +I accidentally double submitted this, and this one has the wrong description. Please close and use +#1900919 instead. + diff --git a/results/classifier/118/review/1901359 b/results/classifier/118/review/1901359 new file mode 100644 index 000000000..15be66ee0 --- /dev/null +++ b/results/classifier/118/review/1901359 @@ -0,0 +1,118 @@ +mistranslation: 0.969 +device: 0.790 +graphic: 0.762 +semantic: 0.752 +register: 0.745 +ppc: 0.732 +performance: 0.708 +architecture: 0.692 +hypervisor: 0.691 +PID: 0.666 +network: 0.658 +peripherals: 0.653 +user-level: 0.647 +kernel: 0.644 +vnc: 0.633 +files: 0.630 +permissions: 0.603 +risc-v: 0.593 +debug: 0.570 +socket: 0.564 +arm: 0.540 +TCG: 0.507 +x86: 0.498 +i386: 0.481 +VMM: 0.454 +assembly: 0.441 +KVM: 0.412 +boot: 0.412 +virtual: 0.396 +-------------------- +x86: 0.093 +debug: 0.070 +TCG: 0.007 +virtual: 0.006 +files: 0.005 +PID: 0.005 +register: 0.005 +hypervisor: 0.004 +user-level: 0.004 +ppc: 0.004 +semantic: 0.004 +arm: 0.003 +network: 0.003 +device: 0.003 +i386: 0.003 +VMM: 0.003 +boot: 0.003 +risc-v: 0.003 +socket: 0.003 +vnc: 0.003 +peripherals: 0.002 +mistranslation: 0.002 +performance: 0.002 +kernel: 0.002 +assembly: 0.002 +permissions: 0.002 +graphic: 0.001 +architecture: 0.001 +KVM: 0.000 + +ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access + +I'v recently stumbled upon a bug in the Plan9 PCI config space access routines for config mode #1. + +The code used to set bit 0 in the CONFIG_ADDRESS register for a Type 1 access. + +This was most likely a misreading of the PCI local bus specification on our side. + +However, in the PCI local bus specification 3.0, it states the following: + +> 3.2.2.3.2 Software Generation of Configuration Transactions +> ... +> For Type 1 translations, the host bridge directly copies the contents of the +> CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines during the +> address phase of a configuration transaction making sure that AD[1::0] is "01". + +note the: "excluding bits 31 and 0" + +What happens in qemu instead is that it uses bit 0 of the CONFIG_ADDRESS +register as part of the register offset (when it probably should ignore it) +when translating from Type 1 to Type 0 address. So once it reaches the device +behind the bridge the register address is off by one. + +is anybody home? + +Yeah, the bug tracker here on Launchpad is somewhat neglected ... Therefore: +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/review/1902112 b/results/classifier/118/review/1902112 new file mode 100644 index 000000000..583ebc681 --- /dev/null +++ b/results/classifier/118/review/1902112 @@ -0,0 +1,108 @@ +mistranslation: 0.800 +register: 0.797 +permissions: 0.789 +performance: 0.788 +user-level: 0.783 +device: 0.769 +files: 0.755 +risc-v: 0.753 +architecture: 0.738 +semantic: 0.727 +virtual: 0.718 +graphic: 0.711 +arm: 0.691 +debug: 0.686 +PID: 0.677 +assembly: 0.668 +boot: 0.657 +kernel: 0.631 +network: 0.610 +ppc: 0.581 +TCG: 0.576 +x86: 0.568 +socket: 0.563 +VMM: 0.556 +peripherals: 0.545 +i386: 0.527 +KVM: 0.525 +hypervisor: 0.523 +vnc: 0.505 +-------------------- +i386: 0.997 +x86: 0.995 +debug: 0.765 +hypervisor: 0.699 +virtual: 0.355 +kernel: 0.089 +user-level: 0.058 +files: 0.057 +device: 0.042 +performance: 0.026 +assembly: 0.026 +peripherals: 0.025 +PID: 0.023 +boot: 0.016 +TCG: 0.015 +register: 0.013 +semantic: 0.012 +architecture: 0.009 +socket: 0.007 +permissions: 0.005 +VMM: 0.004 +KVM: 0.004 +graphic: 0.004 +risc-v: 0.003 +ppc: 0.003 +network: 0.002 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 + +[OSS-Fuzz] Issue 26693: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci: Index-out-of-bounds in xhci_runtime_write + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26693 + +=== Reproducer (build with --enable-sanitizers) === +export UBSAN_OPTIONS="print_stacktrace=1:silence_unsigned_overflow=1" +cat << EOF | ./qemu-system-i386 -display none -machine\ + accel=qtest, -m 512M -machine q35 -nodefaults -drive\ + file=null-co://,if=none,format=raw,id=disk0 -device\ + qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0\ + -device usb-bot -device usb-storage,drive=disk0\ + -chardev null,id=cd0 -chardev null,id=cd1 -device\ + usb-braille,chardev=cd0 -device usb-ccid -device\ + usb-ccid -device usb-kbd -device usb-mouse -device\ + usb-serial,chardev=cd1 -device usb-tablet -device\ + usb-wacom-tablet -device usb-audio -qtest stdio +outl 0xcf8 0x80000803 +outl 0xcfc 0x18caffff +outl 0xcf8 0x80000810 +outl 0xcfc 0x555a2e46 +write 0x555a1004 0x4 0xe7b9aa7a +EOF + +=== Stack Trace === + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/hcd-xhci.c:3012:30 in +../hw/usb/hcd-xhci.c:3012:30: runtime error: index -1 out of bounds for type 'XHCIInterrupter [16]' +#0 0x55bd2e97c8b0 in xhci_runtime_write /src/qemu/hw/usb/hcd-xhci.c:3012:30 +#1 0x55bd2edfdd13 in memory_region_write_accessor /src/qemu/softmmu/memory.c:484:5 +#2 0x55bd2edfdb14 in access_with_adjusted_size /src/qemu/softmmu/memory.c:545:18 +#3 0x55bd2edfd54b in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#4 0x55bd2ed7fa46 in flatview_write_continue /src/qemu/softmmu/physmem.c:2767:23 +#5 0x55bd2ed7cac0 in flatview_write /src/qemu/softmmu/physmem.c:2807:14 +#6 0x55bd2ed7c9f8 in address_space_write /src/qemu/softmmu/physmem.c:2899:18 +#7 0x55bd2e85cf9b in __wrap_qtest_writeq /src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9 +#8 0x55bd2e85b7b1 in op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:476:13 +#9 0x55bd2e85a84c in generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:678:17 +#10 0x55bd2e85dd6f in LLVMFuzzerTestOneInput /src/qemu/tests/qtest/fuzz/fuzz.c:150:5 +#11 0x55bd2e7e9661 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:595:15 +#12 0x55bd2e7d4732 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6 +#13 0x55bd2e7da7ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:852:9 +#14 0x55bd2e8027d2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 +#15 0x7f3d153b783f in __libc_start_main + +ClusterFuzz testcase 5747786781556736 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_qemu&range=202011040616:202011060622 + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/review/1902267 b/results/classifier/118/review/1902267 new file mode 100644 index 000000000..e60fa5674 --- /dev/null +++ b/results/classifier/118/review/1902267 @@ -0,0 +1,128 @@ +architecture: 0.947 +graphic: 0.900 +mistranslation: 0.896 +kernel: 0.864 +user-level: 0.858 +performance: 0.854 +hypervisor: 0.788 +device: 0.770 +ppc: 0.762 +semantic: 0.755 +network: 0.724 +register: 0.717 +debug: 0.715 +peripherals: 0.705 +assembly: 0.701 +files: 0.659 +arm: 0.646 +PID: 0.643 +socket: 0.626 +permissions: 0.616 +vnc: 0.616 +x86: 0.611 +KVM: 0.595 +virtual: 0.590 +i386: 0.573 +risc-v: 0.539 +VMM: 0.533 +TCG: 0.529 +boot: 0.480 +-------------------- +x86: 0.831 +assembly: 0.574 +debug: 0.137 +user-level: 0.090 +ppc: 0.048 +files: 0.033 +i386: 0.030 +TCG: 0.024 +arm: 0.021 +virtual: 0.019 +hypervisor: 0.014 +PID: 0.013 +semantic: 0.012 +network: 0.012 +risc-v: 0.008 +register: 0.005 +device: 0.005 +boot: 0.005 +performance: 0.004 +permissions: 0.003 +kernel: 0.003 +VMM: 0.003 +architecture: 0.003 +socket: 0.002 +vnc: 0.002 +peripherals: 0.002 +graphic: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +CPU not support 32-bit stack in 32-bit unreal mode + +QEMU version 5.0.0 supports 32-bit and 16-bit unreal mode. Great! +Unfortunately, QEMU does not support 32-bit stack in unreal 32-bit mode. +After the INT instruction, the stack is switched to 16-bit, which should not be the case. +At BOCHS, my code works 100%. At QEMU not works. + +Sample code to find out: + +use32 +cli +mov ax,cs +shl eax,16 +mov ax,NewInt80h +mov [IDT32+4*80h],eax +mov edx,esp +mov esp,0x10000 +int 80h +NewInt80h: +xchg esp,edx +cmp edx,0x10000-6 +jnz IsStack16Bit + +Stack selector loaded from GDT: +GDT: +real32_GDT +dq 0 +dw 0xFFFF,0x0000,9A00h,0xCF ; 32-bit code descriptor +dw 0xFFFF,0x0000,9200h,0x8F ; 4 GB data descriptor +dw 0xFFFF,0x0000,9A00h,0x00 ; 16-bit code descriptor +dw 0xFFFF,0x0000,9200h,0xCF ; 32-bit data descriptor stack + + + + + +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/review/1902365 b/results/classifier/118/review/1902365 new file mode 100644 index 000000000..0f9b782ef --- /dev/null +++ b/results/classifier/118/review/1902365 @@ -0,0 +1,483 @@ +user-level: 0.902 +virtual: 0.890 +performance: 0.878 +TCG: 0.868 +hypervisor: 0.868 +mistranslation: 0.868 +risc-v: 0.863 +ppc: 0.859 +KVM: 0.854 +peripherals: 0.843 +graphic: 0.839 +register: 0.831 +x86: 0.824 +device: 0.799 +vnc: 0.798 +network: 0.794 +boot: 0.794 +arm: 0.778 +permissions: 0.775 +VMM: 0.772 +debug: 0.752 +semantic: 0.752 +architecture: 0.721 +socket: 0.705 +i386: 0.682 +PID: 0.679 +files: 0.677 +assembly: 0.662 +kernel: 0.656 +-------------------- +debug: 0.992 +x86: 0.912 +virtual: 0.793 +performance: 0.701 +TCG: 0.136 +hypervisor: 0.116 +user-level: 0.097 +PID: 0.077 +files: 0.028 +register: 0.017 +permissions: 0.011 +semantic: 0.010 +KVM: 0.010 +architecture: 0.008 +device: 0.005 +VMM: 0.005 +kernel: 0.004 +socket: 0.004 +graphic: 0.003 +assembly: 0.002 +peripherals: 0.002 +network: 0.002 +ppc: 0.002 +boot: 0.001 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +3x 100% host CPU core usage while virtual machine is in idle + +My Fedora 33 machine "top" command shows qemu-system-x86_64 process using ~300% CPU, that means 3x CPU cores at 100%. Since the virtual machine (named CentOS 8) is almost in idle (top command inside the VM shows ~0% CPU usage), there must be something wrong. I attach qemu process GDB backtrace, and virtual machine libvirt XML + +Host details: +libvirt-6.6.0-2.fc33.x86_64 +qemu-system-x86-5.1.0-5.fc33.x86_64 +virt-manager-3.1.0-1.fc33.noarch +kernel 5.8.16-300.fc33.x86_64 +CPU: AMD Ryzen 5 3600 + +# gdb qemu-system-x86_64 405756 +GNU gdb (GDB) Fedora 9.2-7.fc33 +Copyright (C) 2020 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-system-x86_64... +Reading symbols from .gnu_debugdata for /usr/bin/qemu-system-x86_64... +(No debugging symbols found in .gnu_debugdata for /usr/bin/qemu-system-x86_64) +Attaching to program: /usr/bin/qemu-system-x86_64, process 405756 +[New LWP 405788] +[New LWP 405798] +[New LWP 405799] +[New LWP 405800] +[New LWP 405801] +[New LWP 405802] +[New LWP 405804] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +0x00007f549d0bdb0e in ppoll () from target:/lib64/libc.so.6 +(gdb) set height 0 +(gdb) set print elements 0 +(gdb) set print frame-arguments all +(gdb) thread apply all backtrace + +Thread 8 (Thread 0x7f53837ff640 (LWP 405804)): +#0 0x00007f549d0bda0f in poll () from target:/lib64/libc.so.6 +#1 0x00007f549e4c2d1e in g_main_context_iterate.constprop () from target:/lib64/libglib-2.0.so.0 +#2 0x00007f549e4716ab in g_main_loop_run () from target:/lib64/libglib-2.0.so.0 +#3 0x00007f549dcfcc66 in red_worker_main.lto_priv () from target:/lib64/libspice-server.so.1 +#4 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#5 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 7 (Thread 0x7f5390dfd640 (LWP 405802)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 6 (Thread 0x7f53915fe640 (LWP 405801)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 5 (Thread 0x7f5391dff640 (LWP 405800)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 4 (Thread 0x7f54988b7640 (LWP 405799)): +#0 0x00007f549d0bf58b in ioctl () from target:/lib64/libc.so.6 +#1 0x000055a60728ec87 in kvm_vcpu_ioctl () +#2 0x000055a60728edc1 in kvm_cpu_exec () +#3 0x000055a60734dc04 in qemu_kvm_cpu_thread_fn () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 3 (Thread 0x7f549917b640 (LWP 405798)): +#0 0x00007f549d0bda0f in poll () from target:/lib64/libc.so.6 +#1 0x00007f549e4c2d1e in g_main_context_iterate.constprop () from target:/lib64/libglib-2.0.so.0 +#2 0x00007f549e4716ab in g_main_loop_run () from target:/lib64/libglib-2.0.so.0 +#3 0x000055a6073c4c81 in iothread_run () +#4 0x000055a6076dc0ff in qemu_thread_start () +#5 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#6 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 2 (Thread 0x7f549b93a640 (LWP 405788)): +#0 0x00007f549d0c350d in syscall () from target:/lib64/libc.so.6 +#1 0x000055a6076dce9a in qemu_event_wait () +#2 0x000055a6076e56ca in call_rcu_thread () +#3 0x000055a6076dc0ff in qemu_thread_start () +#4 0x00007f549d19c3f9 in start_thread () from target:/lib64/libpthread.so.0 +#5 0x00007f549d0c8b03 in clone () from target:/lib64/libc.so.6 + +Thread 1 (Thread 0x7f549bb10f00 (LWP 405756)): +#0 0x00007f549d0bdb0e in ppoll () from target:/lib64/libc.so.6 +#1 0x000055a6076f4901 in qemu_poll_ns () +#2 0x000055a6076f0485 in main_loop_wait () +#3 0x000055a60735cdd7 in qemu_main_loop () +#4 0x000055a607234a1e in main () +(gdb) + + + + +# virsh dumpxml centos8 +<domain type='kvm' id='1'> + <name>centos8</name> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://centos.org/centos/8"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>4096000</memory> + <currentMemory unit='KiB'>4096000</currentMemory> + <vcpu placement='static'>4</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>EPYC-IBPB</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='clwb'/> + <feature policy='require' name='umip'/> + <feature policy='require' name='rdpid'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='perfctr_core'/> + <feature policy='require' name='clzero'/> + <feature policy='require' name='xsaveerptr'/> + <feature policy='require' name='wbnoinvd'/> + <feature policy='require' name='amd-stibp'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='disable' name='npt'/> + <feature policy='disable' name='nrip-save'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + <feature policy='disable' name='monitor'/> + <feature policy='disable' name='svm'/> + <feature policy='require' name='topoext'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8.qcow2' index='6'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-1.qcow2' index='5'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-2.qcow2' index='4'/> + <backingStore/> + <target dev='vdc' bus='virtio'/> + <alias name='virtio-disk2'/> + <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-3.qcow2' index='3'/> + <backingStore/> + <target dev='vdd' bus='virtio'/> + <alias name='virtio-disk3'/> + <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/centos8-4.qcow2' index='2'/> + <backingStore/> + <target dev='vde' bus='virtio'/> + <alias name='virtio-disk4'/> + <address type='pci' domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu'/> + <target dev='sda' bus='sata'/> + <readonly/> + <alias name='sata0-0-0'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='sata' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'> + <alias name='pcie.0'/> + </controller> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <alias name='pci.1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <alias name='pci.2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <alias name='pci.3'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <alias name='pci.4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <alias name='pci.5'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <alias name='pci.6'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='pci' index='7' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='7' port='0x16'/> + <alias name='pci.7'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> + </controller> + <controller type='pci' index='8' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='8' port='0x17'/> + <alias name='pci.8'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/> + </controller> + <controller type='pci' index='9' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='9' port='0x18'/> + <alias name='pci.9'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='10' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='10' port='0x19'/> + <alias name='pci.10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d4:02:c2'/> + <source network='default' portid='643b50a3-f347-4c2e-995e-7644a7ad0a96' bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/4'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/4'> + <source path='/dev/pts/4'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-centos8/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0' state='connected'/> + <alias name='channel1'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + <image compression='off'/> + </graphics> + <sound model='ich9'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir0'/> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <alias name='redir1'/> + <address type='usb' bus='0' port='3'/> + </redirdev> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </rng> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c571,c902</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c571,c902</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> + +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/review/1902394 b/results/classifier/118/review/1902394 new file mode 100644 index 000000000..b36756d23 --- /dev/null +++ b/results/classifier/118/review/1902394 @@ -0,0 +1,168 @@ +mistranslation: 0.918 +user-level: 0.879 +permissions: 0.878 +hypervisor: 0.821 +KVM: 0.799 +TCG: 0.796 +network: 0.776 +debug: 0.774 +files: 0.773 +virtual: 0.772 +register: 0.768 +kernel: 0.762 +socket: 0.762 +peripherals: 0.755 +architecture: 0.747 +graphic: 0.747 +device: 0.743 +assembly: 0.738 +risc-v: 0.732 +semantic: 0.730 +performance: 0.730 +PID: 0.724 +arm: 0.723 +ppc: 0.711 +VMM: 0.707 +x86: 0.703 +boot: 0.702 +vnc: 0.686 +i386: 0.572 +-------------------- +hypervisor: 0.971 +virtual: 0.970 +KVM: 0.953 +performance: 0.884 +kernel: 0.828 +debug: 0.674 +x86: 0.670 +PID: 0.505 +assembly: 0.500 +socket: 0.375 +architecture: 0.252 +boot: 0.132 +user-level: 0.080 +register: 0.056 +semantic: 0.038 +files: 0.012 +device: 0.007 +VMM: 0.007 +TCG: 0.006 +risc-v: 0.005 +ppc: 0.003 +permissions: 0.003 +graphic: 0.002 +peripherals: 0.002 +network: 0.001 +vnc: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +Guest stuck in Paused state right after created It + +Im using Centos 8 . I have try to use many Distribution such as : Centos, Ubuntum, Debian,.. on the guest but still all the the VM get into paused state immidiately after using virt-install ( I have tried using virt-manager too ) + +CPU INFO : +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0-7 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 8 +NUMA node(s): 1 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 85 +Model name: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz +Stepping: 7 +CPU MHz: 2199.998 +BogoMIPS: 4399.99 +Virtualization: VT-x +Hypervisor vendor: KVM +Virtualization type: full +L1d cache: 32K +L1i cache: 32K +L2 cache: 4096K +L3 cache: 16384K +NUMA node0 CPU(s): 0-7 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f rdseed adx smap clflushopt clwb avx512cd xsaveopt xsavec xgetbv1 arat + +VM Log : + +2020-10-31 08:29:51.737+0000: starting up libvirt version: 4.5.0, package: 42.module_el8.2.0+320+13f867d7 (CentOS Buildsys <email address hidden>, 2020-05-28-17:13:31, ), qemu version: 2.12.0qemu-kvm-2.12.0-99.module_el8.2.0+524+f765f7e0.4, kernel: 4.18.0-193.28.1.el8_2.x86_64, hostname: interns.novalocal +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=cirros,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-18-cirros/master-key.aes -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Cascadelake-Server,ss=on,hypervisor=on,tsc-adjust=on,arch-capabilities=on,ibpb=on,skip-l1dfl-vmentry=on,invpcid=off,avx512dq=off,avx512bw=off,avx512vl=off,pku=off,avx512vnni=off,pdpe1gb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ef9573a3-a02d-4ef0-86cb-e38da7b7b20d -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=29,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/kvm/cirros-0.3.0-x86_64-disk.img,format=qcow2,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=31,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:c3:32:b0,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2020-10-31T08:29:51.815604Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/1 (label charserial0) +KVM: exception 0 exit (error code 0x0) +EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050656 +ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 +EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 00000000 0000ffff 00009300 +CS =f000 ffff0000 0000ffff 00009b00 +SS =0000 00000000 0000ffff 00009300 +DS =0000 00000000 0000ffff 00009300 +FS =0000 00000000 0000ffff 00009300 +GS =0000 00000000 0000ffff 00009300 +LDT=0000 00000000 0000ffff 00008200 +TR =0000 00000000 0000ffff 00008b00 +GDT= 00000000 0000ffff +IDT= 00000000 0000ffff +CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=06 66 05 00 00 01 00 8e c1 26 66 a3 74 f0 66 5b 66 5e 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + +The Error I have when try to resume the Guest with Virt Manager : + +Error unpausing domain: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + +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/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1311, in resume + self._backend.resume() + File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2012, in resume + if ret == -1: raise libvirtError ('virDomainResume() failed', dom=self) +libvirt.libvirtError: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required + + +Any help would be so helpful cause I stuck in this case for like 4 days already. + +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/review/1902777 b/results/classifier/118/review/1902777 new file mode 100644 index 000000000..b7d06c7ff --- /dev/null +++ b/results/classifier/118/review/1902777 @@ -0,0 +1,107 @@ +x86: 0.889 +hypervisor: 0.884 +user-level: 0.878 +graphic: 0.866 +performance: 0.865 +files: 0.838 +architecture: 0.825 +device: 0.785 +mistranslation: 0.783 +virtual: 0.772 +permissions: 0.736 +peripherals: 0.722 +debug: 0.705 +PID: 0.687 +network: 0.661 +semantic: 0.651 +VMM: 0.625 +kernel: 0.617 +TCG: 0.608 +ppc: 0.607 +i386: 0.550 +register: 0.550 +arm: 0.541 +KVM: 0.523 +risc-v: 0.493 +socket: 0.480 +vnc: 0.468 +assembly: 0.462 +boot: 0.416 +-------------------- +x86: 0.407 +user-level: 0.101 +virtual: 0.068 +debug: 0.025 +hypervisor: 0.015 +files: 0.012 +TCG: 0.009 +semantic: 0.007 +PID: 0.006 +socket: 0.004 +performance: 0.003 +network: 0.003 +device: 0.002 +register: 0.002 +boot: 0.002 +assembly: 0.002 +architecture: 0.001 +permissions: 0.001 +risc-v: 0.001 +graphic: 0.001 +kernel: 0.001 +vnc: 0.001 +VMM: 0.001 +peripherals: 0.001 +ppc: 0.001 +mistranslation: 0.001 +arm: 0.000 +KVM: 0.000 +i386: 0.000 + +qemu with whpx acceleration crashes with vmx=on + +Under Windows 10, qemu crashes when using whpx acceleration and the vmx=on option. The reported error is + qemu-system-x86_64.exe: WHPX: Unexpected VP exit code 4 +Before the error, it reports + Windows Hypervisor Platform accelerator is operational + +The command line is the following: + "C:\Program Files\qemu\qemu-system-x86_64.exe" -accel whpx -cpu qemu64,vmx=on +It crashes with any model of CPU as long as the "vmx=on" option is added. Without this option it runs fine (but no nested virtualization). + +My processor is an Intel i7-10510U, and I am running Windows 10 2004 (build 19041.572). + +Forgot to say: qemu version 5.1.0 + +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/review/1904317 b/results/classifier/118/review/1904317 new file mode 100644 index 000000000..839ac4ef5 --- /dev/null +++ b/results/classifier/118/review/1904317 @@ -0,0 +1,149 @@ +user-level: 0.871 +graphic: 0.841 +device: 0.819 +semantic: 0.812 +permissions: 0.806 +assembly: 0.806 +network: 0.800 +architecture: 0.799 +peripherals: 0.798 +ppc: 0.795 +socket: 0.792 +arm: 0.792 +PID: 0.791 +mistranslation: 0.787 +register: 0.786 +risc-v: 0.780 +performance: 0.780 +hypervisor: 0.776 +kernel: 0.773 +debug: 0.763 +KVM: 0.748 +VMM: 0.742 +virtual: 0.740 +x86: 0.711 +boot: 0.706 +vnc: 0.704 +files: 0.701 +i386: 0.584 +TCG: 0.551 +-------------------- +x86: 0.864 +kernel: 0.826 +hypervisor: 0.811 +virtual: 0.529 +TCG: 0.278 +debug: 0.263 +register: 0.139 +socket: 0.111 +i386: 0.107 +performance: 0.105 +boot: 0.101 +files: 0.098 +risc-v: 0.091 +PID: 0.089 +architecture: 0.072 +device: 0.059 +ppc: 0.058 +vnc: 0.056 +user-level: 0.040 +KVM: 0.039 +semantic: 0.039 +VMM: 0.032 +network: 0.031 +assembly: 0.027 +arm: 0.019 +permissions: 0.013 +peripherals: 0.005 +graphic: 0.002 +mistranslation: 0.001 + +cpu feature selection is not affected to guest 's cpuid with whpx + +On windows with -accel whpx, "-cpu" is ignored without any messages. +Guest recognizes features as same as host's. + +Confirmed on v5.2.0-rc1. + +I suggest qemu may do, + +- Warn with incompatible -cpu options were given. +- Enhance cpuid handling. + +Background: +I was investigated mmio and block copy issue in Linux kernel. +I met a problem that Linux went ill for touching mmio with whpx. (not with tcg) +I suspect erms(enhanced rep movs) might trigger. +I tried to mask erms on qemu with -feature,erms, but it was ineffective. + +At last, I disabled erms manually, to tweak whpx-all.c to mask erms in cpuid. + +FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of erms. +Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms. + +Cc'ing Sunil (WHPX maintainer). + +On 11/15/20 10:06 AM, Takumi Nakamura wrote: +> Public bug reported: +> +> On windows with -accel whpx, "-cpu" is ignored without any messages. +> Guest recognizes features as same as host's. +> +> Confirmed on v5.2.0-rc1. +> +> I suggest qemu may do, +> +> - Warn with incompatible -cpu options were given. +> - Enhance cpuid handling. +> +> Background: +> I was investigated mmio and block copy issue in Linux kernel. +> I met a problem that Linux went ill for touching mmio with whpx. (not with tcg) +> I suspect erms(enhanced rep movs) might trigger. +> I tried to mask erms on qemu with -feature,erms, but it was ineffective. +> +> At last, I disabled erms manually, to tweak whpx-all.c to mask erms in +> cpuid. +> +> FYI, qemu with whpx from/to mmio, "rep movsb" does byte access regardless of erms. +> Linux kernel tends to choose not "rep movsq" but "rep movsb" with erms. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +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/review/1904464 b/results/classifier/118/review/1904464 new file mode 100644 index 000000000..63bf1b113 --- /dev/null +++ b/results/classifier/118/review/1904464 @@ -0,0 +1,116 @@ +user-level: 0.833 +graphic: 0.809 +semantic: 0.807 +kernel: 0.800 +mistranslation: 0.798 +architecture: 0.751 +files: 0.693 +performance: 0.662 +PID: 0.648 +permissions: 0.646 +hypervisor: 0.623 +virtual: 0.613 +device: 0.566 +debug: 0.554 +socket: 0.542 +ppc: 0.535 +network: 0.534 +peripherals: 0.521 +x86: 0.520 +TCG: 0.516 +VMM: 0.508 +vnc: 0.499 +KVM: 0.480 +register: 0.479 +risc-v: 0.476 +assembly: 0.449 +i386: 0.408 +arm: 0.408 +boot: 0.348 +-------------------- +kernel: 0.733 +hypervisor: 0.124 +TCG: 0.121 +files: 0.052 +x86: 0.049 +PID: 0.041 +debug: 0.029 +virtual: 0.028 +ppc: 0.021 +arm: 0.018 +boot: 0.016 +semantic: 0.016 +performance: 0.015 +network: 0.013 +architecture: 0.011 +device: 0.010 +register: 0.007 +user-level: 0.006 +peripherals: 0.005 +permissions: 0.005 +assembly: 0.004 +risc-v: 0.004 +socket: 0.003 +vnc: 0.002 +graphic: 0.002 +i386: 0.002 +VMM: 0.002 +KVM: 0.001 +mistranslation: 0.001 + +Build fails with 64 bits time_t + +time element is deprecated on new input_event structure in kernel's +input.h [1] + +This will avoid the following build failure: + +hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status': +hw/input/virtio-input-host.c:198:28: error: 'struct input_event' has no member named 'time' + 198 | if (gettimeofday(&evdev.time, NULL)) { + | ^ + +Fixes: + - http://autobuild.buildroot.org/results/a538167e288c14208d557cd45446df86d3d599d5 + - http://autobuild.buildroot.org/results/efd4474fb4b6c0ce0ab3838ce130429c51e43bbb + +[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f + + + +Please send patches to the qemu-devel mailing list (and CC: the corresponding maintainers) for proper review of your patch. See https://wiki.qemu.org/Contribute/SubmitAPatch for details. Thanks! + +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. + + +Fabrice, thanks for moving the ticket here: +https://gitlab.com/qemu-project/qemu/-/issues/246 +... so I'm closing this one on Launchpad now. + diff --git a/results/classifier/118/review/1904652 b/results/classifier/118/review/1904652 new file mode 100644 index 000000000..43c839797 --- /dev/null +++ b/results/classifier/118/review/1904652 @@ -0,0 +1,145 @@ +user-level: 0.856 +hypervisor: 0.821 +graphic: 0.819 +device: 0.816 +permissions: 0.815 +semantic: 0.813 +architecture: 0.776 +i386: 0.767 +register: 0.749 +virtual: 0.746 +debug: 0.744 +arm: 0.743 +performance: 0.733 +assembly: 0.725 +mistranslation: 0.723 +peripherals: 0.712 +vnc: 0.692 +network: 0.681 +PID: 0.679 +x86: 0.673 +files: 0.661 +ppc: 0.650 +kernel: 0.647 +socket: 0.633 +risc-v: 0.631 +VMM: 0.611 +TCG: 0.593 +boot: 0.575 +KVM: 0.551 +-------------------- +hypervisor: 0.938 +virtual: 0.491 +TCG: 0.091 +files: 0.068 +kernel: 0.064 +PID: 0.049 +x86: 0.021 +debug: 0.014 +performance: 0.013 +assembly: 0.013 +i386: 0.012 +device: 0.011 +semantic: 0.007 +ppc: 0.007 +peripherals: 0.005 +architecture: 0.005 +register: 0.004 +arm: 0.004 +KVM: 0.004 +boot: 0.003 +user-level: 0.003 +graphic: 0.002 +risc-v: 0.002 +VMM: 0.002 +network: 0.002 +permissions: 0.001 +vnc: 0.001 +socket: 0.001 +mistranslation: 0.000 + +Assertion failure in usb-ohci + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ohci. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + +-------- + +``` + +Program terminated with signal SIGABRT, Aborted. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7f34d0411440 (LWP 9418))] +gdb-peda$ bt +#0 0x00007f34c8d4ef47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f34c8d508b1 in __GI_abort () at abort.c:79 +#2 0x000055d3a2081844 in ohci_frame_boundary (opaque=0x55d3a4ecdaf0) at ../hw/usb/hcd-ohci.c:1297 +#3 0x000055d3a25be155 in timerlist_run_timers (timer_list=0x55d3a3fd9840) at ../util/qemu-timer.c:574 +#4 0x000055d3a25beaba in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#5 0x000055d3a25beaba in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#6 0x000055d3a25e69a1 in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531 +#7 0x000055d3a2433972 in qemu_main_loop () at ../softmmu/vl.c:1678 +#8 0x000055d3a1d0969b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, + argv@entry=0x7ffc6de722a8, envp=<optimized out>) at ../softmmu/main.c:50 +#9 0x00007f34c8d31b97 in __libc_start_main (main= + 0x55d3a1d09690 <main>, argc=0x15, argv=0x7ffc6de722a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc6de72298) at ../csu/libc-start.c:310 +#10 0x000055d3a1d095aa in _start () +``` + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` +[Terminal 1] + +$ qemu-system-i386 -m 512 -drive file=./fs.img,index=1,media=disk,format=raw -drive file=./hyfuzz.img,index=0,media=disk,format=raw -drive if=none,id=stick,file=./usbdisk.img,format=raw -device pci-ohci,id=usb -device usb-storage,bus=usb.0,drive=stick + +[Terminal 2] + +$ ./repro_log ./fs.img ./pci-ohci + +``` + +Please let me know if I can provide any further info. +-Cheolwoo, Myung (Seoul National University) + + + +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/review/1905 b/results/classifier/118/review/1905 new file mode 100644 index 000000000..44ce8155e --- /dev/null +++ b/results/classifier/118/review/1905 @@ -0,0 +1,63 @@ +architecture: 0.910 +device: 0.879 +network: 0.634 +performance: 0.562 +kernel: 0.509 +arm: 0.508 +socket: 0.490 +peripherals: 0.480 +VMM: 0.469 +ppc: 0.446 +risc-v: 0.440 +boot: 0.433 +semantic: 0.422 +assembly: 0.400 +debug: 0.375 +KVM: 0.374 +i386: 0.346 +permissions: 0.334 +PID: 0.326 +TCG: 0.305 +vnc: 0.296 +graphic: 0.294 +register: 0.257 +x86: 0.223 +hypervisor: 0.186 +mistranslation: 0.182 +virtual: 0.106 +user-level: 0.044 +files: 0.008 +-------------------- +peripherals: 0.418 +register: 0.234 +TCG: 0.159 +kernel: 0.150 +user-level: 0.132 +hypervisor: 0.124 +x86: 0.083 +virtual: 0.079 +network: 0.071 +ppc: 0.060 +device: 0.052 +files: 0.036 +socket: 0.026 +semantic: 0.021 +VMM: 0.020 +i386: 0.018 +arm: 0.015 +risc-v: 0.015 +permissions: 0.014 +debug: 0.014 +assembly: 0.012 +KVM: 0.011 +architecture: 0.007 +vnc: 0.004 +PID: 0.004 +performance: 0.002 +graphic: 0.002 +boot: 0.002 +mistranslation: 0.000 + +Allow for copying text from serial output +Additional information: +In addition to the serial output, it would be beneficial if this copy feature could also be extended to the QEMU monitor and parallel output. diff --git a/results/classifier/118/review/1905521 b/results/classifier/118/review/1905521 new file mode 100644 index 000000000..55099837c --- /dev/null +++ b/results/classifier/118/review/1905521 @@ -0,0 +1,205 @@ +user-level: 0.901 +peripherals: 0.898 +risc-v: 0.878 +ppc: 0.828 +mistranslation: 0.809 +vnc: 0.808 +device: 0.789 +hypervisor: 0.782 +VMM: 0.780 +x86: 0.775 +KVM: 0.773 +register: 0.758 +graphic: 0.744 +permissions: 0.743 +TCG: 0.742 +debug: 0.731 +performance: 0.731 +virtual: 0.723 +boot: 0.696 +i386: 0.693 +architecture: 0.686 +semantic: 0.683 +assembly: 0.666 +files: 0.666 +arm: 0.645 +network: 0.632 +socket: 0.623 +PID: 0.615 +kernel: 0.611 +-------------------- +x86: 0.953 +debug: 0.945 +kernel: 0.944 +hypervisor: 0.221 +performance: 0.139 +TCG: 0.091 +virtual: 0.083 +architecture: 0.074 +PID: 0.066 +boot: 0.028 +device: 0.027 +files: 0.026 +user-level: 0.023 +semantic: 0.017 +KVM: 0.014 +assembly: 0.010 +register: 0.008 +i386: 0.008 +ppc: 0.007 +vnc: 0.006 +network: 0.005 +VMM: 0.005 +risc-v: 0.004 +socket: 0.004 +peripherals: 0.002 +graphic: 0.002 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.001 + +assert issue locates in hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed + +Hello, + +I found an assertion failure in hw/scsi/lsi53c895a.c:624 + +This was found in latest version 5.2.0. + + +my reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + + + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device lsi53c895a -trace lsi\* + +Backtrace is as follows: +#0 0x00007f845c6eff47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f845c6f18b1 in __GI_abort () at abort.c:79 +#2 0x00007f845c6e142a in __assert_fail_base (fmt=0x7f845c868a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a1034486a0 "s->current", file=file@entry=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=line@entry=624, function=function@entry=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:92 +#3 0x00007f845c6e14a2 in __GI___assert_fail (assertion=0x55a1034486a0 "s->current", file=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=624, function=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:101 +#4 0x000055a102049c65 in lsi_do_dma (s=0x62600000c100, out=1) at ../hw/scsi/lsi53c895a.c:624 +#5 0x000055a102051573 in lsi_execute_script (s=0x62600000c100) at ../hw/scsi/lsi53c895a.c:1250 +#6 0x000055a10205b05d in lsi_reg_writeb (s=0x62600000c100, offset=47, val=178 '\262') at ../hw/scsi/lsi53c895a.c:1984 +#7 0x000055a10205fef8 in lsi_io_write (opaque=0x62600000c100, addr=47, val=178, size=1) at ../hw/scsi/lsi53c895a.c:2146 +#8 0x000055a102d1b791 in memory_region_write_accessor (mr=0x62600000cbe0, addr=47, value=0x7f8349dfe2f8, size=1, shift=0, mask=255, attrs=...) at ../softmmu/memory.c:484 +#9 0x000055a102d1bba8 in access_with_adjusted_size (addr=47, value=0x7f8349dfe2f8, size=1, access_size_min=1, access_size_max=1, access_fn=0x55a102d1b4de <memory_region_write_accessor>, mr=0x62600000cbe0, attrs=...) at ../softmmu/memory.c:545 +#10 0x000055a102d261ef in memory_region_dispatch_write (mr=0x62600000cbe0, addr=47, data=178, op=MO_8, attrs=...) at ../softmmu/memory.c:1494 +#11 0x000055a102b57c3c in flatview_write_continue (fv=0x6060000ea920, addr=49199, attrs=..., ptr=0x7f8449efb000, len=1, addr1=47, l=1, mr=0x62600000cbe0) at ../softmmu/physmem.c:2767 +#12 0x000055a102b57f07 in flatview_write (fv=0x6060000ea920, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2807 +#13 0x000055a102b587cb in address_space_write (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2899 +#14 0x000055a102b58878 in address_space_rw (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1, is_write=true) at ../softmmu/physmem.c:2909 +#15 0x000055a102ad4d50 in kvm_handle_io (port=49199, attrs=..., data=0x7f8449efb000, direction=1, size=1, count=1) at ../accel/kvm/kvm-all.c:2283 +#16 0x000055a102ad6a0f in kvm_cpu_exec (cpu=0x62e000000400) at ../accel/kvm/kvm-all.c:2529 +#17 0x000055a102c26fbb in kvm_vcpu_thread_fn (arg=0x62e000000400) at ../accel/kvm/kvm-cpus.c:49 +#18 0x000055a1032c08f8 in qemu_thread_start (args=0x603000082780) at ../util/qemu-thread-posix.c:521 +#19 0x00007f845caa96db in start_thread (arg=0x7f8349dff700) at pthread_create.c:463 +#20 0x00007f845c7d2a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +The poc is attached. + + + +Cc'ing Fam directly because his launchpad account +contact points to invalid email address. + +On 11/25/20 8:22 AM, Gaoning Pan wrote: +> Public bug reported: +> +> Hello, +> +> I found an assertion failure in hw/scsi/lsi53c895a.c:624 +> +> This was found in latest version 5.2.0. +> +> +> my reproduced environment is as follows: +> Host: ubuntu 18.04 +> Guest: ubuntu 18.04 +> +> +> QEMU boot command line: +> qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -display none -device lsi53c895a -trace lsi\* +> +> Backtrace is as follows: +> #0 0x00007f845c6eff47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +> #1 0x00007f845c6f18b1 in __GI_abort () at abort.c:79 +> #2 0x00007f845c6e142a in __assert_fail_base (fmt=0x7f845c868a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a1034486a0 "s->current", file=file@entry=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=line@entry=624, function=function@entry=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:92 +> #3 0x00007f845c6e14a2 in __GI___assert_fail (assertion=0x55a1034486a0 "s->current", file=0x55a103448360 "../hw/scsi/lsi53c895a.c", line=624, function=0x55a10344ae60 <__PRETTY_FUNCTION__.31674> "lsi_do_dma") at assert.c:101 +> #4 0x000055a102049c65 in lsi_do_dma (s=0x62600000c100, out=1) at ../hw/scsi/lsi53c895a.c:624 +> #5 0x000055a102051573 in lsi_execute_script (s=0x62600000c100) at ../hw/scsi/lsi53c895a.c:1250 +> #6 0x000055a10205b05d in lsi_reg_writeb (s=0x62600000c100, offset=47, val=178 '\262') at ../hw/scsi/lsi53c895a.c:1984 +> #7 0x000055a10205fef8 in lsi_io_write (opaque=0x62600000c100, addr=47, val=178, size=1) at ../hw/scsi/lsi53c895a.c:2146 +> #8 0x000055a102d1b791 in memory_region_write_accessor (mr=0x62600000cbe0, addr=47, value=0x7f8349dfe2f8, size=1, shift=0, mask=255, attrs=...) at ../softmmu/memory.c:484 +> #9 0x000055a102d1bba8 in access_with_adjusted_size (addr=47, value=0x7f8349dfe2f8, size=1, access_size_min=1, access_size_max=1, access_fn=0x55a102d1b4de <memory_region_write_accessor>, mr=0x62600000cbe0, attrs=...) at ../softmmu/memory.c:545 +> #10 0x000055a102d261ef in memory_region_dispatch_write (mr=0x62600000cbe0, addr=47, data=178, op=MO_8, attrs=...) at ../softmmu/memory.c:1494 +> #11 0x000055a102b57c3c in flatview_write_continue (fv=0x6060000ea920, addr=49199, attrs=..., ptr=0x7f8449efb000, len=1, addr1=47, l=1, mr=0x62600000cbe0) at ../softmmu/physmem.c:2767 +> #12 0x000055a102b57f07 in flatview_write (fv=0x6060000ea920, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2807 +> #13 0x000055a102b587cb in address_space_write (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1) at ../softmmu/physmem.c:2899 +> #14 0x000055a102b58878 in address_space_rw (as=0x55a105ebca80 <address_space_io>, addr=49199, attrs=..., buf=0x7f8449efb000, len=1, is_write=true) at ../softmmu/physmem.c:2909 +> #15 0x000055a102ad4d50 in kvm_handle_io (port=49199, attrs=..., data=0x7f8449efb000, direction=1, size=1, count=1) at ../accel/kvm/kvm-all.c:2283 +> #16 0x000055a102ad6a0f in kvm_cpu_exec (cpu=0x62e000000400) at ../accel/kvm/kvm-all.c:2529 +> #17 0x000055a102c26fbb in kvm_vcpu_thread_fn (arg=0x62e000000400) at ../accel/kvm/kvm-cpus.c:49 +> #18 0x000055a1032c08f8 in qemu_thread_start (args=0x603000082780) at ../util/qemu-thread-posix.c:521 +> #19 0x00007f845caa96db in start_thread (arg=0x7f8349dff700) at pthread_create.c:463 +> #20 0x00007f845c7d2a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +> +> +> The poc is attached. +> +> ** Affects: qemu +> Importance: Undecided +> Assignee: Gaoning Pan (hades0506) +> Status: New +> +> ** Attachment added: "lsi-assert.c" +> https://bugs.launchpad.net/bugs/1905521/+attachment/5437756/+files/lsi-assert.c +> +> ** Changed in: qemu +> Assignee: (unassigned) => Gaoning Pan (hades0506) +> + + + +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 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/552 + + diff --git a/results/classifier/118/review/1905562 b/results/classifier/118/review/1905562 new file mode 100644 index 000000000..71c53c225 --- /dev/null +++ b/results/classifier/118/review/1905562 @@ -0,0 +1,127 @@ +semantic: 0.939 +graphic: 0.918 +mistranslation: 0.905 +peripherals: 0.883 +permissions: 0.881 +user-level: 0.866 +architecture: 0.855 +debug: 0.854 +performance: 0.852 +TCG: 0.848 +virtual: 0.821 +socket: 0.816 +files: 0.816 +register: 0.807 +assembly: 0.806 +device: 0.802 +arm: 0.800 +ppc: 0.799 +vnc: 0.784 +KVM: 0.768 +hypervisor: 0.763 +network: 0.760 +VMM: 0.730 +risc-v: 0.727 +PID: 0.724 +kernel: 0.700 +boot: 0.673 +x86: 0.577 +i386: 0.504 +-------------------- +KVM: 0.980 +debug: 0.924 +virtual: 0.786 +hypervisor: 0.555 +register: 0.347 +performance: 0.337 +kernel: 0.115 +x86: 0.105 +PID: 0.049 +files: 0.024 +TCG: 0.018 +device: 0.014 +user-level: 0.010 +assembly: 0.008 +architecture: 0.007 +network: 0.006 +ppc: 0.005 +i386: 0.003 +semantic: 0.003 +VMM: 0.003 +socket: 0.003 +peripherals: 0.002 +permissions: 0.002 +vnc: 0.002 +arm: 0.002 +graphic: 0.001 +risc-v: 0.001 +boot: 0.001 +mistranslation: 0.000 + +Guest seems suspended after host freed memory for it using oom-killer + +Host: qemu 5.1.0, linux 5.5.13 +Guest: Windows 7 64-bit + +This guest ran a memory intensive process, and triggered oom-killer on host. Luckily, it killed chromium. My understanding is this should mean qemu should have continued running unharmed. But, the spice connection shows the host system clock is stuck at the exact time oom-killer was triggered. The host is completely unresponsive. + +I can telnet to the qemu monitor. "info status" shows "running". But, multiple times running "info registers -a" and saving the output to text files shows the registers are 100% unchanged, so it's not really running. + +On the host, top shows around 4% CPU usage by qemu. strace shows about 1,000 times a second, these 6 lines repeat: + +0.000698 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c10) = 0 <0.000010> +0.000034 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c60) = 0 <0.000009> +0.000031 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c20) = 0 <0.000007> +0.000028 ioctl(18, KVM_IRQ_LINE_STATUS, 0x7fff1f030c70) = 0 <0.000007> +0.000030 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events =POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, tv_nsec=0}, NULL, 8) = 0 (Timeout) <0.000009> +0.000043 ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events =POLLIN}, {fd=16, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLI N}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}], 16, {tv_sec=0, tv_nsec=769662}, NULL, 8) = 0 (Tim eout) <0.000788> + +In the monitor, "info irq" shows IRQ 0 is increasing about 1,000 times a second. IRQ 0 seems to be for the system clock, and 1,000 times a second seems to be the frequency a windows 7 guest might have the clock at. + +Those fd's are for: (9) [eventfd]; [signalfd], type=STREAM, 4 x the spice socket file, and "TCP localhost:ftnmtp->localhost:36566 (ESTABLISHED)". + +Because the guest's registers aren't changing, it seems to me like monitor thinks the VM is running, but it's actually effectively in a paused state. I think all the strace activity shown above must be generated by the host. Perhaps it's repeatedly trying to contact the guest to inject a new clock, and communicate with it on the various eventfd's, spice socket, etc. So, I'm thinking the strace doesn't give any information about the real reason why the VM is acting as if it's paused. + +I've checked "info block", and there's nothing showing that a device is paused, or that there's any issues with them. (Can't remember what term can be there, but a paused/blocked/etc block device I think caused a VM to act like this for me in the past.) + + +Is there something I can provide to help fix the bug here? + +Is there something I can do, to try to get the VM running again? (I sadly have unsaved work in it.) + + + +Am I correct to expect the VM to continue successfully, after oom-killer successfully freed up memory? This journactl does show a calltrace which includes "vmx_vmexit", and I'm not sure what that function is for but looks a little worrisome. + +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/review/1905979 b/results/classifier/118/review/1905979 new file mode 100644 index 000000000..6dc6fcda3 --- /dev/null +++ b/results/classifier/118/review/1905979 @@ -0,0 +1,115 @@ +semantic: 0.910 +permissions: 0.900 +performance: 0.868 +mistranslation: 0.868 +device: 0.867 +peripherals: 0.857 +graphic: 0.854 +assembly: 0.849 +architecture: 0.843 +network: 0.834 +debug: 0.820 +PID: 0.812 +VMM: 0.808 +TCG: 0.807 +ppc: 0.802 +vnc: 0.795 +files: 0.788 +arm: 0.781 +socket: 0.778 +KVM: 0.775 +risc-v: 0.774 +register: 0.770 +boot: 0.765 +virtual: 0.758 +hypervisor: 0.756 +user-level: 0.754 +kernel: 0.708 +x86: 0.659 +i386: 0.626 +-------------------- +virtual: 0.085 +debug: 0.049 +files: 0.027 +VMM: 0.015 +hypervisor: 0.012 +x86: 0.010 +user-level: 0.008 +kernel: 0.006 +i386: 0.003 +performance: 0.003 +ppc: 0.003 +TCG: 0.003 +device: 0.003 +register: 0.003 +semantic: 0.002 +permissions: 0.002 +risc-v: 0.002 +vnc: 0.002 +PID: 0.001 +boot: 0.001 +architecture: 0.001 +assembly: 0.001 +KVM: 0.001 +arm: 0.001 +network: 0.001 +graphic: 0.001 +mistranslation: 0.000 +socket: 0.000 +peripherals: 0.000 + +Check if F_OFD_SETLK is supported may give wrong result + +In util/osdep.c there is a function qemu_probe_lock_ops() to check if file locks F_OFD_SETLK and F_OFD_GETLK (of the style "Open file description locks (non-POSIX)") are supported. + +This test is done by trying a lock operation on the file /dev/null. + +This test can get a wrong result. + +The result is (probably) if the operating system *in general* supports these locks. However, it does not guarantee that the file system where the lock is really wanted (for instance, in caller raw_check_lock_bytes() in block/file-posix.c) does support these locks. + +(In theory it could even be that /dev/null, being a device special file, does not support the lock type while a plain file would.) + +This is in particular relevant for disk images which are stored on a shared file system (my particular use case is the Quobyte file system, which appears not to support these locks). + +The code as mentioned above is present in the master branch (I checked commit ea8208249d1082eae0444934efb3b59cd3183f05) but also for example on stable-2.11 commit 0982a56a551556c704dc15752dabf57b4be1c640) + +This is rather serious, since it causes VMs to crash: + +Unexpected error in raw_check_lock_bytes() at /build/qemu-PKI6mj/qemu-4.2/block/file-posix.c:796: +Failed to get "write" lock +2020-11-23 11:32:27.810+0000: shutting down, reason=crashed + +when openstack attempts to create a snapshot. + +In this thread, it is pointed out that support for OFD is provided by the generic VFS layer in the kernel, so there should never be a situation where one filesystem supports OFD and another does not support OFD: + + https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05264.html + +Can you say what filesystem you are using that exhibits the lack of OFD support, and what kernel version + +Interesting. Thanks for the link. + +The file system we are using is the Quobyte file system (2.24.1) (https://www.quobyte.com/), which works via FUSE. +We've had problems with OFD locks with this file system in the past, so my first thought, seeing the error in comment #1, was that those would be to blame. + +But if the OFD locks are not really handled by the file system, I'm not sure how that explains the OFD lock issues we had in the past. I don't suppose this changed in the last year or so. Just now I made a little test program (basically copying qemu_lock_fd_test() and qemu_probe_lock_ops() from qemu) to double-check, and indeed right now it seems that the OFD locks *are* working on the Quobyte file system. Or at least qemu_lock_fd_test() doesn't return an error. + +So now I'm back to square one on diagnosing the observed error. It occurred in an installation of Openstack Ussuri installed on Ubuntu 18.04 Bionic using the Ubuntu Cloud Archive for packaging. The Cloud Archive has backports of the latest Qemu to earlier Ubuntu versions. The exact qemu version was http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/q/qemu/qemu_4.2-3ubuntu6.7~cloud0_amd64.deb . + +Annoyingly I have not been able to locate the git repo from which the Ubuntu Cloud Archive creates its packages (containing the patches and build changes for backports); all I can find is version 4.2-3ubuntu6.7 (without ~cloud0) which is for Ubuntu 20.04 Focal. + +For now we're working around it by downgrading Qemu to the normal Bionic version (2.11+dfsg-1ubuntu7.33) + +You wouldn't happen to know where the Ubuntu Cloud Archive stores exact files it creates its packages from? (I have already asked on stackoverflow without success so far: https://stackoverflow.com/questions/65146846/from-which-git-repos-does-the-ubuntu-cloud-archive-compile-its-packages) + + + +Look in the same directory as that .deb link above - the the files ending in orig.tar.gz (upstream source) and files ending in debian.tar.xz (downstream modifications) + +The kernel version is Linux hostname 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +That is indeed the source and patches, but I wanted to follow their git repo for easier maintenance. Surely they must have one. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/1906608 b/results/classifier/118/review/1906608 new file mode 100644 index 000000000..93d42a8da --- /dev/null +++ b/results/classifier/118/review/1906608 @@ -0,0 +1,110 @@ +register: 0.906 +device: 0.855 +performance: 0.826 +ppc: 0.816 +graphic: 0.783 +peripherals: 0.779 +user-level: 0.733 +PID: 0.721 +semantic: 0.697 +mistranslation: 0.678 +permissions: 0.661 +files: 0.625 +kernel: 0.622 +network: 0.620 +architecture: 0.584 +arm: 0.505 +socket: 0.504 +hypervisor: 0.503 +debug: 0.498 +TCG: 0.491 +vnc: 0.483 +VMM: 0.460 +x86: 0.450 +virtual: 0.421 +assembly: 0.418 +boot: 0.369 +i386: 0.362 +KVM: 0.354 +risc-v: 0.315 +-------------------- +x86: 0.039 +TCG: 0.036 +files: 0.026 +virtual: 0.024 +semantic: 0.017 +debug: 0.016 +peripherals: 0.015 +user-level: 0.013 +hypervisor: 0.010 +arm: 0.009 +performance: 0.006 +register: 0.006 +ppc: 0.005 +PID: 0.005 +device: 0.005 +risc-v: 0.005 +network: 0.005 +permissions: 0.003 +i386: 0.003 +assembly: 0.003 +architecture: 0.003 +boot: 0.002 +VMM: 0.002 +kernel: 0.002 +graphic: 0.001 +vnc: 0.001 +socket: 0.001 +mistranslation: 0.001 +KVM: 0.000 + + [Feature request]For some ehci controller, qemu should implement using portsc[26-27] to detect the speed of device. + +for some ehci controller ,for example ehci controller on fsl_imx6,it using portsc[26-27] to decide a full speed device or high speed device was connected, hub-ehci.c should set the portsc[26-27] to return the right speed. + +line:1001 in hub-ehci.c + if (dev && dev->attached && (dev->speedmask & USB_SPEED_MASK_HIGH)) { + val |= PORTSC_PED; + } + +below is the spec for fsl_imx6 USB PART. +PORTSC:27–26 :PSPD +Port Speed - Read Only. +This register field indicates the speed at which the port is operating. +00 Full Speed +01 Low Speed +10 High Speed +11 Undefined + +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/review/1907 b/results/classifier/118/review/1907 new file mode 100644 index 000000000..c12d26d51 --- /dev/null +++ b/results/classifier/118/review/1907 @@ -0,0 +1,117 @@ +user-level: 0.856 +risc-v: 0.833 +permissions: 0.830 +mistranslation: 0.823 +peripherals: 0.812 +hypervisor: 0.811 +KVM: 0.770 +semantic: 0.747 +ppc: 0.739 +graphic: 0.730 +i386: 0.726 +vnc: 0.724 +PID: 0.713 +VMM: 0.713 +TCG: 0.710 +virtual: 0.706 +architecture: 0.690 +register: 0.690 +arm: 0.685 +x86: 0.681 +debug: 0.678 +performance: 0.667 +assembly: 0.665 +boot: 0.657 +device: 0.651 +network: 0.638 +kernel: 0.630 +files: 0.624 +socket: 0.622 +-------------------- +kernel: 0.948 +debug: 0.785 +boot: 0.756 +virtual: 0.638 +PID: 0.173 +x86: 0.071 +files: 0.061 +TCG: 0.043 +i386: 0.022 +register: 0.015 +assembly: 0.015 +hypervisor: 0.013 +performance: 0.006 +VMM: 0.005 +architecture: 0.005 +device: 0.005 +semantic: 0.003 +user-level: 0.002 +graphic: 0.002 +arm: 0.002 +socket: 0.001 +ppc: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +network: 0.001 +peripherals: 0.001 +permissions: 0.000 +vnc: 0.000 +KVM: 0.000 + +QEMU LoongArch regression after merging LASX changes +Description of problem: +After enabling LASX in qemu (@gaosong), booting Gentoo Linux with latest glibc master (w/ LSX & LASX optimized libc routines) will fail in systemd: + +``` +[ 10.350207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000085 +[ 10.350557] CPU: 5 PID: 1 Comm: systemd Not tainted 6.5.2-gentoo #2 +[ 10.350655] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 +[ 10.350961] Stack : 0072617764726148 0000000000000000 9000000000223440 90000001000e4000 +[ 10.351181] 90000001000e7990 90000001000e7998 0000000000000000 90000001000e7ad8 +[ 10.351294] 90000001000e7ad0 90000001000e7ad0 90000001000e7900 0000000000000001 +[ 10.351406] 0000000000000001 90000001000e7998 ec94a2e1446052e6 9000000100438140 +[ 10.351519] 0000000000000001 0000000000000003 0000000000000000 0000000000000030 +[ 10.351630] 0000000000000000 00000000000559bf 00000000056e0000 0000000000000004 +[ 10.351745] 0000000000000000 0000000000000000 900000000162b438 900000000177e000 +[ 10.351856] 00000000400004d8 0000000000000001 0000000000000018 90000001000e7c84 +[ 10.351968] 0000000000020000 0000000000000000 9000000000223458 00007ffff0341af0 +[ 10.352081] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c +[ 10.352196] ... +[ 10.352277] Call Trace: +[ 10.352482] [<9000000000223458>] show_stack+0x5c/0x180 +[ 10.353518] [<9000000001178d4c>] dump_stack_lvl+0x60/0x88 +[ 10.353592] [<900000000115cd7c>] panic+0x13c/0x308 +[ 10.353670] [<900000000024244c>] do_exit+0x860/0x868 +[ 10.353735] [<900000000024261c>] do_group_exit+0x34/0x94 +[ 10.353803] [<9000000000250514>] get_signal+0x75c/0x804 +[ 10.353869] [<90000000002254c4>] arch_do_signal_or_restart+0x74/0xae0 +[ 10.353944] [<90000000002c738c>] exit_to_user_mode_loop.isra.0+0x90/0x10c +[ 10.354041] [<9000000001179ff0>] irqentry_exit_to_user_mode+0x1c/0x28 +[ 10.354119] [<90000000011792f8>] do_bp+0xcc/0x2ac +[ 10.354222] [<90000001005a1924>] 0x90000001005a1924 +[ 10.354522] [<00007ffff0341af0>] 0x7ffff0341af0 +``` + +Full log: + +[stderr](/uploads/61b9870ae2441c9a25f44791c67889b8/stderr) + +Instruction trace `-d in_asm,out_asm,op` (very large): + +[log.tar.zstd](https://cloud.tsinghua.edu.cn/f/a83eac6d44694ede8cb1/?dl=1) + +I also tried to boot LoongArchLinux whose glibc does not have LSX/LASX optimized C routines, and it can boot without problems. If I chroot from LoongArchLinux into Gentoo Linux, running `emerge` command will SIGSEGV. + +If I disable LASX in CPUCFG2, the problem is gone: + +```cpp +// data = FIELD_DP32(data, CPUCFG2, LASX, 1), +``` + +I guess the bug is related to LASX assemblies in [glibc](https://github.com/bminor/glibc/tree/master/sysdeps/loongarch/lp64/multiarch). +Steps to reproduce: +1. Launch qemu +2. Wait for systemd to be killed +3. Collect logs +Additional information: + diff --git a/results/classifier/118/review/1907042 b/results/classifier/118/review/1907042 new file mode 100644 index 000000000..93938331a --- /dev/null +++ b/results/classifier/118/review/1907042 @@ -0,0 +1,112 @@ +user-level: 0.849 +permissions: 0.838 +performance: 0.749 +virtual: 0.736 +register: 0.720 +device: 0.708 +architecture: 0.679 +mistranslation: 0.668 +ppc: 0.660 +VMM: 0.652 +graphic: 0.652 +files: 0.648 +KVM: 0.631 +TCG: 0.630 +hypervisor: 0.617 +assembly: 0.617 +x86: 0.608 +peripherals: 0.604 +socket: 0.588 +arm: 0.583 +semantic: 0.578 +vnc: 0.575 +boot: 0.572 +debug: 0.569 +PID: 0.566 +risc-v: 0.549 +network: 0.540 +kernel: 0.465 +i386: 0.444 +-------------------- +x86: 0.936 +debug: 0.921 +kernel: 0.846 +hypervisor: 0.520 +virtual: 0.360 +TCG: 0.203 +architecture: 0.064 +performance: 0.061 +PID: 0.036 +files: 0.031 +boot: 0.022 +KVM: 0.017 +peripherals: 0.013 +device: 0.011 +semantic: 0.009 +assembly: 0.008 +register: 0.008 +i386: 0.007 +VMM: 0.006 +ppc: 0.005 +network: 0.003 +socket: 0.003 +graphic: 0.002 +user-level: 0.002 +arm: 0.002 +vnc: 0.002 +permissions: 0.002 +risc-v: 0.001 +mistranslation: 0.000 + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed + +Hello, + +An assertion failure was found in hw/usb/core.c:727 in latest version 5.2.0. + +Reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +QEMU boot command line: +qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 -trace usb\* + +Backtrace is as follows: +#0 0x00007f13fff14438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 +#1 0x00007f13fff1603a in __GI_abort () at abort.c:89 +#2 0x00007f13fff0cbe7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=file@entry=0x55f97745f6c0 "../hw/usb/core.c", line=line@entry=727, function=function@entry=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:92 +#3 0x00007f13fff0cc92 in __GI___assert_fail (assertion=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x55f97745f6c0 "../hw/usb/core.c", line=727, function=0x55f9774606e0 <__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:101 +#4 0x000055f975bfc9b2 in usb_ep_get (dev=0x62300000c500, pid=45, ep=1) at ../hw/usb/core.c:727 +#5 0x000055f975f945db in ohci_service_td (ohci=0x6270000191f0, ed=0x7ffcd9308410) at ../hw/usb/hcd-ohci.c:1044 +#6 0x000055f975f95d5e in ohci_service_ed_list (ohci=0x6270000191f0, head=857580576, completion=0) at ../hw/usb/hcd-ohci.c:1200 +#7 0x000055f975f9656d in ohci_process_lists (ohci=0x6270000191f0, completion=0) at ../hw/usb/hcd-ohci.c:1238 +#8 0x000055f975f9725c in ohci_frame_boundary (opaque=0x6270000191f0) at ../hw/usb/hcd-ohci.c:1281 +#9 0x000055f977212494 in timerlist_run_timers (timer_list=0x60b00005b060) at ../util/qemu-timer.c:574 +#10 0x000055f9772126db in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at ../util/qemu-timer.c:588 +#11 0x000055f977212fde in qemu_clock_run_all_timers () at ../util/qemu-timer.c:670 +#12 0x000055f9772d5717 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:531 +#13 0x000055f97695100c in qemu_main_loop () at ../softmmu/vl.c:1677 +#14 0x000055f9758f7601 in main (argc=16, argv=0x7ffcd9308888, envp=0x7ffcd9308910) at ../softmmu/main.c:50 +#15 0x00007f13ffeff840 in __libc_start_main (main=0x55f9758f75b0 <main>, argc=16, argv=0x7ffcd9308888, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcd9308878) at ../csu/libc-start.c:291 +#16 0x000055f9758f74a9 in _start () + + +The poc is attached. + +Thanks. + + + +I trigger the usb_ep_get assertion as well, but I think is't not a bug.(I use the ehci) +Maybe the logic is the function return ep_ctl whith USB_TOKEN_SETUP and ep==0.Otherwise, will goto the next. + +This looks like a dupe of https://bugs.launchpad.net/qemu/+bug/1525123/ , though through OHCI rather than XHCI + + +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/303 + + diff --git a/results/classifier/118/review/1907210 b/results/classifier/118/review/1907210 new file mode 100644 index 000000000..7751f1f99 --- /dev/null +++ b/results/classifier/118/review/1907210 @@ -0,0 +1,113 @@ +user-level: 0.825 +graphic: 0.822 +semantic: 0.808 +performance: 0.744 +architecture: 0.711 +debug: 0.711 +permissions: 0.706 +hypervisor: 0.705 +mistranslation: 0.694 +device: 0.676 +network: 0.668 +vnc: 0.665 +socket: 0.664 +PID: 0.650 +TCG: 0.638 +files: 0.626 +peripherals: 0.614 +ppc: 0.594 +register: 0.592 +kernel: 0.579 +VMM: 0.558 +risc-v: 0.541 +assembly: 0.536 +KVM: 0.520 +i386: 0.503 +virtual: 0.501 +x86: 0.491 +arm: 0.430 +boot: 0.404 +-------------------- +user-level: 0.809 +debug: 0.579 +files: 0.133 +TCG: 0.042 +x86: 0.034 +virtual: 0.020 +network: 0.017 +ppc: 0.011 +arm: 0.010 +semantic: 0.010 +performance: 0.007 +risc-v: 0.004 +PID: 0.004 +assembly: 0.003 +i386: 0.003 +socket: 0.002 +device: 0.002 +hypervisor: 0.002 +permissions: 0.002 +register: 0.002 +graphic: 0.001 +vnc: 0.001 +peripherals: 0.001 +kernel: 0.001 +architecture: 0.001 +boot: 0.001 +VMM: 0.001 +mistranslation: 0.000 +KVM: 0.000 + +QEMU gdbstub command "?" issue + +I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. +Here is documentation from official gdb: +‘?’ Indicate the reason the target halted. The reply is the same as for step and +continue. This packet has a special interpretation when the target is in non-stop +mode; see Section E.10 [Remote Non-Stop], page 733. +Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. + +With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). +Function that handles "?" command has this comment in it: + /* + * Remove all the breakpoints when this query is issued, + * because gdb is doing an initial connect and the state + * should be cleaned up. + */ +From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. +In my opinion initial connect should be detected in some other way, and not with "?" command. + + + +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/review/1907909 b/results/classifier/118/review/1907909 new file mode 100644 index 000000000..42ddb60e0 --- /dev/null +++ b/results/classifier/118/review/1907909 @@ -0,0 +1,124 @@ +user-level: 0.823 +KVM: 0.767 +virtual: 0.737 +device: 0.729 +register: 0.726 +graphic: 0.719 +ppc: 0.704 +hypervisor: 0.704 +architecture: 0.702 +performance: 0.700 +mistranslation: 0.692 +i386: 0.690 +x86: 0.679 +VMM: 0.675 +files: 0.673 +peripherals: 0.673 +permissions: 0.672 +assembly: 0.669 +arm: 0.667 +vnc: 0.666 +TCG: 0.660 +debug: 0.653 +semantic: 0.650 +risc-v: 0.619 +PID: 0.615 +kernel: 0.611 +boot: 0.597 +socket: 0.546 +network: 0.545 +-------------------- +hypervisor: 0.951 +i386: 0.948 +kernel: 0.384 +x86: 0.304 +arm: 0.076 +virtual: 0.074 +TCG: 0.041 +PID: 0.028 +files: 0.014 +performance: 0.012 +assembly: 0.012 +semantic: 0.009 +architecture: 0.009 +debug: 0.008 +device: 0.005 +boot: 0.003 +register: 0.003 +user-level: 0.003 +network: 0.002 +ppc: 0.002 +VMM: 0.002 +risc-v: 0.002 +KVM: 0.002 +graphic: 0.002 +peripherals: 0.002 +permissions: 0.002 +socket: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +assertion failure in am53c974 + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/esp.c:402: void esp_do_dma(ESPState *): Assertion `s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen' failed. + +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fdd25dc4700 (LWP 28983))] +gdb-peda$ bt +#0 0x00007fdd3f8b5f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fdd3f8b78b1 in __GI_abort () at abort.c:79 +#2 0x00007fdd3f8a742a in __assert_fail_base (fmt=0x7fdd3fa2ea38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=file@entry=0x55b3e11a4f73 "../hw/scsi/esp.c", line=line@entry=0x192, function=function@entry=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:92 +#3 0x00007fdd3f8a74a2 in __GI___assert_fail (assertion=0x55b3e11a51c6 "s->cmdlen <= sizeof(s->cmdbuf) && len <= sizeof(s->cmdbuf) - s->cmdlen", file=0x55b3e11a4f73 "../hw/scsi/esp.c", line=0x192, function=0x55b3e11a520d "void esp_do_dma(ESPState *)") at assert.c:101 +#4 0x000055b3e0941441 in esp_do_dma (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:401 +#5 0x000055b3e0944261 in handle_ti (s=0x55b3e49d1c88) at ../hw/scsi/esp.c:549 +#6 0x000055b3e093fdf9 in esp_dma_enable (s=0x55b3e49d1c88, irq=<optimized out>, level=<optimized out>) + at ../hw/scsi/esp.c:79 +#7 0x000055b3e0897930 in esp_pci_dma_write (pci=<optimized out>, saddr=<optimized out>, val=<optimized +out>) at ../hw/scsi/esp-pci.c:83 +#8 0x000055b3e0897930 in esp_pci_io_write (opaque=<optimized out>, addr=<optimized out>, val=0xcf, size=0x4) at ../hw/scsi/esp-pci.c:209 +#9 0x000055b3e0e8f798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#10 0x000055b3e0e8f58e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#11 0x000055b3e0e8f58e in memory_region_dispatch_write (mr=0x55b3e49d1b70, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#12 0x000055b3e0e21541 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=0xffffffcf, attrs=..., result=0x0) at ../memory_ldst.c.inc:382 +#13 0x00007fdcd84a4a7f in code_gen_buffer () +#14 0x000055b3e0e57da0 in cpu_tb_exec (cpu=0x55b3e3c33650, itb=<optimized out>) + at ../accel/tcg/cpu-exec.c:178 +#15 0x000055b3e0e589eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized +out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#16 0x000055b3e0e589eb in cpu_exec (cpu=0x55b3e3c33650) at ../accel/tcg/cpu-exec.c:771 +#17 0x000055b3e0e87b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#18 0x000055b3e0e87b9f in tcg_cpu_thread_fn (arg=0x55b3e3c33650) at ../accel/tcg/tcg-cpus.c:427 +#19 0x000055b3e115f775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#20 0x00007fdd3fc6f6db in start_thread (arg=0x7fdd25dc4700) at pthread_create.c:463 +#21 0x00007fdd3f998a3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +To reproduce the assertion failure, please run the QEMU with the following command line. + + +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. + +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + +It looks like this reproducer triggers the same bug as #1919036, as of 3f8d1885e + +Can you still reproduce the issue with QEMU v6.0? For me, the attached reproducer does not cause a crash anymore... + +As Alexander already wrote, this triggered the same bug as #1919036 which got fixed by commit 0ebb5fd80589835153a0c2baa1b8cc7a04e67a93. Since this is not reproducible anymore, I'm closing this bug now. If you still can reproduce it somehow, please open a new ticket in the new gitlab issue tracker. + diff --git a/results/classifier/118/review/1907952 b/results/classifier/118/review/1907952 new file mode 100644 index 000000000..790042b6e --- /dev/null +++ b/results/classifier/118/review/1907952 @@ -0,0 +1,242 @@ +user-level: 0.881 +semantic: 0.877 +permissions: 0.873 +performance: 0.871 +virtual: 0.862 +register: 0.857 +graphic: 0.852 +device: 0.847 +risc-v: 0.843 +PID: 0.832 +socket: 0.831 +boot: 0.831 +assembly: 0.828 +network: 0.828 +arm: 0.827 +debug: 0.823 +kernel: 0.819 +architecture: 0.818 +ppc: 0.784 +x86: 0.780 +TCG: 0.763 +vnc: 0.754 +mistranslation: 0.750 +files: 0.742 +VMM: 0.692 +peripherals: 0.685 +hypervisor: 0.674 +KVM: 0.664 +i386: 0.317 +-------------------- +arm: 0.996 +hypervisor: 0.915 +virtual: 0.783 +kernel: 0.499 +KVM: 0.472 +debug: 0.126 +architecture: 0.112 +socket: 0.103 +TCG: 0.060 +register: 0.057 +vnc: 0.057 +files: 0.043 +PID: 0.040 +VMM: 0.027 +device: 0.026 +boot: 0.012 +semantic: 0.012 +network: 0.011 +permissions: 0.011 +user-level: 0.008 +performance: 0.006 +assembly: 0.004 +graphic: 0.003 +peripherals: 0.003 +mistranslation: 0.001 +risc-v: 0.001 +x86: 0.000 +ppc: 0.000 +i386: 0.000 + +qemu-system-aarch64: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0 + +I originally observed this on Debian packaged qemu 5.2 at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 + +Today I checked out the latest git source at +Sun, 13 Dec 2020 19:21:09 +0900 +and configured the source as follows: + +./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu \ + --localstatedir=/var --disable-blobs --disable-strip --localstatedir=/var \ + --libdir=/usr/lib/aarch64-linux-gnu \ + --firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu \ + --target-list=aarch64-softmmu,arm-softmmu --disable-werror \ + --disable-user --enable-gtk --enable-vnc +then executed "make" on an ARM64 (not an x86_64) host, +running the latest Debian testing. + +I did the following commands on an arm64 host with the Debian Installer Alpha 3 at +https://cdimage.debian.org/cdimage/bullseye_di_alpha3/arm64/iso-cd/debian-bullseye-DI-alpha3-arm64-netinst.iso + +#!/bin/sh + +ARCH=arm64 +IMAGE=`pwd`/qemu-disk-${ARCH}.qcow2 +CDROM=`pwd`/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso +rm -f $IMAGE +qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o preallocation=off $IMAGE 20G +cd /var/tmp +cp /usr/share/AAVMF/AAVMF_VARS.fd . +$HOME/qemu-git/qemu/build/qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 3072 -smp 2\ + -net nic,model=virtio -net user -object rng-random,filename=/dev/urandom,id=rng0 \ + -device virtio-rng-pci,rng=rng0,id=rng-device0 \ + -drive if=virtio,file=${IMAGE},index=0,format=qcow2,discard=unmap,detect-zeroes=unmap,media=disk \ + -drive if=virtio,file=${CDROM},index=1,format=raw,readonly=on,media=cdrom \ + -drive if=pflash,format=raw,unit=0,file=/usr/share/AAVMF/AAVMF_CODE.fd,readonly=on \ + -drive if=pflash,format=raw,unit=1,file=`pwd`/AAVMF_VARS.fd + +Then 4 arrow keys on the physical keyboard are received as just "^[". + +This symptom was not observed on qemu-system-x86_64. +This symptom was not observed with virt-manager on my arm64 host, neither. +This seems unique to -display gtk of qemu-system-aarch64. + +An easier way to reproduce the symptom was provided by Alper Nebi Yasak at +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808#88 + +qemu-system-aarch64 \ + -display gtk -enable-kvm -machine virt -cpu host -m 1G -smp 2 \ + -kernel /boot/vmlinuz -initrd /boot/initrd.img \ + -append "break console=ttyAMA0" + +Then, run cat on the initramfs shell and see arrow keys result in ^[ . +For x86_64, it's console=ttyS0 and ^[[A etc. + + +This should be fixed already in head-of-git, by commit 8eb13bbbac08aa077e ; this will be in QEMU 6.0. + + +This bug was fixed in the package qemu - 1:6.0+dfsg-1~ubuntu3 + +--------------- +qemu (1:6.0+dfsg-1~ubuntu3) impish; urgency=medium + + * d/p/u/lp-1935617-target-ppc-Fix-load-endianness-for-lxvwsx-lxvdsx.patch: + fix TCG emulation for ppc64 (LP: #1935617) + +qemu (1:6.0+dfsg-1~ubuntu2) impish; urgency=medium + + * d/control: remove fuse2 trial-build (LP 1934510) + +qemu (1:6.0+dfsg-1~ubuntu1) impish; urgency=medium + + * Merge with Debian experimental, Among many other things this fixes LP Bugs: + (LP: #1907952) broken arrow keys in -display gtk on aarch64 + - qemu-kvm to systemd unit + - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm, + hugepages and architecture specifics + - d/qemu-system-common.qemu-kvm.service: systemd unit to call + qemu-kvm-init + - d/qemu-system-common.install: install helper script + - d/qemu-system-common.qemu-kvm.default: defaults for + /etc/default/qemu-kvm + - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm + - Distribution specific machine type + (LP: 1304107 1621042 1776189 1761372 1761372 1776189) + - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine + types containing release versioned machine attributes + - d/qemu-system-x86.NEWS Info on fixed machine type defintions + for host-phys-bits=true + - Add an info about -hpb machine type in debian/qemu-system-x86.NEWS + - ubuntu-q35 alias added to auto-select the most recent q35 ubuntu type + - Enable nesting by default + - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default + in qemu64 on amd + [ No more strictly needed, but required for backward compatibility ] + - improved dependencies + - Make qemu-system-common depend on qemu-block-extra + - Make qemu-utils depend on qemu-block-extra + - Let qemu-utils recommend sharutils + - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490) + - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types + reference 256k path + - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to + handle incoming migrations from former releases. + - d/control-in: Disable capstone disassembler library support (universe) + - d/qemu-system-x86.README.Debian: add info about updated nesting changes + - d/control*, d/rules: disable xen by default, but provide universe + package qemu-system-x86-xen as alternative + [includes compat links changes of 5.0-5ubuntu4] + - Fix upgrade module handling (LP 1905377) + --enable-module-upgrades for qemu-xen which doesn't exist in Debian + * Dropped Changes [in 6.0]: + - d/p/ubuntu/lp-1907789-build-no-pie-is-no-functional-liker-flag.patch: fix + ld usage of -no-pie (LP 1907789) + - d/p/u/lp-1916230-hw-s390x-fix-build-for-virtio-9p-ccw.patch: fix + virtio-9p-ccw being missing (LP 1916230) + - d/p/u/lp-1916705-disas-Fix-build-with-glib2.0-2.67.3.patch: Fix FTFBS due + to glib2.0 >=2.67.3 (LP 1916705) + - d/p/u/lp-1921754*: add EPYC-Rome-v2 as v1 missed IBRS and thereby fails + on some HW/Guest combinations e.g. Windows 10 on Threadripper chips + (LP 1921754) + - d/p/u/lp-1921880*: add EPYC-Milan features and named cpu type support + (LP 1921880) + - d/p/u/lp-1922010-linux-user-s390x-Use-the-guest-pointer-for-the-sigre*: + fix go in qemu-s390x-static (LP 1922010) + * Dropped Changes [in Debian]: + - Allow qemu to load old modules post upgrade (LP 1847361) + - Drop d/qemu-block-extra.*.in, d/qemu-system-gui.*.in + - d/rules: Drop generating package version into maintainer scripts + * Dropped Changes [No more needed >21.04]: + - d/qemu-system-gui.prerm: add no-op prerm to overcome upgrade issues on + the bad old prerm (LP 1906245 1905377) + * Added Changes + - Disable fuse export (universe dependency) + - d/p/ubuntu/enable-svm-by-default.patch: update to match v6.0 + - d/p/ubuntu/define-ubuntu-machine-types.patch: add ubuntu machine types + for v6.0 + - d/p/ubuntu/lp-1929926-*: avoid segfaults by uretprobes (LP: #1929926) + - Ease the use of module retention on upgrades (LP: #1913421) + - d/run-qemu.mount, d/rules: provide run-qemu.mount in qemu-block-extra + - d/rules: only save modules if /run/qemu isn't noexec + - d/rules: clear all (current and former) modules on purge + - debian/qemu-block-extra.postinst: enable mount unit on install/upgrade + - d/control: qemu 6.0 broke libvirt <7.2 add a breaks to avoid partial + upgrade issues (LP: #1932264) + - Enable SDL as secondary UI backend (LP: #1256185) + - d/control: add build dependency libsdl2-dev + - d/control: enable sdl graphics on build + - d/qemu-system-gui.install: add ui-sdl.so + - d/control: add runtime dependency to libgl1 + - d/rules: qemu-system-x86-xen builds modules as well now (follows the + other packages) + +qemu (1:6.0+dfsg-1~exp0) experimental; urgency=medium + + * new upstream release + * remove obsolete patches, refresh use-fixed-data-path.patch + * use libncurses-dev, not old libncursesw5-dev + * enable fuse export (and build-depend on libfuse3-dev) + * install (new) manpages for qemu-storage-daemon + * enable new hexagon qemu-user target + * two patches to fix 3 new spelling mistakes + * remove now-unused shared-library-lacks-prerequisites lintian-overrides + for qemu-user-static + +qemu (1:5.2+dfsg-10) unstable; urgency=medium + + * 5 sdhci fixes from upstream: + dont-transfer-any-data-when-command-time-out.patch + dont-write-to-SDHC_SYSAD-register-when-transfer-is-in-progress.patch + correctly-set-the-controller-status-for-ADMA.patch + limit-block-size-only-when-SDHC_BLKSIZE-register-is-writable.patch + reset-the-data-pointer-of-s-fifo_buffer-when-a-different-block-size...patch + (Closes: #986795, #970937, CVE-2021-3409, CVE-2020-17380, CVE-2020-25085) + * mptsas-remove-unused-MPTSASState.pending-CVE-2021-3392.patch + fix possible use-after-free in mptsas_free_request + (Cloese: #984449, CVE-2021-3392) + + -- Christian Ehrhardt <email address hidden> Tue, 13 Jul 2021 09:34:55 +0200 + diff --git a/results/classifier/118/review/1907969 b/results/classifier/118/review/1907969 new file mode 100644 index 000000000..6f0015e73 --- /dev/null +++ b/results/classifier/118/review/1907969 @@ -0,0 +1,211 @@ +semantic: 0.912 +PID: 0.907 +graphic: 0.905 +permissions: 0.904 +debug: 0.902 +register: 0.895 +architecture: 0.889 +user-level: 0.883 +ppc: 0.876 +arm: 0.875 +risc-v: 0.871 +hypervisor: 0.867 +TCG: 0.859 +performance: 0.854 +mistranslation: 0.850 +device: 0.841 +network: 0.838 +assembly: 0.831 +files: 0.824 +KVM: 0.813 +peripherals: 0.807 +vnc: 0.806 +VMM: 0.804 +virtual: 0.803 +boot: 0.801 +x86: 0.800 +i386: 0.795 +socket: 0.794 +kernel: 0.697 +-------------------- +i386: 0.999 +x86: 0.978 +user-level: 0.653 +TCG: 0.110 +performance: 0.026 +architecture: 0.025 +semantic: 0.025 +files: 0.024 +debug: 0.017 +virtual: 0.013 +PID: 0.009 +hypervisor: 0.009 +kernel: 0.008 +boot: 0.005 +register: 0.005 +device: 0.004 +VMM: 0.004 +KVM: 0.004 +socket: 0.003 +permissions: 0.002 +vnc: 0.002 +network: 0.002 +peripherals: 0.001 +graphic: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +assembly: 0.000 +ppc: 0.000 +arm: 0.000 + +linux-user/i386: Segfault when mixing threads and signals + +Given the following C program, qemu-i386 will surely and certainly segfault when executing it. +The problem is only noticeable if the program is statically linked to musl's libc and, as written +in the title, it only manifests when targeting i386. + +Removing the pthread calls or the second raise() makes it not segfault. + +The crash is in some part of the TCG-generated code, right when it tries to perform a +%gs-relative access. + +If you want a quick way of cross-compiling this binary: + +* Download a copy of the Zig compiler from https://ziglang.org/download/ +* Compile it with + `zig cc -target i386-linux-musl <C-FILE> -o <OUT>` + +``` +#include <pthread.h> +#include <signal.h> +#include <stdio.h> +#include <string.h> +#include <sys/types.h> +#include <unistd.h> +#include <asm/prctl.h> +#include <sys/syscall.h> + +void sig_func(int sig) +{ + write(1, "hi!\n", strlen("hi!\n")); +} + +void func(void *p) { } + +typedef void *(*F)(void *); + +int main() +{ + pthread_t tid; + + struct sigaction action; + action.sa_flags = 0; + action.sa_handler = sig_func; + + if (sigaction(SIGUSR1, &action, NULL) == -1) { + return 1; + } + + // This works. + raise(SIGUSR1); + + pthread_create(&tid, NULL, (F)func, NULL); + pthread_join(tid, NULL); + + // This makes qemu segfault. + raise(SIGUSR1); +} +``` + + + +I finally understand where the problem is. + +Qemu's user-mode emulation maps guest threads to native ones by spawning a new native one +and running a forked copy of the CPUX86State in parallel with the main thread. + +This works fine for pretty much every architecture but i386 where the GDT/LDT comes into +play: the two descriptor tables are shared among all the threads, mimicking the real hw +behaviour, but since no host task-switching is being performed the TLS entry in the GDT +become stale. + +Raising a signal makes Qemu reload the GS segment from the GDT, that's why removing that +line makes the problem disappear. + +The problem is also confined to musl libc because of an interesting implementation choice. +Once a thread dies Glibc adds the now unused stack to a queue in order to reuse it later, +while musl frees it right away when it's not needed anymore and, as a consequence, makes +Qemu segfault. + +As luck has it, after spending too much time debugging this, I found somebody else already +stumbled across this problem and wrote a patch. + +https://<email address hidden>/mbox + +Too bad the patch flew under the radar... + +Le 16/12/2020 à 09:59, The Lemon Man a écrit : +> I finally understand where the problem is. +> +> Qemu's user-mode emulation maps guest threads to native ones by spawning a new native one +> and running a forked copy of the CPUX86State in parallel with the main thread. +> +> This works fine for pretty much every architecture but i386 where the GDT/LDT comes into +> play: the two descriptor tables are shared among all the threads, mimicking the real hw +> behaviour, but since no host task-switching is being performed the TLS entry in the GDT +> become stale. +> +> Raising a signal makes Qemu reload the GS segment from the GDT, that's why removing that +> line makes the problem disappear. +> +> The problem is also confined to musl libc because of an interesting implementation choice. +> Once a thread dies Glibc adds the now unused stack to a queue in order to reuse it later, +> while musl frees it right away when it's not needed anymore and, as a consequence, makes +> Qemu segfault. +> +> As luck has it, after spending too much time debugging this, I found somebody else already +> stumbled across this problem and wrote a patch. +> +> https://<email address hidden>/mbox +> +> Too bad the patch flew under the radar... +> + +Could you add a Reviewed-by and/or a tested by to the patch on the ML? + +Thanks, +Laurent + + +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/review/1908416 b/results/classifier/118/review/1908416 new file mode 100644 index 000000000..756a0c696 --- /dev/null +++ b/results/classifier/118/review/1908416 @@ -0,0 +1,108 @@ +architecture: 0.939 +virtual: 0.912 +device: 0.867 +files: 0.855 +user-level: 0.850 +graphic: 0.841 +peripherals: 0.806 +semantic: 0.787 +arm: 0.786 +performance: 0.781 +permissions: 0.755 +hypervisor: 0.727 +boot: 0.718 +ppc: 0.718 +kernel: 0.716 +register: 0.703 +KVM: 0.697 +debug: 0.674 +mistranslation: 0.667 +VMM: 0.665 +PID: 0.663 +vnc: 0.656 +assembly: 0.655 +TCG: 0.649 +network: 0.642 +socket: 0.602 +risc-v: 0.582 +x86: 0.407 +i386: 0.390 +-------------------- +virtual: 0.892 +arm: 0.459 +user-level: 0.379 +debug: 0.199 +TCG: 0.166 +boot: 0.091 +hypervisor: 0.080 +files: 0.050 +PID: 0.040 +network: 0.034 +register: 0.031 +architecture: 0.028 +socket: 0.025 +risc-v: 0.023 +VMM: 0.019 +vnc: 0.016 +device: 0.014 +performance: 0.014 +semantic: 0.014 +kernel: 0.005 +graphic: 0.005 +assembly: 0.004 +permissions: 0.003 +ppc: 0.002 +x86: 0.001 +peripherals: 0.001 +KVM: 0.001 +mistranslation: 0.001 +i386: 0.001 + +qemu-system-aarch64 can't run Windows 10 for ARM version 2004 + +Problem: qemu-system-aarch64 can't run Windows 10 for ARM version 2004 (20H2) or newer + +Host OS: Windows 10 x64 version 20H2 +CPU : Intel Pentium Dual-core T4300 (no vt-x) +QEMU : QEMU version 5.1.0 from qemu.org + +cmdline: qemu-system-aarch64.exe -M virt -cpu cortex-a72 -smp 3 --accel tcg,thread=multi -m 2048 -pflash QEMU_EFI.img -pflash QEMU_VARS.img -device VGA -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-storage,drive=cdrom -drive file="isofile.iso",media=cdrom,if=none,id=cdrom + +Note: QEMU_VARS and QEMU_EFI are taken from edk2, which can be seen in the attachment below. + +Details: From this post (https://kitsunemimi.pw/notes/posts/running-windows-10-for-arm64-in-a-qemu-virtual-machine.html) and from what I have tried, QEMU can't run Windows ARM newer or equal to the 2004 version. When we boot a 2004 iso (made from uupdump.ml), it stuck as the boot screen with the Windows ARM logo and nothing else. When I check the machine state and registers through the QEMU monitor, it shows that the VM is still running, but the registers are completely frozen! But if I try the older version, like 19H2, it works! Please help! + + + +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/review/1908450 b/results/classifier/118/review/1908450 new file mode 100644 index 000000000..f3159a0e9 --- /dev/null +++ b/results/classifier/118/review/1908450 @@ -0,0 +1,149 @@ +mistranslation: 0.909 +user-level: 0.857 +register: 0.836 +permissions: 0.832 +debug: 0.823 +semantic: 0.810 +graphic: 0.802 +VMM: 0.801 +peripherals: 0.788 +arm: 0.777 +device: 0.770 +socket: 0.769 +PID: 0.761 +hypervisor: 0.760 +assembly: 0.745 +ppc: 0.743 +risc-v: 0.738 +TCG: 0.738 +kernel: 0.726 +architecture: 0.715 +vnc: 0.701 +performance: 0.699 +i386: 0.672 +virtual: 0.663 +x86: 0.653 +files: 0.626 +KVM: 0.570 +boot: 0.559 +network: 0.523 +-------------------- +debug: 0.149 +TCG: 0.080 +files: 0.066 +device: 0.038 +semantic: 0.032 +i386: 0.030 +kernel: 0.029 +architecture: 0.027 +register: 0.023 +VMM: 0.023 +x86: 0.016 +KVM: 0.014 +risc-v: 0.013 +virtual: 0.011 +PID: 0.010 +assembly: 0.009 +boot: 0.008 +ppc: 0.007 +vnc: 0.005 +socket: 0.005 +hypervisor: 0.004 +peripherals: 0.003 +arm: 0.002 +graphic: 0.002 +performance: 0.002 +user-level: 0.001 +mistranslation: 0.001 +network: 0.001 +permissions: 0.001 + +ide/core.c ATA Major Version reporting incorrect + +@@ -165,7 +165,7 @@ static void ide_identify(IDEState *s) + put_le16(p + 76, (1 << 8)); + } + + put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ +- put_le16(p + 80, 0xf0); /* ata3 -> ata6 supported */ ++ put_le16(p + 80, ((1 << 6) | (1 << 5) (1 << 4) (1 << 3)); /* ata3 -> ata6 supported */ + put_le16(p + 81, 0x16); /* conforms to ata5 */ + /* 14=NOP supported, 5=WCACHE supported, 0=SMART supported */ + put_le16(p + 82, (1 << 14) | (1 << 5) | 1); + + +This field Major Version Number field is presently reporting support for ATA-4 through ATA-7. +Bitfield[80] is defined in the ATA-6 specification below. + +0xF0 = (1<<7) | (1<<6) | (1 << 5) | (1 << 4) // 4-7 - current settings +0x78 = (1<<6) | (1<<5) | (1 << 4) | (1 << 3) // 3-6 - new settings + +Either the comment is wrong, or the field is wrong. If the field is wrong it can cause errors in drivers that check support vs conformity. This will not break most guests, since the conformity field is set to ATA-5. + +I'm not sure whether this component supports ATA-7, but since it's commented as if it supports up through 6, correcting the field assignment seems more correct. + +ATA/ATAPI-6 Specification +https://web.archive.org/web/20200124094822/https://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf + +Page 116 +80 - M Major version number +0000h or FFFFh = device does not report version +F 15 Reserved +F 14 Reserved for ATA/ATAPI-14 +F 13 Reserved for ATA/ATAPI-13 +F 12 Reserved for ATA/ATAPI-12 +F 11 Reserved for ATA/ATAPI-11 +F 10 Reserved for ATA/ATAPI-10 +F 9 Reserved for ATA/ATAPI-9 +F 8 Reserved for ATA/ATAPI-8 +F 7 Reserved for ATA/ATAPI-7 +F 6 1 = supports ATA/ATAPI-6 +F 5 1 = supports ATA/ATAPI-5 +F 4 1 = supports ATA/ATAPI-4 +F 3 1 = supports ATA-3 +X 2 Obsolete +X 1 Obsolete +F 0 Reserved + +John, could you please have a look? + +I doubt we truly implement *any* standard precisely correctly, but if we are advertising support for ATA7 and it works, I'd rather just fix the comment to keep behavior the same. + +It probably was a mistake in the original commit from ... sometime before 2006, but if nothing is observably broken, maybe it shouldn't be changed. + +for what it's worth, i have yet to see a driver actually check this field. + +I have seen a ton of code (OVMF and others) detect other information and just straight up say "I'm in QEMU" and YOLO a bunch of things like assuming DMA is available and such, so I somewhat doubt anyone *actually* checks these fields. + +That's probably the single most reasonable thing to do, truth be told! + +I don't have the time to audit these fields properly; I don't know which versions we truly ought to advertise support for. I know I looked at ATA8-AC3 at some point fairly recently and concluded that we don't support all of the "must-support" features of that spec, because we don't implement any of the logging features whatsoever. + +I often consult ATA8-ACS3 to take advantage of clarifications made in later revisions and cross-correlate with ATA7; but I don't know what the most modern specification we can be said to support the minimum feature set from truly is. + +Patches (and reviewers) always welcome; but generally I am afraid of touching too many things because I don't want to break legacy operating systems that might not have an awareness of QEMU. Our testing for older operating systems is not particularly robust, here. + +I think I am still leaning towards just fixing the comment, but if you are aware of some ATA7 thing we are required to support but don't, I'll remove the bit. + +I would just fix the comment for now, likewise I don't have the time to audit +whether the emulation provides full coverage of the standard. + +Really there's two cases here +1) We report ATA4-7 (current status), someone discovers missing bits feature +Response: They file a ticket on the missing feature. + +2) We report ATA3-6 (changed status), legacy stuff checking this bit suddenly break +Response: Rabid screeching somewhere in the depths of the internets. + +Fixing the comment is more risk averse and more likely to produce the desirable +outcome (some reads the comment, and discovers a missing ATA feature for the +reported standard). + + +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/59 + + diff --git a/results/classifier/118/review/1908515 b/results/classifier/118/review/1908515 new file mode 100644 index 000000000..91c1ce027 --- /dev/null +++ b/results/classifier/118/review/1908515 @@ -0,0 +1,140 @@ +user-level: 0.915 +hypervisor: 0.878 +risc-v: 0.863 +mistranslation: 0.844 +graphic: 0.837 +performance: 0.835 +register: 0.828 +permissions: 0.818 +i386: 0.813 +x86: 0.812 +vnc: 0.811 +ppc: 0.811 +KVM: 0.807 +virtual: 0.805 +semantic: 0.801 +TCG: 0.799 +debug: 0.795 +device: 0.794 +arm: 0.793 +peripherals: 0.792 +PID: 0.790 +VMM: 0.786 +files: 0.782 +assembly: 0.780 +socket: 0.775 +architecture: 0.773 +kernel: 0.740 +network: 0.706 +boot: 0.703 +-------------------- +i386: 0.970 +hypervisor: 0.965 +x86: 0.779 +virtual: 0.115 +TCG: 0.036 +PID: 0.030 +kernel: 0.026 +files: 0.019 +performance: 0.009 +assembly: 0.008 +semantic: 0.008 +debug: 0.006 +architecture: 0.005 +register: 0.004 +device: 0.003 +user-level: 0.003 +ppc: 0.003 +KVM: 0.003 +graphic: 0.002 +network: 0.002 +boot: 0.002 +VMM: 0.002 +socket: 0.002 +risc-v: 0.002 +permissions: 0.001 +vnc: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 + +assertion failure in lsi53c810 emulator + +Hello, + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through lsi53c810 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/lsi53c895a.c:624: void lsi_do_dma(LSIState *, int): Assertion `s->current' +failed. +[1] 1406 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-5.2/build/i386-softmmu/qemu-system-i386 -m + +Program terminated with signal SIGABRT, Aborted. +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fa9310a8700 (LWP 2076))] +gdb-peda$ bt +#0 0x00007fa94aa98f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fa94aa9a8b1 in __GI_abort () at abort.c:79 +#2 0x00007fa94aa8a42a in __assert_fail_base (fmt=0x7fa94ac11a38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x562851c9eab9 "s->current", file=file@entry=0x562851c9d4f9 "../hw/scsi/lsi53c895a.c", line=line@entry=0x270, function=function@entry=0x562851c9de43 "void lsi_do_dma(LSIState *, int)") at assert.c:92 +#3 0x00007fa94aa8a4a2 in __GI___assert_fail (assertion=0x562851c9eab9 "s->current", file=0x562851c9d4f9 "../hw/scsi/lsi53c895a.c", line=0x270, function=0x562851c9de43 "void lsi_do_dma(LSIState *, int)") + at assert.c:101 +#4 0x00005628515d9605 in lsi_do_dma (s=0x562855559060, out=0x1) at ../hw/scsi/lsi53c895a.c:624 +#5 0x00005628515d5317 in lsi_execute_script (s=<optimized out>) at ../hw/scsi/lsi53c895a.c:1250 +#6 0x00005628515cec49 in lsi_reg_writeb (s=0x562855559060, offset=0x2f, val=0x1e) + at ../hw/scsi/lsi53c895a.c:2005 +#7 0x0000562851952798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#8 0x000056285195258e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#9 0x000056285195258e in memory_region_dispatch_write (mr=0x562855559960, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#10 0x00005628518e5305 in flatview_write_continue (fv=0x7fa92871f040, addr=0xfebf302c, attrs=..., ptr=0x7fa9310a49b8, len=0x4, addr1=0x7fa9310a3410, l=<optimized out>, mr=0x562855559960) + at ../softmmu/physmem.c:2759 +#11 0x00005628518e6ef6 in flatview_write (fv=0x7fa92871f040, addr=0xfebf302c, attrs=..., len=0x4, buf=<optimized out>) at ../softmmu/physmem.c:2799 +#12 0x00005628518e6ef6 in subpage_write (opaque=<optimized out>, addr=<optimized out>, value=<optimized out>, len=<optimized out>, attrs=...) at ../softmmu/physmem.c:2465 +#13 0x00005628519529a2 in memory_region_write_with_attrs_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:511 +#14 0x00005628519525e1 in access_with_adjusted_size (addr=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, mr=<optimized out>, attrs=..., value=<optimized out>, access_fn=<optimized out>) at ../softmmu/memory.c:552 +#15 0x00005628519525e1 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1508 +#16 0x0000562851a49228 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=<optimized out>, env=<optimized out>) + at ../accel/tcg/cputlb.c:1378 +#17 0x0000562851a49228 in store_helper (env=<optimized out>, addr=<optimized out>, val=<optimized out>, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2397 +#18 0x0000562851a49228 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x2, oi=<optimized out>, retaddr=0x7fa8e44032ee) at ../accel/tcg/cputlb.c:2463 +#19 0x00007fa8e44032ee in code_gen_buffer () +#20 0x000056285191ada0 in cpu_tb_exec (cpu=0x5628547b81a0, itb=<optimized out>) + at ../accel/tcg/cpu-exec.c:178 +#21 0x000056285191b9eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#22 0x000056285191b9eb in cpu_exec (cpu=0x5628547b81a0) at ../accel/tcg/cpu-exec.c:771 +#23 0x000056285194ab9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#24 0x000056285194ab9f in tcg_cpu_thread_fn (arg=0x5628547b81a0) at ../accel/tcg/tcg-cpus.c:427 +#25 0x0000562851c22775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#26 0x00007fa94ae526db in start_thread (arg=0x7fa9310a8700) at pthread_create.c:463 +#27 0x00007fa94ab7ba3f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +To reproduce this issue, please run the QEMU with the following command line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line. +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device lsi53c810,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + + +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/305 + + diff --git a/results/classifier/118/review/1908551 b/results/classifier/118/review/1908551 new file mode 100644 index 000000000..6ad2a023c --- /dev/null +++ b/results/classifier/118/review/1908551 @@ -0,0 +1,140 @@ +semantic: 0.876 +graphic: 0.871 +user-level: 0.862 +debug: 0.849 +permissions: 0.838 +hypervisor: 0.811 +assembly: 0.808 +PID: 0.779 +register: 0.765 +vnc: 0.763 +virtual: 0.757 +ppc: 0.754 +arm: 0.754 +TCG: 0.738 +peripherals: 0.737 +files: 0.720 +performance: 0.711 +device: 0.704 +architecture: 0.700 +risc-v: 0.698 +KVM: 0.671 +mistranslation: 0.667 +VMM: 0.656 +socket: 0.636 +network: 0.628 +kernel: 0.592 +boot: 0.561 +x86: 0.545 +i386: 0.517 +-------------------- +arm: 0.995 +files: 0.078 +debug: 0.045 +architecture: 0.041 +TCG: 0.040 +register: 0.037 +user-level: 0.035 +VMM: 0.032 +performance: 0.031 +virtual: 0.031 +hypervisor: 0.029 +assembly: 0.015 +risc-v: 0.012 +network: 0.011 +semantic: 0.010 +PID: 0.010 +device: 0.007 +kernel: 0.006 +boot: 0.006 +vnc: 0.004 +graphic: 0.003 +KVM: 0.003 +socket: 0.002 +mistranslation: 0.002 +peripherals: 0.002 +ppc: 0.002 +permissions: 0.001 +x86: 0.001 +i386: 0.001 + +aarch64 SVE emulation breaks strnlen and strrchr + +arm optimized-routines have sve string functions with test code. + +the test worked up until recently: with qemu-5.2.0 i see + +$ qemu-aarch64 build/bin/test/strnlen +PASS strnlen +PASS __strnlen_aarch64 +__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80" +__strnlen_aarch64_sve (0x490fa0, 32) len 33 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" +__strnlen_aarch64_sve (0x490fa0, 33) len 33 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" +__strnlen_aarch64_sve (0x490fa0, 32) len 34 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 33) len 34 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 34) len 34 returned 64, expected 34 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 32) len 35 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a\x00c" +__strnlen_aarch64_sve (0x490fa0, 33) len 35 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab\x00" +__strnlen_aarch64_sve (0x490fa0, 34) len 35 returned 64, expected 34 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" +__strnlen_aarch64_sve (0x490fa0, 35) len 35 returned 64, expected 35 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" +FAIL __strnlen_aarch64_sve + +however the test passes with + +qemu-aarch64 -cpu max,sve-max-vq=2 + +there should be nothing vector length specific in the code. + +i haven't debugged it further, to reproduce the issue clone +https://github.com/ARM-software/optimized-routines + +and run 'make build/bin/test/strnlen' with a config.mk like + +SUBS = string +ARCH = aarch64 +CROSS_COMPILE = aarch64-none-linux-gnu- +CC = $(CROSS_COMPILE)gcc +CFLAGS = -std=c99 -pipe -O3 +CFLAGS += -march=armv8.2-a+sve +EMULATOR = qemu-aarch64 + +(native compilation works too, and you can run 'make check' to +run all string tests) this will build a static linked executable +into build/bin/test. if you want a smaller test case edit +string/test/strnlen.c + +I don't know why the test worked previously, and I did not +investigate, but as far as I can tell, the test is broken. + +The test is returning a value >= maxlen because it it using +the wrong increment. Fixed thus. + + + +FWIW, as I think on this further, this probably isn't the +ideal fix -- I recall now that INCP is a "reduction" class +instruction and thus its overhead is non-trivial. + +We could instead add an integer min operation at label 9, +which is outside of the main loop. + +Bah. The code at label 9 does not match the comment. +Best fixed thus. + +... but you also mentioned strrchr, and there is a qemu bug there. The REV (predicate) instruction doesn't seem to be doing the right thing -- input 0x1 -> output 0x80000000 which is not correct for the current vector length (64). + +Patch fixing strrchr: +https://<email address hidden>/ + +https://gitlab.com/qemu-project/qemu/-/commit/70acaafef2e053a3 + diff --git a/results/classifier/118/review/1909256 b/results/classifier/118/review/1909256 new file mode 100644 index 000000000..52a58693f --- /dev/null +++ b/results/classifier/118/review/1909256 @@ -0,0 +1,86 @@ +user-level: 0.892 +risc-v: 0.854 +graphic: 0.844 +arm: 0.827 +permissions: 0.825 +virtual: 0.823 +device: 0.821 +performance: 0.816 +TCG: 0.813 +socket: 0.809 +files: 0.806 +assembly: 0.804 +semantic: 0.803 +architecture: 0.803 +PID: 0.801 +debug: 0.798 +network: 0.792 +kernel: 0.791 +peripherals: 0.791 +boot: 0.788 +mistranslation: 0.782 +register: 0.778 +hypervisor: 0.751 +vnc: 0.735 +ppc: 0.723 +VMM: 0.714 +KVM: 0.688 +x86: 0.612 +i386: 0.558 +-------------------- +debug: 0.290 +x86: 0.093 +PID: 0.046 +files: 0.037 +TCG: 0.031 +ppc: 0.029 +hypervisor: 0.021 +i386: 0.021 +kernel: 0.018 +user-level: 0.014 +semantic: 0.011 +virtual: 0.009 +KVM: 0.009 +network: 0.008 +arm: 0.006 +register: 0.005 +device: 0.004 +VMM: 0.002 +socket: 0.002 +performance: 0.002 +risc-v: 0.002 +architecture: 0.002 +graphic: 0.002 +assembly: 0.001 +permissions: 0.001 +peripherals: 0.001 +vnc: 0.001 +boot: 0.001 +mistranslation: 0.001 + +compile failure if gnutls headers not on default include path + +If the gnutls headers are not on the default compiler include path, then configure correctly finds them and config-host.mak sets up the variables: + +GNUTLS_CFLAGS=-I/opt/homebrew/Cellar/gnutls/3.6.15/include -I/opt/homebrew/Cellar/nettle/3.6/include -I/opt/homebrew/Cellar/libtasn1/4.16.0/include -I/opt/homebrew/Cellar/libidn2/2.3.0/include -I/opt/homebrew/Cellar/p11-kit/0.23.22/include/p11-kit-1 +GNUTLS_LIBS=-L/opt/homebrew/Cellar/gnutls/3.6.15/lib -lgnutls + +but meson fails to put GNUTLS_CFLAGS in the compiler arguments and so you get compile failures like: + +[2/1865] Compiling C object qemu-nbd.p/qemu-nbd.c.o +FAILED: qemu-nbd.p/qemu-nbd.c.o +cc -Iqemu-nbd.p -I. -I../.. -Iqapi -Itrace -Iui -Iui/shader -I/opt/homebrew/Cellar/glib/2.66.4/include -I/opt/homebrew/Cellar/glib/2.66.4/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.66.4/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre/8.44/include -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -std=gnu99 -g -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -iquote /Users/pm215/qemu/tcg/aarch64 -iquote . -iquote /Users/pm215/qemu -iquote /Users/pm215/qemu/accel/tcg -iquote /Users/pm215/qemu/include -iquote /Users/pm215/qemu/disas/libvixl -MD -MQ qemu-nbd.p/qemu-nbd.c.o -MF qemu-nbd.p/qemu-nbd.c.o.d -o qemu-nbd.p/qemu-nbd.c.o -c ../../qemu-nbd.c +In file included from ../../qemu-nbd.c:30: +In file included from /Users/pm215/qemu/include/block/nbd.h:25: +/Users/pm215/qemu/include/crypto/tlscreds.h:28:10: fatal error: 'gnutls/gnutls.h' file not found +#include <gnutls/gnutls.h> + ^~~~~~~~~~~~~~~~~ +1 error generated. + + +The compiler errors happen for any .c file that includes block/nbd.h and also for files in tests that include gnutls.h directly, and for files that directly or indirectly include crypto/tlssession.c. + +My meson-foo is insufficient to suggest the correct fix... + +The fix is committed in 3eacf70bb5a8. + diff --git a/results/classifier/118/review/191 b/results/classifier/118/review/191 new file mode 100644 index 000000000..bd0fd127a --- /dev/null +++ b/results/classifier/118/review/191 @@ -0,0 +1,61 @@ +mistranslation: 0.948 +architecture: 0.689 +graphic: 0.454 +performance: 0.401 +device: 0.383 +semantic: 0.275 +virtual: 0.233 +debug: 0.175 +user-level: 0.160 +permissions: 0.131 +arm: 0.089 +register: 0.083 +network: 0.077 +boot: 0.061 +kernel: 0.060 +VMM: 0.057 +files: 0.052 +TCG: 0.048 +ppc: 0.044 +risc-v: 0.042 +hypervisor: 0.038 +vnc: 0.030 +assembly: 0.029 +PID: 0.028 +peripherals: 0.019 +socket: 0.016 +x86: 0.012 +KVM: 0.007 +i386: 0.006 +-------------------- +virtual: 0.951 +hypervisor: 0.651 +user-level: 0.273 +architecture: 0.257 +device: 0.171 +PID: 0.111 +performance: 0.034 +socket: 0.028 +KVM: 0.020 +semantic: 0.020 +debug: 0.019 +assembly: 0.018 +files: 0.010 +kernel: 0.009 +boot: 0.005 +ppc: 0.005 +arm: 0.004 +TCG: 0.004 +register: 0.003 +VMM: 0.002 +mistranslation: 0.002 +graphic: 0.002 +peripherals: 0.001 +x86: 0.001 +risc-v: 0.001 +i386: 0.000 +vnc: 0.000 +network: 0.000 +permissions: 0.000 + +qemu64 CPU model is incorrect diff --git a/results/classifier/118/review/1910605 b/results/classifier/118/review/1910605 new file mode 100644 index 000000000..a66de7d59 --- /dev/null +++ b/results/classifier/118/review/1910605 @@ -0,0 +1,109 @@ +arm: 0.960 +architecture: 0.954 +user-level: 0.899 +device: 0.886 +graphic: 0.885 +performance: 0.884 +peripherals: 0.868 +network: 0.846 +hypervisor: 0.840 +mistranslation: 0.830 +files: 0.828 +PID: 0.806 +permissions: 0.795 +semantic: 0.782 +kernel: 0.767 +debug: 0.761 +x86: 0.760 +register: 0.755 +assembly: 0.736 +socket: 0.735 +ppc: 0.712 +vnc: 0.708 +boot: 0.683 +i386: 0.661 +virtual: 0.651 +VMM: 0.637 +TCG: 0.634 +risc-v: 0.614 +KVM: 0.574 +-------------------- +arm: 0.568 +hypervisor: 0.160 +TCG: 0.050 +debug: 0.048 +virtual: 0.047 +user-level: 0.037 +files: 0.028 +device: 0.025 +PID: 0.010 +semantic: 0.008 +peripherals: 0.007 +network: 0.005 +boot: 0.004 +register: 0.004 +kernel: 0.004 +performance: 0.003 +risc-v: 0.003 +assembly: 0.003 +ppc: 0.002 +architecture: 0.002 +vnc: 0.002 +permissions: 0.001 +socket: 0.001 +graphic: 0.001 +VMM: 0.001 +mistranslation: 0.001 +i386: 0.001 +x86: 0.001 +KVM: 0.000 + +qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address + + + +Snippet of code sample: + +struct usbdevfs_bulktransfer Bulk; +Bulk.ep = hUsb->UsbOut; +Bulk.len = Len; +Bulk.data = (void *)pData; +Bulk.timeout = Timeout; +Bytes = ioctl(hUsb->fd, USBDEVFS_BULK, &Bulk) + +The above code sample return -1 (EFAULT) Bad address when using qemu-arm-static but is running ok when on qemu-aarch64-static. + +I use a 64-bit intel laptop + +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/review/1911839 b/results/classifier/118/review/1911839 new file mode 100644 index 000000000..316512262 --- /dev/null +++ b/results/classifier/118/review/1911839 @@ -0,0 +1,133 @@ +user-level: 0.937 +peripherals: 0.901 +register: 0.897 +device: 0.891 +performance: 0.876 +risc-v: 0.871 +mistranslation: 0.857 +hypervisor: 0.857 +virtual: 0.845 +permissions: 0.843 +architecture: 0.826 +graphic: 0.813 +boot: 0.812 +arm: 0.805 +assembly: 0.798 +semantic: 0.789 +x86: 0.782 +vnc: 0.775 +network: 0.761 +TCG: 0.756 +files: 0.753 +ppc: 0.750 +VMM: 0.742 +debug: 0.724 +i386: 0.718 +socket: 0.718 +KVM: 0.718 +kernel: 0.706 +PID: 0.655 +-------------------- +i386: 0.998 +x86: 0.989 +debug: 0.698 +kernel: 0.444 +assembly: 0.213 +device: 0.172 +user-level: 0.164 +virtual: 0.145 +files: 0.090 +PID: 0.058 +network: 0.057 +TCG: 0.051 +hypervisor: 0.035 +performance: 0.031 +VMM: 0.021 +semantic: 0.020 +register: 0.019 +KVM: 0.016 +boot: 0.014 +risc-v: 0.012 +ppc: 0.011 +architecture: 0.010 +socket: 0.006 +permissions: 0.006 +graphic: 0.006 +peripherals: 0.002 +vnc: 0.002 +mistranslation: 0.001 +arm: 0.001 + +[OSS-Fuzz] Issue 29586 e1000e: Memcpy-param-overlap in flatview_write_continue + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -M q35 -accel qtest \ +-qtest stdio -nographic -nodefaults -device \ +e1000e,netdev=net0 -netdev user,id=net0 +outl 0xcf8 0x80000811 +outl 0xcfc 0x5ac600 +outl 0xcf8 0x80000801 +outl 0xcfc 0x26000000 +write 0x5ac60100 0x4 0x56000302 +write 0x5ac6011a 0x2 0x1006 +write 0x5ac60120 0x1 0x25 +write 0x5ac6042a 0x2 0x4048 +write 0x5ac60431 0x1 0x04 +write 0x4240 0x1 0xff +write 0x4241 0x1 0x01 +write 0x4249 0x1 0xf5 +write 0x1ff 0x1 0x11 +write 0x5ac60401 0x1 0x12 +write 0x5ac6043a 0x2 0x3000 +write 0x5ac60112 0x2 0xf090 +write 0x5ac60430 0x1 0x0 +write 0x239 0x1 0xff +write 0x2bb 0x1 0x41 +write 0x9531 0x1 0xff +write 0x9532 0x1 0xff +write 0x9533 0x1 0xff +write 0x9534 0x1 0xff +write 0x9535 0x1 0xff +write 0x9536 0x1 0xff +write 0x9537 0x1 0xff +write 0x5ac60403 0x1 0x12 +EOF + +=== Stack Trace === +==1364==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x7f90b7e00025,0x7f90b7e00604) and [0x7f90b7e00225, 0x7f90b7e00804) overlap +#0 __asan_memcpy /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 +#1 flatview_write_continue /src/qemu/softmmu/physmem.c:2764:13 +#2 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#3 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#4 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 +#5 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 +#6 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 +#7 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 +#8 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 +#9 e1000e_write_to_rx_buffers /src/qemu/hw/net/e1000e_core.c:1405:9 +#10 e1000e_write_packet_to_guest /src/qemu/hw/net/e1000e_core.c:1575:21 +#11 e1000e_receive_iov /src/qemu/hw/net/e1000e_core.c:1702:9 +#12 e1000e_nc_receive_iov /src/qemu/hw/net/e1000e.c:214:12 +#13 net_tx_pkt_sendv /src/qemu/hw/net/net_tx_pkt.c:556:9 +#14 net_tx_pkt_send /src/qemu/hw/net/net_tx_pkt.c:633:9 +#15 net_tx_pkt_send_loopback /src/qemu/hw/net/net_tx_pkt.c:646:11 +#16 e1000e_tx_pkt_send /src/qemu/hw/net/e1000e_core.c:657:16 +#17 e1000e_process_tx_desc /src/qemu/hw/net/e1000e_core.c:736:17 +#18 e1000e_start_xmit /src/qemu/hw/net/e1000e_core.c:927:9 +#19 e1000e_set_tctl /src/qemu/hw/net/e1000e_core.c:2424:9 +#20 e1000e_core_write /src/qemu/hw/net/e1000e_core.c:3256:9 +#21 e1000e_mmio_write /src/qemu/hw/net/e1000e.c:110:5 +#22 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#23 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#24 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#25 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 +#26 flatview_write /src/qemu/softmmu/physmem.c:2799:14 +#27 address_space_write /src/qemu/softmmu/physmem.c:2891:18 +#28 __wrap_qtest_writeq /src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9 +#29 op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:479:13 +#30 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29586 + +This is still reproducible with the current git version (commit 7fe7fae8b48e3f9c647fd685e5155ebc8e6fb84d) and clang with ASAN enabled. + diff --git a/results/classifier/118/review/1912170 b/results/classifier/118/review/1912170 new file mode 100644 index 000000000..0599d1b27 --- /dev/null +++ b/results/classifier/118/review/1912170 @@ -0,0 +1,141 @@ +user-level: 0.875 +risc-v: 0.869 +ppc: 0.846 +graphic: 0.842 +hypervisor: 0.840 +mistranslation: 0.831 +register: 0.821 +performance: 0.809 +TCG: 0.808 +vnc: 0.807 +virtual: 0.804 +device: 0.804 +debug: 0.798 +peripherals: 0.793 +semantic: 0.793 +arm: 0.772 +assembly: 0.772 +boot: 0.771 +VMM: 0.769 +KVM: 0.753 +permissions: 0.752 +PID: 0.740 +socket: 0.738 +network: 0.724 +architecture: 0.723 +files: 0.704 +x86: 0.697 +kernel: 0.690 +i386: 0.597 +-------------------- +x86: 0.942 +virtual: 0.905 +user-level: 0.420 +vnc: 0.325 +debug: 0.059 +architecture: 0.055 +register: 0.039 +TCG: 0.024 +hypervisor: 0.021 +files: 0.018 +device: 0.016 +boot: 0.013 +PID: 0.011 +socket: 0.011 +semantic: 0.010 +performance: 0.008 +kernel: 0.006 +ppc: 0.006 +network: 0.006 +KVM: 0.003 +assembly: 0.003 +risc-v: 0.003 +permissions: 0.003 +graphic: 0.002 +peripherals: 0.002 +i386: 0.001 +VMM: 0.001 +mistranslation: 0.001 +arm: 0.001 + +NUMA nodes created with memory-backend-ram shows size different than requested + +I created system with 7 NUMA nodes where nodes 0-3 should have 268435456 bytes size and nodes 4-6 exactly 1610612736 bytes size, but when I run "numactl -H" I got different (smaller) sizes. +It is essential for me to be able to emulate a system with nodes of exact size - is it possible? + +QEMU version: + +QEMU emulator version 5.1.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +QEMU command: + +qemu-system-x86_64 -hda qemu-image/ubuntu-1804.img -enable-kvm -cpu Cascadelake-Server -vnc :5 -netdev user,id=net0,hostfwd=tcp::10022-:22 -device virtio-net,netdev=net0 -boot c -m 5632.0M -object memory-backend-ram,id=ram-node0,size=268435456 -numa node,nodeid=0,cpus=0-3,memdev=ram-node0 -object memory-backend-ram,id=ram-node1,size=268435456 -numa node,nodeid=1,cpus=4-7,memdev=ram-node1 -object memory-backend-ram,id=ram-node2,size=268435456 -numa node,nodeid=2,cpus=8-11,memdev=ram-node2 -object memory-backend-ram,id=ram-node3,size=268435456 -numa node,nodeid=3,cpus=12-15,memdev=ram-node3 -object memory-backend-ram,id=ram-node4,size=1610612736 -numa node,nodeid=4,memdev=ram-node4 -object memory-backend-ram,id=ram-node5,size=1610612736 -numa node,nodeid=5,memdev=ram-node5 -object memory-backend-ram,id=ram-node6,size=1610612736 -numa node,nodeid=6,memdev=ram-node6 -numa dist,src=0,dst=0,val=10 -numa dist,src=0,dst=1,val=21 -numa dist,src=0,dst=2,val=31 -numa dist,src=0,dst=3,val=21 -numa dist,src=0,dst=4,val=17 -numa dist,src=0,dst=5,val=38 -numa dist,src=0,dst=6,val=28 -numa dist,src=1,dst=0,val=21 -numa dist,src=1,dst=1,val=10 -numa dist,src=1,dst=2,val=21 -numa dist,src=1,dst=3,val=31 -numa dist,src=1,dst=4,val=28 -numa dist,src=1,dst=5,val=17 -numa dist,src=1,dst=6,val=38 -numa dist,src=2,dst=0,val=31 -numa dist,src=2,dst=1,val=21 -numa dist,src=2,dst=2,val=10 -numa dist,src=2,dst=3,val=21 -numa dist,src=2,dst=4,val=28 -numa dist,src=2,dst=5,val=28 -numa dist,src=2,dst=6,val=28 -numa dist,src=3,dst=0,val=21 -numa dist,src=3,dst=1,val=31 -numa dist,src=3,dst=2,val=21 -numa dist,src=3,dst=3,val=10 -numa dist,src=3,dst=4,val=28 -numa dist,src=3,dst=5,val=28 -numa dist,src=3,dst=6,val=17 -numa dist,src=4,dst=0,val=17 -numa dist,src=4,dst=1,val=28 -numa dist,src=4,dst=2,val=28 -numa dist,src=4,dst=3,val=28 -numa dist,src=4,dst=4,val=10 -numa dist,src=4,dst=5,val=28 -numa dist,src=4,dst=6,val=28 -numa dist,src=5,dst=0,val=38 -numa dist,src=5,dst=1,val=17 -numa dist,src=5,dst=2,val=28 -numa dist,src=5,dst=3,val=28 -numa dist,src=5,dst=4,val=28 -numa dist,src=5,dst=5,val=10 -numa dist,src=5,dst=6,val=28 -numa dist,src=6,dst=0,val=38 -numa dist,src=6,dst=1,val=28 -numa dist,src=6,dst=2,val=28 -numa dist,src=6,dst=3,val=17 -numa dist,src=6,dst=4,val=28 -numa dist,src=6,dst=5,val=28 -numa dist,src=6,dst=6,val=10 -smp 16,sockets=4,dies=1,cores=4,threads=1 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/mysuser/share -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=share_host -daemonize + +output from numactl -H: + +$ numactl -H +available: 7 nodes (0-6) +node 0 cpus: 0 1 2 3 +node 0 size: 250 MB +node 0 free: 191 MB +node 1 cpus: 4 5 6 7 +node 1 size: 251 MB +node 1 free: 199 MB +node 2 cpus: 8 9 10 11 +node 2 size: 251 MB +node 2 free: 218 MB +node 3 cpus: 12 13 14 15 +node 3 size: 251 MB +node 3 free: 118 MB +node 4 cpus: +node 4 size: 1511 MB +node 4 free: 1507 MB +node 5 cpus: +node 5 size: 1447 MB +node 5 free: 1443 MB +node 6 cpus: +node 6 size: 1489 MB +node 6 free: 1484 MB +node distances: +node 0 1 2 3 4 5 6 + 0: 10 21 31 21 17 38 28 + 1: 21 10 21 31 28 17 38 + 2: 31 21 10 21 28 28 28 + 3: 21 31 21 10 28 28 17 + 4: 17 28 28 28 10 28 28 + 5: 38 17 28 28 28 10 28 + 6: 38 28 28 17 28 28 10 + +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/review/1912790 b/results/classifier/118/review/1912790 new file mode 100644 index 000000000..4b2d1ed60 --- /dev/null +++ b/results/classifier/118/review/1912790 @@ -0,0 +1,129 @@ +register: 0.846 +mistranslation: 0.836 +virtual: 0.823 +peripherals: 0.822 +debug: 0.818 +assembly: 0.815 +device: 0.814 +performance: 0.814 +permissions: 0.809 +semantic: 0.807 +graphic: 0.804 +arm: 0.804 +risc-v: 0.799 +architecture: 0.792 +user-level: 0.786 +socket: 0.782 +hypervisor: 0.772 +network: 0.771 +kernel: 0.767 +boot: 0.760 +TCG: 0.754 +ppc: 0.750 +PID: 0.749 +files: 0.740 +KVM: 0.724 +i386: 0.718 +x86: 0.702 +vnc: 0.702 +VMM: 0.642 +-------------------- +debug: 0.840 +kernel: 0.565 +hypervisor: 0.086 +TCG: 0.075 +files: 0.057 +user-level: 0.049 +PID: 0.037 +register: 0.020 +performance: 0.020 +assembly: 0.019 +semantic: 0.013 +architecture: 0.011 +boot: 0.007 +device: 0.005 +virtual: 0.004 +VMM: 0.002 +risc-v: 0.002 +graphic: 0.002 +network: 0.002 +x86: 0.002 +arm: 0.001 +permissions: 0.001 +socket: 0.001 +ppc: 0.001 +KVM: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +vnc: 0.001 +i386: 0.000 + +qemu-aarch64-static segfaults python3 + +qemu-aarch64-static is segfaulting in a debian build process using debootstrap. + +``` +Type "apropos word" to search for commands related to "word"... +Reading symbols from /usr/bin/qemu-aarch64-static... +Reading symbols from /usr/lib/debug/.build-id/30/efd3930fb9519b21470b113679376f2ffbb41a.debug... +[New LWP 21817] +[New LWP 21819] + +warning: Corrupted shared library list: 0xd5f140 != 0x0 +Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed +Core was generated by `/usr/bin/qemu-aarch64-static /usr/bin/python3.9 -c import imp; print(imp.get_ta'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 have_mmap_lock () at ../../linux-user/mmap.c:43 +43 return mmap_lock_count > 0 ? true : false; +[Current thread is 1 (LWP 21817)] +(gdb) bt +#0 have_mmap_lock () at ../../linux-user/mmap.c:43 +#1 0x000000000058eb2c in page_set_flags (start=start@entry=4194304, end=end@entry=26451968, flags=flags@entry=8) at ../../accel/tcg/translate-all.c:2568 +#2 0x00000000005638cd in target_mmap (start=start@entry=4194304, len=<optimized out>, len@entry=22257160, target_prot=target_prot@entry=0, flags=16434, + fd=fd@entry=-1, offset=offset@entry=0) at ../../linux-user/mmap.c:602 +#3 0x000000000057042d in load_elf_image (image_name=0x7ffff7b7e8d8 "/usr/bin/python3.9", image_fd=3, info=info@entry=0x7ffff7b7ce70, + pinterp_name=pinterp_name@entry=0x7ffff7b7cbd0, bprm_buf=bprm_buf@entry=0x7ffff7b7d080 "\177ELF\002\001\001") at ../../linux-user/elfload.c:2700 +#4 0x0000000000570b9c in load_elf_binary (bprm=bprm@entry=0x7ffff7b7d080, info=info@entry=0x7ffff7b7ce70) at ../../linux-user/elfload.c:3104 +#5 0x00000000005c2fdb in loader_exec (fdexec=fdexec@entry=3, filename=<optimized out>, argv=argv@entry=0x2622910, envp=envp@entry=0x2686340, + regs=regs@entry=0x7ffff7b7cf70, infop=infop@entry=0x7ffff7b7ce70, bprm=<optimized out>) at ../../linux-user/linuxload.c:147 +#6 0x00000000004027f7 in main (argc=<optimized out>, argv=0x7ffff7b7d638, envp=<optimized out>) at ../../linux-user/main.c:810 + +(gdb) i r +rax 0x0 0 +rbx 0x400000 4194304 +rcx 0x7a95d2 8033746 +rdx 0x8 8 +rsi 0x193a000 26451968 +rdi 0x400000 4194304 +rbp 0x400000 0x400000 +rsp 0x7ffff7b7c978 0x7ffff7b7c978 +r8 0xffffffff 4294967295 +r9 0x0 0 +r10 0x4032 16434 +r11 0x206 518 +r12 0x193a000 26451968 +r13 0x8 8 +r14 0x8 8 +r15 0x193a000 26451968 +rip 0x562f20 0x562f20 <have_mmap_lock> +eflags 0x10206 [ PF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 + +``` + +Python3.9 is run as part of the installation of python3-minimal and the segfaults happens reliably here. Debian versionn bullseye (testing) + +Version: qemu-aarch64 version 5.2.0 (Debian 1:5.2+dfsg-3) + +Host is a qemu-system-x86_64: Linux runner 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux. + + + +Sorry, disregard this report. The qemu version actually running was an old version that had this bug (in debian 10). The 5.2 version does not have this issue. +I was confused by binfmt + docker. + diff --git a/results/classifier/118/review/1913926 b/results/classifier/118/review/1913926 new file mode 100644 index 000000000..4aced7bf6 --- /dev/null +++ b/results/classifier/118/review/1913926 @@ -0,0 +1,124 @@ +user-level: 0.952 +device: 0.901 +peripherals: 0.879 +arm: 0.871 +architecture: 0.870 +graphic: 0.866 +mistranslation: 0.790 +hypervisor: 0.750 +PID: 0.723 +performance: 0.720 +permissions: 0.703 +files: 0.698 +virtual: 0.678 +semantic: 0.658 +x86: 0.611 +register: 0.550 +debug: 0.538 +network: 0.533 +risc-v: 0.532 +TCG: 0.521 +ppc: 0.511 +kernel: 0.503 +boot: 0.479 +VMM: 0.466 +vnc: 0.452 +assembly: 0.420 +i386: 0.417 +socket: 0.354 +KVM: 0.351 +-------------------- +user-level: 0.626 +arm: 0.603 +debug: 0.075 +TCG: 0.061 +files: 0.036 +virtual: 0.031 +semantic: 0.014 +PID: 0.013 +device: 0.011 +risc-v: 0.008 +hypervisor: 0.005 +socket: 0.004 +register: 0.004 +VMM: 0.004 +graphic: 0.004 +network: 0.004 +boot: 0.004 +permissions: 0.004 +vnc: 0.002 +kernel: 0.002 +peripherals: 0.002 +performance: 0.002 +ppc: 0.002 +architecture: 0.002 +x86: 0.002 +assembly: 0.001 +mistranslation: 0.001 +i386: 0.000 +KVM: 0.000 + +[QEMU User-Mode] Mesa Fails To Load RadeonSI Driver When In Docker Image + +# System Details +AMD Ryzen 7 3700U +Ubuntu 20.04 Focal Focus + +# Dockerfile + +FROM arm32v7/debian:bullseye + +RUN apt-get update && apt-get install -y mesa-utils + +ENTRYPOINT glxgears + +# Instructions For Reproduction +1. Install Docker +2. Build Docker Image: docker build --tag mesa-arm-test . +3. Run: docker run -v /tmp/.X11-unix:/tmp/.X11-unix --device /dev/dri:/dev/dri -e "DISPLAY=${DISPLAY}" mesa-arm-test + +The Output Is: + +amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-38) +amdgpu: amdgpu_device_initialize failed. +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +libGL error: failed to get magic +libGL error: failed to load driver: radeonsi + +It then appears to run using software rendering. + +I think you definitely need to provide more information ... how do you run QEMU? Which QEMU version? etc. ... Anyway: + +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/review/1913969 b/results/classifier/118/review/1913969 new file mode 100644 index 000000000..992008257 --- /dev/null +++ b/results/classifier/118/review/1913969 @@ -0,0 +1,125 @@ +architecture: 0.872 +hypervisor: 0.693 +x86: 0.635 +performance: 0.612 +virtual: 0.540 +device: 0.522 +network: 0.503 +permissions: 0.497 +peripherals: 0.496 +socket: 0.487 +files: 0.460 +ppc: 0.445 +user-level: 0.444 +kernel: 0.444 +debug: 0.436 +KVM: 0.435 +boot: 0.422 +vnc: 0.406 +mistranslation: 0.396 +VMM: 0.391 +arm: 0.391 +semantic: 0.386 +PID: 0.376 +graphic: 0.360 +TCG: 0.339 +register: 0.322 +risc-v: 0.302 +i386: 0.301 +assembly: 0.299 +-------------------- +x86: 0.862 +hypervisor: 0.811 +TCG: 0.143 +debug: 0.101 +virtual: 0.045 +kernel: 0.016 +PID: 0.015 +VMM: 0.011 +files: 0.011 +performance: 0.009 +semantic: 0.005 +user-level: 0.004 +architecture: 0.003 +boot: 0.003 +network: 0.003 +risc-v: 0.002 +socket: 0.002 +KVM: 0.001 +graphic: 0.001 +device: 0.001 +register: 0.001 +vnc: 0.001 +permissions: 0.001 +assembly: 0.001 +ppc: 0.000 +mistranslation: 0.000 +peripherals: 0.000 +i386: 0.000 +arm: 0.000 + +unable to migrate non shared storage when TLS is used + +Operating system: Gentoo +Architecture: x86_64 +kernel version: 5.4.72, 5.10.11 +libvirt version: at least 6.9.0, 6.10.0, 7.0.0 +Hypervisor and version: qemu 5.1.0, 5.2.0 + +With software versions described above and following configurations: +libvirt: +key_file = "/etc/ssl/libvirt/server.lan.key" +cert_file = "/etc/ssl/libvirt/server.lan.crt" +ca_file = "/etc/ssl/libvirt/ca.crt" +log_filters="3:remote 4:event 3:util.json 3:rpc 1:*" +log_outputs="1:file:/var/log/libvirt/libvirtd.log" +qemu: +default_tls_x509_cert_dir = "/etc/ssl/qemu" +default_tls_x509_verify = 1 +migration with tls: +virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource --copy-storage-all --verbose --tls +never succeeds. Progress stops typically at high progress amounts (95%-98%), and network traffic drastically drops as well (from 1 gbps+ to nothing). domjobinfo progress also stops. Without --tls migrations succeed without issues without any other changes to hosts or configurations. + +Note: I reported this originally as libvirt bug: https://gitlab.com/libvirt/libvirt/-/issues/108. + +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. + + +cc;ing in eblake +Eric: Following that libvirt issue it looks like it's block related; something weird happening where only some of the disks are syncing? + + +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/310 + + diff --git a/results/classifier/118/review/1914986 b/results/classifier/118/review/1914986 new file mode 100644 index 000000000..ad55308ad --- /dev/null +++ b/results/classifier/118/review/1914986 @@ -0,0 +1,148 @@ +semantic: 0.807 +permissions: 0.797 +register: 0.751 +user-level: 0.727 +assembly: 0.717 +graphic: 0.712 +device: 0.710 +mistranslation: 0.705 +virtual: 0.684 +debug: 0.681 +architecture: 0.680 +PID: 0.670 +KVM: 0.665 +arm: 0.618 +vnc: 0.615 +TCG: 0.610 +kernel: 0.609 +socket: 0.592 +ppc: 0.591 +peripherals: 0.590 +x86: 0.575 +hypervisor: 0.571 +network: 0.567 +i386: 0.562 +files: 0.555 +risc-v: 0.545 +performance: 0.529 +boot: 0.528 +VMM: 0.427 +-------------------- +KVM: 0.981 +virtual: 0.812 +register: 0.706 +hypervisor: 0.644 +debug: 0.501 +x86: 0.192 +kernel: 0.171 +boot: 0.054 +performance: 0.041 +assembly: 0.024 +i386: 0.019 +TCG: 0.017 +PID: 0.015 +files: 0.014 +risc-v: 0.013 +device: 0.013 +ppc: 0.011 +arm: 0.010 +user-level: 0.009 +semantic: 0.007 +architecture: 0.004 +peripherals: 0.003 +graphic: 0.002 +VMM: 0.002 +socket: 0.002 +network: 0.001 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +KVM internal error. Suberror: 1 - OVMF / Audio related + +This is latest release QEMU-5.2.0 on Arch Linux running kernel 5.10.13, latest OVMF etc. + +I'm seeing the following crash when loading an audio driver from the OpenCore[1] project in the UEFI shell: + +KVM internal error. Suberror: 1 +emulation failure +RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000000 RDX=0000000000000000 +RSI=0000000000000000 RDI=000000007e423628 RBP=000000007fee6a90 RSP=000000007fee6a08 +R8 =0000000000000000 R9 =0000000000000080 R10=0000000000000000 R11=0000000000000000 +R12=000000007eeaf828 R13=0000000000000000 R14=0000000000000000 R15=000000007fee6a67 +RIP=00000000000b0000 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0038 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +GS =0030 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000007f9ee698 00000047 +IDT= 000000007f27a018 00000fff +CR0=80010033 CR2=0000000000000000 CR3=000000007fc01000 CR4=00000668 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d00 +Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <ff> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + + +Here's the QEMU command line I'm using: + +qemu-system-x86_64 \ +-machine q35,accel=kvm \ +-cpu host,+topoext,+invtsc \ +-smp 4,sockets=1,cores=2 \ +-m 4096 \ +-drive file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,readonly=on \ +-drive file=OVMF_VARS.fd,if=pflash,format=raw \ +-usb -device usb-tablet -device usb-kbd \ +-drive file=OpenCore-0.6.6.img,format=raw \ +-device ich9-intel-hda,bus=pcie.0,addr=0x1b \ +-device hda-micro,audiodev=hda \ +-audiodev pa,id=hda,server=/run/user/1000/pulse/native + +The driver loads fine when using the "no connect" switch. eg: + +Shell> load -nc fs0:\efi\oc\drivers\audiodxe.efi +Shell> Image 'fs0:\EFI\OC\Drivers\AudioDxe.efi' loaded at 7E3C7000 - Success + +However, the crash occurs when loading normally. + +Any ideas? Thanks. + +[1]: https://github.com/acidanthera/OpenCorePkg/releases + +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/review/1915063 b/results/classifier/118/review/1915063 new file mode 100644 index 000000000..bccec7f27 --- /dev/null +++ b/results/classifier/118/review/1915063 @@ -0,0 +1,765 @@ +mistranslation: 0.924 +permissions: 0.894 +user-level: 0.886 +debug: 0.884 +peripherals: 0.852 +semantic: 0.833 +ppc: 0.832 +hypervisor: 0.828 +risc-v: 0.820 +vnc: 0.819 +register: 0.814 +arm: 0.807 +VMM: 0.784 +virtual: 0.783 +files: 0.779 +performance: 0.773 +device: 0.766 +graphic: 0.763 +architecture: 0.758 +boot: 0.757 +network: 0.755 +socket: 0.741 +PID: 0.741 +assembly: 0.734 +x86: 0.730 +TCG: 0.729 +KVM: 0.680 +kernel: 0.676 +i386: 0.543 +-------------------- +virtual: 0.947 +hypervisor: 0.635 +kernel: 0.409 +debug: 0.332 +x86: 0.077 +vnc: 0.067 +files: 0.042 +user-level: 0.039 +register: 0.027 +socket: 0.023 +TCG: 0.021 +PID: 0.014 +VMM: 0.012 +device: 0.011 +network: 0.009 +semantic: 0.008 +boot: 0.008 +risc-v: 0.004 +assembly: 0.003 +ppc: 0.003 +graphic: 0.002 +performance: 0.002 +permissions: 0.002 +architecture: 0.002 +KVM: 0.001 +i386: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +arm: 0.000 + +Windows 10 wil not install using qemu-system-x86_64 + +Steps to reproduce +install virt-manager and ovmf if nopt already there +copy windows and virtio iso files to /var/lib/libvirt/images + +Use virt-manager from local machine to create your VMs with the disk, CPUs and memory required + Select customize configuration then select OVMF(UEFI) instead of seabios + set first CDROM to the windows installation iso (enable in boot options) + add a second CDROM and load with the virtio iso + change spice display to VNC + + Always get a security error from windows and it fails to launch the installer (works on RHEL and Fedora) +I tried updating the qemu version from Focals 4.2 to Groovy 5.0 which was of no help + +This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: + +apport-collect 1915063 + +and then change the status of the bug to 'Confirmed'. + +If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. + +This change has been made by an automated script, maintained by the Ubuntu Kernel Team. + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +apport information + +We believe that the latest version of Windows doesn't play nice with the older version of QEMU - it seems Windows is broken somewhere between 4.2.0-2 and 5.0.0-6 on AMD Ryzen based processors (which is what we have on the P620). + +What are the recommendations for the best way for a Ubuntu customer to get going again, with an updated version of QEMU? + + +I'm subscribing Christian to this bug, who is our QEMU expert. + +Hi, +I was just recently for a different case installing a Win10 guest and had the ISOs available. +So I was trying to install an OVMF based one through virt-manager as you asked. + +ISOs +- win10 20H2_v2 +- virtio iso 0.1.190 + +I used the default "new guest" of virt-manager and then went into "customize before install" to also add the virtio drivers and select the OVMF mode. + +BTW I'd not expect that providing the virtio ISO is related to triggering (or not triggering the bug). If you could confirm that it happens without that as well it would make reproducing this a little bit easier. The default config uses SATA. + +Info: +If the ISO is not auto-boointg (depends on some setup detail e.g. how you add your extra CD images) you can still manually load the Windows EFI loader like: +FS0: +cd EFI +cd BOOT +BOOTX64.EFI + +I started my tests on 21.04 Hirsute as that is what I had around. +qemu 1:5.2+dfsg-6ubuntu2 virt-manager 1:3.2.0-3 ovmf 2020.11-2 +That started up the installer just fine no matter if I used SATA or virtio for the root disk. + +Next I tried Focal (as reported) +qemu 1:4.2-3ubuntu6.14 virt-manager 1:2.2.1-3ubuntu2.1 ovmf 0~20191122.bd85bf54-2ubuntu3.1 +That also started the windows installer without an error. + + +Therefore I can't confirm your issue (yet) and will set this to incomplete. +Have you in the meantime found more details about what exactly makes the issue trigger/pass for you? + +In regard your further comments and for clarification: +- @Mark: I don't have a Ryzen based processor thou, so your case could still be absolutely + valid, yet I can't confirm/deny at the time. Do you have any more data showing that it is + processor dependent? +- David said 5.0 didn't help while Mark said between .2.0-2 and 5.0.0-6 it is fixed. Are + we sure you all talk about the same bug? + For those that want/can try a new version give the virt-stack from [1] a try, if that + resolves it for you we can look fox fixes in between those versions. +- David you said "get a security error from windows" can you be more specific about the error + that you get? That will also help to check if you two are facing the same issue. + +[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports + +I am not using a virtio based drive so that should not be par of the issue, I normally do not use the virtio iso until windows is installed to clear errors in the device manager +I tried using even the version 5.2 from the hirsute release and that also is not working +As a test I tried doing this from an Intel based machine and it does install correctly using even the default version of qemu-system_x64 from focal +Attaching a screen show of the error I get when installing on an AMD Ryzen Threadripper processor + + + +Thanks David, +I have no threadripper around atm, I think I can next week get hands on an EPYC Rome, but that isn't 100% the same. + +But gladly you tried this on the latest qemu 5.2 and since it is failing there as well it might be worth to also report it upstream. That is a great community which might have ran things on a threadripper already and be able to point us to a qemu/kernel fix - or at least an existing discussions abut it. +For now I'm adding a qemu task here which will mirror this case to the mailing list. + +I was playing around with this and find that if I change the Configuration under CPUs from the default (uncheck "Copy host CPU configuration") and select qemu64 in the Model drop down box I can get it to work + +That is awesome David, +qemu64 is like a very low common denominator with only very basic CPU features. +While "copy host" means "enable all you can". + +We can surely work with that a bit, but until I get access to the same HW I need you to do it. + + +If you run in a console `$virsh domcapabilities` it will spew some XML at you. One of the sections will be for "host-model". In my case that looks like + + <mode name='host-model' supported='yes'> + <model fallback='forbid'>Skylake-Client-IBRS</model> + <vendor>Intel</vendor> + <feature policy='require' name='ss'/> + <feature policy='require' name='vmx'/> + <feature policy='require' name='hypervisor'/> +... + </mode> + + +That means a names CPU type (the one that is closest to what you have) and some feature additionally enabled/disabled. + +If you could please post the full output you have, that can be useful. +From there you could go two steps. +1. as you see in my example it will list some cpu features on top of the named type. + If you remove them one by one you might be able to identify the single-cpu featute + that breaks in your case. +2. The named CPU that you have also has a representation, it can be found in + /usr/share/libvirt/cpu_map... + That ill list all the CPU features that make up the named type. + If #1 wasn't sufficient, you can now add those to your guest definition one by one in disabled + state, example + <feature policy='disable' name='ss'/> + +A description of the underlying mechanism is here https://libvirt.org/formatdomain.html#cpu-model-and-topology + +<domainCapabilities> + <path>/usr/bin/qemu-system-x86_64</path> + <domain>kvm</domain> + <machine>pc-i440fx-hirsute</machine> + <arch>x86_64</arch> + <vcpu max='255'/> + <iothreads supported='yes'/> + <os supported='yes'> + <enum name='firmware'> + <value>efi</value> + </enum> + <loader supported='yes'> + <value>/usr/share/OVMF/OVMF_CODE_4M.fd</value> + <enum name='type'> + <value>rom</value> + <value>pflash</value> + </enum> + <enum name='readonly'> + <value>yes</value> + <value>no</value> + </enum> + <enum name='secure'> + <value>no</value> + </enum> + </loader> + </os> + <cpu> + <mode name='host-passthrough' supported='yes'/> + <mode name='host-model' supported='yes'> + <model fallback='forbid'>EPYC-Rome</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + </mode> + <mode name='custom' supported='yes'> + <model usable='yes'>qemu64</model> + <model usable='yes'>qemu32</model> + <model usable='no'>phenom</model> + <model usable='yes'>pentium3</model> + <model usable='yes'>pentium2</model> + <model usable='yes'>pentium</model> + <model usable='no'>n270</model> + <model usable='yes'>kvm64</model> + <model usable='yes'>kvm32</model> + <model usable='no'>coreduo</model> + <model usable='no'>core2duo</model> + <model usable='no'>athlon</model> + <model usable='no'>Westmere-IBRS</model> + <model usable='yes'>Westmere</model> + <model usable='no'>Skylake-Server-noTSX-IBRS</model> + <model usable='no'>Skylake-Server-IBRS</model> + <model usable='no'>Skylake-Server</model> + <model usable='no'>Skylake-Client-noTSX-IBRS</model> + <model usable='no'>Skylake-Client-IBRS</model> + <model usable='no'>Skylake-Client</model> + <model usable='no'>SandyBridge-IBRS</model> + <model usable='yes'>SandyBridge</model> + <model usable='yes'>Penryn</model> + <model usable='no'>Opteron_G5</model> + <model usable='no'>Opteron_G4</model> + <model usable='yes'>Opteron_G3</model> + <model usable='yes'>Opteron_G2</model> + <model usable='yes'>Opteron_G1</model> + <model usable='no'>Nehalem-IBRS</model> + <model usable='yes'>Nehalem</model> + <model usable='no'>IvyBridge-IBRS</model> + <model usable='no'>IvyBridge</model> + <model usable='no'>Icelake-Server-noTSX</model> + <model usable='no'>Icelake-Server</model> + <model usable='no'>Icelake-Client-noTSX</model> + <model usable='no'>Icelake-Client</model> + <model usable='no'>Haswell-noTSX-IBRS</model> + <model usable='no'>Haswell-noTSX</model> + <model usable='no'>Haswell-IBRS</model> + <model usable='no'>Haswell</model> + <model usable='yes'>EPYC-Rome</model> + <model usable='yes'>EPYC-IBPB</model> + <model usable='yes'>EPYC</model> + <model usable='yes'>Dhyana</model> + <model usable='yes'>Conroe</model> + <model usable='no'>Cascadelake-Server-noTSX</model> + <model usable='no'>Cascadelake-Server</model> + <model usable='no'>Broadwell-noTSX-IBRS</model> + <model usable='no'>Broadwell-noTSX</model> + <model usable='no'>Broadwell-IBRS</model> + <model usable='no'>Broadwell</model> + <model usable='yes'>486</model> + </mode> + </cpu> + <devices> + <disk supported='yes'> + <enum name='diskDevice'> + <value>disk</value> + <value>cdrom</value> + <value>floppy</value> + <value>lun</value> + </enum> + <enum name='bus'> + <value>ide</value> + <value>fdc</value> + <value>scsi</value> + <value>virtio</value> + <value>usb</value> + <value>sata</value> + </enum> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + </disk> + <graphics supported='yes'> + <enum name='type'> + <value>sdl</value> + <value>vnc</value> + <value>spice</value> + </enum> + </graphics> + <video supported='yes'> + <enum name='modelType'> + <value>vga</value> + <value>cirrus</value> + <value>vmvga</value> + <value>qxl</value> + <value>virtio</value> + <value>none</value> + <value>bochs</value> + <value>ramfb</value> + </enum> + </video> + <hostdev supported='yes'> + <enum name='mode'> + <value>subsystem</value> + </enum> + <enum name='startupPolicy'> + <value>default</value> + <value>mandatory</value> + <value>requisite</value> + <value>optional</value> + </enum> + <enum name='subsysType'> + <value>usb</value> + <value>pci</value> + <value>scsi</value> + </enum> + <enum name='capsType'/> + <enum name='pciBackend'> + <value>default</value> + <value>vfio</value> + </enum> + </hostdev> + <rng supported='yes'> + <enum name='model'> + <value>virtio</value> + <value>virtio-transitional</value> + <value>virtio-non-transitional</value> + </enum> + <enum name='backendModel'> + <value>random</value> + <value>egd</value> + </enum> + </rng> + </devices> + <features> + <gic supported='no'/> + <vmcoreinfo supported='yes'/> + <genid supported='yes'/> + <backingStoreInput supported='yes'/> + <backup supported='no'/> + <sev supported='no'/> + </features> +</domainCapabilities> + +Ok, so you should be able to drop these lines one by one: + + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + +If that does not yet make it work, add those one by one (removing the features of the named type) + <feature policy='disable' name='3dnowprefetch'/> + <feature policy='disable' name='abm'/> + <feature policy='disable' name='adx'/> + <feature policy='disable' name='aes'/> + <feature policy='disable' name='amd-stibp'/> + <feature policy='disable' name='apic'/> + <feature policy='disable' name='arat'/> + <feature policy='disable' name='avx'/> + <feature policy='disable' name='avx2'/> + <feature policy='disable' name='bmi1'/> + <feature policy='disable' name='bmi2'/> + <feature policy='disable' name='clflush'/> + <feature policy='disable' name='clflushopt'/> + <feature policy='disable' name='clwb'/> + <feature policy='disable' name='clzero'/> + <feature policy='disable' name='cmov'/> + <feature policy='disable' name='cr8legacy'/> + <feature policy='disable' name='cx16'/> + <feature policy='disable' name='cx8'/> + <feature policy='disable' name='de'/> + <feature policy='disable' name='f16c'/> + <feature policy='disable' name='fma'/> + <feature policy='disable' name='fpu'/> + <feature policy='disable' name='fsgsbase'/> + <feature policy='disable' name='fxsr'/> + <feature policy='disable' name='fxsr_opt'/> + <feature policy='disable' name='ibpb'/> + <feature policy='disable' name='lahf_lm'/> + <feature policy='disable' name='lm'/> + <feature policy='disable' name='mca'/> + <feature policy='disable' name='mce'/> + <feature policy='disable' name='misalignsse'/> + <feature policy='disable' name='mmx'/> + <feature policy='disable' name='mmxext'/> + <feature policy='disable' name='movbe'/> + <feature policy='disable' name='msr'/> + <feature policy='disable' name='mtrr'/> + <feature policy='disable' name='npt'/> + <feature policy='disable' name='nrip-save'/> + <feature policy='disable' name='nx'/> + <feature policy='disable' name='osvw'/> + <feature policy='disable' name='pae'/> + <feature policy='disable' name='pat'/> + <feature policy='disable' name='pclmuldq'/> + <feature policy='disable' name='pdpe1gb'/> + <feature policy='disable' name='perfctr_core'/> + <feature policy='disable' name='pge'/> + <feature policy='disable' name='pni'/> + <feature policy='disable' name='popcnt'/> + <feature policy='disable' name='pse'/> + <feature policy='disable' name='pse36'/> + <feature policy='disable' name='rdpid'/> + <feature policy='disable' name='rdrand'/> + <feature policy='disable' name='rdseed'/> + <feature policy='disable' name='rdtscp'/> + <feature policy='disable' name='sep'/> + <feature policy='disable' name='sha-ni'/> + <feature policy='disable' name='smap'/> + <feature policy='disable' name='smep'/> + <feature policy='disable' name='sse'/> + <feature policy='disable' name='sse2'/> + <feature policy='disable' name='sse4.1'/> + <feature policy='disable' name='sse4.2'/> + <feature policy='disable' name='sse4a'/> + <feature policy='disable' name='ssse3'/> + <feature policy='disable' name='svm'/> + <feature policy='disable' name='syscall'/> + <feature policy='disable' name='tsc'/> + <feature policy='disable' name='umip'/> + <feature policy='disable' name='vme'/> + <feature policy='disable' name='wbnoinvd'/> + <feature policy='disable' name='xgetbv1'/> + <feature policy='disable' name='xsave'/> + <feature policy='disable' name='xsavec'/> + <feature policy='disable' name='xsaveerptr'/> + <feature policy='disable' name='xsaveopt'/> + +Eventually I'd hope you identify one feature (re add everything but this to verify) that breaks it. Any chance to do this iterative test? You could also "bisect" this list if you want to save some time. + +On Sat, 03 Apr 2021 16:52:13 -0000 +Christian Ehrhardt <email address hidden> wrote: + +> That is awesome David, +> qemu64 is like a very low common denominator with only very basic CPU features. +> While "copy host" means "enable all you can". + +Also it's worth to try setting real CPU topology for if EPYC cpu model is used. +i.e. use -smp with options that resemble a real EPYC cpu +(for number of core complexes is configured with 'dies' option in QEMU) + + +> We can surely work with that a bit, but until I get access to the same +> HW I need you to do it. +> +> +> If you run in a console `$virsh domcapabilities` it will spew some XML at you. One of the sections will be for "host-model". In my case that looks like +> +> <mode name='host-model' supported='yes'> +> <model fallback='forbid'>Skylake-Client-IBRS</model> +> <vendor>Intel</vendor> +> <feature policy='require' name='ss'/> +> <feature policy='require' name='vmx'/> +> <feature policy='require' name='hypervisor'/> +> ... +> </mode> +> +> +> That means a names CPU type (the one that is closest to what you have) and some feature additionally enabled/disabled. +> +> If you could please post the full output you have, that can be useful. +> >From there you could go two steps. +> 1. as you see in my example it will list some cpu features on top of the named type. +> If you remove them one by one you might be able to identify the single-cpu featute +> that breaks in your case. +> 2. The named CPU that you have also has a representation, it can be found in +> /usr/share/libvirt/cpu_map... +> That ill list all the CPU features that make up the named type. +> If #1 wasn't sufficient, you can now add those to your guest definition one by one in disabled +> state, example +> <feature policy='disable' name='ss'/> +> +> A description of the underlying mechanism is here +> https://libvirt.org/formatdomain.html#cpu-model-and-topology +> + + + +I have not done any of what you are asking so not exactly sure how to change those values, been looking and reading but not finding what I want so thought it might be better to just ask how to do what yo are asking. I did try CPU type EPYC and that did get past the error I am seeing on install + +On Wed, 07 Apr 2021 13:00:23 -0000 +David Ober <email address hidden> wrote: + +> I have not done any of what you are asking so not exactly sure how to +> change those values, been looking and reading but not finding what I +> want so thought it might be better to just ask how to do what yo are +> asking. + +see https://libvirt.org/formatdomain.html#cpu-model-and-topology +for the way to describe topology in domain xml. +Pick a real AMD CPU for cpu model you're are having problem with, +and use its config to define topology. + +> I did try CPU type EPYC and that did get past the error I am +> seeing on install +So it works with EPYC but not with ECPY-Rome, then probably topology +is not issue. + +CCing Babu, +who added EPYC-Rome cpu model, maybe he can help + + + + +I remember seeing something similar before. This was supposed to be fixed by the linux kernel commit. + +commit 841c2be09fe4f495fe5224952a419bd8c7e5b455 +Author: Maxim Levitsky <email address hidden> +Date: Wed Jul 8 14:57:31 2020 +0300 + +kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host + +# git describe --contains 841c2be09fe4f495fe5224952a419bd8c7e5b455 +v5.9-rc1~121^2~67 + +Problem seems to happen with EPYC-Rome model which exposes the feature STIBP but not IBRS. + +Did you guys try "-cpu host"? It might work. + + +Thanks Babu/Igor for chiming in! + +@Babu +That exposed STIBP but not IBRS - isn't that what you tried to solve (for userspace) in qemu via a v2 for the Rome chips? +=> https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01020.html + +I was recently pinging that, as it wasn't merged into the qemu 6.0-rc +Do you have any more insight why this is held back still? + +If I might ask - how does the kernel fix you referenced interact with this proposed qemu change? +Assumptions (please correct me): +1. with the qemu change and using that Rome-v2 it would ask to expose both features and no more crash (even on unfixed kernels) +2. with the kernel fix it will no more crash, even with an unfixed qemu? + +Finally I'm able to test on a Threadripper myself now. + +Note: In regard to the commit that Babu identified - I'm on kernel 5.10.0-1020-oem so that patch would be applied already. I need to find an older kernel to retry with that as well + +(on that new kernel) I did a full Win10 install and it worked fine for me. + +In regard to CPU types (for comparison) I got + +qemu 1:4.2-3ubuntu6.15 / libvirt 6.0.0-0ubuntu8.8: + <mode name='host-model' supported='yes'> + <model fallback='forbid'>EPYC-Rome</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + </mode> + +With a more recent qemu/libvirt it isn't much different for this chip (there recently were some Milan changes, but those seem not to matter for this chip). + +qemu 1:5.2+dfsg-9ubuntu1 / libvirt 7.0.0-2ubuntu1 + + <mode name='host-model' supported='yes'> + <model fallback='forbid'>EPYC-Rome</model> + <vendor>AMD</vendor> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='tsc-deadline'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='tsc_adjust'/> + <feature policy='require' name='stibp'/> + <feature policy='require' name='arch-capabilities'/> + <feature policy='require' name='ssbd'/> + <feature policy='require' name='xsaves'/> + <feature policy='require' name='cmp_legacy'/> + <feature policy='require' name='invtsc'/> + <feature policy='require' name='amd-ssbd'/> + <feature policy='require' name='virt-ssbd'/> + <feature policy='require' name='rdctl-no'/> + <feature policy='require' name='skip-l1dfl-vmentry'/> + <feature policy='require' name='mds-no'/> + <feature policy='require' name='pschange-mc-no'/> + </mode> + + +I wasn't able to crash this setup with an old (18.04) nor a new 21.04) Ubuntu guest. +Installing Win10 worked fine for a while and didn't break as reported. But the setup I have goes through triple ssh-tunnels and around the globe - that slows things down a lot :-/ +This is how far I've got: +1. start up the install +2. select no license key -> custom install -> it started copying files +3. it goes into the first reboot + +After this the latency kills me and virt-manager starts to abort the installation. +So far I did not hit (https://launchpadlibrarian.net/529734412/security.png) as reported by David. +@David - did this already pass the critical step for you, how early or late in the install did you hit the issues. + + +As I said I'll probably need to find an older kernel anyway (to be before the commit that Babu referenced) + +@Christian, +Yes. This following patch fixes the problem + https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01020.html + +I saw your ping on the patch. I am not sure why it is not picked up. I am going ping them today. + +>If I might ask - how does the kernel fix you referenced interact with this proposed qemu change? +>Assumptions (please correct me): +Problem seem to happen when guest tries to access the SPEC_CTRL register to with the wrong settings. The kernel fix avoids writing those values and avoids #GP fault. + +>1. with the qemu change and using that Rome-v2 it would ask to expose both features and no more crash (even >on unfixed kernels) +Yes. With Qemu patch EPYC-Rome v2 this issue will be fixed. + +>2. with the kernel fix it will no more crash, even with an unfixed qemu? +Yes, That is correct. We need at lease one of these patches to fix this problem. + + + +David used "5.6.0-1042.46-oem", the closest I had was "5.6.0-1052-oem" so I tried that one. + +With that my win10 install immediately crashed into the reported issue. + +So to summarize: +1. I can reproduce it +2. Chances are high that it is fixed by kernel commit 841c2be0 "kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host" +3. there are some qemu changes which might be related, but we need Babu to reply about if/how those are related + +I need to get myself updated on Ubuntu oem kernels. +If there is a 5.6 series that is supposed to work on that, then this patch needs to be backported. +But if OTOH it is a valid upgrade path that you'll get the 5.10.0-1020-oem that I had or later as part of your 20.04 OEM then that "is the fix" for you @David. + + + + + +This change was made by a bot. + +Thanks @Babu for the clarifications! +I really hope that the qemu patch makes it in v6.0 - then I can better consider picking it up as backport for qemu (already have a bug about that in bug 1921754 - therefore I'm setting the qemu task here as invalid) + +The last step I can provide for the kernel bug that this one here is (before the rest of the work is with the kernel Team) is to verify/falsify if that also affects the non-oem linux-generic kernel. +There the latest was 5.4.0.71.74 from focal-proposed and the latest already released one is 5.4.0.70.73. + +5.4.0.70.73 - failing +5.4.0.71.74 - failing + +So while the almost-released oem kernel based on 5.10 will cover this - the patch should indeed also be backported to linux-generic and all the other flavours - otherwise Windows (and potentially more) will no more be usable as KVM guest on such Chips (threadrippers, but maybe more AMD chips that are not yet known as well) + +The commit in question is marked for stable: + + commit 841c2be09fe4f495fe5224952a419bd8c7e5b455 + Author: Maxim Levitsky <email address hidden> + Date: Wed Jul 8 14:57:31 2020 +0300 + + kvm: x86: replace kvm_spec_ctrl_test_value with runtime test on the host + + To avoid complex and in some cases incorrect logic in + kvm_spec_ctrl_test_value, just try the guest's given value on the host + processor instead, and if it doesn't #GP, allow the guest to set it. + + One such case is when host CPU supports STIBP mitigation + but doesn't support IBRS (as is the case with some Zen2 AMD cpus), + and in this case we were giving guest #GP when it tried to use STIBP + + The reason why can can do the host test is that IA32_SPEC_CTRL msr is + passed to the guest, after the guest sets it to a non zero value + for the first time (due to performance reasons), + and as as result of this, it is pointless to emulate #GP condition on + this first access, in a different way than what the host CPU does. + + This is based on a patch from Sean Christopherson, who suggested this idea. + + Fixes: 6441fa6178f5 ("KVM: x86: avoid incorrect writes to host MSR_IA32_SPEC_CTRL") + Cc: <email address hidden> + Suggested-by: Sean Christopherson <email address hidden> + Signed-off-by: Maxim Levitsky <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +It appears to be in `v5.4.102` which is currently queued up for the cycle following the one just starting. + +The patch for QEMU that has been mentioned in comment #38 has been merged already, so I'm marking this as Fix-Released there. + diff --git a/results/classifier/118/review/1915431 b/results/classifier/118/review/1915431 new file mode 100644 index 000000000..105a807f1 --- /dev/null +++ b/results/classifier/118/review/1915431 @@ -0,0 +1,104 @@ +user-level: 0.807 +architecture: 0.694 +performance: 0.645 +graphic: 0.622 +hypervisor: 0.619 +semantic: 0.570 +permissions: 0.568 +network: 0.561 +files: 0.559 +device: 0.544 +register: 0.536 +mistranslation: 0.531 +debug: 0.522 +PID: 0.491 +assembly: 0.490 +peripherals: 0.482 +ppc: 0.475 +socket: 0.461 +VMM: 0.450 +TCG: 0.446 +kernel: 0.436 +i386: 0.433 +vnc: 0.428 +x86: 0.413 +KVM: 0.397 +risc-v: 0.373 +virtual: 0.372 +arm: 0.370 +boot: 0.276 +-------------------- +x86: 0.081 +debug: 0.075 +TCG: 0.066 +virtual: 0.065 +user-level: 0.065 +PID: 0.049 +performance: 0.042 +hypervisor: 0.030 +semantic: 0.024 +files: 0.019 +device: 0.014 +i386: 0.014 +network: 0.013 +ppc: 0.009 +register: 0.005 +arm: 0.005 +peripherals: 0.005 +boot: 0.005 +assembly: 0.004 +architecture: 0.004 +risc-v: 0.004 +kernel: 0.003 +permissions: 0.003 +socket: 0.002 +graphic: 0.002 +vnc: 0.002 +VMM: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +QEMU processes started by Acceptance Tests are left running + +Every now and then, QEMU processes started by the Acceptance Tests (thus by Avocado) will be left running. + +From Avocado's perspective, when everything "goes well" and a test reaches completion, there's no attempt to terminate any processes it indirectly started. Some frameworks and tests built on top of Avocado, for instance Avocado-VT, will keep processes running between various tests. + +When a job (and consequently a test) is manually interrupted, then Avocado tries to terminate the entire process tree. + +It may be possible to improve the situation in which, at the very least, the user is: + * notified of left over processes + * have a configuration option that will attempt to kill all processes at the end of the test execution + +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/review/1915539 b/results/classifier/118/review/1915539 new file mode 100644 index 000000000..021508e34 --- /dev/null +++ b/results/classifier/118/review/1915539 @@ -0,0 +1,167 @@ +risc-v: 0.888 +KVM: 0.879 +hypervisor: 0.877 +i386: 0.875 +TCG: 0.869 +VMM: 0.860 +peripherals: 0.853 +vnc: 0.842 +mistranslation: 0.818 +ppc: 0.809 +x86: 0.806 +user-level: 0.694 +semantic: 0.569 +PID: 0.552 +virtual: 0.551 +graphic: 0.550 +device: 0.545 +permissions: 0.545 +register: 0.533 +debug: 0.517 +arm: 0.502 +performance: 0.447 +architecture: 0.424 +boot: 0.421 +network: 0.416 +assembly: 0.415 +socket: 0.415 +files: 0.409 +kernel: 0.407 +-------------------- +i386: 0.999 +x86: 0.985 +debug: 0.858 +virtual: 0.789 +kernel: 0.711 +assembly: 0.705 +hypervisor: 0.428 +device: 0.222 +peripherals: 0.218 +files: 0.147 +TCG: 0.128 +performance: 0.124 +architecture: 0.095 +user-level: 0.075 +register: 0.061 +boot: 0.054 +VMM: 0.051 +KVM: 0.050 +risc-v: 0.043 +PID: 0.041 +semantic: 0.028 +ppc: 0.020 +socket: 0.007 +network: 0.006 +permissions: 0.006 +graphic: 0.005 +vnc: 0.003 +mistranslation: 0.003 +arm: 0.001 + +Null-ptr dereference on AHCICmdHdr in ahci_pio_transfer + +== Reproducer == + +cat << EOF | ./qemu-system-i386 -display none \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-hd,drive=disk0 -machine accel=qtest -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0x10a 0x1 0x02 +write 0xe0000398 0x1 0x01 +write 0x20000 0x1 0x27 +write 0x20001 0x1 0x80 +write 0x20002 0x1 0x20 +write 0x20005 0x1 0x02 +write 0xe00003b8 0x2 0x0101 +write 0xe0000004 0x1 0x01 +write 0x2bb 0x1 0x00 +write 0x2bf 0x1 0x00 +write 0x2cf 0x1 0x00 +write 0x2db 0x1 0x00 +write 0x2df 0x1 0x00 +write 0x2ed 0x1 0x00 +write 0x2ef 0x1 0x00 +write 0x2fb 0x1 0x00 +write 0x2ff 0x1 0x00 +write 0x31f 0x1 0x00 +write 0x32b 0x1 0x00 +write 0x32f 0x1 0x00 +write 0x337 0x1 0x00 +write 0x33f 0x1 0x00 +write 0x347 0x1 0x00 +write 0x357 0x1 0x00 +write 0x35f 0x1 0x00 +write 0x36b 0x1 0x00 +write 0x36f 0x1 0x00 +write 0x377 0x1 0x00 +write 0x37f 0x1 0x00 +write 0x397 0x1 0x00 +write 0x39f 0x1 0x00 +write 0x3ab 0x1 0x00 +write 0x3af 0x1 0x00 +write 0x3b7 0x1 0x00 +write 0x3bf 0x1 0x00 +write 0x3c7 0x1 0x00 +write 0x3d7 0x1 0x00 +write 0x3df 0x1 0x00 +write 0x3eb 0x1 0x00 +write 0x3ef 0x1 0x00 +write 0x3f7 0x1 0x00 +write 0x3ff 0x1 0x00 +write 0xe0000394 0x1 0x00 +write 0xe0000398 0x1 0x01 +EOF + +== Stack Trace == +../hw/ide/ahci.c:1349:46: runtime error: member access within null pointer of +type 'AHCICmdHdr' (aka 'struct AHCICmdHdr') SUMMARY: +UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/ahci.c:1349:46 in +../hw/ide/ahci.c:1349:46: runtime error: load of null pointer of type +'uint16_t' (aka 'unsigned short') +SUMMARY: UndefinedBehaviorSanitizer: +undefined-behavior ../hw/ide/ahci.c:1349:46 in AddressSanitizer:DEADLYSIGNAL +================================================================= +==238806==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc +0x555787d414c9 bp 0x7fffe1bb41a0 sp 0x7fffe1bb3fe0 T0) +==238806==The signal is caused by a READ memory access. +==238806==Hint: address points to the zero page. +#0 0x555787d414c9 in ahci_pio_transfer build/../hw/ide/ahci.c:1349:46 +#1 0x5557886089d6 in ide_transfer_start_norecurse build/../hw/ide/core.c:553:5 +#2 0x555788638945 in ide_transfer_start build/../hw/ide/core.c:560:9 +#3 0x555788638945 in ide_sector_read_cb build/../hw/ide/core.c:761:5 +#4 0x55578860c989 in ide_buffered_readv_cb build/../hw/ide/core.c:656:9 +#5 0x5557898999d6 in blk_aio_complete build/../block/block-backend.c:1412:9 +#6 0x555789db8d26 in aio_bh_poll build/../util/async.c:164:13 +#7 0x555789d80704 in aio_dispatch build/../util/aio-posix.c:381:5 +#8 0x555789dbd94c in aio_ctx_dispatch build/../util/async.c:306:5 +#9 0x7f6dcedcfbaa in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51baa) +#10 0x555789dc3763 in glib_pollfds_poll build/../util/main-loop.c:232:9 +#11 0x555789dc3763 in os_host_main_loop_wait build/../util/main-loop.c:255:5 +#12 0x555789dc3763 in main_loop_wait build/../util/main-loop.c:531:11 +#13 0x555789206a49 in qemu_main_loop build/../softmmu/runstate.c:722:9 +#14 0x555787d052ed in main build/../softmmu/main.c:50:5 +#15 0x7f6dcd84ecc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#16 0x555787c5b619 in _start (system-i386+0x2a13619) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV build/../hw/ide/ahci.c:1349:46 in ahci_pio_transfer +==238806==ABORTING + +OSS-Fuzz link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30861 + +Confirmed. Please migrate to gitlab and assign me. + +--js + + +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/341 + + diff --git a/results/classifier/118/review/1916112 b/results/classifier/118/review/1916112 new file mode 100644 index 000000000..ef3df8e20 --- /dev/null +++ b/results/classifier/118/review/1916112 @@ -0,0 +1,219 @@ +user-level: 0.807 +boot: 0.796 +performance: 0.772 +permissions: 0.754 +TCG: 0.744 +device: 0.733 +debug: 0.729 +graphic: 0.724 +architecture: 0.714 +register: 0.711 +assembly: 0.690 +arm: 0.684 +kernel: 0.680 +peripherals: 0.672 +virtual: 0.671 +semantic: 0.666 +hypervisor: 0.653 +mistranslation: 0.641 +risc-v: 0.637 +ppc: 0.632 +PID: 0.629 +vnc: 0.628 +network: 0.623 +files: 0.620 +KVM: 0.601 +socket: 0.592 +x86: 0.551 +VMM: 0.518 +i386: 0.456 +-------------------- +arm: 0.981 +debug: 0.971 +performance: 0.553 +user-level: 0.311 +kernel: 0.296 +PID: 0.125 +virtual: 0.063 +hypervisor: 0.049 +KVM: 0.038 +boot: 0.030 +files: 0.029 +TCG: 0.016 +vnc: 0.014 +device: 0.012 +risc-v: 0.011 +semantic: 0.011 +register: 0.007 +architecture: 0.006 +socket: 0.005 +assembly: 0.004 +graphic: 0.003 +network: 0.002 +permissions: 0.002 +peripherals: 0.002 +VMM: 0.002 +mistranslation: 0.001 +x86: 0.000 +ppc: 0.000 +i386: 0.000 + +Illegal instruction crash of QEMU on Jetson Nano + +I have a jetson nano (arm64 SBC) and I want to check the native emulation performance of Raspbian Buster. I used the info available here: + +https://github.com/dhruvvyas90/qemu-rpi-kernel/tree/master/native-emuation + +I have Xubuntut 20.04 with KVM enabled kernel running on the Jetson Nano + +However QEMU crashes with "Illegal Instruction" during kernel boot. I have a built latest QEMU from sources with following configuration + +./configure --prefix=/usr/local --target-list=aarch64-softmmu,arm-softmmu --enable-guest-agent --enable-vnc --enable-vnc-jpeg --enable-vnc-png --enable-kvm --enable-spice --enable-sdl --enable-gtk --enable-virglrenderer --enable-opengl + +qemu-system-aarch64 --version +QEMU emulator version 5.2.50 (v5.2.0-1731-g5b19cb63d9) + +When I run as follows: + +../build/qemu-system-aarch64 -M raspi3 +-append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" +-dtb ./bcm2710-rpi-3-b-plus.dtb +-sd /media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.qcow2 +-kernel ./kernel8.img +-m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd + +I get : +[ 74.994834] systemd[1]: Condition check resulted in FUSE Control File System being skipped. +[ 76.281274] systemd[1]: Starting Apply Kernel Variables... +Starting Apply Kernel Variables... +Illegal instruction (core dumped) + +When I use GDB I see this: + +Thread 8 "qemu-system-aar" received signal SIGILL, Illegal instruction. +[Switching to Thread 0x7fad7f9ba0 (LWP 28037)] +0x0000007f888ac690 in code_gen_buffer () +(gdb) bt +#0 0x0000007f888ac690 in code_gen_buffer () +#1 0x0000005555d7c038 in cpu_tb_exec (tb_exit=, itb=, cpu=0x7fb4502c40) +at ../accel/tcg/cpu-exec.c:191 +#2 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x7fb4502c40) +at ../accel/tcg/cpu-exec.c:708 +#3 cpu_exec (cpu=cpu@entry=0x7fb4502c40) at ../accel/tcg/cpu-exec.c:819 +.. + +I have just two questions: + +Is this a problem with QEMU or is there anything specific build or options I need to use. Any specific version of QEMU should be used ? + +Why is TCG used as the accelerator when KVM is present. Is it possible and how to use KVM ? + +If I enabled the KVM then I get this error: + +../build/qemu-system-aarch64 -M raspi3 -enable-kvm -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" -dtb ./bcm2710-rpi-3-b-plus.dtb -sd /media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.qcow2 -kernel ./kernel8.img -m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd +WARNING: Image format was not specified for '/media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. +qemu-system-aarch64: ../softmmu/physmem.c:750: cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' failed. + +Thanks a lot. + +Can you use gdb to display what the instruction that provoked the SIGILL is ? ("disas $pc-32,$pc+32" or similar should do it). + +Re "Why is TCG used as the accelerator when KVM is present?", the answer is that only certain board types and CPU types work with KVM. The simple answer is "only the 'virt' board works with KVM". Other boards generally use a CPU type or CPU features which KVM does not support and so TCG is the only choice. It's a QEMU bug that we assert() rather than printing a helpful error message (which we will probably fix for 6.0.) + + +Disassembly: + +[ OK ] Mounted RPC Pipe File System. +[ 75.916706] systemd[1]: Started Create list of required static device nodes for the current kernel. +[ OK ] Started Create list of req… nodes for the current kernel. + +Thread 7 "qemu-system-aar" received signal SIGILL, Illegal instruction. +[Switching to Thread 0x7fade0aba0 (LWP 7777)] +0x0000007f8aca04d0 in code_gen_buffer () +(gdb) disas $pc-32,$pc+32 +Dump of assembler code from 0x7f8aca04b0 to 0x7f8aca04f0: + 0x0000007f8aca04b0 <code_gen_buffer+162653284>: cmp x0, x3 + 0x0000007f8aca04b4 <code_gen_buffer+162653288>: b.ne 0x7f8aca0908 <code_gen_buffer+162654396> // b.any + 0x0000007f8aca04b8 <code_gen_buffer+162653292>: ldr x23, [x1, x23] + 0x0000007f8aca04bc <code_gen_buffer+162653296>: str x23, [x19, #3688] + 0x0000007f8aca04c0 <code_gen_buffer+162653300>: add w22, w22, w21 + 0x0000007f8aca04c4 <code_gen_buffer+162653304>: str w22, [x19, #16] + 0x0000007f8aca04c8 <code_gen_buffer+162653308>: ldr d0, [x19, #3944] + 0x0000007f8aca04cc <code_gen_buffer+162653312>: ldr d1, [x19, #4192] +=> 0x0000007f8aca04d0 <code_gen_buffer+162653316>: .inst 0x2ee0b822 ; undefined + 0x0000007f8aca04d4 <code_gen_buffer+162653320>: movi d3, #0xff + 0x0000007f8aca04d8 <code_gen_buffer+162653324>: and v1.8b, v1.8b, v3.8b + 0x0000007f8aca04dc <code_gen_buffer+162653328>: and v2.8b, v2.8b, v3.8b + 0x0000007f8aca04e0 <code_gen_buffer+162653332>: .inst 0x2ee14404 ; undefined + 0x0000007f8aca04e4 <code_gen_buffer+162653336>: .inst 0x2ee0b845 ; und--Typ--Ty--Ty-----Ty--T--Type--Type-----Ty--T--Type <RET> for more, q to quit, c to continue without paging-- +efined + 0x0000007f8aca04e8 <code_gen_buffer+162653340>: .inst 0x2ee54400 ; undefined + 0x0000007f8aca04ec <code_gen_buffer+162653344>: ldr d5, 0x7f8aca09f0 <code_gen_buffer+162654628> +End of assembler dump. + + +I can confirm the issue (tested with Jetson Nano and Xavier running Ubuntu bionic). + +Linux starts booting, shows "Welcome to Raspbian GNU/Linux 10 (buster)!" after 33 s on Nano, but QEMU crashes after showing "Mounted Kernel Debug File System" about 77 s after start. + +Debugging is difficult because the failing address in code_gen_buffer changes for each new run, so setting a hardware watchpoint does not work. The disassembly is always the same, only the address of the code changes. + +The same test works better when I use the TCG interpreter (./configure [...] --enable-tcg-interpreter) although a warning says that TCI has less reliability and that it is strongly recommended to remove the --enable-tcg-interpreter configuration option. It reaches "Welcome" after 205 s on Xavier, "Mounted" after 420 s and finally goes into emergency mode because of "Dependency failed for /boot". Linux shows "Press Enter to continue.", but I don't get a command line after doing so. + + +TCG works and I get a Linux boot prompt in the guest Raspbian when vector instructions for TCG are disabled, so obviously the undefined instruction is simply unsupported for Jetson Nano and Xavier. + +Patch used to disable it: + +diff --git a/tcg/aarch64/tcg-target.h b/tcg/aarch64/tcg-target.h +index 5ec30dba25..2240adad1e 100644 +--- a/tcg/aarch64/tcg-target.h ++++ b/tcg/aarch64/tcg-target.h +@@ -125,8 +125,8 @@ typedef enum { + #define TCG_TARGET_HAS_mulsh_i64 1 + #define TCG_TARGET_HAS_direct_jump 1 + +-#define TCG_TARGET_HAS_v64 1 +-#define TCG_TARGET_HAS_v128 1 ++#define TCG_TARGET_HAS_v64 0 ++#define TCG_TARGET_HAS_v128 0 + #define TCG_TARGET_HAS_v256 0 + + #define TCG_TARGET_HAS_andc_vec 1 + + +This has nothing to do with the Jetson Nano, which +uses a very standard Arm cortex-a57. + +I can reproduce this on any arm64 host. + +The sigill is for the code generated for the aa32 instruction + +0xf7ca0820: f3780407 vshl.u64 d16, d7, d8 + + ---- 00000000f7ca0820 0000000000000000 0000000000000000 + ld_vec v64,e8,tmp9,env,$0xf68 pref=0xffffffff00000000 + ld_vec v64,e8,tmp10,env,$0x1060 pref=0xffffffff00000000 + neg_vec v64,e64,tmp15,tmp10 pref=0xffffffff00000000 + ... + + -- guest addr 0x00000000f7ca0820 +0xffff2a790d88: fd47b660 ldr d0, [x19, #0xf68] +0xffff2a790d8c: fd483261 ldr d1, [x19, #0x1060] +0xffff2a790d90: 2ee0b822 .byte 0x22, 0xb8, 0xe0, 0x2e + +The illegal instruction is attempting neg (vector) with v1.1d, +but that runs afoul of the isa constraint + + if size:Q == '110' then UNDEFINED; + +We should have used neg (scalar) instead. + +I can replicate the sigill with RISU. + +Now fixed in master, commit d81bad24dfea6ec0 + +Working well now. Thank you. + diff --git a/results/classifier/118/review/1916775 b/results/classifier/118/review/1916775 new file mode 100644 index 000000000..8e8b3a7fe --- /dev/null +++ b/results/classifier/118/review/1916775 @@ -0,0 +1,152 @@ +user-level: 0.934 +permissions: 0.897 +register: 0.892 +risc-v: 0.883 +network: 0.867 +arm: 0.867 +architecture: 0.866 +performance: 0.861 +KVM: 0.857 +device: 0.855 +peripherals: 0.854 +mistranslation: 0.854 +ppc: 0.850 +boot: 0.849 +virtual: 0.846 +x86: 0.844 +debug: 0.839 +vnc: 0.839 +assembly: 0.838 +semantic: 0.832 +VMM: 0.831 +TCG: 0.824 +kernel: 0.822 +graphic: 0.811 +PID: 0.805 +socket: 0.805 +files: 0.799 +hypervisor: 0.790 +i386: 0.636 +-------------------- +virtual: 0.996 +hypervisor: 0.936 +x86: 0.307 +user-level: 0.274 +debug: 0.106 +performance: 0.045 +PID: 0.014 +boot: 0.012 +register: 0.010 +files: 0.009 +semantic: 0.008 +assembly: 0.007 +kernel: 0.005 +socket: 0.005 +architecture: 0.005 +KVM: 0.005 +device: 0.005 +network: 0.003 +VMM: 0.003 +graphic: 0.003 +peripherals: 0.002 +TCG: 0.001 +permissions: 0.001 +mistranslation: 0.000 +vnc: 0.000 +ppc: 0.000 +risc-v: 0.000 +i386: 0.000 +arm: 0.000 + +Guest freezes until there is a keyboard input on Windows version + +Windows guests are freezing and waiting for keyboard input and it continues to function after I press a key. I am using Windows10 Home and below is the command I use to run the guest. I have suspected if this is caused by random entropy but even with mouse moving it gives same random locks and it continues to work as soon as I press a key so maybe its not about entropy at all, + +startwinguest.bat: +qemu-system-x86_64 ^ + -name "win" ^ + -machine type=q35,accel=whpx ^ + -cpu EPYC,hv_relaxed,hv_time,topoext ^ + -nodefaults ^ + -usb ^ + -rtc base=localtime,driftfix=slew ^ + -smp 6,sockets=1,cores=3,threads=2 ^ + -m 8192 -mem-prealloc ^ + -soundhw hda ^ + -usbdevice tablet ^ + -netdev user,id=mynet0,hostfwd=tcp::3390-:3389 -device virtio-net,netdev=mynet0 ^ + -vga std ^ + -display gtk ^ + -boot d ^ + -device virtio-scsi-pci,id=scsi0 ^ + -drive "file=%~dp0win10.qcow2,if=none,format=qcow2,discard=unmap,aio=threads,cache=writethrough,id=someid" ^ + -device scsi-hd,drive=someid,bus=scsi0.0 ^ + -drive "file=D:\Setups\OS\Windows\en_windows_server_2019_updated_dec_2020_x64_dvd_36e0f791.iso,media=cdrom,index=1" ^ + -drive "file=%~dp0virtio-win-0.1.185.iso,media=cdrom,index=2" + +I run into this behavior too. Win10 Home guest, PCI-passthrough graphics (GTX 1650), host cpu (Ryzen 7 3800XT). Occurs whether or not I use the qcow disk drive. + +qemu-system-x86_64 + -cpu host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy + -smp 8 + -rtc clock=host,base=localtime + -machine type=q35,accel=kvm,kernel_irqchip=on + -enable-kvm + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd + -m 32G + -usb + -device usb-tablet + -vga none + -serial none + -parallel none + -boot cd + -nographic + -device usb-host,vendorid=0x045e,productid=0x00db + -device usb-host,vendorid=0x1bcf,productid=0x0005 + -drive id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2 + -drive id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv + -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on + -device vfio-pci,host=09:00.1,addr=0x02.0x1 + -device vfio-pci,host=09:00.2,addr=0x02.0x2 + -device vfio-pci,host=09:00.3,addr=0x02.0x3 + -netdev tap,id=netid,ifname=taplan,script=no,downscript=no + -device e1000,netdev=netid,mac=52:54:00:01:02:03 + + +PS - My host is Debian 4.19.171-2 + +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 ticket has been moved here (thanks, Abdurrahim): +https://gitlab.com/qemu-project/qemu/-/issues/289 +... thus I'm closing this ticket on Launchpad now. + diff --git a/results/classifier/118/review/1917661 b/results/classifier/118/review/1917661 new file mode 100644 index 000000000..ccba69d96 --- /dev/null +++ b/results/classifier/118/review/1917661 @@ -0,0 +1,114 @@ +register: 0.875 +peripherals: 0.849 +permissions: 0.803 +graphic: 0.802 +debug: 0.775 +risc-v: 0.762 +mistranslation: 0.756 +device: 0.740 +performance: 0.736 +hypervisor: 0.735 +semantic: 0.735 +user-level: 0.700 +vnc: 0.690 +architecture: 0.671 +PID: 0.660 +VMM: 0.649 +files: 0.630 +x86: 0.629 +ppc: 0.619 +network: 0.593 +socket: 0.589 +kernel: 0.558 +arm: 0.537 +TCG: 0.530 +assembly: 0.514 +virtual: 0.512 +KVM: 0.492 +i386: 0.454 +boot: 0.443 +-------------------- +debug: 0.900 +virtual: 0.256 +user-level: 0.237 +register: 0.046 +arm: 0.041 +x86: 0.040 +TCG: 0.033 +files: 0.029 +semantic: 0.012 +PID: 0.009 +assembly: 0.008 +network: 0.006 +performance: 0.006 +hypervisor: 0.005 +device: 0.005 +risc-v: 0.005 +peripherals: 0.004 +ppc: 0.004 +boot: 0.004 +socket: 0.004 +permissions: 0.002 +architecture: 0.002 +kernel: 0.002 +graphic: 0.002 +i386: 0.001 +vnc: 0.001 +mistranslation: 0.001 +VMM: 0.001 +KVM: 0.000 + +qemu gdb wrong registers group for riscv64 + +Step to reproduce: +1. run qemu-system-riscv64 in gdb mode +2. attach gdb +3. set a breakpoint and run +4. print register-groups using "maintenance print register-groups" command + +... + sbadaddr 4162 4162 1628 8 long all,general + msounteren 4163 4163 1636 8 long all,general + mbadaddr 4164 4164 1644 8 long all,general + htimedeltah 4165 4165 1652 8 long all,general + +These registers don't belong to general group, instead they belong to all, system and csr groups. + +I forgot to specify the version, I built qemu sha c40ae5a3ee387b13116948cbfe7824f03311db7e + +$ qemu-system-riscv64 --version +QEMU emulator version 5.2.50 (v5.2.0-2392-gc40ae5a3ee-dirty) + + +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/review/1918 b/results/classifier/118/review/1918 new file mode 100644 index 000000000..eb5b7affd --- /dev/null +++ b/results/classifier/118/review/1918 @@ -0,0 +1,109 @@ +user-level: 0.849 +permissions: 0.833 +architecture: 0.824 +graphic: 0.816 +x86: 0.813 +performance: 0.803 +peripherals: 0.802 +semantic: 0.796 +device: 0.794 +register: 0.793 +debug: 0.792 +assembly: 0.788 +virtual: 0.784 +files: 0.776 +network: 0.774 +TCG: 0.772 +socket: 0.761 +vnc: 0.758 +KVM: 0.755 +ppc: 0.754 +hypervisor: 0.751 +risc-v: 0.748 +kernel: 0.741 +VMM: 0.734 +mistranslation: 0.732 +arm: 0.729 +PID: 0.722 +i386: 0.670 +boot: 0.625 +-------------------- +debug: 0.134 +hypervisor: 0.110 +files: 0.108 +x86: 0.086 +virtual: 0.067 +TCG: 0.062 +kernel: 0.060 +PID: 0.036 +register: 0.034 +VMM: 0.032 +device: 0.017 +user-level: 0.008 +vnc: 0.007 +socket: 0.007 +network: 0.007 +semantic: 0.006 +boot: 0.004 +ppc: 0.004 +permissions: 0.004 +architecture: 0.003 +graphic: 0.003 +performance: 0.003 +KVM: 0.002 +risc-v: 0.002 +assembly: 0.002 +peripherals: 0.001 +arm: 0.000 +mistranslation: 0.000 +i386: 0.000 + +Build failure on FreeBSD 13.2-RELEASE-p3 amd64 with --vhost-user +Description of problem: +- Assumption that the python interpreter is in PATH as `python3` +- Attempt to include Linux headers on a FreeBSD system +Steps to reproduce: +1. `$ ./configure --prefix=/opt/qemu --enable-vhost-user` (log attached below) +2. `$ ninja -C build` +3. See it running a python script without an explicit python interpreter +4. Work around by invoking the python script through the interpreter that meson found: + +```diff +diff --git a/ui/meson.build b/ui/meson.build +index 0a1e8272a3..c6456f54c4 100644 +--- a/ui/meson.build ++++ b/ui/meson.build +@@ -81,7 +81,7 @@ if dbus_display + input: 'dbus-display1.xml', + output: 'dbus-display1.xml', + env: env, +- command: [xml_pp, '@INPUT@', '@OUTPUT@']) ++ command: [python, xml_pp, '@INPUT@', '@OUTPUT@']) + dbus_display1 = custom_target('dbus-display gdbus-codegen', + output: ['dbus-display1.h', 'dbus-display1.c'], + input: xml, + +``` + +5. Then fails trying to include a Linux header: + +```console +/usr/bin/cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../bsd-user/include -Isubprojects/dtc/libfdt -I../subprojects/dtc/libfdt -Iui -I../ui -I/usr/local/include/capstone -I/usr/local/include/pixman-1 -I/usr/local/include/l +ibpng16 -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/local/include/SDL2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/slirp -I/usr/local/include/gtk-3.0 +-I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/libepoll-shim -I/usr/local/include/ +atk-1.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/vte-2.91 -I/usr/local/include/webp -fcolor-diagnostics -Wall -Winvalid-pch -st +d=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wn +ested-externs -Wendif-labels -Wexpansion-to-defined -Wmissing-format-attribute -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compar +e -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -Wthread-safety -iquote . -iquote /usr/home/nico/build/qemu -iquote /usr/home/nico/build/qemu/include -iquote /usr/home/nico/build/qemu/host/include/x86_64 -iquote /usr/home/nico/build/qe +mu/host/include/generic -iquote /usr/home/nico/build/qemu/tcg/i386 -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fPIE -DAVIF_DLL -DHWY_SHARED_DEFINE -D_REENTRANT -D_THREAD_SAFE - +MD -MQ libcommon.fa.p/hw_net_vhost_net.c.o -MF libcommon.fa.p/hw_net_vhost_net.c.o.d -o libcommon.fa.p/hw_net_vhost_net.c.o -c ../hw/net/vhost_net.c +In file included from ../hw/net/vhost_net.c:37: +/usr/home/nico/build/qemu/linux-headers/linux/vhost.h:14:10: fatal error: 'linux/vhost_types.h' file not found +#include <linux/vhost_types.h> + ^~~~~~~~~~~~~~~~~~~~~ +``` + +I don't know what that is about. Full build log is attached below. +Additional information: +[config_log](/uploads/49d1c33d4b3951f79f826a701ceff1c2/config_log) +[build_log_fail](/uploads/2cb3b49e7503a430457c4d99b1c60dbe/build_log_fail) diff --git a/results/classifier/118/review/1918026 b/results/classifier/118/review/1918026 new file mode 100644 index 000000000..35d966c81 --- /dev/null +++ b/results/classifier/118/review/1918026 @@ -0,0 +1,100 @@ +mistranslation: 0.963 +architecture: 0.962 +performance: 0.915 +semantic: 0.886 +graphic: 0.817 +user-level: 0.807 +device: 0.770 +risc-v: 0.757 +debug: 0.745 +hypervisor: 0.670 +PID: 0.661 +permissions: 0.647 +network: 0.646 +peripherals: 0.614 +register: 0.591 +TCG: 0.589 +virtual: 0.589 +ppc: 0.579 +VMM: 0.570 +vnc: 0.567 +files: 0.558 +socket: 0.540 +KVM: 0.539 +kernel: 0.530 +arm: 0.530 +x86: 0.486 +boot: 0.473 +assembly: 0.440 +i386: 0.414 +-------------------- +hypervisor: 0.190 +assembly: 0.133 +architecture: 0.049 +TCG: 0.043 +virtual: 0.042 +register: 0.037 +performance: 0.030 +debug: 0.027 +kernel: 0.026 +files: 0.017 +risc-v: 0.015 +user-level: 0.013 +PID: 0.008 +semantic: 0.008 +device: 0.008 +vnc: 0.006 +boot: 0.006 +socket: 0.005 +VMM: 0.005 +network: 0.005 +peripherals: 0.005 +mistranslation: 0.005 +permissions: 0.004 +graphic: 0.003 +KVM: 0.001 +x86: 0.001 +arm: 0.001 +i386: 0.001 +ppc: 0.001 + +RISCV64 32-bit AMOs incorrectly simulated + +Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14) + +test: + amomaxu.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); // FAIL, saw -11 +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); // FAIL, raw -11 +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); + +test: + amomax.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); // FAIL, saw -7 + +I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl. + +Not as simple as _tl vs _i32. That suffix should be taking +care of the sign-extension to _tl that happens after the +operation. The size of the operation should be in the MO_TESL, +which specifies target-endian signed "long" (32-bit). + +Will investigate further. + +Flushing out the report to something that compiles, +the test case works for me using qemu 5.2. + diff --git a/results/classifier/118/review/1918149 b/results/classifier/118/review/1918149 new file mode 100644 index 000000000..6db5c572f --- /dev/null +++ b/results/classifier/118/review/1918149 @@ -0,0 +1,103 @@ +mistranslation: 0.940 +architecture: 0.880 +TCG: 0.851 +user-level: 0.773 +network: 0.738 +device: 0.734 +performance: 0.715 +debug: 0.687 +files: 0.685 +hypervisor: 0.683 +register: 0.645 +semantic: 0.637 +permissions: 0.635 +graphic: 0.622 +peripherals: 0.619 +kernel: 0.611 +risc-v: 0.601 +ppc: 0.601 +PID: 0.566 +vnc: 0.565 +socket: 0.546 +x86: 0.538 +boot: 0.479 +assembly: 0.476 +VMM: 0.465 +virtual: 0.453 +arm: 0.437 +KVM: 0.401 +i386: 0.400 +-------------------- +TCG: 0.207 +debug: 0.114 +user-level: 0.062 +hypervisor: 0.029 +kernel: 0.029 +files: 0.025 +PID: 0.016 +semantic: 0.013 +virtual: 0.007 +network: 0.006 +performance: 0.006 +register: 0.004 +architecture: 0.003 +assembly: 0.003 +device: 0.002 +boot: 0.002 +vnc: 0.002 +socket: 0.002 +permissions: 0.002 +risc-v: 0.002 +mistranslation: 0.001 +graphic: 0.001 +ppc: 0.001 +peripherals: 0.001 +VMM: 0.001 +arm: 0.000 +x86: 0.000 +KVM: 0.000 +i386: 0.000 + +qemu-user reports wrong fault_addr in signal handler + +When a SEGV signal occurs and si_addr of the info struct is nil, qemu still tries to translate the address from host to guest (handle_cpu_signal in accel/tcg/user-exec.c). This means, that the actual signal handler, will receive a fault_addr that is something like 0xffffffffbf709000. + +I was able to get this to happen, by branching to a non canonical address on aarch64. +I used 5.2 (commit: 553032db17). However, building from source, this only seems to happen, if I use the same configure flags as the debian build: + +../configure --static --target-list=aarch64-linux-user --disable-system --enable-trace-backends=simple --disable-linux-io-uring --disable-pie --extra-cflags="-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --extra-ldflags="-Wl,-z,relro -Wl,--as-needed" + +Let me know, if you need more details. + +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/review/1918975 b/results/classifier/118/review/1918975 new file mode 100644 index 000000000..9e4a22eb4 --- /dev/null +++ b/results/classifier/118/review/1918975 @@ -0,0 +1,110 @@ +user-level: 0.905 +mistranslation: 0.839 +semantic: 0.802 +graphic: 0.767 +permissions: 0.727 +performance: 0.726 +register: 0.725 +architecture: 0.717 +risc-v: 0.689 +socket: 0.673 +hypervisor: 0.666 +files: 0.664 +network: 0.662 +PID: 0.647 +kernel: 0.615 +device: 0.607 +peripherals: 0.564 +x86: 0.544 +vnc: 0.530 +ppc: 0.528 +debug: 0.512 +TCG: 0.511 +VMM: 0.497 +arm: 0.484 +KVM: 0.481 +boot: 0.478 +i386: 0.470 +assembly: 0.429 +virtual: 0.322 +-------------------- +user-level: 0.347 +TCG: 0.203 +virtual: 0.150 +x86: 0.145 +semantic: 0.078 +arm: 0.051 +hypervisor: 0.046 +files: 0.017 +ppc: 0.011 +debug: 0.011 +i386: 0.010 +register: 0.006 +PID: 0.006 +risc-v: 0.006 +architecture: 0.004 +boot: 0.004 +assembly: 0.003 +network: 0.003 +device: 0.003 +kernel: 0.002 +performance: 0.002 +permissions: 0.001 +vnc: 0.001 +VMM: 0.001 +graphic: 0.001 +socket: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +[Feature request] Propagate interpreter to spawned processes + +I want QEMU user static to propagate interpreter to spawned processes, for instances by adding -R recursive. + +I.e. if my program is interpreted by QEMU static than everything what it launches should be interpreted by it, too. + +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. + + +Also, is this a duplicate of https://bugs.launchpad.net/qemu/+bug/1912107 or do you mean something different here? + +Hi, + +This is the same bug, child processes from quemu are not quemu. I think I know how this can be fixed, but right now I have no time to even try it. + +However use case is a bit different, I don't use binfmtmisc - so I will leave it to your decision, if it's same or not. + +I.e. Imagine I run sh with qemu - I want any process launched from sh to be as well qemu interpreted. + +I think one ticket should be enough to track this problem, so let's continue the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/306 + diff --git a/results/classifier/118/review/1920752 b/results/classifier/118/review/1920752 new file mode 100644 index 000000000..d407c9497 --- /dev/null +++ b/results/classifier/118/review/1920752 @@ -0,0 +1,169 @@ +mistranslation: 0.863 +user-level: 0.863 +virtual: 0.836 +peripherals: 0.813 +permissions: 0.806 +register: 0.803 +device: 0.795 +risc-v: 0.790 +semantic: 0.769 +arm: 0.763 +vnc: 0.763 +assembly: 0.755 +debug: 0.755 +hypervisor: 0.751 +architecture: 0.749 +graphic: 0.748 +KVM: 0.743 +PID: 0.735 +network: 0.733 +performance: 0.727 +TCG: 0.716 +boot: 0.715 +kernel: 0.703 +ppc: 0.695 +socket: 0.681 +files: 0.654 +VMM: 0.628 +x86: 0.587 +i386: 0.497 +-------------------- +virtual: 0.995 +arm: 0.993 +KVM: 0.886 +hypervisor: 0.842 +peripherals: 0.622 +device: 0.085 +kernel: 0.082 +user-level: 0.060 +debug: 0.042 +VMM: 0.034 +register: 0.031 +files: 0.023 +architecture: 0.018 +PID: 0.008 +semantic: 0.008 +socket: 0.008 +TCG: 0.004 +graphic: 0.003 +boot: 0.003 +permissions: 0.003 +network: 0.003 +assembly: 0.002 +performance: 0.002 +risc-v: 0.002 +vnc: 0.001 +x86: 0.001 +mistranslation: 0.001 +ppc: 0.000 +i386: 0.000 + +USB SoundCard Passthrough not working on arm64 + +Hello, + +I am virtualizing a armhf guest on a aarch64 host and was to use my Sound Blaster USB Soundcard as passthrough. + +armhf Guest is: Debian Buster +aarch64 host is a jetson nano. KVM is enabled. + +Latest qemu is built from sources. +The command I use for running is as follows: + +../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm \ +-kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' \ +-device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,hostbus=1,hostport=2.3 -serial stdio \ +-device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \ +-drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd \ +-netdev user,id=mynet -device virtio-net-device,netdev=mynet \ +-bios edk2-arm-code.fd -no-reboot + + +Where are my lsusb -t shows: + +rreddy78@jetson-nano:~/Downloads$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M + |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M + |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M + |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M + |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + +Within the VM I can see the usb as follows + +rreddy78@debian:~$ lsusb -t +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M + |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M + + +Its looks like some passthrough as but it seems like only for + + _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M + +I am not sure if passthrough even works because this post I saw + +https://community.arm.com/developer/ip-products/system/f/embedded-forum/48031/usb-pass-through-in-qemu-command-line-for-arm-machines/168764#168764 + +Hi, do you see errors on stderr when running with "-d guest_errors"? +If so can you attach the log produced by using "-D guest_errors.log -d guest_errors"? + + +Not much. + +Here is the log + +gic_cpu_read: Bad offset fc +gic_cpu_read: Bad offset fc +virtio_mmio_write: attempt to write guest features with guest_features_sel > 0 in legacy mode +virtio_mmio_write: attempt to write guest features with guest_features_sel > 0 in legacy mode + + +This time I used it differently i.e: + +rreddy78@jetson-nano:~/debian-buster-qemu$ lsusb -s 1:8 +Bus 001 Device 008: ID 041e:324d Creative Technology, Ltd + +And + +-device usb-host,vendorid=0x041e,productid=0x324d -D guest_errors.log -d guest_errors + + + +Can you record usb traffic (add pcap=<file> to usb-host)? + +I ran it as follows: + + qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-host,pcap=test.pcap,hostbus=1,hostport=2.1 -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd -netdev user,id=mynet -device virtio-net-device,netdev=mynet -bios edk2-arm-code.fd -no-reboot + +But the pcap file is empty: + +file test.pcap +test.pcap: empty + + + + +Hello, + +You can close this bug as as a simple usb-audio switch is working fine for me: +I just added -device usb-audio and set the -device nec-usb-xhci and sound within the qemu is working fine.. + +qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host,aarch64=off -enable-kvm -kernel vmlinuz-4.19.0-14-armmp-lpae -initrd initrd.img-4.19.0-14-armmp-lpae -append 'root=/dev/vda2' -device nec-usb-xhci,id=xhci -device usb-kbd -device usb-mouse -device usb-audio -serial stdio -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on -drive if=none,file=hda2.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd -netdev user,id=mynet -device virtio-net-device,netdev=mynet -bios edk2-arm-code.fd -no-reboot + + +One more point. The solution above is not usb passthrough. +I just noticed that qemu needs to be configured for usb passthrough. I am trying that out now + +Configure with --enable-libusb + libusb libusb (for usb passthrough) + + +Closing as requested in comment #6 + diff --git a/results/classifier/118/review/1922391 b/results/classifier/118/review/1922391 new file mode 100644 index 000000000..c022fa167 --- /dev/null +++ b/results/classifier/118/review/1922391 @@ -0,0 +1,187 @@ +semantic: 0.911 +graphic: 0.878 +permissions: 0.870 +PID: 0.869 +register: 0.859 +assembly: 0.857 +arm: 0.851 +architecture: 0.843 +device: 0.838 +debug: 0.829 +VMM: 0.827 +peripherals: 0.819 +performance: 0.814 +risc-v: 0.810 +user-level: 0.809 +boot: 0.796 +vnc: 0.794 +TCG: 0.788 +network: 0.784 +kernel: 0.769 +socket: 0.761 +ppc: 0.760 +virtual: 0.760 +hypervisor: 0.754 +mistranslation: 0.731 +files: 0.660 +KVM: 0.603 +x86: 0.536 +i386: 0.479 +-------------------- +ppc: 0.991 +debug: 0.954 +user-level: 0.526 +hypervisor: 0.168 +virtual: 0.113 +TCG: 0.077 +files: 0.046 +PID: 0.046 +performance: 0.041 +kernel: 0.029 +boot: 0.029 +semantic: 0.027 +register: 0.011 +assembly: 0.006 +device: 0.005 +VMM: 0.004 +socket: 0.003 +architecture: 0.003 +x86: 0.003 +graphic: 0.002 +i386: 0.002 +network: 0.002 +KVM: 0.001 +permissions: 0.001 +risc-v: 0.001 +peripherals: 0.001 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 + +qemu-system-ppc assertion "!mr->container" failed + +Hi, + +I'm trying to run the NetBSD/macppc 8.2 installer (which is 32-bit ppc) in qemu-system-ppc +version 5.2.0, and I'm hitting this assertion failure quite a bit into the "unpacking sets" +part of the installation procedure, unpacking from the install iso image. + +Qemu is run on a NetBSD/amd64 9.1 host system. The stack backtrace from the core file is + +Program terminated with signal SIGABRT, Aborted. +#0 0x000078859a36791a in _lwp_kill () from /usr/lib/libc.so.12 +[Current thread is 1 (process 1)] +(gdb) where +#0 0x000078859a36791a in _lwp_kill () from /usr/lib/libc.so.12 +#1 0x000078859a3671ca in abort () from /usr/lib/libc.so.12 +#2 0x000078859a2a8507 in __assert13 () from /usr/lib/libc.so.12 +#3 0x000000015a3c19c0 in memory_region_finalize () +#4 0x000000015a3fef1c in object_unref () +#5 0x000000015a3feee6 in object_unref () +#6 0x000000015a374154 in address_space_unmap () +#7 0x000000015a276551 in pmac_ide_atapi_transfer_cb () +#8 0x000000015a150a59 in dma_blk_cb () +#9 0x000000015a46a1c7 in blk_aio_complete () +#10 0x000000015a5a617d in coroutine_trampoline () +#11 0x000078859a264150 in ?? () from /usr/lib/libc.so.12 +Backtrace stopped: Cannot access memory at address 0x7884894ff000 +(gdb) + +I start qemu with this small script: + +--- +#!/bin/sh + +MEM=3g +qemu-system-ppc \ + -M mac99,via=pmu \ + -m $MEM \ + -nographic \ + -drive id=hda,format=raw,file=disk.img \ + -L pc-bios \ + -netdev user,id=net0,hostfwd=tcp::2223-:22,ipv6=off \ + -net nic,model=rtl8139,netdev=net0 \ + -boot d \ + -cdrom NetBSD-8.2-macppc.iso +--- + +and boot the install kernel with "boot cd:ofwboot.xcf". If someone wants +to replicate this I can provide more detailed instructions to repeat the +procedure I used to start the install. + +Any hints about what more to look for? + +Regards, + +- Håvard + +Hmm, + +it seems I need to retract this bug. It turns out that the 32-bit macppc port +of NetBSD only supports a maximum of 2GB of memory. As a NetBSD developer said it: + +> The physical memory map on G4 Macs doesn't have room for more than 2G of RAM. + +So, I've set the status of this bug report to "Invalid", as that seemed to be the +best fit. + +Regards, + +- Håvard + + +If the machine can not support more than 2GB, QEMU should report an error when the user tries to assign too many memory, not crash and let it figure out. +Setting the bug status to confirmed. + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00570.html + +On 4/7/21 3:11 PM, Mark Cave-Ayland wrote: +> On 06/04/2021 09:48, Philippe Mathieu-Daudé wrote: +> +>> On Mac99 and newer machines, the Uninorth PCI host bridge maps +>> the PCI hole region at 2GiB, so the RAM area beside 2GiB is not +>> accessible by the CPU. Restrict the memory to 2GiB to avoid +>> problems such the one reported in the buglink. +>> +>> Buglink: https://bugs.launchpad.net/qemu/+bug/1922391 +>> Reported-by: Håvard Eidnes <email address hidden> +>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +>> --- +>> hw/ppc/mac_newworld.c | 4 ++++ +>> 1 file changed, 4 insertions(+) +>> +>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c +>> index 21759628466..d88b38e9258 100644 +>> --- a/hw/ppc/mac_newworld.c +>> +++ b/hw/ppc/mac_newworld.c +>> @@ -157,6 +157,10 @@ static void ppc_core99_init(MachineState *machine) +>> } +>> /* allocate RAM */ +>> + if (machine->ram_size > 2 * GiB) { +>> + error_report("RAM size more than 2 GiB is not supported"); +>> + exit(1); +>> + } +>> memory_region_add_subregion(get_system_memory(), 0, machine->ram); +>> /* allocate and load firmware ROM */ +> +> I think the patch is correct, however I'm fairly sure that the default +> g3beige machine also has the PCI hole located at 0x80000000 so the same +> problem exists there too. +> +> Also are you keen to get this merged for 6.0? It doesn't seem to solve a +> security issue/release blocker and I'm sure the current behaviour has +> been like this for a long time... + +No problem. I wanted to revisit this bug anyway, I realized during the +night, while this patch makes QEMU exit cleanly, it hides the bug which +is likely in TYPE_MACIO_IDE (I haven't tried Håvard's full reproducer). + +Regards, + +Phil. + + +Philippe's fix has been merged here: +https://gitlab.com/qemu-project/qemu/-/commit/03b3542ac93cb196bf6a6 + diff --git a/results/classifier/118/review/1923197 b/results/classifier/118/review/1923197 new file mode 100644 index 000000000..26872da9d --- /dev/null +++ b/results/classifier/118/review/1923197 @@ -0,0 +1,196 @@ +semantic: 0.907 +debug: 0.904 +register: 0.895 +permissions: 0.884 +mistranslation: 0.879 +arm: 0.864 +user-level: 0.862 +assembly: 0.855 +PID: 0.853 +hypervisor: 0.849 +socket: 0.832 +peripherals: 0.824 +VMM: 0.815 +device: 0.813 +performance: 0.808 +graphic: 0.805 +ppc: 0.804 +files: 0.803 +risc-v: 0.800 +architecture: 0.795 +KVM: 0.794 +virtual: 0.792 +vnc: 0.737 +TCG: 0.735 +boot: 0.724 +network: 0.710 +kernel: 0.708 +x86: 0.596 +i386: 0.482 +-------------------- +risc-v: 0.843 +assembly: 0.830 +debug: 0.128 +architecture: 0.034 +TCG: 0.032 +ppc: 0.026 +hypervisor: 0.025 +semantic: 0.020 +register: 0.017 +VMM: 0.016 +KVM: 0.010 +device: 0.010 +PID: 0.009 +virtual: 0.009 +files: 0.009 +socket: 0.005 +vnc: 0.005 +kernel: 0.004 +performance: 0.004 +user-level: 0.004 +peripherals: 0.003 +permissions: 0.003 +network: 0.002 +boot: 0.002 +mistranslation: 0.001 +graphic: 0.001 +arm: 0.000 +i386: 0.000 +x86: 0.000 + +RISC-V priviledged instruction error + +Hello when performing an MRET with MPP set to something else than 0b11 in MSTATUS, 'Invalid Instruction' exception will be triggered. The problem appeared in code after version 5.2.0. + +<pre> + # setup interrupt handling for monitor mode + la t0, entry_loop + la t1, entry_trap + li t2, 0x888 + li t3, 0x1880 # MPP in MSTATUS selects to which mode to return & MPIE selects if to enable interrupts after MRET + csrw mepc, t0 + csrw mtvec, t1 + csrs mie, t2 + csrs mstatus, t3 + + # if supervisor mode not supported, then loop forever + csrr t0, misa + li t1, 0x40000 + and t2, t1, t0 + beqz t2, 1f + + # setup interrupt i& exception delegation for supervisor mode + li t0, 0xc0000000 # 3 GiB (entry address of supervisor) + li t1, 0x1000 + #li t2, 0x300 # bit 8 & 9 is for ecall from user & supervisor mode + #li t3, 0x222 + csrw mepc, t0 + csrc mstatus, t1 + #csrs medeleg, t2 + #csrs mideleg, t3 + + # pass mhartid as first parameter to supervisor + csrr a0, mhartid + +1: + mret +</pre> + +I'm guessing that this is a bug in your guest as it hasn't configured PMP regions. + +From the RISC-V spec: + +" +If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an +S-mode or U-mode access, but at least one PMP entry is implemented, the access fails. +" + +Confusingly implemented here means implemented in hardware, not just configured. + +You can check this by reverting this QEMU commit: + +commit d102f19a2085ac931cb998e6153b73248cca49f1 +Author: Atish Patra <email address hidden> +Date: Wed Dec 23 11:25:53 2020 -0800 + + target/riscv/pmp: Raise exception if no PMP entry is configured + + As per the privilege specification, any access from S/U mode should fail + if no pmp region is configured. + + Signed-off-by: Atish Patra <email address hidden> + Reviewed-by: Alistair Francis <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Alistair Francis <email address hidden> + + +Hello Francis, + +I'll configure PMP than do the test again. Sorry I hadn't understood what +changed between version 5.2 and 6.0-rc2, since my code worked before. + +Best regards, +Teodori Serge + +On Thu, 15 Apr 2021, 06:15 Alistair Francis, <email address hidden> +wrote: + +> I'm guessing that this is a bug in your guest as it hasn't configured +> PMP regions. +> +> >From the RISC-V spec: +> +> " +> If no PMP entry matches an M-mode access, the access succeeds. If no PMP +> entry matches an +> S-mode or U-mode access, but at least one PMP entry is implemented, the +> access fails. +> " +> +> Confusingly implemented here means implemented in hardware, not just +> configured. +> +> ** Changed in: qemu +> Status: Confirmed => Invalid +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1923197 +> +> Title: +> RISC-V priviledged instruction error +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions +> + + +We fixed a bug to make QEMU act more like hardware, which now means that PMP must be configured in M-mode. + +Hello Francis, + +Yes thank you. I added code to setup a basic PMP and it works now. Thank +you and best regards, + +Teodori Serge + +On Sun, 18 Apr 2021, 05:55 Alistair Francis, <email address hidden> +wrote: + +> We fixed a bug to make QEMU act more like hardware, which now means that +> PMP must be configured in M-mode. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1923197 +> +> Title: +> RISC-V priviledged instruction error +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions +> + + diff --git a/results/classifier/118/review/1923648 b/results/classifier/118/review/1923648 new file mode 100644 index 000000000..85c0e282e --- /dev/null +++ b/results/classifier/118/review/1923648 @@ -0,0 +1,119 @@ +x86: 0.918 +performance: 0.910 +vnc: 0.884 +files: 0.876 +device: 0.870 +VMM: 0.864 +architecture: 0.858 +permissions: 0.852 +network: 0.849 +ppc: 0.831 +graphic: 0.808 +risc-v: 0.802 +user-level: 0.798 +socket: 0.794 +peripherals: 0.758 +kernel: 0.750 +register: 0.749 +debug: 0.744 +assembly: 0.744 +hypervisor: 0.734 +arm: 0.729 +mistranslation: 0.712 +KVM: 0.679 +PID: 0.659 +virtual: 0.655 +semantic: 0.650 +TCG: 0.640 +i386: 0.637 +boot: 0.628 +-------------------- +virtual: 0.908 +performance: 0.886 +hypervisor: 0.365 +debug: 0.330 +x86: 0.213 +TCG: 0.060 +PID: 0.048 +boot: 0.037 +files: 0.031 +socket: 0.031 +risc-v: 0.027 +device: 0.023 +semantic: 0.020 +register: 0.020 +vnc: 0.016 +network: 0.014 +VMM: 0.012 +user-level: 0.010 +kernel: 0.009 +assembly: 0.006 +permissions: 0.006 +architecture: 0.004 +peripherals: 0.003 +ppc: 0.003 +graphic: 0.001 +KVM: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +macOS App Nap feature gradually freezes QEMU process + +macOS version: 10.15.2 +QEMU versions: 5.2.0 (from MacPorts) + 5.2.92 (v6.0.0-rc2-23-g9692c7b037) + +If the QEMU window is not visible (hidden, minimized or another application is in full screen mode), the QEMU process gradually freezes: it still runs, but the VM does not respond to external requests such as Telnet or SSH until the QEMU window is visible on the desktop. + +This behavior is due to the work of the macOS App Nap function: +https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/AppNap.html#//apple_ref/doc/uid/TP40013929-CH2-SW1 + +It doesn't matter how the process is started -- as a background job or as a foreground shell process in case QEMU has a desktop window. + +My VM does not have a display output, only a serial line, most likely if the VM was using OpenGL, or playing sound (or any other App Nap triggers), then the problem would never have been detected. + +In my case only one starting way without this problem: +sudo qemu-system-x86_64 -nodefaults \ +-cpu host -accel hvf -smp 1 -m 384 \ +-device virtio-blk-pci,drive=flash0 \ +-drive file=/vios-adventerprisek9-m.vmdk.SPA.156-1.T.vmdk,if=none,format=vmdk,id=flash0 \ +-device e1000,netdev=local -netdev tap,id=local,ifname=tap0,script=no,downscript=no \ +-serial stdio -display none + +The typical way from the internet to disable App Nap doesn't work: +defaults write NSGlobalDomain NSAppSleepDisabled -bool YES + +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. + + +Moved here: +https://gitlab.com/qemu-project/qemu/-/issues/334 + diff --git a/results/classifier/118/review/1924231 b/results/classifier/118/review/1924231 new file mode 100644 index 000000000..d0d73d6f2 --- /dev/null +++ b/results/classifier/118/review/1924231 @@ -0,0 +1,176 @@ +user-level: 0.845 +KVM: 0.714 +risc-v: 0.667 +ppc: 0.656 +virtual: 0.623 +hypervisor: 0.621 +graphic: 0.597 +peripherals: 0.584 +performance: 0.575 +vnc: 0.562 +TCG: 0.559 +x86: 0.558 +permissions: 0.542 +register: 0.536 +VMM: 0.517 +PID: 0.507 +debug: 0.503 +mistranslation: 0.499 +semantic: 0.489 +device: 0.477 +architecture: 0.462 +files: 0.408 +kernel: 0.406 +assembly: 0.393 +arm: 0.358 +network: 0.331 +boot: 0.322 +i386: 0.314 +socket: 0.245 +-------------------- +arm: 0.769 +debug: 0.279 +virtual: 0.086 +files: 0.064 +TCG: 0.031 +PID: 0.025 +network: 0.022 +hypervisor: 0.018 +register: 0.017 +semantic: 0.007 +socket: 0.006 +performance: 0.005 +device: 0.005 +permissions: 0.003 +architecture: 0.003 +VMM: 0.003 +boot: 0.003 +kernel: 0.002 +graphic: 0.002 +risc-v: 0.002 +user-level: 0.002 +peripherals: 0.002 +vnc: 0.001 +ppc: 0.001 +assembly: 0.001 +KVM: 0.001 +mistranslation: 0.001 +x86: 0.001 +i386: 0.000 + +Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on. + +the QEMU release version where the bug was found. + +apt list --installed | grep qemu +qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.14 amd64 [installed] + + +The installing "libc-bin" which "wget" depends on crashes as below when we execute docker image of Debian GNU/Linux bullseye for ARM64 on Ubuntu 20.04 for AMD64. +This problem also occurs on CI(GitHub Actions)(https://github.com/groonga/groonga/runs/2338497272?check_suite_focus=true#step:11:127). +Probably, The cause of this crash is https://bugs.launchpad.net/qemu/+bug/1749393. +This bug has already been fixed in qemu-user-static pacakge for Ubuntu 20.10. + +However, this fix is not included in qemu-user-static pacakge for Ubuntu 20.04. +Currently, GitHub Actions does not support Ubuntu 20.10. +Therefore, this problem is still happening in CI. + +Would it be possible for you to backport this fix into Ubuntu 20.04? + + +How to reproduce: + +sudo apt install -y qemu-user-static docker.io +sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt install -y wget' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB] +Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] +Get:3 http://deb.debian.org/debian bullseye-updates InRelease [40.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 Packages [8084 kB] +Get:5 http://security.debian.org/debian-security bullseye-security/main arm64 Packages [808 B] +Fetched 8311 kB in 4s (2001 kB/s) +Reading package lists... +Building dependency tree... +Reading state information... +2 packages can be upgraded. Run 'apt list --upgradable' to see them. + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Reading package lists... +Building dependency tree... +Reading state information... +The following additional packages will be installed: + ca-certificates libpsl5 openssl publicsuffix +The following NEW packages will be installed: + ca-certificates libpsl5 openssl publicsuffix wget +0 upgraded, 5 newly installed, 0 to remove and 2 not upgraded. +Need to get 2111 kB of archives. +After this operation, 5844 kB of additional disk space will be used. +Get:1 http://deb.debian.org/debian bullseye/main arm64 openssl arm64 1.1.1k-1 [829 kB] +Get:2 http://deb.debian.org/debian bullseye/main arm64 ca-certificates all 20210119 [158 kB] +Get:3 http://deb.debian.org/debian bullseye/main arm64 libpsl5 arm64 0.21.0-1.2 [57.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 wget arm64 1.21-1 [946 kB] +Get:5 http://deb.debian.org/debian bullseye/main arm64 publicsuffix all 20210108.1309-1 [121 kB] +debconf: delaying package configuration, since apt-utils is not installed +Fetched 2111 kB in 0s (12.9 MB/s) +Selecting previously unselected package openssl. +(Reading database ... 6640 files and directories currently installed.) +Preparing to unpack .../openssl_1.1.1k-1_arm64.deb ... +Unpacking openssl (1.1.1k-1) ... +Selecting previously unselected package ca-certificates. +Preparing to unpack .../ca-certificates_20210119_all.deb ... +Unpacking ca-certificates (20210119) ... +Selecting previously unselected package libpsl5:arm64. +Preparing to unpack .../libpsl5_0.21.0-1.2_arm64.deb ... +Unpacking libpsl5:arm64 (0.21.0-1.2) ... +Selecting previously unselected package wget. +Preparing to unpack .../archives/wget_1.21-1_arm64.deb ... +Unpacking wget (1.21-1) ... +Selecting previously unselected package publicsuffix. +Preparing to unpack .../publicsuffix_20210108.1309-1_all.deb ... +Unpacking publicsuffix (20210108.1309-1) ... +Setting up libpsl5:arm64 (0.21.0-1.2) ... +Setting up wget (1.21-1) ... +Setting up openssl (1.1.1k-1) ... +Setting up publicsuffix (20210108.1309-1) ... +Setting up ca-certificates (20210119) ... +debconf: unable to initialize frontend: Dialog +debconf: (TERM is not set, so the dialog frontend is not usable.) +debconf: falling back to frontend: Readline +debconf: unable to initialize frontend: Readline +debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) +debconf: falling back to frontend: Teletype +Updating certificates in /etc/ssl/certs... +129 added, 0 removed; done. +Processing triggers for libc-bin (2.31-11) ... +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +dpkg: error processing package libc-bin (--configure): + installed libc-bin package post-installation script subprocess returned error exit status 139 +Processing triggers for ca-certificates (20210119) ... +Updating certificates in /etc/ssl/certs... +0 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d... +done. +Errors were encountered while processing: + libc-bin +E: Sub-process /usr/bin/dpkg returned an error code (1) + +This is the bug tracker for upstream QEMU. If you'd like to request Ubuntu to backport some fix into their packages of QEMU, you'll need to file it against the Ubuntu QEMU package bug tracker. Since those bugs are also tracked in Launchpad, I'll try re-componenting this bug report to the Ubuntu QEMU package... + + +I'm sorry that I send a wrong destination of report. +Thank you for re-componenting this bug report. + +Thank you for taking the time to report this bug and helping to make Ubuntu better. + +In Launchpad we use one bug per issue. Since this issue is already reported in bug 1749393, I'm marking this bug as a duplicate of that one. + +You're requesting to backport the fix to 20.04. We can track this in the other bug with a bug task, which I'll open now. + +Status changed to 'Confirmed' because the bug affects multiple users. + diff --git a/results/classifier/118/review/1924603 b/results/classifier/118/review/1924603 new file mode 100644 index 000000000..3a46269f3 --- /dev/null +++ b/results/classifier/118/review/1924603 @@ -0,0 +1,159 @@ +user-level: 0.914 +semantic: 0.906 +permissions: 0.905 +KVM: 0.898 +graphic: 0.898 +debug: 0.885 +virtual: 0.878 +register: 0.875 +assembly: 0.867 +risc-v: 0.862 +kernel: 0.861 +VMM: 0.860 +device: 0.854 +architecture: 0.850 +arm: 0.849 +performance: 0.845 +mistranslation: 0.844 +files: 0.838 +PID: 0.836 +peripherals: 0.835 +ppc: 0.833 +socket: 0.818 +hypervisor: 0.814 +x86: 0.813 +network: 0.810 +boot: 0.787 +TCG: 0.782 +vnc: 0.782 +i386: 0.533 +-------------------- +x86: 0.989 +network: 0.957 +virtual: 0.856 +hypervisor: 0.739 +debug: 0.610 +kernel: 0.580 +files: 0.045 +assembly: 0.030 +i386: 0.027 +KVM: 0.025 +TCG: 0.019 +device: 0.018 +PID: 0.016 +register: 0.013 +VMM: 0.010 +semantic: 0.010 +architecture: 0.007 +socket: 0.004 +user-level: 0.004 +boot: 0.003 +performance: 0.003 +ppc: 0.002 +permissions: 0.001 +graphic: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +vnc: 0.001 +peripherals: 0.001 +arm: 0.000 + +Incorrect feature negotiation for vhost-vdpa netdevice + +QEMU cmdline: +============= +./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -m 2G -hda /gautam/centos75_1.qcow2 -name gautam,process=gautam -enable-kvm -netdev vhost-vdpa,id=mynet0,vhostdev=/dev/vhost-vdpa-0 -device virtio-net-pci,netdev=mynet0,mac=02:AA:BB:DD:00:20,disable-modern=off,page-per-vq=on -cpu host --nographic + +Host OS: +======== +Linux kernel 5.11 running on x86 host + +Guest OS: +========== +CentOS 7.5 + +Root cause analysis: +===================== + +For vhost-vdpa netdevice, the feature negotiation results in sending the superset of features received from device in call to get_features vdpa ops callback. + +During the feature-negotiation phase, the acknowledged feature bits are initialized with backend_features and then checked for supported feature bits in vhost_ack_features(): + +void vhost_net_ack_features(struct vhost_net *net, uint64_t features) +{ + net->dev.acked_features = net->dev.backend_features; + vhost_ack_features(&net->dev, vhost_net_get_feature_bits(net), features); +} + + +The vhost_ack_features() function just builds up on the dev.acked_features and never trims it down: + +void vhost_ack_features(struct vhost_dev *hdev, const int *feature_bits, uint64_t features) +{ const int *bit = feature_bits; + + while (*bit != VHOST_INVALID_FEATURE_BIT) { + uint64_t bit_mask = (1ULL << *bit); + + if (features & bit_mask) + hdev->acked_features |= bit_mask; + + bit++; + } +} + +Because of this hdev->acked_features is always minimally equal to the value of device features and this is the value that is passed to the device in set_features callback: + +static int vhost_dev_set_features(struct vhost_dev *dev, bool enable_log) +{ + uint64_t *features = dev->acked_features; + ..... + r = dev->vhost_ops->*vhost_set_features*(dev, features); +} + +QEMU version: 5.1.0 + +https://qemu-devel.nongnu.narkive.com/jUimpLt0/patch-vhost-net-initialize-acked-features-to-a-safe-value-during-ack +This review of a patch that introduced "acked_features = backend_features" behaviour suggests that acked_features should be 0 by default, but it ended up pushing it as it is now (as they say that not setting acked_features to backend_features sometimes makes acked_features value 'unexpected') + +Other devices initialize acked_features to guest_features (basically what VM writes to driver_features ANDed with device_features), changing default value to any of those (0 as review initially suggested, or guest_features) should fix this problem for us + +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 ticket has been moved here (thanks, Gautam): +https://gitlab.com/qemu-project/qemu/-/issues/331 +... thus I'm closing this on Launchpad now. + +Thanks Thomas Huth. + +I couldn't find an option to assign the issue on gitlab to anyone. Can you please help with that? + +Not sure who should be the assignee here ... maybe it's best if you write a mail to the people who have been involved in the original code (see https://gitlab.com/qemu-project/qemu/-/commit/108a64818e69be0a97c ) and ask them who could have a look at this issue. + diff --git a/results/classifier/118/review/1924914 b/results/classifier/118/review/1924914 new file mode 100644 index 000000000..f4526fe22 --- /dev/null +++ b/results/classifier/118/review/1924914 @@ -0,0 +1,150 @@ +user-level: 0.869 +KVM: 0.803 +register: 0.784 +permissions: 0.768 +ppc: 0.764 +mistranslation: 0.760 +TCG: 0.758 +graphic: 0.706 +x86: 0.689 +performance: 0.687 +hypervisor: 0.687 +device: 0.684 +virtual: 0.684 +debug: 0.683 +VMM: 0.678 +vnc: 0.676 +risc-v: 0.669 +architecture: 0.668 +semantic: 0.667 +peripherals: 0.645 +boot: 0.642 +arm: 0.627 +network: 0.624 +assembly: 0.621 +PID: 0.611 +kernel: 0.602 +files: 0.587 +i386: 0.553 +socket: 0.541 +-------------------- +virtual: 0.950 +debug: 0.863 +kernel: 0.816 +hypervisor: 0.691 +register: 0.421 +assembly: 0.128 +PID: 0.120 +x86: 0.089 +KVM: 0.026 +performance: 0.019 +semantic: 0.019 +files: 0.015 +VMM: 0.014 +user-level: 0.010 +device: 0.008 +architecture: 0.006 +TCG: 0.004 +graphic: 0.003 +socket: 0.002 +network: 0.002 +boot: 0.001 +peripherals: 0.001 +i386: 0.001 +vnc: 0.001 +permissions: 0.000 +ppc: 0.000 +risc-v: 0.000 +mistranslation: 0.000 +arm: 0.000 + +Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver) + +System is Arch Linux (guest and host OS). + +Problem: + +Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. + +This is the command I use to run my guest: + +qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 + +This doesn't happen when I use X with i3-wm. + + + +I can't get it to happen with -vga qxl. + +I can't reproduce it with weston. + +-cpu host -smp 4 makes the hang/freeze go away. + +From the dmesg above: + +[ 573.935889] Oops: 0000 [#1] PREEMPT SMP PTI +[ 573.935892] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.11.11-arch1-1 #1 +[ 573.935896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.14.0-1 04/01/2014 +[ 573.935899] Workqueue: events_unbound commit_work [drm_kms_helper] +[ 573.935949] RIP: 0010:dma_fence_wait_timeout+0x20/0x110 +[ 573.935953] Code: 5c 41 5d 41 5e 41 5f c3 66 90 0f 1f 44 00 00 41 54 55 53 48 83 ec 08 48 85 d2 0f 88 da 00 00 00 48 89 fd 89 f3 0f 1f 44 00 00 <48> 8b 45 08 0f b6 f3 48 89 ef 48 8b 40 28 48 85 c0 0f 84 ac 00 00 +[ 573.935956] RSP: 0018:ffffbbf100043db0 EFLAGS: 00010206 +[ 573.935958] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001 +[ 573.935959] RDX: 7fffffffffffffff RSI: 0000000000000001 RDI: 0000000000000000 +[ 573.935961] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff90631e171bc0 +[ 573.935962] R10: 0000000000000001 R11: 0000000000000001 R12: ffff906408336000 +[ 573.935964] R13: ffff906380260cc0 R14: ffff906401700000 R15: 0000000000000005 +[ 573.935966] FS: 0000000000000000(0000) GS:ffff90643bc00000(0000) knlGS:0000000000000000 +[ 573.935967] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 573.935969] CR2: 0000000000000008 CR3: 000000011ed86000 CR4: 00000000000006f0 +[ 573.935973] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 573.935974] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 573.935976] Call Trace: +[ 573.935983] ? virtio_gpu_notify+0x46/0x60 [virtio_gpu] +[ 573.935995] virtio_gpu_cursor_plane_update+0x1c3/0x2a0 [virtio_gpu] +[ 573.936005] drm_atomic_helper_commit_planes+0xb7/0x220 [drm_kms_helper] +[ 573.936024] drm_atomic_helper_commit_tail+0x42/0x80 [drm_kms_helper] +[ 573.936038] commit_tail+0xce/0x130 [drm_kms_helper] +[ 573.936050] process_one_work+0x214/0x3e0 +[ 573.936054] worker_thread+0x4d/0x3d0 +[ 573.936056] ? rescuer_thread+0x3c0/0x3c0 +[ 573.936058] kthread+0x133/0x150 +[ 573.936061] ? __kthread_bind_mask+0x60/0x60 +[ 573.936064] ret_from_fork+0x22/0x30 +[ 573.936072] Modules linked in: cfg80211 rfkill ghash_generic gf128mul cryptd gcm ccm algif_aead des_generic libdes cbc ecb algif_skcipher cmac md4 algif_hash af_alg ppdev pktcdvd parport_pc parport i2c_piix4 joydev mousedev mac_hid psmouse qemu_fw_cfg pcspkr pkcs8_key_parser speakup_soft speakup fuse bpf_preload ip_tables x_tables overlay squashfs loop isofs sr_mod cdrom ata_generic pata_acpi virtio_gpu virtio_dma_buf drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm intel_agp intel_gtt serio_raw e1000 virtio_pci ata_piix agpgart floppy +[ 573.936161] CR2: 0000000000000008 +[ 573.936163] ---[ end trace 0f1e24b3ea0a35cd ]--- +[ 573.936165] RIP: 0010:dma_fence_wait_timeout+0x20/0x110 + +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/review/1926759 b/results/classifier/118/review/1926759 new file mode 100644 index 000000000..b88bcb085 --- /dev/null +++ b/results/classifier/118/review/1926759 @@ -0,0 +1,120 @@ +architecture: 0.869 +semantic: 0.770 +user-level: 0.755 +arm: 0.721 +graphic: 0.694 +device: 0.644 +ppc: 0.643 +performance: 0.633 +kernel: 0.631 +debug: 0.602 +PID: 0.590 +permissions: 0.575 +files: 0.573 +vnc: 0.552 +register: 0.551 +risc-v: 0.536 +assembly: 0.506 +x86: 0.499 +socket: 0.491 +virtual: 0.452 +hypervisor: 0.440 +peripherals: 0.430 +i386: 0.422 +VMM: 0.414 +network: 0.398 +boot: 0.365 +mistranslation: 0.349 +TCG: 0.318 +KVM: 0.297 +-------------------- +arm: 0.969 +user-level: 0.693 +debug: 0.668 +virtual: 0.350 +semantic: 0.032 +TCG: 0.021 +files: 0.017 +architecture: 0.015 +PID: 0.015 +kernel: 0.015 +assembly: 0.012 +performance: 0.009 +VMM: 0.008 +register: 0.007 +hypervisor: 0.007 +socket: 0.005 +boot: 0.003 +device: 0.003 +vnc: 0.002 +permissions: 0.002 +network: 0.002 +graphic: 0.002 +peripherals: 0.001 +ppc: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +KVM: 0.001 +x86: 0.000 +i386: 0.000 + +WFI instruction results in unhandled CPU exception + +Hi + +I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following crash log. + +qemu: unhandled CPU exception 0x10001 - aborting +R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec +R04=00010a28 R05=00010158 R06=00087460 R07=00010158 +R08=00000000 R09=00000000 R10=00085b7c R11=408009f4 +R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8 +PSR=60000010 -ZC- A usr32 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 + +WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. + +Regards +Muhui + +Please provide a test case binary and your QEMU command line. + + +Oh, and the QEMU version you're using as well, please. + + +cmd： ~/qemu-5.1.0/arm-linux-user/qemu-arm ~/test2 + +QEMU version: qemu-arm version 5.1.0 + +Sorry that I didn't test it on the latest version of QEMU. + +Crash repros on current QEMU. + +This is a bug, in that we shouldn't crash like this. However, it doesn't really make any sense for a userspace program (which is what a binary run by qemu-arm is) to execute the WFI instruction, which is largely intended for OSes to use. If your guest binary needs to use WFI, you should probably be running it on the system emulation QEMU, which does handle WFI correctly. + + +The aarch64 kernel traps and handles WFI as a NOP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c219bc4e9205 -- so that's probably the most sensible implementation for our linux-user mode. (The aarch32 kernel doesn't trap it, yet, but +"WFI is a NOP" is a valid architectural implementation anyway.) + + +I agree with this implementation. Though WFI seems make no sense for a userspace program, we should not have assumption that the userspace program will not use this instruction. + +It seems ARM manual does not defined the implementation of function EnterLowPowerState(); However, before executing this instruction, there are some checks like below: + +if PSTATE.EL == EL0 then + // Check for traps described by the OS which may be EL1 or EL2. + AArch32.CheckForWFxTrap(EL1, FALSE); + +I am not sure whether it is complex/required to implement this in QEMU. Maybe patch the WFI as a NOP looks like the best idea at this moment. + +We do implement those traps, but only in the system mode emulator, because it makes no sense to trap to EL2 in the usermode emulator where EL2 doesn't exist. + + +Should be fixed by: +https://<email address hidden>/ + + +Fix has been merged: +https://gitlab.com/qemu-project/qemu/-/commit/5b2c8af89b82a671137a + diff --git a/results/classifier/118/review/1926996 b/results/classifier/118/review/1926996 new file mode 100644 index 000000000..73ae75c5f --- /dev/null +++ b/results/classifier/118/review/1926996 @@ -0,0 +1,130 @@ +architecture: 0.952 +user-level: 0.919 +graphic: 0.908 +arm: 0.781 +performance: 0.776 +semantic: 0.756 +x86: 0.699 +mistranslation: 0.678 +device: 0.661 +ppc: 0.626 +debug: 0.623 +permissions: 0.606 +kernel: 0.598 +files: 0.596 +network: 0.579 +PID: 0.550 +hypervisor: 0.544 +TCG: 0.510 +vnc: 0.504 +VMM: 0.497 +socket: 0.469 +risc-v: 0.467 +register: 0.450 +peripherals: 0.448 +virtual: 0.430 +boot: 0.411 +KVM: 0.283 +assembly: 0.247 +i386: 0.213 +-------------------- +files: 0.040 +debug: 0.027 +TCG: 0.018 +virtual: 0.014 +user-level: 0.006 +network: 0.006 +hypervisor: 0.005 +PID: 0.004 +architecture: 0.004 +semantic: 0.003 +kernel: 0.002 +vnc: 0.002 +x86: 0.002 +register: 0.002 +device: 0.002 +VMM: 0.002 +risc-v: 0.001 +performance: 0.001 +graphic: 0.001 +assembly: 0.001 +socket: 0.001 +permissions: 0.001 +peripherals: 0.001 +boot: 0.001 +mistranslation: 0.000 +arm: 0.000 +ppc: 0.000 +i386: 0.000 +KVM: 0.000 + +qemu-user clone syscall fails + +qemu-user fails to emulate clone() (https://linux.die.net/man/2/clone). The architecture doesn't seem to matter, tho I've mostly been testing aarch64. + +Attached is clone_test.c that demonstrates the problem. Running it natively looks like this: +$ bin/clone_test +The variable was 9 +clone returned 4177: 0 Success +The variable is now 42 + + +However, running it via qemu looks like: +$ qemu-aarch64-static --version +qemu-aarch64 version 5.2.0 (v5.2.0) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ qemu-aarch64-static ./clone_test +The variable was 9 +clone returned -1: 22 Invalid argument +The variable is now 9 + + + +clone_test aarch64 binary + +clone_test x86_64 binary + +clone_test (aarch64) + +clone_test (x86_64) + +I suspect it's failing because the qemu-user emulation of clone is basically enough for what libc uses and not for your own set of flags: + + https://qemu-project.gitlab.io/qemu/src/S/2440.html#L6478 + +For a full explanation see: https://qemu-project.gitlab.io/qemu/src/S/2440.html#L141 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know how to transfer the bug to the new system if +(if still necessary). For this we're setting the status to "Incomplete" +now. + +In the unlikely case that 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 should be +moved to the new system, 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/review/1934 b/results/classifier/118/review/1934 new file mode 100644 index 000000000..2df9479ba --- /dev/null +++ b/results/classifier/118/review/1934 @@ -0,0 +1,84 @@ +TCG: 0.916 +graphic: 0.833 +performance: 0.767 +PID: 0.708 +socket: 0.691 +mistranslation: 0.677 +semantic: 0.673 +device: 0.671 +ppc: 0.671 +files: 0.668 +VMM: 0.656 +arm: 0.653 +architecture: 0.622 +kernel: 0.621 +network: 0.620 +vnc: 0.615 +register: 0.596 +risc-v: 0.568 +debug: 0.554 +peripherals: 0.507 +hypervisor: 0.481 +boot: 0.479 +permissions: 0.471 +user-level: 0.424 +KVM: 0.412 +assembly: 0.402 +virtual: 0.308 +i386: 0.206 +x86: 0.055 +-------------------- +TCG: 0.648 +files: 0.255 +debug: 0.093 +kernel: 0.068 +register: 0.039 +VMM: 0.034 +hypervisor: 0.030 +PID: 0.027 +risc-v: 0.027 +performance: 0.024 +KVM: 0.021 +semantic: 0.012 +device: 0.010 +virtual: 0.009 +architecture: 0.009 +assembly: 0.008 +vnc: 0.006 +user-level: 0.004 +boot: 0.004 +socket: 0.003 +peripherals: 0.003 +network: 0.002 +graphic: 0.002 +permissions: 0.001 +mistranslation: 0.001 +ppc: 0.000 +arm: 0.000 +x86: 0.000 +i386: 0.000 + +Build failure on s390x with Clang 17 due to int128 alignment used in `__sync_` operations +Description of problem: +We experienced this downstream, but filing this here since the code still seems to be the same in git. + +https://reviews.llvm.org/D143813 introduced this warning since, according to the description, `__int128` +needs to be 8-byte aligned on s390 but the code in `host/include/generic/host/atomic128-ldst.h` unconditionally uses 16-byte alignment. + +The output is: + +``` +In file included from ../accel/tcg/cputlb.c:32: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:62: +/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-ldst.h:68:15: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment] + 68 | } while (!__sync_bool_compare_and_swap_16(ptr_align, old, new.i)); + | ^ +In file included from ../accel/tcg/cputlb.c:32: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:61: +/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-cas.h:36:11: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment] + 36 | r.i = __sync_val_compare_and_swap_16(ptr_align, c.i, n.i); + | ^ +2 errors generated. +``` diff --git a/results/classifier/118/review/194 b/results/classifier/118/review/194 new file mode 100644 index 000000000..12e5510c2 --- /dev/null +++ b/results/classifier/118/review/194 @@ -0,0 +1,61 @@ +mistranslation: 0.923 +performance: 0.709 +device: 0.605 +graphic: 0.488 +semantic: 0.316 +architecture: 0.191 +user-level: 0.183 +virtual: 0.140 +register: 0.126 +i386: 0.110 +arm: 0.100 +assembly: 0.062 +debug: 0.059 +hypervisor: 0.041 +peripherals: 0.037 +vnc: 0.033 +ppc: 0.033 +risc-v: 0.033 +PID: 0.032 +TCG: 0.030 +boot: 0.030 +network: 0.028 +permissions: 0.020 +kernel: 0.015 +VMM: 0.015 +x86: 0.014 +files: 0.012 +socket: 0.012 +KVM: 0.001 +-------------------- +virtual: 0.928 +hypervisor: 0.910 +boot: 0.757 +user-level: 0.225 +semantic: 0.053 +performance: 0.041 +permissions: 0.035 +PID: 0.028 +debug: 0.015 +files: 0.012 +device: 0.011 +peripherals: 0.007 +x86: 0.006 +kernel: 0.006 +assembly: 0.006 +TCG: 0.006 +KVM: 0.006 +i386: 0.004 +ppc: 0.004 +VMM: 0.003 +arm: 0.003 +graphic: 0.002 +network: 0.002 +socket: 0.002 +architecture: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +vnc: 0.000 +register: 0.000 + +Qemu fails to start with error " There is no option group 'spice'" diff --git a/results/classifier/118/review/1953 b/results/classifier/118/review/1953 new file mode 100644 index 000000000..bc6602b68 --- /dev/null +++ b/results/classifier/118/review/1953 @@ -0,0 +1,206 @@ +user-level: 0.810 +architecture: 0.799 +register: 0.787 +permissions: 0.773 +device: 0.769 +assembly: 0.757 +semantic: 0.755 +performance: 0.736 +files: 0.730 +PID: 0.725 +virtual: 0.724 +KVM: 0.718 +debug: 0.707 +graphic: 0.704 +arm: 0.700 +VMM: 0.663 +x86: 0.613 +kernel: 0.584 +boot: 0.541 +risc-v: 0.539 +hypervisor: 0.530 +peripherals: 0.527 +network: 0.525 +TCG: 0.508 +ppc: 0.502 +vnc: 0.486 +socket: 0.430 +mistranslation: 0.425 +i386: 0.383 +-------------------- +x86: 0.905 +debug: 0.592 +performance: 0.229 +user-level: 0.228 +hypervisor: 0.068 +PID: 0.064 +files: 0.060 +virtual: 0.045 +risc-v: 0.036 +arm: 0.034 +VMM: 0.033 +register: 0.023 +TCG: 0.022 +device: 0.020 +boot: 0.017 +socket: 0.013 +network: 0.013 +peripherals: 0.010 +kernel: 0.010 +assembly: 0.008 +graphic: 0.007 +ppc: 0.007 +architecture: 0.004 +vnc: 0.004 +semantic: 0.004 +KVM: 0.002 +permissions: 0.001 +i386: 0.001 +mistranslation: 0.001 + +Segmentation fault when compiling elixir app on qemu aarch64 on x86_64 host +Description of problem: +When I try to install an elixir escript using + +``` +mix escript.install github upmaru/pakman --force +``` + +I run into a segfault with the following output + +``` + + +Build and Deploy +failed Oct 22, 2023 in 1m 27s +2s +2s +22s +56s +remote: Compressing objects: 86% (144/167) +remote: Compressing objects: 87% (146/167) +remote: Compressing objects: 88% (147/167) +remote: Compressing objects: 89% (149/167) +remote: Compressing objects: 90% (151/167) +remote: Compressing objects: 91% (152/167) +remote: Compressing objects: 92% (154/167) +remote: Compressing objects: 93% (156/167) +remote: Compressing objects: 94% (157/167) +remote: Compressing objects: 95% (159/167) +remote: Compressing objects: 96% (161/167) +remote: Compressing objects: 97% (162/167) +remote: Compressing objects: 98% (164/167) +remote: Compressing objects: 99% (166/167) +remote: Compressing objects: 100% (167/167) +remote: Compressing objects: 100% (167/167), done. +remote: Total 2568 (delta 86), reused 188 (delta 58), pack-reused 2341 +origin/HEAD set to develop +Resolving Hex dependencies... +Resolution completed in 0.872s +New: + castore 1.0.4 + finch 0.16.0 + hpax 0.1.2 + jason 1.4.1 + mime 2.0.5 + mint 1.5.1 + nimble_options 1.0.2 + nimble_pool 1.0.0 + slugger 0.3.0 + telemetry 1.2.1 + tesla 1.7.0 + yamerl 0.10.0 + yaml_elixir 2.8.0 +* Getting tesla (Hex package) +* Getting jason (Hex package) +* Getting yaml_elixir (Hex package) +* Getting slugger (Hex package) +* Getting finch (Hex package) +* Getting mint (Hex package) +* Getting castore (Hex package) +* Getting hpax (Hex package) +* Getting mime (Hex package) +* Getting nimble_options (Hex package) +* Getting nimble_pool (Hex package) +* Getting telemetry (Hex package) +* Getting yamerl (Hex package) +Resolving Hex dependencies... +Resolution completed in 0.413s +Unchanged: + castore 1.0.4 + finch 0.16.0 + hpax 0.1.2 + jason 1.4.1 + mime 2.0.5 + mint 1.5.1 + nimble_options 1.0.2 + nimble_pool 1.0.0 + slugger 0.3.0 + telemetry 1.2.1 + tesla 1.7.0 + yamerl 0.10.0 + yaml_elixir 2.8.0 +All dependencies are up to date +==> mime +Compiling 1 file (.ex) +Generated mime app +==> nimble_options +Compiling 3 files (.ex) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Create a repo using the github action zacksiri/setup-alpine +2. Install elixir +3. run `mix escript.install github upmaru/pakman --force` +Additional information: +You can use the following github action config as an example / starting point. + + +```yml +name: 'Deployment' + +on: + push: + branches: + - main + - master + - develop + +jobs: + build_and_deploy: + name: Build and Deploy + runs-on: ubuntu-latest + steps: + - name: 'Checkout' + uses: actions/checkout@v3 + with: + ref: ${{ github.event.workflow_run.head_branch }} + fetch-depth: 0 + + - name: 'Setup Alpine' + uses: zacksiri/setup-alpine@master + with: + branch: v3.18 + arch: aarch64 + qemu-repo: edge + packages: | + zip + tar + sudo + alpine-sdk + coreutils + cmake + elixir + + - name: 'Setup PAKman' + run: | + export MIX_ENV=prod + + mix local.rebar --force + mix local.hex --force + mix escript.install github upmaru/pakman --force + shell: alpine.sh {0} +``` + +I'm using alpine 3.18 which has otp25 with jit enabled so I suspect this is something to do with https://gitlab.com/qemu-project/qemu/-/issues/1034 diff --git a/results/classifier/118/review/1955 b/results/classifier/118/review/1955 new file mode 100644 index 000000000..9ebdc7038 --- /dev/null +++ b/results/classifier/118/review/1955 @@ -0,0 +1,86 @@ +architecture: 0.916 +graphic: 0.840 +performance: 0.806 +ppc: 0.803 +semantic: 0.801 +device: 0.645 +files: 0.587 +permissions: 0.571 +user-level: 0.553 +PID: 0.505 +peripherals: 0.432 +socket: 0.420 +network: 0.394 +debug: 0.384 +hypervisor: 0.377 +kernel: 0.355 +mistranslation: 0.346 +boot: 0.280 +vnc: 0.269 +TCG: 0.269 +risc-v: 0.256 +register: 0.239 +assembly: 0.183 +virtual: 0.172 +x86: 0.148 +VMM: 0.147 +arm: 0.146 +i386: 0.111 +KVM: 0.107 +-------------------- +ppc: 0.244 +architecture: 0.110 +debug: 0.064 +TCG: 0.052 +files: 0.045 +PID: 0.026 +socket: 0.019 +semantic: 0.019 +register: 0.018 +performance: 0.014 +virtual: 0.013 +hypervisor: 0.012 +device: 0.011 +network: 0.009 +VMM: 0.009 +assembly: 0.008 +vnc: 0.006 +user-level: 0.005 +boot: 0.004 +KVM: 0.004 +kernel: 0.003 +peripherals: 0.003 +risc-v: 0.002 +x86: 0.002 +graphic: 0.002 +permissions: 0.001 +i386: 0.001 +mistranslation: 0.001 +arm: 0.001 + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/118/review/1956 b/results/classifier/118/review/1956 new file mode 100644 index 000000000..077b79d7c --- /dev/null +++ b/results/classifier/118/review/1956 @@ -0,0 +1,61 @@ +architecture: 0.983 +mistranslation: 0.891 +device: 0.819 +x86: 0.695 +semantic: 0.541 +boot: 0.297 +graphic: 0.287 +peripherals: 0.242 +virtual: 0.225 +network: 0.186 +performance: 0.173 +register: 0.158 +debug: 0.132 +permissions: 0.123 +PID: 0.100 +i386: 0.089 +files: 0.083 +risc-v: 0.081 +TCG: 0.077 +user-level: 0.042 +vnc: 0.025 +ppc: 0.023 +VMM: 0.015 +hypervisor: 0.014 +assembly: 0.013 +socket: 0.011 +arm: 0.009 +kernel: 0.001 +KVM: 0.001 +-------------------- +x86: 0.946 +virtual: 0.673 +i386: 0.124 +files: 0.090 +kernel: 0.062 +TCG: 0.039 +KVM: 0.026 +hypervisor: 0.024 +semantic: 0.023 +assembly: 0.022 +architecture: 0.020 +register: 0.013 +device: 0.010 +VMM: 0.009 +user-level: 0.008 +debug: 0.006 +risc-v: 0.002 +PID: 0.002 +performance: 0.001 +socket: 0.001 +peripherals: 0.001 +graphic: 0.001 +network: 0.001 +permissions: 0.001 +boot: 0.001 +ppc: 0.000 +vnc: 0.000 +arm: 0.000 +mistranslation: 0.000 + +[x86,microvm] Update microvm documentation with ACPI option diff --git a/results/classifier/118/review/1970 b/results/classifier/118/review/1970 new file mode 100644 index 000000000..f8a79db59 --- /dev/null +++ b/results/classifier/118/review/1970 @@ -0,0 +1,61 @@ +mistranslation: 0.856 +device: 0.778 +performance: 0.742 +arm: 0.599 +network: 0.574 +risc-v: 0.348 +boot: 0.337 +graphic: 0.335 +architecture: 0.271 +semantic: 0.261 +ppc: 0.260 +permissions: 0.259 +user-level: 0.257 +kernel: 0.248 +register: 0.216 +vnc: 0.208 +hypervisor: 0.192 +files: 0.191 +PID: 0.175 +socket: 0.171 +VMM: 0.171 +virtual: 0.165 +debug: 0.154 +TCG: 0.129 +KVM: 0.058 +assembly: 0.056 +peripherals: 0.027 +i386: 0.014 +x86: 0.011 +-------------------- +device: 0.632 +mistranslation: 0.142 +virtual: 0.071 +user-level: 0.034 +performance: 0.026 +files: 0.021 +semantic: 0.017 +network: 0.009 +peripherals: 0.007 +PID: 0.007 +kernel: 0.007 +architecture: 0.007 +arm: 0.004 +register: 0.004 +ppc: 0.003 +assembly: 0.003 +debug: 0.003 +boot: 0.003 +TCG: 0.003 +graphic: 0.002 +socket: 0.001 +hypervisor: 0.001 +risc-v: 0.001 +KVM: 0.001 +permissions: 0.001 +vnc: 0.001 +VMM: 0.001 +x86: 0.000 +i386: 0.000 + +A64 LDRA decode scales the immediate by wrong amount diff --git a/results/classifier/118/review/1978 b/results/classifier/118/review/1978 new file mode 100644 index 000000000..7482ef016 --- /dev/null +++ b/results/classifier/118/review/1978 @@ -0,0 +1,65 @@ +mistranslation: 0.874 +risc-v: 0.863 +device: 0.855 +performance: 0.841 +files: 0.818 +vnc: 0.809 +graphic: 0.778 +network: 0.694 +socket: 0.635 +register: 0.606 +kernel: 0.564 +semantic: 0.524 +debug: 0.465 +permissions: 0.447 +peripherals: 0.435 +ppc: 0.427 +i386: 0.409 +architecture: 0.396 +boot: 0.385 +hypervisor: 0.307 +TCG: 0.274 +arm: 0.258 +x86: 0.253 +VMM: 0.242 +user-level: 0.215 +virtual: 0.189 +KVM: 0.146 +PID: 0.138 +assembly: 0.108 +-------------------- +debug: 0.636 +kernel: 0.467 +assembly: 0.459 +hypervisor: 0.321 +files: 0.268 +device: 0.249 +x86: 0.238 +performance: 0.216 +register: 0.159 +i386: 0.140 +arm: 0.115 +virtual: 0.099 +peripherals: 0.089 +ppc: 0.077 +architecture: 0.052 +PID: 0.016 +boot: 0.015 +semantic: 0.014 +TCG: 0.013 +risc-v: 0.012 +network: 0.008 +VMM: 0.008 +user-level: 0.005 +socket: 0.005 +KVM: 0.003 +permissions: 0.003 +graphic: 0.003 +vnc: 0.002 +mistranslation: 0.002 + +sifive_e : erroneous CLINT frequency +Description of problem: +CLINT's `mtime` updates at a clock frequency of [10 MHz](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/riscv/sifive_e.c?ref_type=heads#L228), whereas [SiFive documentation](https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf?_gl=1*w2ieef*_ga*MTcyNDI2MjM0Ny4xNjk2ODcwNTM3*_ga_T369JS7J9N*MTY5Njg3MDUzNy4xLjAuMTY5Njg3MDUzNy42MC4wLjA.) shows that its clock frequency is 32.768 kHz (i.e., the RTC clock). + +This difference leads to unexpected timing behavior. Due to the difference, it can even trigger multiple nested interrupts as the IRQ routine is not able to return before a new timer interrupt is triggered. diff --git a/results/classifier/118/review/1981 b/results/classifier/118/review/1981 new file mode 100644 index 000000000..6146ce76c --- /dev/null +++ b/results/classifier/118/review/1981 @@ -0,0 +1,70 @@ +mistranslation: 0.886 +device: 0.862 +graphic: 0.856 +register: 0.802 +risc-v: 0.754 +arm: 0.698 +socket: 0.694 +semantic: 0.612 +network: 0.594 +peripherals: 0.546 +ppc: 0.523 +debug: 0.515 +architecture: 0.494 +performance: 0.450 +vnc: 0.329 +kernel: 0.290 +virtual: 0.270 +user-level: 0.225 +PID: 0.200 +permissions: 0.199 +files: 0.188 +assembly: 0.121 +VMM: 0.063 +i386: 0.026 +boot: 0.021 +hypervisor: 0.018 +KVM: 0.011 +TCG: 0.010 +x86: 0.008 +-------------------- +debug: 0.498 +x86: 0.466 +files: 0.416 +register: 0.309 +i386: 0.208 +hypervisor: 0.191 +risc-v: 0.100 +virtual: 0.098 +TCG: 0.080 +peripherals: 0.076 +ppc: 0.067 +arm: 0.065 +device: 0.056 +kernel: 0.033 +VMM: 0.027 +assembly: 0.020 +PID: 0.009 +semantic: 0.009 +boot: 0.008 +user-level: 0.007 +architecture: 0.007 +network: 0.007 +KVM: 0.006 +socket: 0.004 +performance: 0.003 +permissions: 0.003 +graphic: 0.002 +vnc: 0.002 +mistranslation: 0.001 + +wrong address of pmpaddr13 and pmpaddr14 CSRs +Description of problem: +In qemu\disas\riscv.c lines 2119 & 2120 it seems that there is a confusion about the correct address of the pmpaddr13 and pmpaddr14 CSRs +``` +line 2117 case 0x03bb: return "pmpaddr11"; +line 2118 case 0x03bc: return "pmpaddr12"; +**line 2119 case 0x03bd: return "pmpaddr14"; <--- pmpaddr13 should be here +line 2120 case 0x03be: return "pmpaddr13"; <--- pmpaddr14 should be here** +line 2121 case 0x03bf: return "pmpaddr15"; +``` diff --git a/results/classifier/118/review/1987 b/results/classifier/118/review/1987 new file mode 100644 index 000000000..9908b09ea --- /dev/null +++ b/results/classifier/118/review/1987 @@ -0,0 +1,108 @@ +mistranslation: 0.948 +user-level: 0.910 +permissions: 0.909 +register: 0.905 +architecture: 0.885 +device: 0.883 +performance: 0.881 +peripherals: 0.875 +risc-v: 0.868 +arm: 0.868 +KVM: 0.865 +assembly: 0.862 +TCG: 0.843 +debug: 0.841 +graphic: 0.839 +ppc: 0.829 +kernel: 0.827 +VMM: 0.824 +socket: 0.822 +vnc: 0.812 +hypervisor: 0.801 +files: 0.784 +boot: 0.761 +PID: 0.749 +virtual: 0.747 +x86: 0.744 +network: 0.736 +i386: 0.691 +semantic: 0.690 +-------------------- +debug: 0.978 +virtual: 0.947 +user-level: 0.723 +kernel: 0.496 +x86: 0.407 +performance: 0.193 +hypervisor: 0.090 +i386: 0.053 +PID: 0.050 +TCG: 0.044 +files: 0.035 +register: 0.030 +ppc: 0.026 +assembly: 0.021 +semantic: 0.017 +architecture: 0.008 +arm: 0.008 +VMM: 0.008 +device: 0.005 +network: 0.004 +socket: 0.002 +risc-v: 0.002 +KVM: 0.002 +vnc: 0.002 +graphic: 0.002 +boot: 0.002 +permissions: 0.001 +peripherals: 0.001 +mistranslation: 0.000 + +snapshot: main thread hangs for a while after 'loadvm' +Description of problem: +When I was testing qemu snapshots, I found that after the `loadvm` command, the virtual machine would often get stuck for a while, and it can **resume execution after I enter some characters into the terminal**, this is weird because my guest system doesn't need to accept input. + +After some debugging, I found that the guest kernel is executing a `wait` instruction in `__r4k_wait()`. + +And I found that the main thread usually does not sleep at `qemu_poll_ns()` during normal execution, but after `loadvm`, the timeout is set to a large value (related to the interval time of snapshot operations), causes the main thread to get stuck on 'qemu_poll_ns()'. + +After some analysis, I think it is because save/load_snapshot() does not handle timers related to QEMU_CLOCK_VIRTUAL well, such as `mips_timer_cb()`, resulting in incorrect value when calculating timeout. +Steps to reproduce: +1. Start emulation and connect monitor +2. `savevm` and wait for a moment +3. `loadvm` +Additional information: +Stack backtrace of the guest kernel: +``` +► 0 0x80104d40 __r4k_wait+32 + 1 0x80143cc4 cpu_startup_entry+284 + 2 0x80143cc4 cpu_startup_entry+284 + 3 0x80143cc4 cpu_startup_entry+284 + 4 0x80633fe0 kernel_init + 5 0x80825cb8 start_kernel+1072 +``` + +Stack backtrace of the main thread: +``` +0 0x7ffff74f0a96 ppoll+166 +1 0x555555ea4786 qemu_poll_ns+221 +2 0x555555e9fea7 os_host_main_loop_wait+93 +3 0x555555e9ffd6 main_loop_wait+187 +4 0x555555a644fd qemu_main_loop+46 +5 0x5555557d2b6a qemu_default_main+17 +6 0x5555557d2ba9 main+45 +7 0x7ffff7402083 __libc_start_main+243 +``` + +Stack backtrace of the vCPU thread: +``` +#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556550848) at ../sysdeps/nptl/futex-internal.h:183 +#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x5555564d0860 <qemu_global_mutex>, cond=0x555556550820) at pthread_cond_wait.c:508 +#2 __pthread_cond_wait (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>) at pthread_cond_wait.c:647 +#3 0x0000555555e85602 in qemu_cond_wait_impl (cond=0x555556550820, mutex=0x5555564d0860 <qemu_global_mutex>, file=0x5555560122ab "../system/cpus.c", line=431) at ../util/qemu-thread-posix.c:225 +#4 0x0000555555a5618f in qemu_wait_io_event (cpu=0x555556825200) at ../system/cpus.c:431 +#5 0x0000555555c8bcf1 in mttcg_cpu_thread_fn (arg=0x555556825200) at ../accel/tcg/tcg-accel-ops-mttcg.c:118 +#6 0x0000555555e85e50 in qemu_thread_start (args=0x555556550860) at ../util/qemu-thread-posix.c:541 +#7 0x00007ffff75d8609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#8 0x00007ffff74fd133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +``` diff --git a/results/classifier/118/review/1995 b/results/classifier/118/review/1995 new file mode 100644 index 000000000..275581ab7 --- /dev/null +++ b/results/classifier/118/review/1995 @@ -0,0 +1,61 @@ +mistranslation: 0.977 +semantic: 0.699 +user-level: 0.514 +virtual: 0.471 +device: 0.469 +performance: 0.298 +graphic: 0.277 +boot: 0.183 +i386: 0.149 +x86: 0.123 +assembly: 0.107 +architecture: 0.090 +ppc: 0.069 +KVM: 0.054 +TCG: 0.048 +hypervisor: 0.046 +kernel: 0.043 +debug: 0.042 +vnc: 0.036 +peripherals: 0.032 +register: 0.027 +VMM: 0.022 +PID: 0.018 +socket: 0.017 +files: 0.016 +permissions: 0.016 +risc-v: 0.012 +network: 0.008 +arm: 0.005 +-------------------- +boot: 0.708 +semantic: 0.550 +user-level: 0.242 +kernel: 0.210 +performance: 0.055 +device: 0.034 +virtual: 0.027 +mistranslation: 0.024 +permissions: 0.016 +TCG: 0.016 +debug: 0.014 +assembly: 0.014 +files: 0.012 +VMM: 0.009 +arm: 0.007 +peripherals: 0.006 +x86: 0.006 +hypervisor: 0.005 +KVM: 0.004 +i386: 0.003 +PID: 0.003 +risc-v: 0.003 +network: 0.003 +architecture: 0.002 +socket: 0.002 +register: 0.002 +ppc: 0.002 +graphic: 0.001 +vnc: 0.001 + +No equivalent of `-boot once` for `bootindex` diff --git a/results/classifier/118/review/1999 b/results/classifier/118/review/1999 new file mode 100644 index 000000000..8a677618f --- /dev/null +++ b/results/classifier/118/review/1999 @@ -0,0 +1,111 @@ +mistranslation: 0.889 +debug: 0.873 +peripherals: 0.869 +risc-v: 0.866 +kernel: 0.854 +graphic: 0.854 +KVM: 0.848 +assembly: 0.844 +user-level: 0.830 +files: 0.823 +performance: 0.815 +arm: 0.808 +hypervisor: 0.807 +device: 0.807 +register: 0.806 +permissions: 0.806 +virtual: 0.805 +architecture: 0.805 +PID: 0.803 +semantic: 0.794 +TCG: 0.794 +VMM: 0.792 +network: 0.770 +boot: 0.764 +vnc: 0.753 +socket: 0.742 +i386: 0.690 +x86: 0.676 +ppc: 0.658 +-------------------- +debug: 0.994 +kernel: 0.920 +KVM: 0.852 +x86: 0.305 +virtual: 0.277 +TCG: 0.063 +files: 0.058 +hypervisor: 0.055 +register: 0.048 +i386: 0.045 +device: 0.042 +performance: 0.032 +PID: 0.032 +user-level: 0.031 +ppc: 0.030 +architecture: 0.026 +network: 0.021 +arm: 0.013 +peripherals: 0.012 +assembly: 0.009 +risc-v: 0.009 +semantic: 0.008 +boot: 0.008 +socket: 0.007 +VMM: 0.007 +permissions: 0.005 +graphic: 0.003 +vnc: 0.002 +mistranslation: 0.001 + +qemu got sigabrt when using vpp in guest and dpdk for qemu +Description of problem: +When set the interface up in vpp, the qemu process is crashed with signal sigabrt. + +After some debug, i have identified that the problem lies in the following function. + +```c +static int setup_routing_entry(struct kvm *kvm, + struct kvm_irq_routing_table *rt, + struct kvm_kernel_irq_routing_entry *e, + const struct kvm_irq_routing_entry *ue) +{ + struct kvm_kernel_irq_routing_entry *ei; + int r; + u32 gsi = array_index_nospec(ue->gsi, KVM_MAX_IRQ_ROUTES); + + /* + * Do not allow GSI to be mapped to the same irqchip more than once. + * Allow only one to one mapping between GSI and non-irqchip routing. + */ + hlist_for_each_entry(ei, &rt->map[gsi], link) + if (ei->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->u.irqchip.irqchip == ei->irqchip.irqchip) + return -EINVAL; + +``` + +I added some debug printk like following + +```c + hlist_for_each_entry(ei, &rt->map[gsi], link) + if (ei->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->type != KVM_IRQ_ROUTING_IRQCHIP || + ue->u.irqchip.irqchip == ei->irqchip.irqchip){ + printk("ei->type: %u, KVM_IRQ_ROUTING_IRQCHIP: %u, ue->type: %u, ue->u.irqchip.irqchip: %u , ei->irqchip.irqchip: %u", ei->type, KVM_IRQ_ROUTING_IRQCHIP , ue->type, ue->u.irqchip.irqchip , ei->irqchip.irqchip); + return -EINVAL; + } +``` + +Then i got following in dmesg + +``` +[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024 +[Thu Nov 23 09:29:10 2023] ei->type: 2, KVM_IRQ_ROUTING_IRQCHIP: 1, ue->type: 1, ue->u.irqchip.irqchip: 2 , ei->irqchip.irqchip: 4276097024 +``` +Steps to reproduce: +This is a kube-ovn + dpdk env, not easy to reproduce now.. +Additional information: +* I also file a bug on kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=218177 +* the libvirt xml file is also attached [instance.xml](/uploads/05b391046fdc1263fd7e63bcfab6f4fb/instance.xml) diff --git a/results/classifier/118/review/2007 b/results/classifier/118/review/2007 new file mode 100644 index 000000000..260b6b93f --- /dev/null +++ b/results/classifier/118/review/2007 @@ -0,0 +1,89 @@ +register: 0.943 +peripherals: 0.857 +semantic: 0.833 +performance: 0.828 +device: 0.796 +hypervisor: 0.785 +architecture: 0.761 +graphic: 0.731 +kernel: 0.637 +debug: 0.627 +network: 0.617 +assembly: 0.594 +ppc: 0.592 +vnc: 0.565 +x86: 0.562 +user-level: 0.529 +permissions: 0.528 +arm: 0.524 +i386: 0.506 +socket: 0.476 +PID: 0.469 +KVM: 0.441 +boot: 0.428 +risc-v: 0.426 +mistranslation: 0.424 +VMM: 0.386 +TCG: 0.269 +virtual: 0.237 +files: 0.164 +-------------------- +kernel: 0.870 +register: 0.819 +hypervisor: 0.699 +debug: 0.695 +x86: 0.657 +arm: 0.296 +KVM: 0.231 +assembly: 0.213 +virtual: 0.138 +TCG: 0.123 +user-level: 0.080 +ppc: 0.046 +i386: 0.040 +risc-v: 0.039 +files: 0.036 +peripherals: 0.035 +PID: 0.034 +VMM: 0.022 +device: 0.021 +performance: 0.015 +architecture: 0.010 +network: 0.009 +semantic: 0.008 +boot: 0.007 +vnc: 0.003 +socket: 0.003 +permissions: 0.003 +graphic: 0.002 +mistranslation: 0.000 + +Unable to update APIC_TPR when x2APIC is enabled and -global kvm-pit.lost_tick_policy=discard parameter provided +Description of problem: +I am developing a custom OS and I wanted to implement x2APIC support. I was able to enable x2APIC, read and write some registers, like APIC_VER and APIC_SIVR. Everything looks good, except that I cannot update APIC_TPR register. Reading it always returns 0. The code I wrote works properly on bare metal. Below some observations: + +Scenario 1: +1. Enable x2APIC +2. Write to CR8 - success +3. Read from CR8 - gives correct value +4. Read from APIC_TPR - gives correct value + +Scenario 2: +1. Enable x2APIC +2. Read from APIC_TPR - gives 0 +3. Write to APIC_TPR +4. Read from APIC_TPR - gives 0 again + +Scenario 3: +1. Initialize APIC (LAPIC or xAPIC) +2. Write to APIC_TPR +3. Read from APIC_TPR - gives correct value +4. Switch to x2APIC +5. Read from APIC_TPR - gives correct value stored in pt. 2 +6. Write to APIC_TPR +7. Read from APIC_TPR - gives values stored in pt.2, not in point 6! + +Looks like APIC_TPR is stuck at value stored there before switching to x2APIC and it cannot be updated with MSR. Only update CR8 works. +I have checked parameters I passed to qemu. After removing `-global kvm-pit.lost_tick_policy=discard` problem is gone and APIC_TPR is updated correctly. +Additional information: +Please let me know if you need additional information. diff --git a/results/classifier/118/review/2036 b/results/classifier/118/review/2036 new file mode 100644 index 000000000..aca41da7c --- /dev/null +++ b/results/classifier/118/review/2036 @@ -0,0 +1,71 @@ +architecture: 0.964 +i386: 0.940 +x86: 0.904 +ppc: 0.894 +files: 0.893 +graphic: 0.877 +device: 0.872 +peripherals: 0.869 +risc-v: 0.859 +mistranslation: 0.803 +vnc: 0.707 +network: 0.703 +semantic: 0.694 +TCG: 0.685 +VMM: 0.681 +PID: 0.640 +socket: 0.597 +register: 0.593 +permissions: 0.570 +performance: 0.564 +boot: 0.520 +debug: 0.513 +arm: 0.429 +kernel: 0.427 +virtual: 0.382 +user-level: 0.370 +KVM: 0.323 +hypervisor: 0.220 +assembly: 0.030 +-------------------- +hypervisor: 0.885 +files: 0.881 +TCG: 0.565 +kernel: 0.398 +debug: 0.194 +register: 0.115 +VMM: 0.092 +virtual: 0.075 +risc-v: 0.057 +x86: 0.052 +i386: 0.035 +semantic: 0.028 +KVM: 0.026 +arm: 0.021 +device: 0.020 +assembly: 0.012 +PID: 0.012 +user-level: 0.011 +network: 0.008 +ppc: 0.007 +architecture: 0.006 +peripherals: 0.005 +boot: 0.005 +socket: 0.004 +performance: 0.004 +graphic: 0.003 +vnc: 0.002 +permissions: 0.001 +mistranslation: 0.000 + +`edk2-riscv-code.fd.bz2` is included in the repo but not installed to `$PREFIX/share/qemu` +Description of problem: +`edk2-riscv-code.fd.bz2` is included in the repo (https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/edk2-riscv-code.fd.bz2), but this file is not installed to `$PREFIX/share/qemu`. + +The binaries for other architectures (aarch64, arm, i386, x86\_64) are installed as expected. +https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/meson.build?ref_type=tags#L3-L12 +Steps to reproduce: +`ls $PREFIX/share/qemu/edk2-*` +Additional information: +- Not sure if this is intentional or a bug. +- The descriptor JSON file is missing for riscv: https://gitlab.com/qemu-project/qemu/-/tree/v8.2.0-rc4/pc-bios/descriptors diff --git a/results/classifier/118/review/2043 b/results/classifier/118/review/2043 new file mode 100644 index 000000000..affac6356 --- /dev/null +++ b/results/classifier/118/review/2043 @@ -0,0 +1,134 @@ +user-level: 0.853 +risc-v: 0.772 +permissions: 0.769 +vnc: 0.742 +semantic: 0.729 +virtual: 0.729 +performance: 0.726 +device: 0.722 +graphic: 0.710 +VMM: 0.705 +assembly: 0.703 +hypervisor: 0.699 +ppc: 0.698 +architecture: 0.679 +boot: 0.678 +peripherals: 0.675 +PID: 0.673 +arm: 0.664 +register: 0.652 +debug: 0.649 +TCG: 0.648 +mistranslation: 0.618 +x86: 0.617 +KVM: 0.613 +socket: 0.599 +kernel: 0.582 +network: 0.568 +files: 0.526 +i386: 0.484 +-------------------- +virtual: 0.948 +debug: 0.523 +kernel: 0.081 +VMM: 0.079 +performance: 0.067 +user-level: 0.063 +TCG: 0.059 +graphic: 0.056 +assembly: 0.052 +device: 0.039 +files: 0.035 +vnc: 0.023 +PID: 0.023 +x86: 0.019 +socket: 0.018 +risc-v: 0.017 +semantic: 0.015 +register: 0.014 +i386: 0.012 +hypervisor: 0.010 +boot: 0.010 +peripherals: 0.010 +architecture: 0.009 +arm: 0.008 +ppc: 0.006 +permissions: 0.005 +network: 0.002 +mistranslation: 0.001 +KVM: 0.000 + +QEMU hangs sometimes during TRIM command +Description of problem: +I encountered a virtual machine freeze when map cache invalidation request was received while executing a TRIM command. + +I did some research and i think i found the problem. + +1. `xen_invalidate_map_cache` calls `bdrv_drain_all` before invalidation +2. All BlockBackend devices run into quiesce mode (increment of `blk->quiesce_counter` in `blk_root_drained_begin`) +3. When processing another block in TRIM command coroutine `blk_co_do_pdiscard` calls `blk_wait_while_drained` +4. In `blk_wait_while_drained` we go under tre condition, decrement `in_flight` counter and yield the coroutine +5. After return from `blk_aio_complete_bh` `in_flight` counter of `BlockBackend` device remains with value 1, which prevents `AIO_WAIT_WHILE_UNLOCKED(NULL, bdrv_drain_all_poll());` loop from exiting +6. So QEMU stays in `bdrv_drain_all_begin` method + +Now why `in_flight` counter does not go to zero in point 5? + +Below is a call diagram for TRIM command. For example, consider processing of 2 blocks. + + + +s can be seen from the diagram `in_flight` counter of BlockBackend at first increments at start of command in `ide_issue_trim`, and next in `blk_aio_prwv` before start of coroutine. But for second and next blocks we get into BH method `blk_aio_complete_bh` and before decrementing `in_flight` we call `acb->common.cb` callback, that is in fact `ide_issue_trim_cb`, so we incrementing `in_flight` again to value of 3. And decrementing to value of 2 before return from `blk_aio_complete`. + +So, the value of `blk->in_flight` varies in range [2..3] during block processing. + +Now consider the situation when map cache invalidation request is received during a block processing in TRIM command. Below is a call diagram for this situation. + + + +In this example we get invalidation request before second block processing. Our BlockBackend device run into quiesce mode, and we yielding the coroutine in `blk_wait_while_drained`, decrementing `in_flight` counter from 3 to 2. Second decrement is made in `blk_aio_complete` (2 to 1). + +And now we get in situation, when we not scheduling any block processing methods, as they must be called later from `bdrv_drain_all_end`, and on the other hand, `bdrv_drain_all_poll` always returns true, as we have non-zero `in_flight` counter on one of BlockBackend devices. + +As one of possible solutions i try to call `blk_set_disable_request_queuing(s->blk, true);` in `ide_issue_trim` and corresponding `blk_set_disable_request_queuing(blk, false);` in `ide_trim_bh_cb`. Looks like it solves the problem, so TRIM command always process completely, as is ignore quiesce mode and not do coroutine yielding. But i think is not optimal. + +I try also remove incrementing and decrementing of `in_flight` counter in `ide_issue_trim` and `ide_trim_bh_cb`, so value of counter varies in range [1..2] during block processing. This also works, but i started to get warings like `Locked DMA mapping while invalidating mapcache!`, as TRIM command probably uses map cache and is not completed before actual map cache invalidation. +Steps to reproduce: +1. Run virtual machine +2. Run progrms, work with files, etc. +Additional information: +QEMU trace logs. Enabled trace events: handle_ioreq, ide_dma_cb, dma_blk_io, dma_blk_cb, dma_complete, qemu_coroutime_yield. + +Log of TRIM command without freeze excerpt: + +``` +… +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0x1f4 data=0x0 count=1 size=1 +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0x1f5 data=0x0 count=1 size=1 +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0x1f7 data=0x6 count=1 size=1 +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0xc160 data=0x1 count=1 size=1 +ide_dma_cb IDEState 0x5559d513ff98; sector_num=0 n=1 cmd=DMA TRIM +dma_blk_io dbs=0x5559d5c6f350 bs=0x5559d513ff98 offset=0 to_dev=1 +dma_blk_cb dbs=0x5559d5c6f350 ret=0 +dma_blk_cb dbs=0x5559d5c6f350 ret=0 +dma_complete dbs=0x5559d5c6f350 ret=0 cb=0x5559d1585620 +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=1 df=0 ptr=0 port=0xc162 data=0x0 count=1 size=1 +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=1 df=0 ptr=0 port=0xc162 data=0x0 count=1 size=1 +handle_ioreq I/O=0x7ffc51d5e160 type=0 dir=0 df=0 ptr=0 port=0xc160 data=0x0 count=1 size=1 +… +``` + +Log of TRIM command with freeze: + +``` +… +handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4 +handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4 +handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4 +handle_ioreq I/O=0x7ffc52722ae0 type=0 dir=0 df=0 ptr=0 port=0xc160 data=0x1 count=1 size=1 +ide_dma_cb IDEState 0x55c76faccf98; sector_num=0 n=1 cmd=DMA TRIM +dma_blk_io dbs=0x55c770425b50 bs=0x55c76faccf98 offset=0 to_dev=1 +dma_blk_cb dbs=0x55c770425b50 ret=0 +handle_ioreq I/O=0x7ffc52722ae0 type=8 dir=0 df=0 ptr=0 port=0x0 data=0xffffffffffffffff count=0 size=4 +qemu_coroutine_yield from 0x55c76f4207f0 to 0x7f7fb099e0c0 +[end of log, no more events] +``` diff --git a/results/classifier/118/review/2047 b/results/classifier/118/review/2047 new file mode 100644 index 000000000..8be19cf4d --- /dev/null +++ b/results/classifier/118/review/2047 @@ -0,0 +1,63 @@ +architecture: 0.832 +arm: 0.807 +device: 0.801 +semantic: 0.747 +graphic: 0.596 +performance: 0.498 +ppc: 0.476 +virtual: 0.455 +files: 0.441 +network: 0.437 +permissions: 0.418 +register: 0.365 +boot: 0.299 +debug: 0.299 +TCG: 0.287 +mistranslation: 0.282 +vnc: 0.224 +socket: 0.209 +risc-v: 0.191 +x86: 0.182 +peripherals: 0.172 +i386: 0.162 +PID: 0.111 +assembly: 0.074 +VMM: 0.053 +KVM: 0.044 +hypervisor: 0.044 +user-level: 0.044 +kernel: 0.038 +-------------------- +register: 0.165 +files: 0.060 +TCG: 0.040 +virtual: 0.017 +semantic: 0.013 +network: 0.011 +risc-v: 0.006 +device: 0.004 +VMM: 0.004 +architecture: 0.003 +peripherals: 0.003 +kernel: 0.003 +user-level: 0.003 +boot: 0.002 +debug: 0.002 +graphic: 0.002 +arm: 0.002 +assembly: 0.001 +PID: 0.001 +permissions: 0.001 +hypervisor: 0.001 +KVM: 0.001 +socket: 0.001 +ppc: 0.001 +vnc: 0.001 +performance: 0.001 +i386: 0.000 +x86: 0.000 +mistranslation: 0.000 + +Support of LibVF.IO - vendor neutral GPU multiplexing tool driven by YAML & VFIO. +Additional information: +Git: https://github.com/Arc-Compute/LibVF.IO/tree/master/ diff --git a/results/classifier/118/review/2054889 b/results/classifier/118/review/2054889 new file mode 100644 index 000000000..ba1fbf124 --- /dev/null +++ b/results/classifier/118/review/2054889 @@ -0,0 +1,113 @@ +architecture: 0.915 +peripherals: 0.882 +permissions: 0.858 +hypervisor: 0.845 +arm: 0.840 +device: 0.839 +socket: 0.833 +register: 0.832 +PID: 0.824 +files: 0.810 +performance: 0.809 +ppc: 0.797 +mistranslation: 0.791 +network: 0.776 +user-level: 0.747 +semantic: 0.739 +x86: 0.701 +risc-v: 0.691 +boot: 0.679 +graphic: 0.667 +assembly: 0.659 +debug: 0.656 +kernel: 0.625 +vnc: 0.605 +TCG: 0.583 +virtual: 0.572 +i386: 0.505 +VMM: 0.477 +KVM: 0.454 +-------------------- +peripherals: 0.043 +files: 0.040 +device: 0.039 +x86: 0.038 +TCG: 0.026 +debug: 0.025 +virtual: 0.024 +PID: 0.019 +hypervisor: 0.018 +semantic: 0.013 +user-level: 0.013 +kernel: 0.009 +register: 0.008 +i386: 0.007 +VMM: 0.006 +boot: 0.006 +risc-v: 0.005 +architecture: 0.004 +permissions: 0.003 +performance: 0.003 +network: 0.002 +assembly: 0.002 +socket: 0.002 +graphic: 0.002 +arm: 0.002 +ppc: 0.001 +vnc: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +pcap streams are text files which insert 0xD in Windows version + +Since Windows text files use CRLFs for all \n, the Windows version of QEMU inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP files. + +Starting at line 275 in hw/usb/bus (https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/bus.c?ref_type=heads#L275), the file is opened as text instead of binary. + +I think the following patch would fix the issue: + if (dev->pcap_filename) { +- int fd = qemu_open_old(dev->pcap_filename, O_CREAT | O_WRONLY | O_TRUNC, 0666); ++ int fd = qemu_open_old(dev->pcap_filename, O_CREAT | O_WRONLY | O_TRUNC | O_BINARY, 0666); + if (fd < 0) { + error_setg(errp, "open %s failed", dev->pcap_filename); + usb_qdev_unrealize(qdev); + return; + } +- dev->pcap = fdopen(fd, "w"); ++ dev->pcap = fdopen(fd, "wb"); + usb_pcap_init(dev->pcap); + } + +To show an example, when using a very common protocol to USB disks, the BBB protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10) command (implemented at https://gitlab.com/qemu-project/qemu/-/blob/master/hw/scsi/scsi-disk.c#L2068) will have a command block length of 10 (0xA). When this 10-byte command (part of the 31-byte CBW) is placed into the PCAP file, the Windows file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a 32-byte CBW. + +Actual CBW: + 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC............ + 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. + +PCAP CBW + 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............ + 0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. + +I believe simply opening the PCAP file as BINARY instead of TEXT will fix this issue. + +Thank you. + +Hi Benjamin, + +QEMU bug tracker is on GitLab: +https://gitlab.com/qemu-project/qemu/-/issues + +But instead of re-opening the issue there, since you +already figured the problem, do you mind directly post +your patch? See guidelines there: +https://www.qemu.org/docs/master/devel/submitting-a-patch.html + +Thanks! + +Phil. + +I have sent a patch as directed. I hope it is correctly done. + +Thank you. +Ben + diff --git a/results/classifier/118/review/208 b/results/classifier/118/review/208 new file mode 100644 index 000000000..19125a09d --- /dev/null +++ b/results/classifier/118/review/208 @@ -0,0 +1,61 @@ +architecture: 0.844 +device: 0.695 +performance: 0.617 +arm: 0.438 +graphic: 0.396 +i386: 0.257 +virtual: 0.255 +x86: 0.239 +semantic: 0.222 +boot: 0.221 +network: 0.209 +user-level: 0.207 +permissions: 0.186 +mistranslation: 0.146 +PID: 0.106 +peripherals: 0.056 +debug: 0.047 +register: 0.037 +ppc: 0.036 +assembly: 0.031 +files: 0.028 +TCG: 0.026 +hypervisor: 0.026 +socket: 0.020 +KVM: 0.019 +risc-v: 0.008 +VMM: 0.007 +vnc: 0.006 +kernel: 0.003 +-------------------- +user-level: 0.520 +virtual: 0.226 +network: 0.030 +register: 0.027 +files: 0.021 +semantic: 0.010 +performance: 0.009 +x86: 0.007 +assembly: 0.004 +device: 0.004 +i386: 0.003 +boot: 0.002 +arm: 0.002 +ppc: 0.002 +socket: 0.002 +PID: 0.001 +VMM: 0.001 +peripherals: 0.001 +graphic: 0.001 +vnc: 0.001 +TCG: 0.001 +risc-v: 0.001 +kernel: 0.001 +debug: 0.001 +KVM: 0.001 +architecture: 0.000 +hypervisor: 0.000 +permissions: 0.000 +mistranslation: 0.000 + +Write a new, asynchronous qmp-shell TUI diff --git a/results/classifier/118/review/2089 b/results/classifier/118/review/2089 new file mode 100644 index 000000000..16665bd69 --- /dev/null +++ b/results/classifier/118/review/2089 @@ -0,0 +1,87 @@ +architecture: 0.971 +semantic: 0.855 +graphic: 0.833 +device: 0.746 +arm: 0.697 +ppc: 0.597 +permissions: 0.553 +kernel: 0.535 +hypervisor: 0.503 +vnc: 0.500 +performance: 0.482 +assembly: 0.466 +files: 0.446 +network: 0.405 +PID: 0.385 +TCG: 0.368 +socket: 0.335 +VMM: 0.256 +debug: 0.246 +register: 0.208 +boot: 0.172 +peripherals: 0.165 +x86: 0.138 +risc-v: 0.134 +mistranslation: 0.117 +user-level: 0.113 +KVM: 0.086 +virtual: 0.038 +i386: 0.034 +-------------------- +arm: 0.935 +assembly: 0.297 +architecture: 0.221 +kernel: 0.077 +files: 0.075 +TCG: 0.067 +virtual: 0.057 +register: 0.039 +hypervisor: 0.033 +performance: 0.020 +device: 0.013 +PID: 0.010 +debug: 0.010 +VMM: 0.008 +semantic: 0.006 +risc-v: 0.004 +network: 0.004 +boot: 0.003 +user-level: 0.003 +peripherals: 0.003 +mistranslation: 0.002 +KVM: 0.001 +graphic: 0.001 +socket: 0.001 +vnc: 0.001 +permissions: 0.001 +ppc: 0.001 +x86: 0.000 +i386: 0.000 + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/118/review/211 b/results/classifier/118/review/211 new file mode 100644 index 000000000..2df750cc9 --- /dev/null +++ b/results/classifier/118/review/211 @@ -0,0 +1,61 @@ +architecture: 0.868 +peripherals: 0.766 +device: 0.763 +arm: 0.667 +performance: 0.511 +network: 0.363 +semantic: 0.288 +kernel: 0.264 +graphic: 0.252 +assembly: 0.225 +permissions: 0.206 +ppc: 0.195 +boot: 0.154 +TCG: 0.132 +debug: 0.123 +VMM: 0.114 +vnc: 0.109 +mistranslation: 0.100 +virtual: 0.077 +PID: 0.069 +register: 0.067 +x86: 0.049 +user-level: 0.037 +socket: 0.035 +hypervisor: 0.033 +i386: 0.027 +risc-v: 0.026 +files: 0.015 +KVM: 0.007 +-------------------- +hypervisor: 0.950 +virtual: 0.919 +debug: 0.245 +kernel: 0.094 +architecture: 0.041 +files: 0.035 +register: 0.025 +TCG: 0.021 +ppc: 0.020 +permissions: 0.019 +KVM: 0.015 +semantic: 0.014 +user-level: 0.013 +VMM: 0.012 +arm: 0.009 +performance: 0.007 +assembly: 0.006 +device: 0.004 +PID: 0.003 +graphic: 0.003 +boot: 0.001 +risc-v: 0.001 +socket: 0.001 +peripherals: 0.001 +network: 0.000 +vnc: 0.000 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-aarch64-static segfault if /proc not mounted inside chroot diff --git a/results/classifier/118/review/2123 b/results/classifier/118/review/2123 new file mode 100644 index 000000000..27def85de --- /dev/null +++ b/results/classifier/118/review/2123 @@ -0,0 +1,91 @@ +architecture: 0.826 +graphic: 0.818 +semantic: 0.778 +device: 0.724 +performance: 0.683 +vnc: 0.670 +risc-v: 0.626 +mistranslation: 0.614 +ppc: 0.584 +network: 0.574 +kernel: 0.541 +debug: 0.534 +register: 0.504 +boot: 0.489 +PID: 0.418 +permissions: 0.400 +arm: 0.384 +socket: 0.376 +user-level: 0.354 +peripherals: 0.348 +virtual: 0.299 +VMM: 0.286 +TCG: 0.236 +x86: 0.224 +i386: 0.191 +hypervisor: 0.185 +files: 0.171 +KVM: 0.046 +assembly: 0.022 +-------------------- +user-level: 0.598 +virtual: 0.176 +debug: 0.169 +hypervisor: 0.112 +PID: 0.093 +TCG: 0.028 +register: 0.022 +files: 0.018 +arm: 0.008 +semantic: 0.006 +performance: 0.003 +boot: 0.003 +kernel: 0.003 +architecture: 0.002 +device: 0.002 +peripherals: 0.001 +network: 0.001 +graphic: 0.001 +permissions: 0.001 +assembly: 0.001 +risc-v: 0.001 +socket: 0.001 +x86: 0.001 +ppc: 0.001 +mistranslation: 0.000 +VMM: 0.000 +vnc: 0.000 +i386: 0.000 +KVM: 0.000 + +Invalid subprocess commands spawns successfully when running under QEMU +Description of problem: +When executing a subprocess from with a non-existing command EQMU still spawns a process. + +Consider this small rust program for instance: +```rust +use std::process::Command; + +fn main() { + match Command::new("thisdoesnotexist").spawn() { + Ok(child) => { + println!("Child process id is {}", child.id()); + } + Err(_) => { + println!("This should happen"); + } + } +} +``` + +**Executing with `qemu-aarch64`:** +```shell +qemu-aarch64 ./rust-app +Child process id is 20182 +``` + +**Executing regularly:** +```shell +./rust-app +This should happen +``` diff --git a/results/classifier/118/review/2130 b/results/classifier/118/review/2130 new file mode 100644 index 000000000..0ca71ca46 --- /dev/null +++ b/results/classifier/118/review/2130 @@ -0,0 +1,61 @@ +mistranslation: 0.980 +virtual: 0.439 +performance: 0.432 +semantic: 0.396 +graphic: 0.234 +device: 0.188 +architecture: 0.180 +debug: 0.168 +KVM: 0.144 +vnc: 0.118 +i386: 0.112 +user-level: 0.111 +VMM: 0.105 +x86: 0.105 +register: 0.096 +permissions: 0.093 +PID: 0.091 +TCG: 0.081 +ppc: 0.079 +network: 0.074 +peripherals: 0.074 +assembly: 0.070 +boot: 0.064 +risc-v: 0.058 +files: 0.054 +socket: 0.052 +kernel: 0.023 +hypervisor: 0.014 +arm: 0.008 +-------------------- +semantic: 0.140 +virtual: 0.079 +user-level: 0.060 +assembly: 0.028 +debug: 0.025 +kernel: 0.018 +files: 0.013 +KVM: 0.009 +boot: 0.007 +ppc: 0.006 +performance: 0.006 +VMM: 0.005 +device: 0.004 +x86: 0.004 +TCG: 0.003 +risc-v: 0.003 +i386: 0.002 +network: 0.002 +graphic: 0.002 +peripherals: 0.001 +hypervisor: 0.001 +arm: 0.001 +register: 0.001 +PID: 0.001 +mistranslation: 0.001 +vnc: 0.001 +socket: 0.001 +permissions: 0.000 +architecture: 0.000 + +latest code missing "singlestep" diff --git a/results/classifier/118/review/2141 b/results/classifier/118/review/2141 new file mode 100644 index 000000000..0ee2ca78c --- /dev/null +++ b/results/classifier/118/review/2141 @@ -0,0 +1,84 @@ +ppc: 0.933 +architecture: 0.903 +graphic: 0.843 +device: 0.835 +performance: 0.786 +peripherals: 0.720 +semantic: 0.678 +debug: 0.623 +user-level: 0.583 +hypervisor: 0.567 +i386: 0.520 +register: 0.483 +network: 0.461 +permissions: 0.437 +arm: 0.431 +mistranslation: 0.422 +PID: 0.376 +x86: 0.355 +assembly: 0.318 +boot: 0.313 +virtual: 0.306 +VMM: 0.257 +vnc: 0.255 +socket: 0.250 +files: 0.236 +TCG: 0.178 +kernel: 0.151 +KVM: 0.144 +risc-v: 0.143 +-------------------- +virtual: 0.722 +x86: 0.587 +files: 0.125 +VMM: 0.105 +user-level: 0.096 +debug: 0.087 +register: 0.087 +semantic: 0.069 +hypervisor: 0.057 +PID: 0.050 +kernel: 0.045 +device: 0.044 +socket: 0.043 +assembly: 0.037 +TCG: 0.034 +architecture: 0.031 +boot: 0.020 +performance: 0.018 +network: 0.015 +KVM: 0.014 +peripherals: 0.013 +vnc: 0.011 +permissions: 0.011 +i386: 0.009 +graphic: 0.009 +arm: 0.004 +risc-v: 0.004 +ppc: 0.001 +mistranslation: 0.001 + +Output of "-cpu help" for sparc does not clearly indicate the valid input for "-cpu" option. +Description of problem: +The output of the "-cpu help" does not indicate clearly what the input to a "-cpu" command can be. +Steps to reproduce: +1. ./qemu-system-sparc -cpu help +Additional information: +``` +% ./qemu-system-sparc -cpu help +Sparc Fujitsu MB86904 IU 04000000 FPU 00080000 MMU 04000000 NWINS 8 +Sparc Fujitsu MB86907 IU 05000000 FPU 00080000 MMU 05000000 NWINS 8 +Sparc TI MicroSparc I IU 41000000 FPU 00080000 MMU 41000000 NWINS 7 -fsmuld +Sparc TI MicroSparc II IU 42000000 FPU 00080000 MMU 02000000 NWINS 8 +Sparc TI MicroSparc IIep IU 42000000 FPU 00080000 MMU 04000000 NWINS 8 +Sparc TI SuperSparc 40 IU 41000000 FPU 00000000 MMU 00000800 NWINS 8 +Sparc TI SuperSparc 50 IU 40000000 FPU 00000000 MMU 01000800 NWINS 8 +Sparc TI SuperSparc 51 IU 40000000 FPU 00000000 MMU 01000000 NWINS 8 +Sparc TI SuperSparc 60 IU 40000000 FPU 00000000 MMU 01000800 NWINS 8 +Sparc TI SuperSparc 61 IU 44000000 FPU 00000000 MMU 01000000 NWINS 8 +Sparc TI SuperSparc II IU 40000000 FPU 00000000 MMU 08000000 NWINS 8 +Sparc LEON2 IU f2000000 FPU 00080000 MMU f2000000 NWINS 8 +Sparc LEON3 IU f3000000 FPU 00080000 MMU f3000000 NWINS 8 +``` +It's unclear from this output whether an appropriate choice for a -cpu option is +"Sparc Fujitsu MB86904", "Sparc Fujitsu MB86904", "Fujitsu MB86904", "MB86904", or even something else like "FJI, MB86904" diff --git a/results/classifier/118/review/2142 b/results/classifier/118/review/2142 new file mode 100644 index 000000000..5447d8a7f --- /dev/null +++ b/results/classifier/118/review/2142 @@ -0,0 +1,61 @@ +architecture: 0.826 +performance: 0.755 +graphic: 0.732 +device: 0.690 +virtual: 0.651 +debug: 0.569 +mistranslation: 0.500 +semantic: 0.419 +i386: 0.418 +x86: 0.356 +boot: 0.264 +arm: 0.178 +hypervisor: 0.173 +TCG: 0.162 +user-level: 0.150 +ppc: 0.124 +register: 0.102 +vnc: 0.067 +VMM: 0.052 +permissions: 0.044 +assembly: 0.039 +PID: 0.037 +socket: 0.034 +kernel: 0.020 +risc-v: 0.015 +network: 0.013 +peripherals: 0.011 +files: 0.009 +KVM: 0.007 +-------------------- +virtual: 0.945 +VMM: 0.342 +hypervisor: 0.263 +debug: 0.176 +PID: 0.172 +KVM: 0.094 +kernel: 0.078 +assembly: 0.066 +x86: 0.028 +semantic: 0.023 +architecture: 0.018 +arm: 0.014 +socket: 0.013 +files: 0.011 +performance: 0.009 +user-level: 0.008 +TCG: 0.007 +device: 0.007 +register: 0.006 +ppc: 0.006 +risc-v: 0.005 +graphic: 0.003 +boot: 0.003 +peripherals: 0.001 +i386: 0.001 +permissions: 0.001 +network: 0.001 +mistranslation: 0.001 +vnc: 0.000 + +`-machine microvm -cpu host` crashes when guest attempts to check CPUID SGX bits diff --git a/results/classifier/118/review/2159 b/results/classifier/118/review/2159 new file mode 100644 index 000000000..d02e9be53 --- /dev/null +++ b/results/classifier/118/review/2159 @@ -0,0 +1,237 @@ +risc-v: 0.900 +graphic: 0.891 +register: 0.890 +permissions: 0.878 +peripherals: 0.876 +TCG: 0.875 +virtual: 0.874 +boot: 0.873 +architecture: 0.872 +device: 0.864 +VMM: 0.859 +debug: 0.849 +x86: 0.841 +hypervisor: 0.841 +PID: 0.835 +user-level: 0.835 +network: 0.833 +assembly: 0.832 +kernel: 0.832 +arm: 0.826 +ppc: 0.824 +socket: 0.822 +files: 0.806 +vnc: 0.806 +semantic: 0.800 +performance: 0.781 +KVM: 0.765 +mistranslation: 0.673 +i386: 0.598 +-------------------- +debug: 0.968 +TCG: 0.794 +x86: 0.733 +hypervisor: 0.439 +virtual: 0.096 +performance: 0.036 +i386: 0.033 +files: 0.027 +PID: 0.019 +user-level: 0.012 +device: 0.011 +register: 0.010 +kernel: 0.009 +architecture: 0.007 +semantic: 0.006 +boot: 0.006 +network: 0.004 +assembly: 0.004 +graphic: 0.004 +permissions: 0.002 +socket: 0.002 +peripherals: 0.001 +VMM: 0.001 +risc-v: 0.001 +vnc: 0.001 +KVM: 0.001 +mistranslation: 0.001 +ppc: 0.001 +arm: 0.000 + +qemu-system-x86_64 crashes in temp_load (tcg) on i686 host +Description of problem: +qemu crashes early +Steps to reproduce: +1. compile qemu git (commit commit 5d1fc614413b10dd94858b07a1b2e26b1aa0296c (origin/master, origin/HEAD) +) with line +../configure --prefix=/usr --enable-virglrenderer --libdir=lib --audio-drv-list=alsa,oss --enable-opengl --extra-cflags="-I/usr/X11R7/include -O2 -march=i686 -mtune=native -m32 -Wno-maybe-uninitialized -Wno-nested-externs -Wno-implicit-function-declaration" --disable-werror + +2. setarch i686 ninja (kernel is x86_64 on host) +3. try to boot 64-bit x86 Salix/Slackel (Slackware live images) +Additional information: +``` + gdb x86_64-softmmu/qemu-system-x86_64 +GNU gdb (GDB) 11.2 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "i586-slackware-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from x86_64-softmmu/qemu-system-x86_64... +warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". +To enable execution of this file add + add-auto-load-safe-path /dev/shm/qemu/.gdbinit +line to your configuration file "/root/.config/gdb/gdbinit". +To completely disable this security protection add + set auto-load safe-path / +line to your configuration file "/root/.config/gdb/gdbinit". +For more information about this security protection see the +--Type <RET> for more, q to quit, c to continue without paging-- +"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: + info "(gdb)Auto-loading safe path" +(gdb) r -m 1000 -cdrom /home/guest/ISO/sla +slackellive64-openbox-7.7.1.iso slackware-8.0-install-d1.iso +(gdb) r -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso +Starting program: /dev/shm/qemu/build/x86_64-softmmu/qemu-system-x86_64 -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". +[New Thread 0xf3e79b00 (LWP 27354)] +[New Thread 0xf2f09b00 (LWP 27355)] +[New Thread 0xb1917b00 (LWP 27356)] +[New Thread 0xaf60cb00 (LWP 27357)] +[Thread 0xaf60cb00 (LWP 27357) exited] +[New Thread 0xaf60cb00 (LWP 27358)] +[New Thread 0xaec86b00 (LWP 27359)] +[Thread 0xaf60cb00 (LWP 27358) exited] +[Thread 0xaec86b00 (LWP 27359) exited] +[New Thread 0xaec86b00 (LWP 27360)] +[New Thread 0xaf60cb00 (LWP 27361)] +[Thread 0xaec86b00 (LWP 27360) exited] +[Thread 0xaf60cb00 (LWP 27361) exited] +[Thread 0xf2f09b00 (LWP 27355) exited] + +Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0xb1917b00 (LWP 27356)] +0x56d08a95 in temp_load (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441 +4441 tcg_out_ld(s, ts->type, reg, ts->mem_base->reg, ts->mem_offset); +(gdb) bt full +#0 0x56d08a95 in temp_load + (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441 + reg = TCG_REG_ECX + __func__ = "temp_load" +#1 0x56d0fe23 in tcg_reg_alloc_op (op=<optimized out>, s=<optimized out>) + at ../tcg/tcg.c:4881 + i_required_regs = <optimized out> + copyto_new_reg = false + ts2 = <optimized out> + i1 = <optimized out> + i_preferred_regs = <optimized out> + allocate_new_reg = <optimized out> + i2 = <optimized out> + i = 0 + new_args = + {1, 5, 2852, 0, 64, 0, 0, 1467284236, 4149882880, 2829350448, 1, 1456305553, 4149882880, 2969568784, 2969568920, 2969568944} + arg_life = <optimized out> + i_allocated_regs = <optimized out> + nb_oargs = <optimized out> + arg = <optimized out> + const_args = +--Type <RET> for more, q to quit, c to continue without paging-- + {0, 0, 0, 0, 1, 1, 1467284236, -1315870200, 1487331864, -1069806704, 0, 1467284236, 1456520351, 1489883472, 2, -1325347776} + k = <optimized out> + arg_ct = <optimized out> + o_allocated_regs = <optimized out> + nb_iargs = <optimized out> + reg = <optimized out> + ts = 0xb1001f40 + op_cond = <optimized out> + opc = <optimized out> + i = <optimized out> + start_words = <optimized out> + num_insns = <optimized out> + op = <optimized out> + __PRETTY_FUNCTION__ = "tcg_gen_code" +#2 tcg_gen_code + (s=<optimized out>, tb=<optimized out>, pc_start=<optimized out>) + at ../tcg/tcg.c:6216 + opc = <optimized out> + i = <optimized out> + start_words = <optimized out> + num_insns = <optimized out> + op = <optimized out> +--Type <RET> for more, q to quit, c to continue without paging-- + __PRETTY_FUNCTION__ = "tcg_gen_code" +#3 0x56af0118 in setjmp_gen_code + (env=env@entry=0x57afab90, tb=tb@entry=0xf0b7d580 <code_gen_buffer+8389982>, pc=18446744072243800976, host_pc=0xc03c0b90, max_insns=0xb1916acc, ti=<optimized out>) at ../accel/tcg/translate-all.c:284 + ret = <optimized out> + __PRETTY_FUNCTION__ = "setjmp_gen_code" +#4 0x56af06e2 in tb_gen_code + (cpu=0x57af8860, pc=18446744072243800976, cs_base=0, flags=4244144, cflags=<optimized out>) at ../accel/tcg/translate-all.c:359 + env = 0x57afab90 + tb = 0xf0b7d580 <code_gen_buffer+8389982> + existing_tb = <optimized out> + phys_pc = 245525392 + phys_p2 = <optimized out> + gen_code_buf = 0xf0b7d600 <code_gen_buffer+8390110> "‹]ш…Ы\017Њр" + gen_code_size = <optimized out> + search_size = <optimized out> + max_insns = 64 + host_pc = 0xc03c0b90 + __PRETTY_FUNCTION__ = "tb_gen_code" + __func__ = "tb_gen_code" +#5 0x56ae75bd in cpu_exec_loop +--Type <RET> for more, q to quit, c to continue without paging-- + (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24) + at ../accel/tcg/cpu-exec.c:982 + jc = <optimized out> + h = <optimized out> + tb = 0x0 + flags = <optimized out> + cflags = 4278321152 + pc = <optimized out> + cs_base = <optimized out> + last_tb = <optimized out> + tb_exit = 0 + ret = <optimized out> +#6 0x56ae7a70 in cpu_exec_setjmp + (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24) + at ../accel/tcg/cpu-exec.c:1028 +#7 0x56ae83a8 in cpu_exec (cpu=<optimized out>) + at ../accel/tcg/cpu-exec.c:1054 + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} + _rcu_read_auto = 0x1 +#8 0x56b0ff5e in tcg_cpu_exec (cpu=0x57af8860) + at ../accel/tcg/tcg-accel-ops.c:76 + ret = <optimized out> +--Type <RET> for more, q to quit, c to continue without paging-- + __PRETTY_FUNCTION__ = "tcg_cpu_exec" +#9 0x56b10a47 in rr_cpu_thread_fn (arg=<optimized out>) + at ../accel/tcg/tcg-accel-ops-rr.c:261 + r = <optimized out> + cpu_budget = <optimized out> + force_rcu = + {notify = 0x56b106e0 <rr_force_rcu>, node = {le_next = 0x0, le_prev = 0xb19179b0}} + cpu = 0x57af8860 + __PRETTY_FUNCTION__ = "rr_cpu_thread_fn" +#10 0x56cc77e5 in qemu_thread_start (args=0x57b51ce0) + at ../util/qemu-thread-posix.c:541 + __cancel_buf = + {__cancel_jmp_buf = {{__cancel_jmp_buf = {1467284236, 1471487200, 1471152128, -1315869272, 1617656260, -631423478}, __mask_was_saved = 0}}, __pad = {0xb1916d64, 0x0, 0x0, 0x0}} + __cancel_routine = 0x56cc7840 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + start_routine = 0x56b10818 <rr_cpu_thread_fn> + arg = 0x57af8860 + r = <optimized out> +#11 0xf63d5328 in start_thread () at /lib/libpthread.so.0 +#12 0xf604ef06 in clone () at /lib/libc.so.6 +``` diff --git a/results/classifier/118/review/2160 b/results/classifier/118/review/2160 new file mode 100644 index 000000000..266ef3cee --- /dev/null +++ b/results/classifier/118/review/2160 @@ -0,0 +1,61 @@ +architecture: 0.906 +device: 0.862 +network: 0.743 +socket: 0.696 +debug: 0.691 +performance: 0.675 +graphic: 0.549 +peripherals: 0.548 +arm: 0.468 +files: 0.357 +register: 0.250 +semantic: 0.227 +mistranslation: 0.153 +boot: 0.141 +PID: 0.120 +virtual: 0.096 +hypervisor: 0.090 +ppc: 0.082 +i386: 0.072 +permissions: 0.070 +vnc: 0.061 +VMM: 0.045 +kernel: 0.040 +x86: 0.040 +TCG: 0.032 +user-level: 0.024 +assembly: 0.010 +risc-v: 0.007 +KVM: 0.002 +-------------------- +i386: 0.869 +x86: 0.786 +virtual: 0.056 +architecture: 0.040 +TCG: 0.032 +debug: 0.027 +files: 0.025 +user-level: 0.022 +performance: 0.022 +semantic: 0.019 +PID: 0.008 +boot: 0.007 +assembly: 0.007 +register: 0.006 +peripherals: 0.005 +kernel: 0.004 +VMM: 0.004 +socket: 0.004 +hypervisor: 0.004 +network: 0.004 +device: 0.003 +graphic: 0.002 +ppc: 0.002 +KVM: 0.002 +permissions: 0.001 +risc-v: 0.001 +vnc: 0.000 +mistranslation: 0.000 +arm: 0.000 + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-libusb" diff --git a/results/classifier/118/review/2177 b/results/classifier/118/review/2177 new file mode 100644 index 000000000..7105a0311 --- /dev/null +++ b/results/classifier/118/review/2177 @@ -0,0 +1,61 @@ +architecture: 0.889 +device: 0.844 +performance: 0.748 +network: 0.739 +debug: 0.660 +graphic: 0.586 +arm: 0.440 +files: 0.388 +socket: 0.256 +register: 0.255 +semantic: 0.247 +mistranslation: 0.175 +boot: 0.140 +PID: 0.135 +peripherals: 0.134 +hypervisor: 0.122 +TCG: 0.106 +virtual: 0.093 +i386: 0.082 +ppc: 0.080 +vnc: 0.069 +permissions: 0.064 +kernel: 0.045 +x86: 0.045 +VMM: 0.044 +user-level: 0.027 +risc-v: 0.010 +assembly: 0.007 +KVM: 0.003 +-------------------- +i386: 0.800 +x86: 0.767 +architecture: 0.061 +virtual: 0.060 +TCG: 0.057 +debug: 0.030 +performance: 0.024 +files: 0.022 +semantic: 0.021 +user-level: 0.020 +kernel: 0.013 +assembly: 0.012 +boot: 0.006 +PID: 0.006 +hypervisor: 0.006 +device: 0.005 +register: 0.004 +network: 0.004 +socket: 0.003 +VMM: 0.003 +graphic: 0.002 +ppc: 0.002 +KVM: 0.001 +permissions: 0.001 +peripherals: 0.001 +risc-v: 0.000 +mistranslation: 0.000 +vnc: 0.000 +arm: 0.000 + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-dtc" diff --git a/results/classifier/118/review/2184 b/results/classifier/118/review/2184 new file mode 100644 index 000000000..631721c2f --- /dev/null +++ b/results/classifier/118/review/2184 @@ -0,0 +1,113 @@ +mistranslation: 0.831 +graphic: 0.829 +user-level: 0.801 +permissions: 0.769 +peripherals: 0.765 +risc-v: 0.761 +debug: 0.758 +register: 0.750 +VMM: 0.745 +hypervisor: 0.743 +ppc: 0.739 +semantic: 0.735 +KVM: 0.730 +assembly: 0.724 +performance: 0.723 +TCG: 0.719 +architecture: 0.715 +device: 0.713 +virtual: 0.691 +PID: 0.688 +vnc: 0.674 +network: 0.673 +arm: 0.669 +kernel: 0.664 +socket: 0.661 +files: 0.653 +x86: 0.646 +boot: 0.642 +i386: 0.625 +-------------------- +debug: 0.450 +TCG: 0.169 +kernel: 0.123 +files: 0.086 +device: 0.081 +virtual: 0.063 +register: 0.054 +PID: 0.052 +user-level: 0.048 +peripherals: 0.026 +hypervisor: 0.024 +semantic: 0.020 +x86: 0.017 +architecture: 0.016 +socket: 0.012 +VMM: 0.010 +risc-v: 0.009 +performance: 0.009 +boot: 0.007 +i386: 0.007 +assembly: 0.006 +arm: 0.004 +vnc: 0.004 +network: 0.004 +permissions: 0.003 +graphic: 0.003 +ppc: 0.003 +KVM: 0.001 +mistranslation: 0.001 + +NVMe differences between QEMU v4.1.0 and v8.2.1 +Description of problem: +We are currently upgrading QEMU from v4.1.0 to v8.2.1. In order to keep compatibility between the two QEMUs, we are adding ``-machine pc-q35-4.1``. One of our test is to ensure a guest that has hibernated on the previous QEMU is able to resume on the new one. + +When resuming, we get the following error: + +``` +[ 7.394709] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 +[ 7.926188] nvme nvme0: Device not ready; aborting reset, CSTS=0x1 +[ 7.938235] Read-error on swap-device (259:0:4874880) +[ 7.938237] Read-error on swap-device (259:0:4620184) +[ 7.938240] Read-error on swap-device (259:0:5536464) +[ 7.938311] Read-error on swap-device (259:0:5006840) +[ 7.938316] Read-error on swap-device (259:0:5791888) +[ 7.938386] Read-error on swap-device (259:0:6579728) +[ 7.938391] Read-error on swap-device (259:0:5536680) +[ 7.938431] Read-error on swap-device (259:0:4877384) +[ 7.938434] Read-error on swap-device (259:0:5005376) +[ 7.938457] Read-error on swap-device (259:0:5269328) +[ 7.939200] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 7.939267] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 7.946359] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.063186] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.069556] Aborting journal on device nvme0n1p1-8. +[ 8.069561] Buffer I/O error on dev nvme0n1p1, logical block 262144, lost sync page write +[ 8.069564] JBD2: Error -5 detected when updating journal superblock for nvme0n1p1-8. +[ 8.081218] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.081242] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write +[ 8.081247] EXT4-fs (nvme0n1p1): I/O error while writing superblock +[ 8.147693] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.147753] Buffer I/O error on dev nvme0n1p1, logical block 0, lost sync page write +[ 8.163478] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.174179] EXT4-fs (nvme0n1p1): I/O error while writing superblock +[ 8.198741] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0 +[ 8.214483] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:1: reading directory lblock 0 +[ 8.230322] EXT4-fs error (device nvme0n1p1): __ext4_find_entry:1611: inode #1561: comm kworker/u8:2: reading directory lblock 0 +[ 8.246249] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b +[ 8.246269] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246291] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246336] Core dump to |/usr/share/apport/apport pipe failed +[ 8.246826] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249232] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249320] Core dump to |/usr/share/apport/apport pipe failed +[ 8.249880] Core dump to |/usr/share/apport/apport pipe failed +``` + +Digging throw the NVMe code, I have found one [patch](https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04202.html) changing the BAR layout. It doesn't look like there is a way to select the previous BAR layout. + +When selecting the ``-machine``, I was expecting that the underlying HW (including devices) would not change. Can you clarify if hibernating from QEMU A and resuming to QEMU B is meant to be supported? +Steps to reproduce: +1. Start the guest with qemu v4.1.0 and an NVME disk +2. Hibernate the OS +3. Resume the guest with qemu v8.2.1 diff --git a/results/classifier/118/review/2194 b/results/classifier/118/review/2194 new file mode 100644 index 000000000..803c7ec97 --- /dev/null +++ b/results/classifier/118/review/2194 @@ -0,0 +1,154 @@ +user-level: 0.811 +peripherals: 0.805 +permissions: 0.803 +device: 0.786 +graphic: 0.781 +risc-v: 0.778 +virtual: 0.777 +register: 0.776 +assembly: 0.764 +architecture: 0.764 +PID: 0.762 +kernel: 0.756 +KVM: 0.746 +arm: 0.738 +semantic: 0.735 +ppc: 0.728 +hypervisor: 0.716 +TCG: 0.712 +network: 0.691 +boot: 0.690 +VMM: 0.676 +performance: 0.644 +files: 0.626 +vnc: 0.613 +debug: 0.610 +mistranslation: 0.593 +x86: 0.480 +socket: 0.478 +i386: 0.387 +-------------------- +boot: 0.989 +kernel: 0.984 +virtual: 0.933 +hypervisor: 0.846 +debug: 0.481 +PID: 0.364 +user-level: 0.306 +socket: 0.258 +x86: 0.253 +vnc: 0.246 +TCG: 0.194 +VMM: 0.188 +register: 0.184 +device: 0.150 +assembly: 0.107 +semantic: 0.089 +KVM: 0.063 +files: 0.060 +performance: 0.027 +architecture: 0.024 +network: 0.023 +risc-v: 0.022 +graphic: 0.014 +mistranslation: 0.007 +peripherals: 0.007 +permissions: 0.005 +ppc: 0.005 +i386: 0.002 +arm: 0.002 + +qemu-system-mips64el loongson3-virt fails to complete boot +Description of problem: +I try to install Debian 12 using the netboot kernel (6.1.0) and initrd: +``` +NETBOOT=http://ftp.debian.org/debian/dists/stable/main/installer-mips64el/current/images/loongson-3/netboot +wget $NETBOOT/initrd.gz +wget $NETBOOT/vmlinuz-6.1.0-18-loongson-3 -O vmlinuz +qemu-img create -f qcow2 disk.qcow2 30G +``` + +Then I boot the installer: +``` +qemu-system-mips64el \ + -machine loongson3-virt -cpu Loongson-3A1000 -smp 4 -m 6G -nographic \ + -kernel vmlinuz -initrd initrd.gz \ + -drive file=disk.qcow2,if=none,id=drive-virtio-disk0 \ + -device virtio-blk-pci,drive=drive-virtio-disk0 \ + -append "root=/dev/sda1" +``` + +The boot stops after this: +``` +[ 0.000000] Linux version 6.1.0-18-loongson-3 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 6.1.76-1 (2024-02-01) +[ 0.000000] Firmware: Coherent DMA: on +[ 0.000000] CpuClock = 800000000 +[ 0.000000] The bridge chip is VIRTUAL +[ 0.000000] CP0_Config3: CP0 16.3 (0x80) +[ 0.000000] CP0_PageGrain: CP0 5.1 (0x20000000) +[ 0.000000] NUMA: Discovered 4 cpus on 1 nodes +[ 0.000000] Node 0, mem_type:1 [0x0000000000000000], 0x000000000f000000 bytes usable +[ 0.000000] Node 0, mem_type:2 [0x0000000090000000], 0x0000000170000000 bytes usable +[ 0.000000] Node0's addrspace_offset is 0x0 +[ 0.000000] Node0: start_pfn=0x0, end_pfn=0x80000 +[ 0.000000] NUMA: set cpumask cpu 0 on node 0 +[ 0.000000] NUMA: set cpumask cpu 1 on node 0 +[ 0.000000] NUMA: set cpumask cpu 2 on node 0 +[ 0.000000] NUMA: set cpumask cpu 3 on node 0 +[ 0.000000] printk: bootconsole [early0] enabled +[ 0.000000] CPU0 revision is: 00006305 (ICT Loongson-3) +[ 0.000000] FPU revision is: 00770501 +[ 0.000000] MIPS: machine is loongson,loongson64v-4core-virtio +[ 0.000000] Initial ramdisk at: 0x9800000004000000 (28553950 bytes) +[ 0.000000] software IO TLB: area num 1. +[ 0.000000] software IO TLB: mapped [mem 0x0000000005b3c000-0x0000000009b3c000] (64MB) +[ 0.000000] DMI not present or invalid. +[ 0.000000] Detected 4 available CPU(s) +[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. +[ 0.000000] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes +[ 0.000000] Unified victim cache 0kB direct mapped, linesize 0 bytes. +[ 0.000000] Unified secondary cache 4096kB 4-way, linesize 32 bytes. +[ 0.000000] Zone ranges: +[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff] +[ 0.000000] Normal [mem 0x0000000100000000-0x00000001ffffffff] +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000000000-0x000000000effffff] +[ 0.000000] node 0: [mem 0x0000000090000000-0x00000001ffffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff] +[ 0.000000] On node 0, zone DMA32: 1024 pages in unavailable ranges +[ 0.000000] percpu: Embedded 13 pages/cpu s170800 r8192 d34000 u212992 +[ 0.000000] Fallback order for Node 0: 0 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 390660 +[ 0.000000] Policy zone: Normal +[ 0.000000] Kernel command line: rd_start=0xffffffff84000000 rd_size=28553950 root=/dev/sda1 nokaslr +[ 0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space. +[ 0.000000] Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes, linear) +[ 0.000000] mem auto-init: stack:all(zero), heap alloc:on, heap free:off +[ 0.000000] Memory: 2183328K/6275072K available (11247K kernel code, 1773K rwdata, 3152K rodata, 2688K init, 547K bss, 184208K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 +[ 0.000000] ftrace: allocating 32150 entries in 32 pages +[ 0.000000] ftrace: allocated 32 pages with 1 groups +[ 0.000000] trace event string verifier disabled +[ 0.000000] rcu: Preemptible hierarchical RCU implementation. +[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4. +[ 0.000000] Trampoline variant of Tasks RCU enabled. +[ 0.000000] Rude variant of Tasks RCU enabled. +[ 0.000000] Tracing variant of Tasks RCU enabled. +[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. +[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 +[ 0.000000] NR_IRQS: 320 +[ 0.000000] ISA Bridge: /bus@10000000/isa@18000000 +[ 0.000000] IO 0x0000000018000000..0x0000000018003fff -> 0x0000000000000000 +[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. +[ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 4778151116 ns +[ 0.000072] sched_clock: 32 bits at 400MHz, resolution 2ns, wraps every 5368709118ns +[ 0.002813] Console: colour dummy device 80x25 +[ 0.003195] printk: console [tty0] enabled +[ 0.005876] printk: bootconsole [early0] disabled +``` + +Then, nothing happens. The qemu process uses 100% CPU on the host. + +I tried with `-smp 1` and got the same result. diff --git a/results/classifier/118/review/2195 b/results/classifier/118/review/2195 new file mode 100644 index 000000000..01f4299e7 --- /dev/null +++ b/results/classifier/118/review/2195 @@ -0,0 +1,99 @@ +x86: 0.983 +architecture: 0.926 +TCG: 0.925 +device: 0.910 +permissions: 0.851 +graphic: 0.851 +kernel: 0.826 +semantic: 0.763 +ppc: 0.752 +performance: 0.733 +PID: 0.724 +debug: 0.721 +vnc: 0.688 +socket: 0.673 +risc-v: 0.648 +register: 0.635 +files: 0.621 +user-level: 0.619 +mistranslation: 0.595 +peripherals: 0.553 +boot: 0.453 +VMM: 0.442 +virtual: 0.423 +hypervisor: 0.384 +network: 0.370 +arm: 0.347 +i386: 0.329 +KVM: 0.267 +assembly: 0.254 +-------------------- +debug: 0.942 +x86: 0.801 +virtual: 0.719 +kernel: 0.520 +register: 0.489 +assembly: 0.372 +TCG: 0.275 +hypervisor: 0.238 +user-level: 0.136 +KVM: 0.122 +performance: 0.047 +files: 0.024 +PID: 0.016 +architecture: 0.010 +semantic: 0.010 +device: 0.007 +boot: 0.005 +risc-v: 0.004 +VMM: 0.004 +graphic: 0.003 +ppc: 0.003 +socket: 0.002 +peripherals: 0.001 +network: 0.001 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.001 +i386: 0.000 + +qemu-system-x86_64 : cannot resume from S3 suspend for Q35 + OVMF +Description of problem: +There is a specific configuration where the resume from S3 does not work: + +- Q35 machine + OVMF.fd (https://retrage.github.io/edk2-nightly/) +- TCG acceleration (it works when --accel=kvm is set) + +The output at resume is: + +``` +!!!! X64 Exception Type - 05(#BR - BOUND Range Exceeded) CPU Apic ID - 00000000 !!!! +RIP - 0000000000006237, CS - 0000000000000028, RFLAGS - 0000000000000002 +RAX - 0000000080000027, RCX - 0000000000000000, RDX - 0000000000000000 +RBX - 0000000099200000, RSP - 000000000FF96236, RBP - 000000000FF96320 +RSI - 000000000F74E000, RDI - 0000000000833F31 +R8 - 0000002800000000, R9 - 0000000000000000, R10 - 000000000FF968F0 +R11 - 0000000000828B30, R12 - 000000000FF9ACD0, R13 - 000000000F76B000 +R14 - 000000000F76A000, R15 - 0000000000000000 +DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 +GS - 0000000000000030, SS - 0000000000000030 +CR0 - 0000000080000033, CR2 - 0000000000000000, CR3 - 000000000F75B000 +CR4 - 0000000000000668, CR8 - 0000000000000000 +DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 +DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 +GDTR - 0000000000833DE0 0000000000000047, LDTR - 0000000000000000 +IDTR - 000000000FF97D70 000000000000021F, TR - 0000000000000000 +FXSAVE_STATE - 000000000FF95E90 +!!!! Can't find image information. !!!! +``` + +After bisecting, this is caused by commit : 18a536f1f8d6222e562f59179e837fdfd8b92718 If i revert this comment, the resume works nicely. + +I used a script to generate a tiny initrd to test but i think the problem can be reproduced with any guest kernel + rootfs. I also verify that this problem can be reproduced with different host kernels (6.5) than the one i used (6.8) +Steps to reproduce: +1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img +2. Run qemu and drop into shell +3. Put machine into S3 (echo mem \> /sys/power/state) +4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup) +5. The machine does not resume correctly diff --git a/results/classifier/118/review/2197 b/results/classifier/118/review/2197 new file mode 100644 index 000000000..8a03a5325 --- /dev/null +++ b/results/classifier/118/review/2197 @@ -0,0 +1,118 @@ +architecture: 0.856 +mistranslation: 0.853 +graphic: 0.815 +socket: 0.794 +ppc: 0.696 +device: 0.681 +performance: 0.655 +kernel: 0.591 +debug: 0.432 +peripherals: 0.422 +PID: 0.394 +network: 0.366 +semantic: 0.360 +user-level: 0.334 +assembly: 0.330 +boot: 0.302 +permissions: 0.290 +register: 0.235 +vnc: 0.233 +TCG: 0.166 +hypervisor: 0.153 +VMM: 0.137 +risc-v: 0.129 +x86: 0.126 +arm: 0.118 +i386: 0.081 +files: 0.055 +KVM: 0.040 +virtual: 0.004 +-------------------- +user-level: 0.701 +network: 0.397 +virtual: 0.390 +ppc: 0.091 +i386: 0.090 +socket: 0.048 +x86: 0.041 +TCG: 0.028 +debug: 0.025 +arm: 0.020 +architecture: 0.012 +PID: 0.012 +risc-v: 0.007 +KVM: 0.005 +kernel: 0.005 +performance: 0.004 +files: 0.003 +semantic: 0.003 +device: 0.003 +register: 0.003 +boot: 0.002 +permissions: 0.001 +graphic: 0.001 +mistranslation: 0.001 +vnc: 0.001 +VMM: 0.001 +hypervisor: 0.001 +peripherals: 0.001 +assembly: 0.000 + +qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly +Description of problem: +Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**. + +When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero. +Steps to reproduce: +1. compile this code to binary executable: +```c +#include <unistd.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <linux/if_alg.h> + +int create_alg(const char *alg) +{ + struct sockaddr_alg salg; + int sk; + + sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0); + if (sk < 0) + return -1; + + memset(&salg, 0, sizeof(salg)); + salg.salg_family = AF_ALG; + strcpy((char *) salg.salg_type, "hash"); + strcpy((char *) salg.salg_name, alg); + + if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) { + close(sk); + return -1; + } + + return sk; +} + +int main() { + int fd = create_alg("hmac(sha1)"); + char buf[10]; + int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0); + if(ret < 0){ + perror("err"); + } + else{ + puts("SUCCESS!"); + } + return 0; +} +``` +2. run it in any qemu user space emulator + +On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`. + +The error is neither informative nor intuitive and could be misleading for user programs. +Additional information: +I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing. diff --git a/results/classifier/118/review/2214 b/results/classifier/118/review/2214 new file mode 100644 index 000000000..af478e2f6 --- /dev/null +++ b/results/classifier/118/review/2214 @@ -0,0 +1,61 @@ +mistranslation: 0.899 +device: 0.886 +semantic: 0.611 +network: 0.587 +architecture: 0.507 +user-level: 0.444 +performance: 0.416 +virtual: 0.369 +debug: 0.271 +register: 0.219 +graphic: 0.198 +hypervisor: 0.185 +arm: 0.175 +ppc: 0.138 +i386: 0.133 +vnc: 0.108 +risc-v: 0.099 +permissions: 0.097 +x86: 0.092 +peripherals: 0.085 +boot: 0.054 +assembly: 0.048 +socket: 0.046 +files: 0.042 +PID: 0.023 +TCG: 0.021 +kernel: 0.018 +VMM: 0.010 +KVM: 0.007 +-------------------- +debug: 0.969 +virtual: 0.938 +user-level: 0.653 +hypervisor: 0.104 +semantic: 0.061 +x86: 0.044 +performance: 0.026 +i386: 0.021 +files: 0.013 +device: 0.011 +assembly: 0.010 +peripherals: 0.006 +register: 0.004 +kernel: 0.004 +arm: 0.003 +boot: 0.002 +graphic: 0.002 +architecture: 0.002 +network: 0.002 +TCG: 0.002 +ppc: 0.001 +VMM: 0.001 +PID: 0.001 +permissions: 0.001 +socket: 0.001 +mistranslation: 0.001 +vnc: 0.000 +risc-v: 0.000 +KVM: 0.000 + +QEMU gdbstub does not report SIGALRM diff --git a/results/classifier/118/review/222 b/results/classifier/118/review/222 new file mode 100644 index 000000000..9653c762d --- /dev/null +++ b/results/classifier/118/review/222 @@ -0,0 +1,61 @@ +mistranslation: 0.958 +PID: 0.792 +peripherals: 0.639 +performance: 0.634 +device: 0.565 +semantic: 0.510 +graphic: 0.501 +virtual: 0.355 +architecture: 0.341 +network: 0.284 +arm: 0.267 +i386: 0.265 +ppc: 0.238 +hypervisor: 0.236 +VMM: 0.196 +x86: 0.194 +user-level: 0.189 +KVM: 0.169 +kernel: 0.166 +debug: 0.134 +socket: 0.133 +boot: 0.126 +TCG: 0.119 +vnc: 0.107 +assembly: 0.101 +risc-v: 0.099 +permissions: 0.093 +register: 0.087 +files: 0.032 +-------------------- +PID: 0.852 +kernel: 0.738 +debug: 0.148 +hypervisor: 0.079 +files: 0.051 +ppc: 0.043 +virtual: 0.034 +performance: 0.033 +x86: 0.023 +TCG: 0.022 +VMM: 0.019 +semantic: 0.019 +KVM: 0.013 +permissions: 0.009 +risc-v: 0.008 +device: 0.008 +user-level: 0.006 +architecture: 0.006 +peripherals: 0.006 +i386: 0.004 +register: 0.004 +vnc: 0.004 +boot: 0.004 +assembly: 0.003 +socket: 0.003 +arm: 0.002 +mistranslation: 0.002 +graphic: 0.001 +network: 0.001 + +Reading /proc/self/task/<pid>/maps is not remapped to the target diff --git a/results/classifier/118/review/2232 b/results/classifier/118/review/2232 new file mode 100644 index 000000000..9c80f27ab --- /dev/null +++ b/results/classifier/118/review/2232 @@ -0,0 +1,61 @@ +mistranslation: 0.880 +virtual: 0.753 +device: 0.574 +semantic: 0.415 +graphic: 0.391 +vnc: 0.388 +network: 0.353 +VMM: 0.345 +user-level: 0.344 +architecture: 0.335 +register: 0.335 +ppc: 0.331 +performance: 0.313 +PID: 0.297 +files: 0.282 +TCG: 0.276 +permissions: 0.274 +arm: 0.234 +risc-v: 0.232 +debug: 0.201 +socket: 0.150 +boot: 0.132 +KVM: 0.124 +assembly: 0.102 +kernel: 0.102 +peripherals: 0.098 +i386: 0.096 +x86: 0.080 +hypervisor: 0.035 +-------------------- +virtual: 0.890 +files: 0.820 +user-level: 0.658 +semantic: 0.188 +hypervisor: 0.102 +debug: 0.019 +device: 0.016 +x86: 0.013 +permissions: 0.009 +KVM: 0.008 +graphic: 0.006 +register: 0.004 +boot: 0.004 +i386: 0.004 +arm: 0.004 +ppc: 0.003 +assembly: 0.002 +PID: 0.002 +TCG: 0.002 +performance: 0.001 +mistranslation: 0.001 +VMM: 0.001 +architecture: 0.001 +peripherals: 0.000 +network: 0.000 +risc-v: 0.000 +socket: 0.000 +vnc: 0.000 +kernel: 0.000 + +ui/qemu.desktop is nonconformant with the desktop entry specification diff --git a/results/classifier/118/review/2236 b/results/classifier/118/review/2236 new file mode 100644 index 000000000..d5480d2d8 --- /dev/null +++ b/results/classifier/118/review/2236 @@ -0,0 +1,61 @@ +architecture: 0.931 +mistranslation: 0.853 +ppc: 0.756 +device: 0.695 +performance: 0.575 +semantic: 0.355 +graphic: 0.313 +boot: 0.250 +register: 0.235 +risc-v: 0.224 +permissions: 0.214 +vnc: 0.186 +network: 0.154 +arm: 0.148 +debug: 0.115 +i386: 0.104 +assembly: 0.097 +PID: 0.090 +VMM: 0.070 +socket: 0.063 +TCG: 0.062 +virtual: 0.059 +user-level: 0.045 +kernel: 0.030 +KVM: 0.025 +files: 0.024 +peripherals: 0.023 +hypervisor: 0.022 +x86: 0.008 +-------------------- +ppc: 0.972 +architecture: 0.819 +register: 0.071 +device: 0.057 +socket: 0.033 +assembly: 0.030 +files: 0.028 +semantic: 0.025 +PID: 0.017 +peripherals: 0.015 +arm: 0.015 +virtual: 0.014 +kernel: 0.014 +debug: 0.011 +TCG: 0.010 +performance: 0.009 +i386: 0.008 +VMM: 0.007 +user-level: 0.007 +boot: 0.005 +x86: 0.003 +KVM: 0.003 +graphic: 0.002 +risc-v: 0.002 +hypervisor: 0.002 +mistranslation: 0.002 +vnc: 0.001 +network: 0.001 +permissions: 0.001 + +32-bit PPC CPUs are reported based on 64-bit base CPU diff --git a/results/classifier/118/review/2248 b/results/classifier/118/review/2248 new file mode 100644 index 000000000..eb6e6576c --- /dev/null +++ b/results/classifier/118/review/2248 @@ -0,0 +1,96 @@ +architecture: 0.939 +graphic: 0.837 +assembly: 0.815 +device: 0.776 +ppc: 0.771 +kernel: 0.751 +TCG: 0.746 +vnc: 0.746 +network: 0.743 +socket: 0.741 +VMM: 0.731 +register: 0.723 +files: 0.722 +performance: 0.702 +PID: 0.693 +risc-v: 0.685 +permissions: 0.675 +hypervisor: 0.661 +arm: 0.642 +x86: 0.631 +debug: 0.622 +user-level: 0.616 +i386: 0.589 +peripherals: 0.573 +boot: 0.547 +semantic: 0.539 +KVM: 0.475 +mistranslation: 0.466 +virtual: 0.343 +-------------------- +debug: 0.522 +performance: 0.340 +TCG: 0.169 +files: 0.138 +hypervisor: 0.090 +architecture: 0.045 +kernel: 0.033 +register: 0.019 +assembly: 0.017 +PID: 0.015 +user-level: 0.015 +virtual: 0.012 +network: 0.009 +device: 0.006 +semantic: 0.005 +VMM: 0.004 +boot: 0.003 +risc-v: 0.002 +peripherals: 0.002 +graphic: 0.002 +socket: 0.001 +mistranslation: 0.001 +permissions: 0.001 +arm: 0.001 +vnc: 0.000 +KVM: 0.000 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. diff --git a/results/classifier/118/review/2253 b/results/classifier/118/review/2253 new file mode 100644 index 000000000..bfc9e90fb --- /dev/null +++ b/results/classifier/118/review/2253 @@ -0,0 +1,61 @@ +semantic: 0.818 +network: 0.768 +performance: 0.754 +device: 0.753 +hypervisor: 0.659 +mistranslation: 0.600 +graphic: 0.574 +peripherals: 0.554 +permissions: 0.401 +architecture: 0.365 +arm: 0.359 +socket: 0.299 +files: 0.280 +debug: 0.273 +register: 0.254 +vnc: 0.233 +user-level: 0.222 +virtual: 0.219 +kernel: 0.188 +assembly: 0.182 +VMM: 0.166 +boot: 0.159 +TCG: 0.150 +risc-v: 0.109 +PID: 0.098 +ppc: 0.096 +i386: 0.076 +x86: 0.076 +KVM: 0.051 +-------------------- +network: 0.993 +files: 0.545 +x86: 0.273 +debug: 0.148 +kernel: 0.124 +i386: 0.066 +device: 0.065 +virtual: 0.033 +assembly: 0.027 +performance: 0.026 +socket: 0.026 +ppc: 0.025 +user-level: 0.019 +TCG: 0.019 +semantic: 0.013 +hypervisor: 0.010 +VMM: 0.009 +peripherals: 0.008 +KVM: 0.007 +PID: 0.005 +architecture: 0.005 +risc-v: 0.004 +vnc: 0.004 +boot: 0.003 +arm: 0.003 +graphic: 0.002 +register: 0.002 +permissions: 0.001 +mistranslation: 0.001 + +NO_CAST.INTEGER_OVERFLOW in /hw/net/eepro100.c diff --git a/results/classifier/118/review/2265 b/results/classifier/118/review/2265 new file mode 100644 index 000000000..35172295b --- /dev/null +++ b/results/classifier/118/review/2265 @@ -0,0 +1,108 @@ +risc-v: 0.908 +user-level: 0.897 +peripherals: 0.875 +permissions: 0.853 +VMM: 0.849 +hypervisor: 0.845 +KVM: 0.840 +ppc: 0.834 +vnc: 0.831 +x86: 0.831 +mistranslation: 0.827 +TCG: 0.814 +graphic: 0.798 +register: 0.785 +architecture: 0.763 +virtual: 0.760 +performance: 0.755 +debug: 0.750 +arm: 0.743 +files: 0.739 +semantic: 0.729 +device: 0.720 +socket: 0.718 +i386: 0.714 +assembly: 0.707 +network: 0.702 +boot: 0.695 +kernel: 0.664 +PID: 0.636 +-------------------- +x86: 0.992 +debug: 0.965 +hypervisor: 0.772 +user-level: 0.353 +assembly: 0.352 +kernel: 0.230 +TCG: 0.103 +PID: 0.062 +performance: 0.058 +register: 0.045 +files: 0.044 +virtual: 0.016 +semantic: 0.012 +VMM: 0.011 +architecture: 0.007 +device: 0.005 +boot: 0.004 +network: 0.004 +risc-v: 0.003 +KVM: 0.003 +peripherals: 0.003 +graphic: 0.002 +permissions: 0.002 +socket: 0.002 +ppc: 0.001 +vnc: 0.001 +mistranslation: 0.001 +arm: 0.000 +i386: 0.000 + +qemu-system-x86_64 crash creating snapshot +Description of problem: +I'm facing a crash in qemu-system-x86_64.\ +I crash because bs->children.lh_first is null and QLIST_NEXT try dereference the pointer. It triggers a SIGSEGV\ +The manner to reproduce is too complex to give on gitlab and the version is not recent. (I reproduce also with 7.1)\ + +here is the stack: + +(gdb) p bs->children\ +$1 = {lh_first = 0x0}\ +(gdb)\ +(gdb) p child\ +$2 = (BdrvChild *) 0x0\ +(gdb)\ + if (bs->implicit) {\ + /* For implicit nodes, just copy everything from the single child */\ + child = QLIST_FIRST(&bs->children);\ +----->> assert(QLIST_NEXT(child, next) == NULL);\ + pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),\ + + +#0 bdrv_refresh_filename (bs=0x562927927000) at ../qemu-6.2.0/block.c:7525\ +#1 0x000056292527dd97 in bdrv_block_device_info (blk=blk@entry=0x0, bs=bs@entry=0x562927927000, flat=flat@entry=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block/qapi.c:58\ +#2 0x00005629252470c0 in bdrv_named_nodes_list (flat=true, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/block.c:5863\ +#3 0x000056292523da7e in qmp_query_named_block_nodes (has_flat=<optimized out>, flat=<optimized out>, errp=errp@entry=0x7ffcef7e8318) at ../qemu-6.2.0/blockdev.c:2935\ +#4 0x0000562925301ebd in qmp_marshal_query_named_block_nodes (args=<optimized out>, ret=0x7fc833c83e88, errp=0x7fc833c83e80) at qapi/qapi-commands-block-core.c:423\ +#5 0x0000562925344129 in do_qmp_dispatch_bh (opaque=0x7fc833c83e90) at ../qemu-6.2.0/qapi/qmp-dispatch.c:129 +#6 0x000056292535ecf5 in aio_bh_call (bh=0x5629295ab560) at ../qemu-6.2.0/util/async.c:141\ +#7 aio_bh_poll (ctx=ctx@entry=0x5629276c93e0) at ../qemu-6.2.0/util/async.c:169\ +#8 0x000056292534cf9e in aio_dispatch (ctx=0x5629276c93e0) at ../qemu-6.2.0/util/aio-posix.c:381\ +#9 0x000056292535eb9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311\ +#10 0x00007fc8351cafee in g_match_info_fetch_pos () from /lib/x86_64-linux-gnu/libglib-2.0.so.0\ +#11 0x00007fc800000000 in ?? ()\ +#12 0x000003a05cb8b408 in ?? ()\ +#13 0x0000000000000000 in ?? ()\ + +The case lh_first = 0x0 seems to be common, but never when bs->implicit is true. bs->implicit seems to be switch to true by another thread.\ +Because the qemu version and the system are too old, I'm not expecting a patch, I'm just requesting an opinion.\ + +I fixed the problem by just doing:\ +child = QLIST_FIRST(&bs->children);\ +if (bs->implicit && (child != NULL)) {\ + assert(QLIST_NEXT(child, next) == NULL);\ + ....\ +}\ +I don't have the qemu knowledge to evaluate it and consequences.\ +Is there anyone who have any idea ?\ +Thank you very much.\ diff --git a/results/classifier/118/review/2287 b/results/classifier/118/review/2287 new file mode 100644 index 000000000..493e870d4 --- /dev/null +++ b/results/classifier/118/review/2287 @@ -0,0 +1,89 @@ +user-level: 0.850 +permissions: 0.837 +debug: 0.823 +performance: 0.782 +register: 0.762 +virtual: 0.754 +semantic: 0.752 +arm: 0.747 +architecture: 0.747 +peripherals: 0.739 +device: 0.720 +mistranslation: 0.717 +hypervisor: 0.717 +i386: 0.713 +kernel: 0.705 +assembly: 0.696 +vnc: 0.691 +graphic: 0.691 +files: 0.690 +PID: 0.681 +KVM: 0.681 +ppc: 0.675 +boot: 0.666 +risc-v: 0.621 +TCG: 0.621 +socket: 0.617 +network: 0.616 +VMM: 0.596 +x86: 0.524 +-------------------- +hypervisor: 0.916 +x86: 0.888 +boot: 0.876 +virtual: 0.800 +TCG: 0.772 +debug: 0.543 +socket: 0.052 +kernel: 0.043 +files: 0.036 +user-level: 0.028 +register: 0.018 +PID: 0.014 +device: 0.011 +performance: 0.008 +semantic: 0.007 +VMM: 0.005 +i386: 0.004 +assembly: 0.004 +risc-v: 0.004 +architecture: 0.003 +graphic: 0.003 +network: 0.002 +KVM: 0.002 +ppc: 0.002 +peripherals: 0.002 +permissions: 0.002 +vnc: 0.002 +mistranslation: 0.001 +arm: 0.001 + +whpx, on booting win98, qemu crashes with Failed to emulate PortIO access with EmulatorReturnStatus: 2 +Description of problem: +Q) What is the correct command line arguments to boot win98se with ```accel whpx``` + +The above given command line crashes partway through the win98se boot process before the desktop shows up +``` +Windows Hypervisor Platform accelerator is operational +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: warning: GLib-GIO: Failed to open application manifest `C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AppxManifest.xml' for package #34 (`Microsoft.MicrosoftEdge_44.19041.1266.0_neutral__8wekyb3d8bbwe'): error code 0x2 +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to emulate PortIO access with EmulatorReturnStatus: 2 +C:\vol\scoop_01\SCOOPG\apps\qemu\current\qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor +``` +Steps to reproduce: +1. Finish a complete win98 install using ```-machine type=pc,accel=tcg -cpu qemu64``` + ```qemu-system-x86_64 -machine type=pc,accel=tcg -cpu qemu64 -smp "sockets=1,cores=1,threads=1" -m 512 -nodefaults -bios bios-256k.bin -rtc base=localtime -display sdl,gl=on -device VGA,vgamem_mb=128 -audiodev dsound,id=snd1 -device adlib,audiodev=snd1 -audiodev dsound,id=snd2 -device ac97,audiodev=snd2 -boot c -drive index=0,if=ide,media=disk,format=vhdx,file="F:\Win98m40_sys.vhdx" -drive index=1,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_01.vhdx" -drive index=3,if=ide,media=disk,format=vhdx,file="F:\Win98m40_data_02.vhdx"``` + With all guestos-win98-drivers installed the win98 seems to work satisfactorily. + Using vga driver from https://github.com/JHRobotics/vmdisp9x/releases +2. now change processor to ```-cpu core2duo```, it boots . This does not seem to matter, bug exists even with qemu64 +3. now change accel to ```-machine type=pc,accel=whpx ```, qemu crashes partway into boot before bringing up desktop. + with or without ```kernel-irqchip=off``` does not matter + with or without cpu arguments ```,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-time``` also does not matter +4. Setting back to ```-machine type=pc,accel=tcg -cpu core2duo``` restores bootable win98se. +Additional information: +- [target/i386/whpx/whpx-all.c#L920](https://gitlab.com/qemu-project/qemu/-/blob/a12214d1c4204d2f51d8724993b8dfcf50dd7d94/target/i386/whpx/whpx-all.c#L920) +- The part of the OS bootsequence, which includes the Win98/DOS boot menu, scandisk, etc. works fine. Its possible to boot to DOS mode and run DOS commands. The crash happens when into the win.com Win98SE boot sequence just before it can bring up the GUI desktop. +- qemu crashes even if in the win98/DOS bootmenu, selection is made to boot into ```safe-mode```, which is supposed to boot a vanilla 16-color VGA desktop loading minimal drivers. As before, crash happens before GUI desktop is loaded. +- 20220623 Learn.Microsoft WHvEmulatorTryIoEmulation and WHvEmulatorTryMmioEmulation + https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation +- 20220426 Learn.Microsoft WHV_EMULATOR_STATUS + https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatorstatus diff --git a/results/classifier/118/review/2297 b/results/classifier/118/review/2297 new file mode 100644 index 000000000..54168cf64 --- /dev/null +++ b/results/classifier/118/review/2297 @@ -0,0 +1,61 @@ +mistranslation: 0.998 +device: 0.739 +permissions: 0.723 +peripherals: 0.722 +semantic: 0.695 +performance: 0.307 +user-level: 0.294 +graphic: 0.250 +ppc: 0.230 +assembly: 0.222 +debug: 0.206 +architecture: 0.153 +arm: 0.117 +virtual: 0.104 +risc-v: 0.057 +files: 0.045 +boot: 0.038 +i386: 0.030 +VMM: 0.027 +TCG: 0.023 +register: 0.023 +PID: 0.023 +socket: 0.020 +vnc: 0.017 +network: 0.012 +x86: 0.008 +hypervisor: 0.006 +kernel: 0.005 +KVM: 0.005 +-------------------- +debug: 0.104 +semantic: 0.083 +user-level: 0.063 +virtual: 0.062 +device: 0.047 +boot: 0.038 +mistranslation: 0.032 +x86: 0.021 +files: 0.017 +network: 0.015 +kernel: 0.010 +ppc: 0.010 +assembly: 0.008 +register: 0.005 +peripherals: 0.005 +performance: 0.001 +graphic: 0.001 +permissions: 0.001 +TCG: 0.001 +architecture: 0.001 +hypervisor: 0.000 +arm: 0.000 +vnc: 0.000 +VMM: 0.000 +socket: 0.000 +PID: 0.000 +risc-v: 0.000 +i386: 0.000 +KVM: 0.000 + +Incorrect String: PowerMAC (Media Access Control instead of Macintosh) diff --git a/results/classifier/118/review/230 b/results/classifier/118/review/230 new file mode 100644 index 000000000..5b34ad2fe --- /dev/null +++ b/results/classifier/118/review/230 @@ -0,0 +1,61 @@ +mistranslation: 0.948 +device: 0.879 +network: 0.722 +architecture: 0.711 +graphic: 0.681 +arm: 0.524 +performance: 0.482 +semantic: 0.477 +debug: 0.449 +risc-v: 0.413 +vnc: 0.407 +hypervisor: 0.406 +ppc: 0.315 +TCG: 0.259 +peripherals: 0.197 +permissions: 0.183 +i386: 0.181 +assembly: 0.168 +boot: 0.165 +VMM: 0.163 +PID: 0.160 +x86: 0.159 +virtual: 0.158 +user-level: 0.109 +socket: 0.057 +files: 0.045 +register: 0.037 +KVM: 0.031 +kernel: 0.012 +-------------------- +virtual: 0.860 +kernel: 0.847 +debug: 0.788 +user-level: 0.441 +hypervisor: 0.174 +assembly: 0.131 +x86: 0.058 +VMM: 0.046 +TCG: 0.027 +KVM: 0.026 +architecture: 0.023 +semantic: 0.021 +i386: 0.020 +device: 0.020 +risc-v: 0.018 +files: 0.018 +peripherals: 0.012 +performance: 0.009 +ppc: 0.008 +boot: 0.006 +graphic: 0.006 +PID: 0.005 +arm: 0.005 +mistranslation: 0.004 +network: 0.002 +socket: 0.002 +register: 0.001 +vnc: 0.001 +permissions: 0.000 + +Confuse error message in virtio_init_region_cache() diff --git a/results/classifier/118/review/2300 b/results/classifier/118/review/2300 new file mode 100644 index 000000000..297b2b322 --- /dev/null +++ b/results/classifier/118/review/2300 @@ -0,0 +1,61 @@ +architecture: 0.818 +performance: 0.790 +device: 0.644 +permissions: 0.570 +graphic: 0.473 +peripherals: 0.466 +virtual: 0.462 +mistranslation: 0.400 +assembly: 0.317 +semantic: 0.312 +user-level: 0.170 +ppc: 0.153 +register: 0.128 +KVM: 0.119 +debug: 0.118 +x86: 0.108 +network: 0.104 +files: 0.096 +arm: 0.089 +PID: 0.084 +hypervisor: 0.083 +VMM: 0.076 +TCG: 0.062 +socket: 0.055 +i386: 0.051 +boot: 0.049 +vnc: 0.048 +risc-v: 0.030 +kernel: 0.020 +-------------------- +files: 0.711 +x86: 0.699 +kernel: 0.175 +debug: 0.071 +virtual: 0.068 +peripherals: 0.058 +semantic: 0.055 +user-level: 0.037 +KVM: 0.026 +assembly: 0.019 +risc-v: 0.016 +network: 0.014 +ppc: 0.010 +PID: 0.009 +hypervisor: 0.008 +performance: 0.007 +i386: 0.007 +boot: 0.007 +register: 0.006 +arm: 0.005 +VMM: 0.005 +graphic: 0.005 +TCG: 0.004 +device: 0.003 +socket: 0.002 +architecture: 0.002 +permissions: 0.002 +mistranslation: 0.001 +vnc: 0.001 + +Unintialized variable in double_cpdo.c diff --git a/results/classifier/118/review/2303 b/results/classifier/118/review/2303 new file mode 100644 index 000000000..d4300f114 --- /dev/null +++ b/results/classifier/118/review/2303 @@ -0,0 +1,131 @@ +assembly: 0.939 +permissions: 0.905 +graphic: 0.892 +architecture: 0.888 +peripherals: 0.887 +files: 0.870 +virtual: 0.869 +register: 0.869 +performance: 0.868 +device: 0.859 +semantic: 0.856 +debug: 0.848 +vnc: 0.846 +hypervisor: 0.844 +risc-v: 0.843 +KVM: 0.842 +arm: 0.838 +socket: 0.831 +PID: 0.815 +kernel: 0.809 +mistranslation: 0.807 +TCG: 0.796 +user-level: 0.788 +ppc: 0.772 +boot: 0.771 +x86: 0.770 +i386: 0.745 +VMM: 0.715 +network: 0.705 +-------------------- +kernel: 0.939 +debug: 0.282 +files: 0.204 +user-level: 0.204 +hypervisor: 0.203 +x86: 0.142 +virtual: 0.126 +device: 0.097 +KVM: 0.096 +graphic: 0.086 +TCG: 0.074 +ppc: 0.045 +i386: 0.033 +risc-v: 0.024 +VMM: 0.023 +architecture: 0.017 +PID: 0.016 +assembly: 0.009 +register: 0.008 +boot: 0.005 +performance: 0.005 +semantic: 0.005 +peripherals: 0.004 +socket: 0.003 +vnc: 0.003 +arm: 0.003 +permissions: 0.001 +network: 0.001 +mistranslation: 0.001 + +Multiple displays configuration supports +Additional information: +The following patch is a quick "hack" to make it work + +```patch + +From 18ad5058a18fa9f6db2c0c3058e25989908d95bb Mon Sep 17 00:00:00 2001 +From: Sergio Lopez <slp@redhat.com> +Date: Fri, 23 Jun 2023 13:15:15 +0200 +Subject: [PATCH 6/8] HACK: Set static resolutions for the VM + +--- + hw/display/virtio-gpu-base.c | 10 +++++++++- + ui/gtk.c | 6 ++++-- + 2 files changed, 13 insertions(+), 3 deletions(-) + +diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c +index a29f191aa8..b1ccfa17b7 100644 +--- a/hw/display/virtio-gpu-base.c ++++ b/hw/display/virtio-gpu-base.c +@@ -47,6 +47,7 @@ virtio_gpu_base_fill_display_info(VirtIOGPUBase *g, + dpy_info->pmodes[i].enabled = 1; + dpy_info->pmodes[i].r.width = cpu_to_le32(g->req_state[i].width); + dpy_info->pmodes[i].r.height = cpu_to_le32(g->req_state[i].height); ++ fprintf(stderr, "display %d: %dx%d\n", i, dpy_info->pmodes[i].r.width, dpy_info->pmodes[i].r.height); + } + } + } +@@ -63,14 +64,17 @@ static void virtio_gpu_text_update(void *opaque, console_ch_t *chardata) + { + } + ++#if 0 + static void virtio_gpu_notify_event(VirtIOGPUBase *g, uint32_t event_type) + { + g->virtio_config.events_read |= event_type; + virtio_notify_config(&g->parent_obj); + } ++#endif + + static void virtio_gpu_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info) + { ++#if 0 + VirtIOGPUBase *g = opaque; + + if (idx >= g->conf.max_outputs) { +@@ -94,6 +98,7 @@ static void virtio_gpu_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info) + /* send event to guest */ + virtio_gpu_notify_event(g, VIRTIO_GPU_EVENT_DISPLAY); + return; ++#endif + } + + static void +@@ -186,11 +191,14 @@ virtio_gpu_base_device_realize(DeviceState *qdev, + virtio_add_queue(vdev, 16, cursor_cb); + } + +- g->enabled_output_bitmask = 1; ++ g->enabled_output_bitmask = 3; + + g->req_state[0].width = g->conf.xres; + g->req_state[0].height = g->conf.yres; + ++ g->req_state[1].width = 800; ++ g->req_state[1].height = 600; ++ + g->hw_ops = &virtio_gpu_ops; + for (i = 0; i < g->conf.max_outputs; i++) { + g->scanout[i].con = +``` diff --git a/results/classifier/118/review/2330 b/results/classifier/118/review/2330 new file mode 100644 index 000000000..d65a4a85d --- /dev/null +++ b/results/classifier/118/review/2330 @@ -0,0 +1,133 @@ +register: 0.889 +graphic: 0.888 +user-level: 0.854 +mistranslation: 0.833 +virtual: 0.826 +risc-v: 0.822 +permissions: 0.820 +vnc: 0.811 +arm: 0.809 +i386: 0.807 +TCG: 0.800 +device: 0.800 +assembly: 0.796 +architecture: 0.785 +semantic: 0.782 +peripherals: 0.779 +debug: 0.779 +ppc: 0.777 +KVM: 0.771 +performance: 0.766 +VMM: 0.742 +PID: 0.739 +hypervisor: 0.736 +kernel: 0.718 +network: 0.692 +boot: 0.688 +x86: 0.677 +socket: 0.661 +files: 0.554 +-------------------- +x86: 0.841 +kernel: 0.837 +debug: 0.526 +device: 0.474 +peripherals: 0.178 +i386: 0.106 +files: 0.055 +user-level: 0.036 +TCG: 0.026 +assembly: 0.025 +virtual: 0.023 +VMM: 0.017 +hypervisor: 0.016 +semantic: 0.016 +ppc: 0.015 +PID: 0.014 +register: 0.011 +KVM: 0.009 +architecture: 0.009 +performance: 0.009 +arm: 0.009 +boot: 0.005 +risc-v: 0.003 +socket: 0.002 +network: 0.001 +vnc: 0.001 +graphic: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +acpi-erst: divide by zero in make_erst_storage_header() +Description of problem: +When we gives `0` to `record_size` for `acpi-erst` device, below code may triggers divide-by-zero. + +```c +static void make_erst_storage_header(ERSTDeviceState *s) + ... + header->magic = cpu_to_le64(ERST_STORE_MAGIC); + header->record_size = cpu_to_le32(s->default_record_size); + header->version = cpu_to_le16(0x0100); + header->reserved = cpu_to_le16(0x0000); + + /* Compute mapsize */ + mapsz = s->storage_size / s->default_record_size; // devide-by-zero occurs +``` + +`acpi-erst` device refuses invalid value for `record_size` and does appropriate condition check in `check_erst_backend_storage()`, but this check is placed before the function triggering the error when `header->magic` is 0. + +```c +static void check_erst_backend_storage(ERSTDeviceState *s, Error **errp) + ... + /* + * Check if header is uninitialized; HostMemoryBackend inits to 0 + */ + if (le64_to_cpu(header->magic) == 0UL) { + make_erst_storage_header(s); + } + + /* Validity check record_size */ + record_size = le32_to_cpu(header->record_size); + if (!( + (record_size) && /* non zero */ + (record_size >= UEFI_CPER_RECORD_MIN_SIZE) && + (((record_size - 1) & record_size) == 0) && /* is power of 2 */ + (record_size >= 4096) /* PAGE_SIZE */ + )) { + error_setg(errp, "ERST record_size %u is invalid", record_size); + return; + } +``` +Steps to reproduce: +1. make sure `acpi-erst.backing` doesn't exist in current folder. +2. run qemu command. +```bash +./build/qemu-system-i386 -object memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x10000,share=on -device acpi-erst,memdev=erstnvram,record_size=0 +``` +Additional information: +I built qemu from source code with `--enable-sanitizers`, and backtrace is as follows: +```bash +AddressSanitizer:DEADLYSIGNAL +================================================================= +==401519==ERROR: AddressSanitizer: FPE on unknown address 0x55bd0616fd53 (pc 0x55bd0616fd53 bp 0x61f000000e80 sp 0x7fffd16e5d90 T0) + #0 0x55bd0616fd53 in make_erst_storage_header /home/xxx/qemu/build/../hw/acpi/erst.c:401 + #1 0x55bd0616fd53 in check_erst_backend_storage /home/xxx/qemu/build/../hw/acpi/erst.c:431 + #2 0x55bd0616fd53 in erst_realizefn /home/xxx/qemu/build/../hw/acpi/erst.c:973 + #3 0x55bd06268426 in pci_qdev_realize /home/xxx/qemu/build/../hw/pci/pci.c:2093 + #4 0x55bd06557629 in device_set_realized /home/xxx/qemu/build/../hw/core/qdev.c:510 + #5 0x55bd0655ecc8 in property_set_bool /home/xxx/qemu/build/../qom/object.c:2362 + #6 0x55bd0655cec4 in object_property_set /home/xxx/qemu/build/../qom/object.c:1471 + #7 0x55bd06560dec in object_property_set_qobject /home/xxx/qemu/build/../qom/qom-qobject.c:28 + #8 0x55bd0655d30a in object_property_set_bool /home/xxx/qemu/build/../qom/object.c:1541 + #9 0x55bd0632f8cf in qdev_device_add_from_qdict /home/xxx/qemu/build/../system/qdev-monitor.c:719 + #10 0x55bd0632fc91 in qdev_device_add /home/xxx/qemu/build/../system/qdev-monitor.c:738 + #11 0x55bd0633ae7e in device_init_func /home/xxx/qemu/build/../system/vl.c:1203 + #12 0x55bd066e7a50 in qemu_opts_foreach /home/xxx/qemu/build/../util/qemu-option.c:1135 + #13 0x55bd06335421 in qemu_create_cli_devices /home/xxx/qemu/build/../system/vl.c:2640 + #14 0x55bd06335421 in qmp_x_exit_preconfig /home/xxx/qemu/build/../system/vl.c:2709 + #15 0x55bd06338f42 in qemu_init /home/xxx/qemu/build/../system/vl.c:3742 + #16 0x55bd06553e35 in main /home/xxx/qemu/build/../system/main.c:47 + #17 0x7efcdb919d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 + #18 0x7efcdb919e3f in __libc_start_main_impl ../csu/libc-start.c:392 + #19 0x55bd060ecb24 in _start (/home/xxx/qemu/build/qemu-system-i386+0x32db24) +``` diff --git a/results/classifier/118/review/2343 b/results/classifier/118/review/2343 new file mode 100644 index 000000000..515d2ba80 --- /dev/null +++ b/results/classifier/118/review/2343 @@ -0,0 +1,91 @@ +architecture: 0.913 +boot: 0.896 +user-level: 0.871 +device: 0.859 +ppc: 0.850 +debug: 0.838 +socket: 0.837 +graphic: 0.827 +performance: 0.824 +files: 0.820 +semantic: 0.810 +permissions: 0.783 +x86: 0.782 +hypervisor: 0.766 +kernel: 0.758 +vnc: 0.758 +PID: 0.749 +risc-v: 0.742 +i386: 0.739 +network: 0.711 +VMM: 0.695 +register: 0.685 +KVM: 0.645 +virtual: 0.639 +TCG: 0.621 +assembly: 0.581 +peripherals: 0.578 +arm: 0.495 +mistranslation: 0.468 +-------------------- +virtual: 0.806 +boot: 0.368 +debug: 0.203 +hypervisor: 0.166 +kernel: 0.069 +TCG: 0.051 +PID: 0.021 +files: 0.019 +device: 0.015 +register: 0.014 +VMM: 0.008 +architecture: 0.008 +arm: 0.005 +assembly: 0.005 +user-level: 0.004 +peripherals: 0.004 +performance: 0.004 +risc-v: 0.003 +semantic: 0.003 +network: 0.003 +socket: 0.002 +KVM: 0.002 +graphic: 0.001 +vnc: 0.001 +permissions: 0.001 +ppc: 0.001 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +pflash write timeout u-boot@qemu-system-aarch64 +Description of problem: +Emulating the write into flash of environment variables within U-boot is not possible anymore. This works natively in Fedora 39 which has the 8.1.3 qemu version. Stopped working after transitioning to Fedora 40 which currently comes with 8.2.2, also doesn't work with Debian 12 which has 7.2.9. + +The write fails with the following message: + +``` +=> saveenv +Saving Environment to Flash... Un-Protected 2 sectors +Erasing Flash... +.. done +Erased 2 sectors +Writing to Flash... pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +pflash_write: Write to buffer emulation is flawed +Flash buffer write timeout at address 4000000 data ffffffffb64f6361 +Timeout writing to Flash +Protected 2 sectors +Failed (1) +``` +Steps to reproduce: +1. Download or build u-boot for aarch64 qemu. You can extract from u-boot-qemu debian package https://packages.debian.org/unstable/u-boot-qemu . +2. `truncate -s 64m varstore.img` +3. `qemu-system-aarch64 -machine virt -cpu cortex-a35 -nographic -smp 2 -m 1G -bios u-boot.bin -drive if=pflash,format=raw,file=varstore.img,readonly=off,index=1 -d guest_errors,unimp` +Additional information: +After building versions 8.1.3 and 8.1.4 I found both were working fine regartheless the host OS, the issue was introduced in 8.1.5. +After inspecting commits history I drop the following commit [hw/pflash: implement update buffer for block writes (hash:fcc79f2e09550b0461792491965fe202ed2219ae)](https://gitlab.com/qemu-project/qemu/-/commit/fcc79f2e09550b0461792491965fe202ed2219ae) rebuilt and the issue was gone. +I then recheck all non working versions and both versions 8.2.2 and 7.2.9 also have this commit, this explains why it also doesn't work. +I attached a trace running with v8.1.5 and v8.1.5 with drop commit. +[v8.1.5.log](/uploads/04aa0e24e1e16f6bdf29a6e6be587ba1/v8.1.5.log) +[v8.1.5-drop-fcc79f2e.log](/uploads/206fe958ab78c12542fda3764df978da/v8.1.5-drop-fcc79f2e.log) diff --git a/results/classifier/118/review/2356 b/results/classifier/118/review/2356 new file mode 100644 index 000000000..dd602772b --- /dev/null +++ b/results/classifier/118/review/2356 @@ -0,0 +1,75 @@ +register: 0.982 +device: 0.876 +graphic: 0.843 +kernel: 0.777 +architecture: 0.765 +performance: 0.708 +debug: 0.595 +network: 0.593 +semantic: 0.481 +vnc: 0.480 +ppc: 0.456 +socket: 0.442 +peripherals: 0.357 +files: 0.353 +assembly: 0.308 +PID: 0.302 +permissions: 0.287 +x86: 0.270 +VMM: 0.268 +hypervisor: 0.246 +mistranslation: 0.226 +i386: 0.226 +TCG: 0.211 +virtual: 0.192 +arm: 0.180 +boot: 0.169 +user-level: 0.095 +KVM: 0.094 +risc-v: 0.079 +-------------------- +debug: 0.923 +hypervisor: 0.465 +virtual: 0.218 +TCG: 0.187 +kernel: 0.120 +performance: 0.076 +files: 0.067 +device: 0.036 +register: 0.025 +assembly: 0.017 +user-level: 0.014 +architecture: 0.014 +peripherals: 0.009 +semantic: 0.009 +VMM: 0.008 +PID: 0.008 +KVM: 0.003 +boot: 0.003 +network: 0.003 +risc-v: 0.002 +graphic: 0.002 +socket: 0.002 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.001 +vnc: 0.000 +x86: 0.000 +ppc: 0.000 +i386: 0.000 + +assert in stm32l4x5_rcc +Description of problem: +The following log reveals it: + +``` +qemu-system-aarch64: ../hw/misc/stm32l4x5_rcc.c:546: void rcc_update_cfgr_register(Stm32l4x5RccState *): Assertion `val <= 0b100' failed. +Aborted +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-aarch64 -display \ +none -machine accel=qtest, -m 512M -machine b-l475e-iot01a -qtest stdio +writeq 0x40021008 0xffffffff +EOF +``` diff --git a/results/classifier/118/review/2369 b/results/classifier/118/review/2369 new file mode 100644 index 000000000..ce324a511 --- /dev/null +++ b/results/classifier/118/review/2369 @@ -0,0 +1,61 @@ +mistranslation: 0.993 +graphic: 0.560 +device: 0.430 +semantic: 0.427 +performance: 0.412 +arm: 0.318 +boot: 0.217 +user-level: 0.207 +virtual: 0.183 +network: 0.181 +peripherals: 0.160 +architecture: 0.157 +ppc: 0.130 +hypervisor: 0.119 +files: 0.118 +permissions: 0.101 +debug: 0.090 +VMM: 0.088 +vnc: 0.076 +PID: 0.066 +TCG: 0.065 +i386: 0.064 +register: 0.054 +socket: 0.052 +x86: 0.049 +risc-v: 0.044 +kernel: 0.035 +KVM: 0.019 +assembly: 0.014 +-------------------- +virtual: 0.951 +hypervisor: 0.931 +user-level: 0.339 +debug: 0.172 +performance: 0.084 +files: 0.029 +semantic: 0.017 +VMM: 0.014 +device: 0.013 +x86: 0.011 +assembly: 0.008 +peripherals: 0.006 +TCG: 0.006 +i386: 0.004 +kernel: 0.004 +boot: 0.003 +KVM: 0.003 +architecture: 0.003 +permissions: 0.003 +arm: 0.003 +ppc: 0.003 +PID: 0.003 +network: 0.002 +graphic: 0.001 +register: 0.001 +risc-v: 0.001 +socket: 0.001 +mistranslation: 0.000 +vnc: 0.000 + +qemu-img measure is incorrect when using discard-no-unref diff --git a/results/classifier/118/review/2371 b/results/classifier/118/review/2371 new file mode 100644 index 000000000..a2abc648b --- /dev/null +++ b/results/classifier/118/review/2371 @@ -0,0 +1,112 @@ +semantic: 0.839 +graphic: 0.831 +permissions: 0.819 +mistranslation: 0.816 +debug: 0.780 +risc-v: 0.777 +arm: 0.773 +vnc: 0.770 +PID: 0.755 +ppc: 0.754 +performance: 0.753 +peripherals: 0.750 +files: 0.747 +architecture: 0.728 +socket: 0.722 +network: 0.699 +hypervisor: 0.695 +device: 0.671 +register: 0.663 +kernel: 0.656 +i386: 0.653 +user-level: 0.651 +virtual: 0.628 +assembly: 0.628 +x86: 0.609 +boot: 0.550 +TCG: 0.547 +KVM: 0.531 +VMM: 0.349 +-------------------- +risc-v: 0.911 +assembly: 0.729 +debug: 0.455 +register: 0.187 +files: 0.127 +semantic: 0.104 +architecture: 0.058 +TCG: 0.058 +kernel: 0.054 +user-level: 0.028 +virtual: 0.026 +hypervisor: 0.016 +device: 0.015 +performance: 0.014 +PID: 0.012 +VMM: 0.007 +peripherals: 0.007 +boot: 0.005 +graphic: 0.004 +vnc: 0.003 +mistranslation: 0.003 +network: 0.002 +permissions: 0.002 +KVM: 0.001 +socket: 0.001 +ppc: 0.001 +i386: 0.001 +arm: 0.000 +x86: 0.000 + +A bug in RISC-V froundnx.h instruction +Description of problem: +According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN. +However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h: +``` +// target/riscv/fpu_helper.c +uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1) +{ + float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h. + frs1 = float16_round_to_int(frs1, &env->fp_status); + return nanbox_h(env, frs1); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char o_F5[8]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + printf("%02x ", o_F5[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "lui t5, %hi(i_F6)\n" + "addi t5, t5, %lo(i_F6)\n" + "fld ft6, 0(t5)\n" + ".insn 0x445372d3\n" // froundnx.h ft5, ft6 + "lui t5, %hi(o_F5)\n" + "addi t5, t5, %lo(o_F5)\n" + "fsd ft5, 0(t5)\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + + return 0; +} +``` +2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/118/review/237164 b/results/classifier/118/review/237164 new file mode 100644 index 000000000..bf9b16b77 --- /dev/null +++ b/results/classifier/118/review/237164 @@ -0,0 +1,155 @@ +semantic: 0.922 +register: 0.906 +debug: 0.897 +permissions: 0.894 +user-level: 0.892 +PID: 0.882 +performance: 0.873 +virtual: 0.869 +mistranslation: 0.862 +assembly: 0.856 +graphic: 0.856 +peripherals: 0.856 +device: 0.855 +architecture: 0.849 +arm: 0.841 +risc-v: 0.833 +socket: 0.824 +files: 0.821 +hypervisor: 0.806 +ppc: 0.806 +network: 0.801 +KVM: 0.785 +boot: 0.735 +vnc: 0.734 +TCG: 0.721 +kernel: 0.720 +VMM: 0.707 +x86: 0.614 +i386: 0.462 +-------------------- +virtual: 0.058 +hypervisor: 0.032 +KVM: 0.022 +debug: 0.019 +user-level: 0.015 +semantic: 0.015 +files: 0.013 +TCG: 0.010 +register: 0.007 +PID: 0.007 +i386: 0.006 +risc-v: 0.006 +ppc: 0.006 +device: 0.005 +graphic: 0.005 +socket: 0.004 +boot: 0.003 +VMM: 0.003 +x86: 0.002 +performance: 0.002 +vnc: 0.002 +kernel: 0.002 +architecture: 0.002 +peripherals: 0.001 +arm: 0.001 +network: 0.001 +assembly: 0.001 +mistranslation: 0.001 +permissions: 0.001 + +kvm needs to correctly simulate a proper monitor + +Binary package hint: xorg + +With xserver-xor-video-cirrus 1.2.1, there should be no need to require special handling for kvm in dexconf any longer. +See also: bug 193323. + +Quote from Bryce: +>Possibly with this fix, some portion of the kvm-specific changes to +>dexconf could be dropped. +> +>If anyone is interested in assisting with this, please file a new bug assigned to me, attach a minimal xorg.conf that has been adequately tested. Here are >the current kvm-specific things dexconf is doing: +>a) hardcoding the driver to cirrus +>b) specifying the depth +>c) setting the HorizSync and VertRefresh +>d) specifying the available resolutions +> +>In theory, none of these four things should be necessary, but I suspect +>this bug fix only addresses b and maybe c. Please test if these can be +>removed and if so, file a bug and I can take care of dropping them in +>dexconf. Thanks ahead of time. + +considering this is a follow-up bug to #193323, it should certainly be marked as 'confirmed', since it is a genuie issue. + + +Since I've compared qemu and kvm sources to find out why kvm works, and qemu doesn't (d'oh *g*), here my results: +a) not too sure if this is addressed with the update, or if this was a problem in the first place. +b) dexconf sets the depth to 24, which now the driver also does if it finds the corresponding cirrus card +c) haven't seen any implementation difference between qemu/kvm, so it should work +d) same as for c). + +To make FAUmachine (which however has a different cirrus implementation than qemu) work with the old cirrus driver, the only thing that was needed in the first place was to set the default depth to 24bpp. + +However I suggest to keep this bug in the state new, until anyone has in fact tested that kvm works with a plain xorg.conf. + +bryce: none of the quirks you are mentioning are actually working in qemu. The relevant part of dexconf that detects kvm is in line 271: + +QEMU_KVM=$(grep "QEMU Virtual CPU" /proc/cpuinfo || true) +if [ -n "$QEMU_KVM" ]; then + DEVICE_DRIVER="cirrus" +fi + +Only kvm reports that in /proc/cpuinfo. qemu reports "Pentium II (Katmai)", which is the very reason why the hardy live cd works in kvm but not in qemu. + +TBH, I'd suggest to just strip the kvm quircks out of dexconf in intrepid right now, and see if a daily livecd comes up. I'm pretty confident that it does so. + +Okay, I've stripped those all out of dexconf and repackaged xorg accordingly. Could you please test and verify it works ok? + +http://people.ubuntu.com/~bryce/Testing/xorg/ + +as asked on irc: can you provide a .deb for x11-common there as well? (iirc dexconf is in there... at least it's not in the .debs you put up there ;)) + +Just tested kvm with the hardy cd, installing xserver-xorg-video-cirrus from intrepid, and then x11-common and rerunning dexconf. +gdm comes up, however it uses a smaller resolution by default then. + +I'll attach xorg.conf (as supplied by the dexconf run), and Xorg.0.log (from the start with the new driver/new xorg.log) in a minute. + + + + + +what's the status of this? The kvm environment (still) doesn't seem to autoconfigure too well, that's why the Modes and HorizSync/VertRefresh are hardcoded. + +I just tested this, and Gnome comes up just fine without xorg.conf, however, the screen resolution is a sad little 800x600 without xorg.conf. It's 1024x768 with xorg.conf. + +:-Dustin + +kirkland confirmed that kvm still does not work properly without these quirks, so they cannot be dropped at this time. Feel free to reopen the xorg task if this situation changes, but moving the issue to kvm for now. + +Hi, + +to fix the kvm issue, kvm needs to simulate a monitor attached to the cirrus card, together with an EDID eeprom delivering the correct data for monitor modes. The simulated cirrus card shoul provide this via register sr8. A sample implementation can be found at www.faumachine.org (cvs checkout, see node-pc/simulator/chip_cirrus_gd5446.c -- based on qemu -- and lib/sig_i2c_bus.c and finally node-pc/monitor.c for the EDID contents) for details how to do it. + +Feel free to ask if anything is unclear. + +Cheers, + Stefan. + +Hey Stefan- + +There was actually some discussion upstream among KVM and Xorg developers. I think they determined that this was a 'won't fix' situation, but I need to check that. Let me track that down... + + +:-Dustin + +As a workaround, the driver itself can force the resolution to a certain degree. This is covered in bug #349331 + +Isn't the issue here that the emulated card has too low video memory forcing 800x600 when the driver selects the default 24bpp depth? + +This is an issue with some very old real hardware too. + +I guess X could account for that but due to its architecture every driver would likely have a separate check for this condition (S3, cirrus, and any other driver that could be possibly used with such low-mem card). + +Since cirrus is not the prefered graphics card in QEMU anymore, and there hasn't been any update to this within the last four years, I think nobody will take care of this ticket anymore, so setting the status to "Won't fix" now. + diff --git a/results/classifier/118/review/2377 b/results/classifier/118/review/2377 new file mode 100644 index 000000000..9c95577f3 --- /dev/null +++ b/results/classifier/118/review/2377 @@ -0,0 +1,85 @@ +architecture: 0.960 +graphic: 0.873 +device: 0.844 +semantic: 0.784 +arm: 0.778 +performance: 0.724 +PID: 0.713 +debug: 0.677 +user-level: 0.643 +register: 0.573 +files: 0.553 +permissions: 0.545 +mistranslation: 0.503 +boot: 0.476 +network: 0.457 +virtual: 0.455 +hypervisor: 0.430 +x86: 0.394 +socket: 0.360 +peripherals: 0.345 +vnc: 0.303 +i386: 0.267 +risc-v: 0.212 +ppc: 0.173 +TCG: 0.137 +kernel: 0.135 +VMM: 0.124 +assembly: 0.095 +KVM: 0.073 +-------------------- +arm: 0.992 +debug: 0.831 +hypervisor: 0.821 +kernel: 0.291 +virtual: 0.263 +files: 0.031 +PID: 0.027 +TCG: 0.025 +architecture: 0.025 +user-level: 0.019 +VMM: 0.014 +boot: 0.013 +register: 0.009 +performance: 0.007 +device: 0.004 +socket: 0.003 +assembly: 0.002 +network: 0.002 +risc-v: 0.002 +graphic: 0.001 +KVM: 0.001 +vnc: 0.001 +semantic: 0.001 +peripherals: 0.001 +permissions: 0.000 +x86: 0.000 +ppc: 0.000 +mistranslation: 0.000 +i386: 0.000 + +Debootstrapping debian-bullseye arm64 segfaults with qemu >=8.1 +Steps to reproduce: +1. Use qemu >= 8.1 (version <= 8.0.x work well) +2. Install `debootstrap` package +3. Run `sudo debootstrap --arch=arm64 bullseye root11-arm64` + +This fails to chroot into the system being debootstrapped: + +``` +$ sudo debootstrap --arch=arm64 bullseye root11-arm64 +... +W: Failure trying to run: chroot "/home/3/root11" /sbin/ldconfig +W: See /home/3/root11/debootstrap/debootstrap.log for details +$ tail -n2 /home/3/root11/debootstrap/debootstrap.log +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +/usr/share/debootstrap/functions: line 1092: 3869 Segmentation fault chroot "/home/3/root11" "$@" +``` +Additional information: +Failure happens only when debootstrapping "bullseye" with "arm64" architecture. +Older (e.g. <= "buster") and newer (e.g. > "bookworm") distros are deboostrapped OK. +Other (e.g. "armhf" and others) architectures are debootstrapped OK. + +Qemu version <8.1 (e.g. 8.0.5 I use in Gentoo or versions in Debian <= bookworm) don't have the bug. + +Originally faced the issue with Gentoo host. Recently rechecked with Debian Trixie host. diff --git a/results/classifier/118/review/238 b/results/classifier/118/review/238 new file mode 100644 index 000000000..21169f83a --- /dev/null +++ b/results/classifier/118/review/238 @@ -0,0 +1,61 @@ +architecture: 0.814 +user-level: 0.740 +network: 0.708 +device: 0.537 +graphic: 0.486 +performance: 0.456 +TCG: 0.374 +arm: 0.361 +debug: 0.326 +ppc: 0.280 +kernel: 0.272 +VMM: 0.217 +vnc: 0.214 +semantic: 0.208 +mistranslation: 0.194 +boot: 0.192 +risc-v: 0.174 +PID: 0.141 +register: 0.124 +permissions: 0.118 +assembly: 0.113 +virtual: 0.094 +files: 0.046 +hypervisor: 0.046 +KVM: 0.044 +socket: 0.031 +peripherals: 0.010 +i386: 0.009 +x86: 0.005 +-------------------- +network: 0.834 +user-level: 0.676 +debug: 0.091 +files: 0.073 +x86: 0.066 +virtual: 0.049 +kernel: 0.033 +performance: 0.024 +assembly: 0.012 +semantic: 0.008 +i386: 0.006 +device: 0.005 +graphic: 0.003 +boot: 0.003 +PID: 0.002 +TCG: 0.002 +ppc: 0.002 +peripherals: 0.002 +KVM: 0.001 +register: 0.001 +architecture: 0.001 +VMM: 0.001 +permissions: 0.001 +socket: 0.001 +vnc: 0.000 +arm: 0.000 +mistranslation: 0.000 +risc-v: 0.000 +hypervisor: 0.000 + +capstone link failure building linux-user static diff --git a/results/classifier/118/review/2386 b/results/classifier/118/review/2386 new file mode 100644 index 000000000..270f52dc6 --- /dev/null +++ b/results/classifier/118/review/2386 @@ -0,0 +1,103 @@ +register: 0.937 +risc-v: 0.931 +graphic: 0.899 +performance: 0.895 +ppc: 0.839 +files: 0.834 +socket: 0.812 +device: 0.808 +vnc: 0.803 +PID: 0.762 +network: 0.759 +arm: 0.758 +architecture: 0.746 +kernel: 0.733 +permissions: 0.697 +assembly: 0.688 +debug: 0.684 +TCG: 0.644 +mistranslation: 0.640 +x86: 0.631 +semantic: 0.624 +boot: 0.615 +VMM: 0.575 +KVM: 0.565 +hypervisor: 0.556 +user-level: 0.533 +peripherals: 0.532 +i386: 0.522 +virtual: 0.377 +-------------------- +files: 0.215 +assembly: 0.161 +semantic: 0.116 +risc-v: 0.060 +debug: 0.057 +register: 0.017 +PID: 0.013 +user-level: 0.012 +architecture: 0.010 +virtual: 0.008 +TCG: 0.007 +hypervisor: 0.006 +device: 0.005 +performance: 0.004 +network: 0.003 +socket: 0.003 +boot: 0.003 +kernel: 0.002 +peripherals: 0.002 +permissions: 0.002 +graphic: 0.002 +mistranslation: 0.002 +vnc: 0.001 +VMM: 0.001 +KVM: 0.000 +arm: 0.000 +i386: 0.000 +ppc: 0.000 +x86: 0.000 + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/118/review/2401 b/results/classifier/118/review/2401 new file mode 100644 index 000000000..a89f51448 --- /dev/null +++ b/results/classifier/118/review/2401 @@ -0,0 +1,61 @@ +mistranslation: 0.943 +semantic: 0.460 +architecture: 0.390 +virtual: 0.390 +device: 0.368 +kernel: 0.348 +user-level: 0.314 +performance: 0.278 +i386: 0.221 +hypervisor: 0.194 +peripherals: 0.179 +network: 0.174 +x86: 0.169 +ppc: 0.159 +KVM: 0.155 +graphic: 0.154 +files: 0.151 +arm: 0.126 +debug: 0.120 +TCG: 0.097 +vnc: 0.092 +boot: 0.075 +VMM: 0.068 +permissions: 0.067 +PID: 0.046 +socket: 0.036 +register: 0.030 +risc-v: 0.030 +assembly: 0.030 +-------------------- +network: 0.991 +files: 0.273 +semantic: 0.246 +user-level: 0.157 +permissions: 0.150 +virtual: 0.059 +device: 0.025 +kernel: 0.022 +VMM: 0.019 +x86: 0.012 +debug: 0.011 +vnc: 0.009 +KVM: 0.007 +assembly: 0.007 +socket: 0.004 +boot: 0.004 +i386: 0.004 +TCG: 0.003 +ppc: 0.003 +mistranslation: 0.003 +hypervisor: 0.003 +risc-v: 0.003 +architecture: 0.002 +peripherals: 0.002 +graphic: 0.001 +arm: 0.001 +PID: 0.001 +performance: 0.000 +register: 0.000 + +"-nic none" option has no equivalent in config file diff --git a/results/classifier/118/review/241119 b/results/classifier/118/review/241119 new file mode 100644 index 000000000..19ea574d2 --- /dev/null +++ b/results/classifier/118/review/241119 @@ -0,0 +1,153 @@ +user-level: 0.879 +graphic: 0.859 +peripherals: 0.825 +semantic: 0.823 +architecture: 0.815 +permissions: 0.804 +device: 0.788 +mistranslation: 0.752 +virtual: 0.752 +debug: 0.743 +assembly: 0.733 +performance: 0.726 +register: 0.717 +PID: 0.701 +hypervisor: 0.693 +ppc: 0.686 +KVM: 0.681 +socket: 0.675 +network: 0.662 +files: 0.635 +boot: 0.628 +TCG: 0.612 +arm: 0.611 +kernel: 0.585 +risc-v: 0.582 +VMM: 0.562 +vnc: 0.556 +x86: 0.474 +i386: 0.309 +-------------------- +virtual: 0.942 +peripherals: 0.752 +KVM: 0.432 +user-level: 0.258 +hypervisor: 0.089 +x86: 0.087 +kernel: 0.075 +debug: 0.016 +i386: 0.014 +register: 0.010 +TCG: 0.010 +PID: 0.010 +device: 0.007 +files: 0.006 +socket: 0.004 +VMM: 0.003 +boot: 0.003 +vnc: 0.003 +network: 0.002 +ppc: 0.002 +performance: 0.002 +risc-v: 0.002 +semantic: 0.002 +assembly: 0.001 +graphic: 0.001 +arm: 0.001 +architecture: 0.001 +permissions: 0.001 +mistranslation: 0.001 + +usb_add of a Creative ZEN unrecognized in guest + +Binary package hint: kvm + +This happens when I add my Creative ZEN to a virtual machine running XP. The device is recognised well at first and drivers are installed correctly. But when trying to connect windows crashes with the classic blue screen It complains about something like usbohci.sys, I can't read well because it crashes too fast. +I have also tried with another virtual machine running Vista, same results. +Any help would be really appreciated! + +I'm using the module kvm-amd with Ubuntu 8.04 + +The USB device has the following ID: 041e:4157 Creative Technology, Ltd + +kvm: + Installed: 1:62+dfsg-0ubuntu7 + Candidate: 1:62+dfsg-0ubuntu7 + Version table: + *** 1:62+dfsg-0ubuntu7 0 + 500 http://archive.ubuntu.com hardy/main Packages + 100 /var/lib/dpkg/status + +Hi, thanks for the bug report. + +This bug was reported against Hardy's kvm-62. Unfortunately, kvm-62 is not able to do usb-passthrough properly. + +Would it be possible for you to test this against intrepid and/or jaunty? + +:-Dustin + +If you're running Hardy, could you please test this using the kvm-84 package in this PPA: + * https://launchpad.net/~ubuntu-virt/+archive/ppa + +Does this solve the issue, or is it reproducible? + +:-Dustin + + +I'm running Intrepid now, however I tried the package you suggested (kvm-84) but the problem persists. + +kvm: + Installed: 1:84+dfsg-0ubuntu8~ppa6 + Candidate: 1:84+dfsg-0ubuntu8~ppa6 + Version table: + *** 1:84+dfsg-0ubuntu8~ppa6 0 + 100 /var/lib/dpkg/status + 1:72+dfsg-1ubuntu6 0 + 500 http://archive.ubuntu.com intrepid/main Packages + +The console output when trying to usb_add the device is the following: + +husb: open device 1.5 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 1.5 +usb_linux_update_endp_table: Protocol error + + +I forgot: + +Using the new kvm package the virtual machine now doesn't crash with the blue screen anymore. Now it seems like the device is not correctly recognized or initialized + +Okay, the problem persists in kvm-84. I'll mark it as 'Confirmed', and point upstream at the issue. Thanks. + +:-Dustin + +@Dustin +Did this hit upstream, I looked yesterday and couldn't find it to track it. + +To copy this upstream, click "Also affects project", and enter "qemu". + +kvm-84 is very old. Please try to reproduce this against the latest qemu git or at least 0.12.4. + +Hi. I have a similar problem, with a simple JetFlash usb drive. + +After adding it with usb_add, "info usb" shows nothing and I start getting the following message in the console: +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 1.3 +usb_linux_update_endp_table: Protocol error + +This is under Maverick using qemu-kvm 0.12.5+noroms-0ubuntu7 + +The same operation works fine in the same pc under my gentoo system, currently running qemu-kvm-0.13.0, but it has been working now for a year, without ever giving me problems. + +Hi, + +is this still an issue under natty or oneiric? + +Hi, unfortunately my Creative ZEN (for which I initially issued the bug) broke, so I am not able to verify if it is an issue anymore, I'm sorry. + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + +Closing this bug since the hardware is not available anymore (according to comment #11). + diff --git a/results/classifier/118/review/2414 b/results/classifier/118/review/2414 new file mode 100644 index 000000000..19ce78e7b --- /dev/null +++ b/results/classifier/118/review/2414 @@ -0,0 +1,177 @@ +mistranslation: 0.917 +graphic: 0.913 +peripherals: 0.893 +TCG: 0.887 +semantic: 0.873 +VMM: 0.868 +hypervisor: 0.862 +assembly: 0.862 +ppc: 0.857 +permissions: 0.830 +socket: 0.825 +x86: 0.815 +debug: 0.804 +KVM: 0.803 +vnc: 0.800 +arm: 0.788 +risc-v: 0.766 +network: 0.758 +device: 0.754 +virtual: 0.750 +architecture: 0.735 +user-level: 0.729 +PID: 0.725 +register: 0.724 +performance: 0.685 +boot: 0.642 +kernel: 0.621 +files: 0.613 +i386: 0.545 +-------------------- +kernel: 0.978 +x86: 0.973 +hypervisor: 0.962 +virtual: 0.961 +debug: 0.774 +PID: 0.135 +assembly: 0.048 +boot: 0.047 +TCG: 0.042 +files: 0.020 +register: 0.010 +KVM: 0.006 +architecture: 0.006 +VMM: 0.005 +semantic: 0.004 +performance: 0.004 +i386: 0.003 +device: 0.003 +socket: 0.002 +ppc: 0.002 +graphic: 0.002 +risc-v: 0.001 +user-level: 0.001 +vnc: 0.001 +permissions: 0.001 +network: 0.001 +mistranslation: 0.001 +peripherals: 0.000 +arm: 0.000 + +qemu 9.0.0 crashing with OpenBSD 7.5 +Description of problem: +After upgrading from Qemu 8.23 to 9.0 this virtual does not start anymore (others do). The bootloader runs fine and starts the OpenBSD kernel, some kernel messages are shown on VGA console. It never reaches userland. +Additional information: +``` +Jun 29 07:15:10 hypervisor kernel: qemu-system-x86[12021]: segfault at 14 ip 000056547310bee4 sp 00007fc6d68c8310 error 4 in qemu-system-x86_64[565472ee0000+6ea000] +Jun 29 07:15:10 hypervisor kernel: Code: 01 00 00 48 83 c4 58 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 40 00 89 f0 48 8b 8b 40 83 00 00 4c 8d 0c 40 49 c1 e1 03 4c 01 c9 <8b> 41 14 85 c0 0f 84 11 01 00 00 83 c0 01 89 41 14 41 80 bf d1 01 +Jun 29 07:15:10 hypervisor systemd[1]: Started Process Core Dump (PID 12122/UID 0). +Jun 29 07:15:39 hypervisor systemd-coredump[12123]: Process 12017 (qemu-system-x86) of user 954 dumped core. + + Stack trace of thread 12021: + #0 0x000056547310bee4 n/a (qemu-system-x86_64 + 0x397ee4) + #1 0x000056547330d5e2 n/a (qemu-system-x86_64 + 0x5995e2) + #2 0x000056547330dba6 n/a (qemu-system-x86_64 + 0x599ba6) + #3 0x000056547330e059 memory_region_dispatch_write (qemu-system-x86_64 + 0x59a059) + #4 0x00005654735c1e1f n/a (qemu-system-x86_64 + 0x84de1f) + #5 0x0000565473314a7d n/a (qemu-system-x86_64 + 0x5a0a7d) + #6 0x0000565473314b76 address_space_write (qemu-system-x86_64 + 0x5a0b76) + #7 0x000056547336cafe kvm_cpu_exec (qemu-system-x86_64 + 0x5f8afe) + #8 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e) + #9 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #10 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #11 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12026: + #0 0x00007fc6d93b3740 n/a (libc.so.6 + 0x8f740) + #1 0x00007fc6d93ba551 pthread_mutex_lock (libc.so.6 + 0x96551) + #2 0x0000565473535858 qemu_mutex_lock_impl (qemu-system-x86_64 + 0x7c1858) + #3 0x000056547313f906 bql_lock_impl (qemu-system-x86_64 + 0x3cb906) + #4 0x00005654735c1c7f n/a (qemu-system-x86_64 + 0x84dc7f) + #5 0x0000565473313776 flatview_read_continue (qemu-system-x86_64 + 0x59f776) + #6 0x0000565473314df0 n/a (qemu-system-x86_64 + 0x5a0df0) + #7 0x0000565473314eb6 address_space_read_full (qemu-system-x86_64 + 0x5a0eb6) + #8 0x000056547336cdf5 kvm_cpu_exec (qemu-system-x86_64 + 0x5f8df5) + #9 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e) + #10 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #11 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #12 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12018: + #0 0x00007fc6d9402f43 clock_nanosleep (libc.so.6 + 0xdef43) + #1 0x00007fc6d940ed77 __nanosleep (libc.so.6 + 0xead77) + #2 0x00007fc6d98ccee0 g_usleep (libglib-2.0.so.0 + 0x8dee0) + #3 0x0000565473545a75 n/a (qemu-system-x86_64 + 0x7d1a75) + #4 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #5 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #6 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12020: + #0 0x00007fc6d942c39d __poll (libc.so.6 + 0x10839d) + #1 0x00007fc6d98fd8fd n/a (libglib-2.0.so.0 + 0xbe8fd) + #2 0x00007fc6d989c787 g_main_loop_run (libglib-2.0.so.0 + 0x5d787) + #3 0x00005654733bf7c2 n/a (qemu-system-x86_64 + 0x64b7c2) + #4 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #5 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #6 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12017: + #0 0x00007fc6d942c910 ppoll (libc.so.6 + 0x108910) + #1 0x000056547354ae83 qemu_poll_ns (qemu-system-x86_64 + 0x7d6e83) + #2 0x000056547355800e main_loop_wait (qemu-system-x86_64 + 0x7e400e) + #3 0x000056547337a337 qemu_default_main (qemu-system-x86_64 + 0x606337) + #4 0x00007fc6d9349c88 n/a (libc.so.6 + 0x25c88) + #5 0x00007fc6d9349d4c __libc_start_main (libc.so.6 + 0x25d4c) + #6 0x0000565472ef08b5 _start (qemu-system-x86_64 + 0x17c8b5) + + Stack trace of thread 12025: + #0 0x00007fc6d942c39d __poll (libc.so.6 + 0x10839d) + #1 0x00007fc6d98fd8fd n/a (libglib-2.0.so.0 + 0xbe8fd) + #2 0x00007fc6d989c787 g_main_loop_run (libglib-2.0.so.0 + 0x5d787) + #3 0x00007fc6d78ff0cb n/a (libspice-server.so.1 + 0x530cb) + #4 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #5 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12117: + #0 0x00007fc6d93b34e9 n/a (libc.so.6 + 0x8f4e9) + #1 0x00007fc6d93b6242 pthread_cond_timedwait (libc.so.6 + 0x92242) + #2 0x0000565473536546 n/a (qemu-system-x86_64 + 0x7c2546) + #3 0x00005654735367ad qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x7c27ad) + #4 0x00005654735569d5 n/a (qemu-system-x86_64 + 0x7e29d5) + #5 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #6 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #7 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12028: + #0 0x00007fc6d93b3740 n/a (libc.so.6 + 0x8f740) + #1 0x00007fc6d93ba551 pthread_mutex_lock (libc.so.6 + 0x96551) + #2 0x0000565473535858 qemu_mutex_lock_impl (qemu-system-x86_64 + 0x7c1858) + #3 0x000056547313f906 bql_lock_impl (qemu-system-x86_64 + 0x3cb906) + #4 0x00005654735c1c7f n/a (qemu-system-x86_64 + 0x84dc7f) + #5 0x0000565473313776 flatview_read_continue (qemu-system-x86_64 + 0x59f776) + #6 0x0000565473314df0 n/a (qemu-system-x86_64 + 0x5a0df0) + #7 0x0000565473314eb6 address_space_read_full (qemu-system-x86_64 + 0x5a0eb6) + #8 0x000056547336cdf5 kvm_cpu_exec (qemu-system-x86_64 + 0x5f8df5) + #9 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e) + #10 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #11 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #12 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + + Stack trace of thread 12027: + #0 0x00007fc6d93b3740 n/a (libc.so.6 + 0x8f740) + #1 0x00007fc6d93ba551 pthread_mutex_lock (libc.so.6 + 0x96551) + #2 0x0000565473535858 qemu_mutex_lock_impl (qemu-system-x86_64 + 0x7c1858) + #3 0x000056547313f906 bql_lock_impl (qemu-system-x86_64 + 0x3cb906) + #4 0x00005654735c1c7f n/a (qemu-system-x86_64 + 0x84dc7f) + #5 0x0000565473313776 flatview_read_continue (qemu-system-x86_64 + 0x59f776) + #6 0x0000565473314df0 n/a (qemu-system-x86_64 + 0x5a0df0) + #7 0x0000565473314eb6 address_space_read_full (qemu-system-x86_64 + 0x5a0eb6) + #8 0x000056547336cdf5 kvm_cpu_exec (qemu-system-x86_64 + 0x5f8df5) + #9 0x000056547336f56e n/a (qemu-system-x86_64 + 0x5fb56e) + #10 0x000056547352fca8 n/a (qemu-system-x86_64 + 0x7bbca8) + #11 0x00007fc6d93b6ded n/a (libc.so.6 + 0x92ded) + #12 0x00007fc6d943a0dc n/a (libc.so.6 + 0x1160dc) + ELF object binary architecture: AMD x86-64 +Jun 29 07:15:40 hypervisor systemd[1]: systemd-coredump@2-12122-0.service: Deactivated successfully. +Jun 29 07:15:40 hypervisor systemd[1]: systemd-coredump@2-12122-0.service: Consumed 20.231s CPU time. +``` diff --git a/results/classifier/118/review/2419 b/results/classifier/118/review/2419 new file mode 100644 index 000000000..711544c82 --- /dev/null +++ b/results/classifier/118/review/2419 @@ -0,0 +1,78 @@ +architecture: 0.860 +arm: 0.781 +device: 0.662 +graphic: 0.619 +semantic: 0.503 +mistranslation: 0.492 +performance: 0.403 +permissions: 0.337 +ppc: 0.297 +network: 0.294 +vnc: 0.286 +socket: 0.282 +register: 0.251 +files: 0.234 +boot: 0.232 +PID: 0.223 +peripherals: 0.186 +risc-v: 0.174 +user-level: 0.168 +assembly: 0.166 +kernel: 0.158 +debug: 0.154 +VMM: 0.130 +hypervisor: 0.112 +virtual: 0.104 +i386: 0.103 +x86: 0.100 +TCG: 0.098 +KVM: 0.040 +-------------------- +arm: 0.995 +assembly: 0.530 +debug: 0.210 +files: 0.180 +TCG: 0.112 +architecture: 0.107 +semantic: 0.083 +hypervisor: 0.067 +virtual: 0.038 +register: 0.023 +kernel: 0.022 +PID: 0.014 +VMM: 0.010 +device: 0.010 +user-level: 0.008 +network: 0.005 +performance: 0.005 +risc-v: 0.003 +boot: 0.003 +peripherals: 0.003 +socket: 0.003 +mistranslation: 0.002 +graphic: 0.002 +KVM: 0.001 +vnc: 0.001 +permissions: 0.001 +ppc: 0.000 +i386: 0.000 +x86: 0.000 + +ldapr_stlr_i instructions doesn't consider signed offset +Description of problem: +The format ldapr_stlr_i models the load acquire / store release immediate instructions. \ +These instructions has a bug in the sign extension calculation of the imm field. \ +imm should be defined as s9 instead of 9. + +@ldapr_stlr_i .. ...... .. . imm:9 .. rn:5 rt:5 &ldapr_stlr_i + +Should be changed to: + +@ldapr_stlr_i .. ...... .. . imm:s9 .. rn:5 rt:5 &ldapr_stlr_i +Steps to reproduce: +1. Run ARM target +2. Generate any ldapr_stlr_i instructions (for example: LDAPUR) +3. When the imm value is negative, the immediate calculation is done wrong. In case the calculation leads to an undefined location, QEMU will fail. +Additional information: +In trans_LDAPR_i (translate-a64.c), when imm field is negative, the value of a->imm will be 512-x instead of x. \ +I already fixed the issue by adding the s9 to the imm field. This made a call to sextend32 for imm instead of extend32 in the generated file build/libqemu-aarch64-softmmu.fa.p/decode-a64.c.inc diff --git a/results/classifier/118/review/2426 b/results/classifier/118/review/2426 new file mode 100644 index 000000000..964388c1a --- /dev/null +++ b/results/classifier/118/review/2426 @@ -0,0 +1,61 @@ +architecture: 0.809 +device: 0.509 +performance: 0.410 +x86: 0.242 +ppc: 0.226 +graphic: 0.212 +debug: 0.179 +i386: 0.173 +mistranslation: 0.168 +arm: 0.158 +boot: 0.140 +VMM: 0.131 +PID: 0.119 +risc-v: 0.117 +semantic: 0.112 +TCG: 0.090 +virtual: 0.079 +register: 0.076 +KVM: 0.076 +user-level: 0.074 +vnc: 0.058 +socket: 0.036 +hypervisor: 0.030 +kernel: 0.023 +permissions: 0.012 +assembly: 0.012 +files: 0.004 +network: 0.003 +peripherals: 0.001 +-------------------- +architecture: 0.570 +x86: 0.162 +user-level: 0.074 +semantic: 0.051 +PID: 0.051 +VMM: 0.044 +socket: 0.031 +TCG: 0.031 +i386: 0.026 +device: 0.025 +kernel: 0.024 +performance: 0.019 +assembly: 0.016 +debug: 0.012 +ppc: 0.011 +virtual: 0.010 +files: 0.007 +arm: 0.006 +boot: 0.004 +register: 0.002 +graphic: 0.002 +risc-v: 0.002 +KVM: 0.002 +hypervisor: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +vnc: 0.000 +network: 0.000 +permissions: 0.000 + +How to determine which cpu microarchitecture is suitable for use on Windows 11? diff --git a/results/classifier/118/review/2430 b/results/classifier/118/review/2430 new file mode 100644 index 000000000..ad0a10a66 --- /dev/null +++ b/results/classifier/118/review/2430 @@ -0,0 +1,67 @@ +mistranslation: 0.843 +performance: 0.813 +graphic: 0.744 +device: 0.711 +kernel: 0.535 +network: 0.530 +vnc: 0.507 +TCG: 0.500 +files: 0.439 +PID: 0.429 +socket: 0.411 +VMM: 0.392 +debug: 0.365 +semantic: 0.364 +architecture: 0.363 +risc-v: 0.349 +boot: 0.339 +arm: 0.302 +ppc: 0.299 +permissions: 0.294 +register: 0.248 +KVM: 0.206 +peripherals: 0.203 +hypervisor: 0.192 +user-level: 0.184 +x86: 0.183 +i386: 0.177 +virtual: 0.086 +assembly: 0.086 +-------------------- +files: 0.118 +user-level: 0.097 +virtual: 0.072 +TCG: 0.049 +x86: 0.040 +debug: 0.039 +KVM: 0.021 +VMM: 0.006 +hypervisor: 0.005 +semantic: 0.004 +kernel: 0.003 +device: 0.003 +register: 0.002 +assembly: 0.002 +i386: 0.002 +PID: 0.001 +architecture: 0.001 +risc-v: 0.001 +performance: 0.001 +ppc: 0.001 +network: 0.001 +boot: 0.001 +graphic: 0.000 +arm: 0.000 +vnc: 0.000 +mistranslation: 0.000 +permissions: 0.000 +peripherals: 0.000 +socket: 0.000 + +allocate / free need use glibs's function. +Description of problem: +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/core/machine.c?ref_type=heads#L982 + +use g_free to free config,because it is allocated by g_malloc0 + +on windows,if use crt's free && glib's(DLL) g_malloc0 ,will crash. diff --git a/results/classifier/118/review/2432 b/results/classifier/118/review/2432 new file mode 100644 index 000000000..e4870ac2c --- /dev/null +++ b/results/classifier/118/review/2432 @@ -0,0 +1,130 @@ +user-level: 0.901 +graphic: 0.892 +permissions: 0.890 +virtual: 0.879 +register: 0.876 +mistranslation: 0.872 +risc-v: 0.869 +debug: 0.859 +performance: 0.850 +semantic: 0.850 +device: 0.848 +arm: 0.833 +architecture: 0.828 +vnc: 0.824 +KVM: 0.823 +TCG: 0.821 +assembly: 0.817 +hypervisor: 0.809 +VMM: 0.791 +PID: 0.786 +files: 0.782 +peripherals: 0.781 +x86: 0.772 +socket: 0.768 +kernel: 0.761 +boot: 0.756 +ppc: 0.752 +network: 0.701 +i386: 0.676 +-------------------- +x86: 0.975 +kernel: 0.800 +debug: 0.646 +ppc: 0.189 +TCG: 0.178 +files: 0.131 +assembly: 0.089 +i386: 0.068 +VMM: 0.064 +virtual: 0.062 +register: 0.045 +device: 0.043 +KVM: 0.034 +PID: 0.033 +peripherals: 0.022 +semantic: 0.019 +architecture: 0.013 +hypervisor: 0.012 +user-level: 0.011 +performance: 0.008 +arm: 0.006 +risc-v: 0.006 +graphic: 0.002 +socket: 0.002 +network: 0.002 +boot: 0.002 +permissions: 0.002 +mistranslation: 0.001 +vnc: 0.001 + +Bug in bcm2835_thermal interface +Description of problem: +Stack traces, crash detail: +``` +#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:44 +#1 __pthread_kill_internal (signo=6, threadid=140737230841344) at ./nptl/pthread_kill.c:78 +#2 __GI___pthread_kill (threadid=140737230841344, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 +#3 0x00007ffff5042476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#4 0x00007ffff50287f3 in __GI_abort () at ./stdlib/abort.c:79 +#5 0x00007ffff6f0eb57 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#6 0x00007ffff6f6870f in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x0000555555d642a6 in bcm2835_thermal_write (opaque=0x7ffff0a475b0, addr=2, value=0, size=2) + at ../hw/misc/bcm2835_thermal.c:76 +#8 0x0000555556c4a119 in memory_region_write_accessor + (mr=0x7ffff0a478e0, addr=2, value=0x7fffffffd250, size=2, shift=0, mask=65535, attrs=...) + at ../system/memory.c:497 +#9 0x0000555556c49da6 in access_with_adjusted_size + (addr=2, value=0x7fffffffd250, size=2, access_size_min=1, access_size_max=4, access_fn=0x555556c49ef0 <memory_region_write_accessor>, mr=0x7ffff0a478e0, attrs=...) at ../system/memory.c:573 +#10 0x0000555556c49395 in memory_region_dispatch_write (mr=0x7ffff0a478e0, addr=2, data=0, op=MO_16, attrs=...) + at ../system/memory.c:1521 +#11 0x0000555556c84e88 in flatview_write_continue_step + (attrs=..., buf=0x7fffffffd470 "", len=512, mr_addr=2, l=0x7fffffffd360, mr=0x7ffff0a478e0) + at ../system/physmem.c:2757 +#12 0x0000555556c84c42 in flatview_write_continue + (fv=0x555559717490, addr=1059135490, attrs=..., ptr=0x7fffffffd470, len=512, mr_addr=2, l=2, mr=0x7ffff0a478e0) at ../system/physmem.c:2787 +#13 0x0000555556c73305 in flatview_write + (fv=0x555559717490, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2818 +#14 0x0000555556c73179 in address_space_write +--Type <RET> for more, q to quit, c to continue without paging--c + (as=0x5555598056f0, addr=1059135490, attrs=..., buf=0x7fffffffd470, len=512) at ../system/physmem.c:2938 +#15 0x0000555556c735df in address_space_set (as=0x5555598056f0, addr=1059135490, c=0 '\000', len=2025625, attrs=...) at ../system/physmem.c:2965 +#16 0x0000555555a95b66 in rom_reset (unused=0x0) at ../hw/core/loader.c:1284 +#17 0x0000555555ab872d in legacy_reset_hold (obj=0x5555598069b0, type=RESET_TYPE_COLD) at ../hw/core/reset.c:76 +#18 0x0000555556d7dbf4 in resettable_phase_hold (obj=0x5555598069b0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:180 +#19 0x0000555556d7d19f in resettable_container_child_foreach (obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resetcontainer.c:54 +#20 0x0000555556d7f4a4 in resettable_child_foreach (rc=0x555558b02f50, obj=0x5555595573d0, cb=0x555556d7d970 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:92 +#21 0x0000555556d7da92 in resettable_phase_hold (obj=0x5555595573d0, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:169 +#22 0x0000555556d7d47a in resettable_assert_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:58 +#23 0x0000555556d7d2f7 in resettable_reset (obj=0x5555595573d0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:45 +#24 0x0000555555ab842e in qemu_devices_reset (reason=SHUTDOWN_CAUSE_NONE) at ../hw/core/reset.c:179 +#25 0x000055555633227d in qemu_system_reset (reason=SHUTDOWN_CAUSE_NONE) at ../system/runstate.c:493 +#26 0x0000555555aa6bd2 in qdev_machine_creation_done () at ../hw/core/machine.c:1643 +#27 0x000055555633679f in qemu_machine_creation_done (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2685 +#28 0x0000555556335ffd in qmp_x_exit_preconfig (errp=0x555558587ee0 <error_fatal>) at ../system/vl.c:2715 +#29 0x000055555633bfe4 in qemu_init (argc=9, argv=0x7fffffffdc68) at ../system/vl.c:3759 +#30 0x0000555556d6eea2 in main (argc=9, argv=0x7fffffffdc68) at ../system/main.c:47 +``` +Description: +I encountered a part of the code during QEMU execution that shouldn't have been reached, which led to an error. + +Crash detail: +``` +ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached +Bail out! ERROR:../hw/misc/bcm2835_thermal.c:76:bcm2835_thermal_write: code should not be reached +Aborted +``` + +Malicious inputs: +Malicious input is attached as tar.gz archive to this file, it contains file name id:000017,sig:06,src:000428,time:48261741,execs:1725363,op:havoc,rep:8 +[malicious_input.tar.gz](/uploads/fcf47faafb59308cfdb04b3e81e788f3/malicious_input.tar.gz) + +Affected code area/snippet: + +qemu/hw/misc/bcm2835_thermal.c:bcm2835_thermal_write + + +Acknowledge for reporting this issue: +Alisher Darmenov (darmenovalisher@gmail.com), +Mohamadreza Rostami (mohamadreza.rostami@trust.tu-darmstadt.de), +Ahmad-Reza Sadeghi (ahmad.sadeghi@trust.tu-darmstadt.de) diff --git a/results/classifier/118/review/2451 b/results/classifier/118/review/2451 new file mode 100644 index 000000000..1e2ad5e19 --- /dev/null +++ b/results/classifier/118/review/2451 @@ -0,0 +1,61 @@ +mistranslation: 0.875 +user-level: 0.691 +virtual: 0.587 +permissions: 0.516 +semantic: 0.337 +debug: 0.331 +peripherals: 0.308 +ppc: 0.242 +register: 0.225 +device: 0.222 +boot: 0.212 +performance: 0.192 +assembly: 0.188 +arm: 0.171 +graphic: 0.164 +socket: 0.156 +files: 0.103 +kernel: 0.082 +PID: 0.061 +i386: 0.046 +TCG: 0.046 +VMM: 0.030 +KVM: 0.021 +network: 0.018 +risc-v: 0.008 +architecture: 0.006 +hypervisor: 0.005 +x86: 0.003 +vnc: 0.002 +-------------------- +user-level: 0.742 +peripherals: 0.132 +virtual: 0.071 +semantic: 0.068 +PID: 0.032 +files: 0.024 +vnc: 0.010 +device: 0.010 +boot: 0.009 +performance: 0.008 +VMM: 0.007 +ppc: 0.005 +permissions: 0.005 +register: 0.005 +KVM: 0.005 +socket: 0.004 +debug: 0.004 +mistranslation: 0.003 +assembly: 0.002 +network: 0.002 +risc-v: 0.002 +hypervisor: 0.002 +kernel: 0.002 +TCG: 0.001 +i386: 0.001 +x86: 0.001 +arm: 0.001 +graphic: 0.000 +architecture: 0.000 + +Italian language (po) not updated diff --git a/results/classifier/118/review/2452 b/results/classifier/118/review/2452 new file mode 100644 index 000000000..598715a67 --- /dev/null +++ b/results/classifier/118/review/2452 @@ -0,0 +1,61 @@ +architecture: 0.957 +device: 0.890 +arm: 0.550 +performance: 0.549 +network: 0.421 +debug: 0.336 +graphic: 0.321 +vnc: 0.310 +boot: 0.288 +hypervisor: 0.223 +register: 0.173 +semantic: 0.165 +socket: 0.147 +assembly: 0.135 +ppc: 0.115 +i386: 0.083 +mistranslation: 0.081 +kernel: 0.074 +risc-v: 0.069 +VMM: 0.064 +peripherals: 0.060 +virtual: 0.057 +PID: 0.041 +user-level: 0.040 +permissions: 0.016 +TCG: 0.014 +x86: 0.005 +files: 0.002 +KVM: 0.000 +-------------------- +kernel: 0.879 +register: 0.665 +assembly: 0.655 +debug: 0.367 +x86: 0.359 +arm: 0.287 +virtual: 0.160 +user-level: 0.111 +hypervisor: 0.072 +architecture: 0.062 +i386: 0.057 +semantic: 0.049 +device: 0.048 +performance: 0.045 +peripherals: 0.037 +boot: 0.025 +TCG: 0.021 +files: 0.017 +KVM: 0.015 +ppc: 0.014 +risc-v: 0.012 +socket: 0.010 +VMM: 0.009 +PID: 0.007 +network: 0.007 +graphic: 0.004 +vnc: 0.002 +permissions: 0.001 +mistranslation: 0.001 + +memory allocation for AMDVIIOTLBEntry in amdvi_update_iotlb() diff --git a/results/classifier/118/review/2473 b/results/classifier/118/review/2473 new file mode 100644 index 000000000..a72e04c07 --- /dev/null +++ b/results/classifier/118/review/2473 @@ -0,0 +1,63 @@ +architecture: 0.955 +device: 0.820 +arm: 0.740 +performance: 0.644 +network: 0.509 +kernel: 0.347 +debug: 0.346 +boot: 0.304 +register: 0.303 +hypervisor: 0.273 +VMM: 0.224 +socket: 0.219 +vnc: 0.190 +mistranslation: 0.180 +semantic: 0.172 +ppc: 0.156 +PID: 0.145 +peripherals: 0.123 +graphic: 0.113 +files: 0.102 +TCG: 0.101 +assembly: 0.081 +permissions: 0.064 +virtual: 0.059 +risc-v: 0.048 +user-level: 0.031 +KVM: 0.026 +x86: 0.011 +i386: 0.003 +-------------------- +hypervisor: 0.975 +virtual: 0.968 +debug: 0.836 +assembly: 0.146 +architecture: 0.085 +arm: 0.081 +TCG: 0.046 +kernel: 0.042 +semantic: 0.032 +KVM: 0.029 +register: 0.028 +PID: 0.018 +user-level: 0.014 +files: 0.014 +performance: 0.009 +VMM: 0.007 +device: 0.006 +boot: 0.004 +graphic: 0.001 +risc-v: 0.001 +peripherals: 0.001 +network: 0.001 +socket: 0.001 +ppc: 0.001 +mistranslation: 0.000 +permissions: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-system-aarch64: Stop execution on unhandled exceptions +Additional information: + diff --git a/results/classifier/118/review/2484 b/results/classifier/118/review/2484 new file mode 100644 index 000000000..00f0a14e3 --- /dev/null +++ b/results/classifier/118/review/2484 @@ -0,0 +1,61 @@ +mistranslation: 0.962 +graphic: 0.911 +debug: 0.735 +network: 0.543 +arm: 0.484 +device: 0.477 +VMM: 0.391 +performance: 0.342 +kernel: 0.339 +architecture: 0.313 +risc-v: 0.301 +ppc: 0.301 +vnc: 0.269 +boot: 0.239 +peripherals: 0.227 +TCG: 0.176 +hypervisor: 0.169 +i386: 0.167 +PID: 0.167 +KVM: 0.158 +x86: 0.147 +semantic: 0.142 +socket: 0.123 +register: 0.118 +virtual: 0.097 +files: 0.083 +assembly: 0.081 +user-level: 0.057 +permissions: 0.033 +-------------------- +permissions: 0.877 +user-level: 0.195 +network: 0.163 +VMM: 0.056 +device: 0.055 +TCG: 0.049 +virtual: 0.029 +files: 0.028 +KVM: 0.026 +kernel: 0.025 +debug: 0.019 +peripherals: 0.019 +semantic: 0.014 +socket: 0.006 +assembly: 0.006 +x86: 0.006 +hypervisor: 0.006 +risc-v: 0.005 +architecture: 0.005 +PID: 0.004 +vnc: 0.004 +register: 0.003 +arm: 0.003 +graphic: 0.003 +boot: 0.002 +mistranslation: 0.002 +i386: 0.002 +ppc: 0.002 +performance: 0.001 + +Confusing query-gic-capabilities output in --without-default-devices config diff --git a/results/classifier/118/review/2499 b/results/classifier/118/review/2499 new file mode 100644 index 000000000..e988cd349 --- /dev/null +++ b/results/classifier/118/review/2499 @@ -0,0 +1,90 @@ +TCG: 0.846 +architecture: 0.742 +semantic: 0.735 +graphic: 0.664 +device: 0.625 +performance: 0.607 +socket: 0.554 +vnc: 0.546 +PID: 0.522 +peripherals: 0.510 +ppc: 0.508 +network: 0.485 +hypervisor: 0.456 +files: 0.441 +register: 0.419 +risc-v: 0.416 +kernel: 0.414 +virtual: 0.410 +x86: 0.408 +user-level: 0.378 +assembly: 0.322 +VMM: 0.305 +permissions: 0.264 +i386: 0.259 +debug: 0.218 +mistranslation: 0.198 +arm: 0.192 +boot: 0.138 +KVM: 0.120 +-------------------- +assembly: 0.575 +TCG: 0.164 +debug: 0.097 +performance: 0.084 +files: 0.081 +virtual: 0.060 +user-level: 0.053 +kernel: 0.028 +semantic: 0.025 +register: 0.024 +VMM: 0.018 +device: 0.012 +architecture: 0.011 +hypervisor: 0.007 +peripherals: 0.005 +PID: 0.005 +KVM: 0.004 +risc-v: 0.004 +boot: 0.003 +x86: 0.003 +permissions: 0.002 +graphic: 0.001 +arm: 0.001 +network: 0.001 +ppc: 0.001 +socket: 0.001 +vnc: 0.001 +mistranslation: 0.001 +i386: 0.001 + +m68k: fpu: fsave/frestore should be enabled for 68020/68030 +Description of problem: +valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception. + +I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences. + +``` diff +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index d5d2322329..92dc9d8563 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore) + gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE); + return; + } +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + SRC_EA(env, addr, OS_LONG, 0, NULL); + /* FIXME: check the state frame */ + } else { +@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave) + return; + } + +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + /* always write IDLE */ + TCGv idle = tcg_constant_i32(0x41000000); + DEST_EA(env, insn, OS_LONG, idle, NULL); +``` diff --git a/results/classifier/118/review/2515 b/results/classifier/118/review/2515 new file mode 100644 index 000000000..99d0767f1 --- /dev/null +++ b/results/classifier/118/review/2515 @@ -0,0 +1,106 @@ +register: 0.898 +TCG: 0.892 +user-level: 0.890 +peripherals: 0.883 +virtual: 0.877 +assembly: 0.873 +debug: 0.867 +risc-v: 0.862 +architecture: 0.857 +arm: 0.855 +permissions: 0.849 +graphic: 0.840 +KVM: 0.838 +ppc: 0.838 +performance: 0.833 +kernel: 0.828 +VMM: 0.824 +semantic: 0.822 +vnc: 0.821 +device: 0.811 +hypervisor: 0.811 +mistranslation: 0.810 +PID: 0.809 +boot: 0.801 +files: 0.765 +socket: 0.756 +network: 0.656 +i386: 0.561 +x86: 0.525 +-------------------- +virtual: 0.922 +debug: 0.807 +TCG: 0.224 +hypervisor: 0.121 +kernel: 0.114 +user-level: 0.074 +VMM: 0.068 +PID: 0.046 +register: 0.033 +files: 0.027 +risc-v: 0.021 +architecture: 0.018 +ppc: 0.015 +assembly: 0.015 +performance: 0.014 +semantic: 0.013 +device: 0.013 +socket: 0.010 +KVM: 0.009 +boot: 0.008 +network: 0.008 +graphic: 0.006 +permissions: 0.005 +vnc: 0.003 +peripherals: 0.003 +mistranslation: 0.001 +x86: 0.000 +arm: 0.000 +i386: 0.000 + +qemu -daemonize crashes on macOS with "NSPlaceholderDate initialize may have been in progress in another thread" +Description of problem: +Context: I build [an open source project](https://tsduck.io/) on several operating systems and architectures. For riscv64, s390x, ppc64, I build in emulated virtual machines. The three emulated OS work correctly when running qemu manually and the project is correctly built. + +Now, I want to automate the process in a script: for each target architecture, boot the VM (start qemu as a background process), connect to the VM using ssh, build the software, collect the binaries, shut down the VM. + +Starting the same qemu command as used interactively as a background process with `&` does not work and fails immediately, apparently because of the lack of stdin. So, I added option `-daemonize` (and removed `-nographic` because an error message says the two options are incompatible). + +Using `-daemonize` instead of `-nographic`, all qemu command immediately fail with the following error: + +``` +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. +``` +Steps to reproduce: +``` +$ qemu-system-riscv64 -machine virt -smp 8 -m 8192 -daemonize \ + -bios fw_jump.bin -kernel u-boot.bin \ + -device virtio-net-device,netdev=net \ + -netdev user,id=net,hostfwd=tcp::2233-:22 \ + -drive file=disk.qcow2,format=qcow2,if=virtio -device virtio-rng-pci +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1141]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + + +$ qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -daemonize \ + -drive file=disk.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \ + -device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,bootindex=1 \ + -nic user,hostfwd=tcp::2288-:22 +objc[1209]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1209]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. + + +$ qemu-system-ppc64 -smp 8 -m 8192 -daemonize \ + -drive file=disk.qcow2,format=qcow2 -nic user,hostfwd=tcp::2299-:22 +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-cfpc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-sbbc=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ibs=workaround +qemu-system-ppc64: warning: TCG doesn't support requested feature, cap-ccf-assist=on +objc[1166]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. +objc[1166]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. +``` + +All the above commands work correctly when using `-nographic` instead of `-daemonize`. The virtual disks are the same as in the interactive runs, with a fully configured Linux OS (Ubuntu or Debian). +Additional information: +From a [report from here](https://stackoverflow.com/questions/63041445/python-os-high-sierra-nsplaceholderdate-error), I tried to define the environment variable `OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES` before running qemu. The `[__NSPlaceholderDate initialize]` errors disappear but qemu still crashes immediately. diff --git a/results/classifier/118/review/2517 b/results/classifier/118/review/2517 new file mode 100644 index 000000000..ed60c213a --- /dev/null +++ b/results/classifier/118/review/2517 @@ -0,0 +1,61 @@ +architecture: 0.948 +device: 0.724 +performance: 0.481 +virtual: 0.383 +risc-v: 0.375 +mistranslation: 0.295 +debug: 0.290 +graphic: 0.266 +TCG: 0.249 +boot: 0.194 +KVM: 0.104 +vnc: 0.098 +semantic: 0.091 +hypervisor: 0.079 +VMM: 0.079 +PID: 0.072 +arm: 0.070 +permissions: 0.064 +register: 0.051 +user-level: 0.017 +i386: 0.017 +network: 0.013 +ppc: 0.008 +kernel: 0.006 +x86: 0.005 +assembly: 0.004 +files: 0.002 +peripherals: 0.001 +socket: 0.001 +-------------------- +virtual: 0.979 +hypervisor: 0.720 +performance: 0.235 +debug: 0.141 +KVM: 0.084 +kernel: 0.056 +socket: 0.027 +x86: 0.021 +risc-v: 0.016 +TCG: 0.013 +PID: 0.013 +device: 0.012 +user-level: 0.011 +VMM: 0.010 +semantic: 0.008 +assembly: 0.006 +ppc: 0.006 +network: 0.006 +register: 0.005 +architecture: 0.004 +files: 0.002 +i386: 0.002 +boot: 0.002 +arm: 0.002 +graphic: 0.002 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.001 +peripherals: 0.000 + +destroying a vCPU will leak its AddressSpaces diff --git a/results/classifier/118/review/2526 b/results/classifier/118/review/2526 new file mode 100644 index 000000000..358add7bd --- /dev/null +++ b/results/classifier/118/review/2526 @@ -0,0 +1,99 @@ +architecture: 0.939 +permissions: 0.900 +performance: 0.893 +graphic: 0.890 +TCG: 0.888 +files: 0.881 +arm: 0.861 +device: 0.859 +debug: 0.858 +KVM: 0.855 +assembly: 0.853 +user-level: 0.852 +register: 0.852 +peripherals: 0.840 +risc-v: 0.835 +mistranslation: 0.830 +virtual: 0.826 +semantic: 0.826 +socket: 0.823 +PID: 0.805 +vnc: 0.804 +kernel: 0.802 +ppc: 0.794 +hypervisor: 0.777 +network: 0.728 +boot: 0.723 +VMM: 0.678 +x86: 0.643 +i386: 0.560 +-------------------- +files: 0.426 +hypervisor: 0.400 +TCG: 0.116 +register: 0.052 +PID: 0.049 +architecture: 0.041 +kernel: 0.020 +virtual: 0.018 +permissions: 0.015 +semantic: 0.014 +debug: 0.013 +performance: 0.012 +user-level: 0.011 +device: 0.009 +boot: 0.004 +network: 0.004 +VMM: 0.004 +peripherals: 0.003 +assembly: 0.002 +graphic: 0.002 +socket: 0.002 +ppc: 0.002 +KVM: 0.002 +risc-v: 0.001 +mistranslation: 0.001 +vnc: 0.001 +arm: 0.001 +x86: 0.001 +i386: 0.000 + +qemu-system-aarch64: Build of system emulators with --static failed on aarch64 Ubuntu 22.04 for tests/unit/test-bitcnt +Description of problem: +Build Qemu got error: +``` +[1107/2870] Compiling C object tcg/libtcg_system.fa.p/perf.c.o +[1108/2870] Linking target tests/unit/test-bitcnt +FAILED: tests/unit/test-bitcnt +cc -o tests/unit/test-bitcnt tests/unit/test-bitcnt.p/test-bitcnt.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libevent-loop-base.fa libqom.fa -Wl,--no-whole-archive -static-pie -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libevent-loop-base.fa libqom.fa /usr/lib/aarch64-linux-gnu/libgio-2.0.a /usr/lib/aarch64-linux-gnu/libgmodule-2.0.a -pthread /usr/lib/aarch64-linux-gnu/libz.a -ldl /usr/lib/aarch64-linux-gnu/libblkid.a /usr/lib/aarch64-linux-gnu/libselinux.a /usr/lib/aarch64-linux-gnu/libsepol.a /usr/lib/aarch64-linux-gnu/libpcre2-8.a /usr/lib/aarch64-linux-gnu/libgobject-2.0.a /usr/lib/aarch64-linux-gnu/libffi.a /usr/lib/aarch64-linux-gnu/libglib-2.0.a -lm /usr/lib/aarch64-linux-gnu/libpcre.a -lmount -lmount -Wl,--end-group +/usr/bin/ld: cannot find -lmount: No such file or directory +/usr/bin/ld: cannot find -lmount: No such file or directory +collect2: error: ld returned 1 exit status +[1109/2870] Linking target tests/unit/test-qapi-util +FAILED: tests/unit/test-qapi-util +cc -o tests/unit/test-qapi-util tests/unit/test-qapi-util.p/test-qapi-util.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libevent-loop-base.fa libqom.fa -Wl,--no-whole-archive -static-pie -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libevent-loop-base.fa libqom.fa /usr/lib/aarch64-linux-gnu/libgio-2.0.a /usr/lib/aarch64-linux-gnu/libgmodule-2.0.a -pthread /usr/lib/aarch64-linux-gnu/libz.a -ldl /usr/lib/aarch64-linux-gnu/libblkid.a /usr/lib/aarch64-linux-gnu/libselinux.a /usr/lib/aarch64-linux-gnu/libsepol.a /usr/lib/aarch64-linux-gnu/libpcre2-8.a /usr/lib/aarch64-linux-gnu/libgobject-2.0.a /usr/lib/aarch64-linux-gnu/libffi.a /usr/lib/aarch64-linux-gnu/libglib-2.0.a -lm /usr/lib/aarch64-linux-gnu/libpcre.a -lmount -lmount -Wl,--end-group +/usr/bin/ld: cannot find -lmount: No such file or directory +/usr/bin/ld: cannot find -lmount: No such file or directory +collect2: error: ld returned 1 exit status +[1110/2870] Linking target tests/unit/check-qom-interface +FAILED: tests/unit/check-qom-interface +cc -o tests/unit/check-qom-interface tests/unit/check-qom-interface.p/check-qom-interface.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libevent-loop-base.fa libqom.fa -Wl,--no-whole-archive -static-pie -fstack-protector-strong -Wl,-z,relro -Wl,-z,now -Wl,--start-group libqemuutil.a subprojects/libvhost-user/libvhost-user-glib.a subprojects/libvhost-user/libvhost-user.a libevent-loop-base.fa libqom.fa /usr/lib/aarch64-linux-gnu/libgio-2.0.a /usr/lib/aarch64-linux-gnu/libgmodule-2.0.a -pthread /usr/lib/aarch64-linux-gnu/libz.a -ldl /usr/lib/aarch64-linux-gnu/libblkid.a /usr/lib/aarch64-linux-gnu/libselinux.a /usr/lib/aarch64-linux-gnu/libsepol.a /usr/lib/aarch64-linux-gnu/libpcre2-8.a /usr/lib/aarch64-linux-gnu/libgobject-2.0.a /usr/lib/aarch64-linux-gnu/libffi.a /usr/lib/aarch64-linux-gnu/libglib-2.0.a -lm /usr/lib/aarch64-linux-gnu/libpcre.a -lmount -lmount -Wl,--end-group +/usr/bin/ld: cannot find -lmount: No such file or directory +/usr/bin/ld: cannot find -lmount: No such file or directory +collect2: error: ld returned 1 exit status +``` +After install libmount-dev, this error is still there. +If we just run: +``` +./configure --target-list=aarch64-softmmu --enable-kvm +make -16 +``` +This works well. +Steps to reproduce: +``` +1. ./configure --target-list=aarch64-softmmu --enable-kvm --disable-brlapi --disable-docs --disable-curses --disable-gtk --disable-opengl --disable-sdl --disable-spice --disable-vte --disable-vnc --disable-vnc-jpeg --disable-png --disable-vnc-sasl --disable-auth-pam --disable-glusterfs --disable-libiscsi --disable-libnfs --disable-libssh --disable-bzip2 --disable-lzo --disable-snappy --disable-slirp --disable-libusb --disable-usb-redir --static --disable-qom-cast-debug --disable-libudev --disable-curl --disable-rdma --disable-tools --enable-virtfs --disable-bsd-user --disable-linux-user --disable-sparse --disable-vde --disable-nettle --disable-xen --disable-linux-aio --disable-capstone --disable-virglrenderer --disable-replication --disable-smartcard --disable-guest-agent --disable-guest-agent-msi --disable-vvfat --disable-vdi --disable-qed --disable-qcow1 --disable-bochs --disable-cloop --disable-dmg --disable-parallels --disable-colo-proxy --disable-debug-graph-lock --disable-hexagon-idef-parser --disable-libdw --disable-pipewire --disable-pixman --disable-relocatable --disable-rutabaga-gfx --disable-vmdk --disable-avx512bw --disable-vpc --disable-vhdx --disable-hv-balloon + +2.make -j16 +``` +Additional information: + diff --git a/results/classifier/118/review/2534 b/results/classifier/118/review/2534 new file mode 100644 index 000000000..736d49cda --- /dev/null +++ b/results/classifier/118/review/2534 @@ -0,0 +1,70 @@ +register: 0.934 +graphic: 0.919 +device: 0.915 +architecture: 0.879 +debug: 0.863 +PID: 0.855 +files: 0.845 +kernel: 0.805 +performance: 0.800 +boot: 0.769 +mistranslation: 0.737 +socket: 0.726 +TCG: 0.716 +permissions: 0.713 +vnc: 0.688 +VMM: 0.660 +semantic: 0.655 +ppc: 0.621 +user-level: 0.601 +x86: 0.548 +risc-v: 0.536 +arm: 0.492 +i386: 0.473 +network: 0.426 +hypervisor: 0.390 +virtual: 0.359 +peripherals: 0.235 +assembly: 0.221 +KVM: 0.076 +-------------------- +virtual: 0.949 +debug: 0.523 +kernel: 0.299 +user-level: 0.174 +TCG: 0.095 +files: 0.044 +hypervisor: 0.032 +device: 0.020 +register: 0.014 +PID: 0.012 +socket: 0.007 +assembly: 0.005 +boot: 0.005 +semantic: 0.004 +performance: 0.003 +architecture: 0.003 +network: 0.002 +peripherals: 0.002 +vnc: 0.002 +VMM: 0.002 +x86: 0.001 +graphic: 0.001 +KVM: 0.001 +i386: 0.001 +permissions: 0.001 +ppc: 0.001 +risc-v: 0.001 +arm: 0.000 +mistranslation: 0.000 + +Solaris cannot be power offed with system_powerdown on qemu-system-sparc +Description of problem: +When a `system_powerdown` is done in the QEMU Monitor, nothing happens. Also happens with `qemu-system-sparc.exe` version 9.1.0-rc3, that is, it's not fixed in newer versions. Looking at [sun4m.c](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/sparc/sun4m.c#L451) code, it registers a system_powerdown handler, but it's not working. +Steps to reproduce: +1. Start the machine with the command line above and wait for the complete OS initialization +2. Open the machine monitor +3. Do a `system_powerdown` command +4. Nothing will happen +Additional information: + diff --git a/results/classifier/118/review/255 b/results/classifier/118/review/255 new file mode 100644 index 000000000..95d819c57 --- /dev/null +++ b/results/classifier/118/review/255 @@ -0,0 +1,61 @@ +architecture: 0.887 +debug: 0.813 +performance: 0.751 +mistranslation: 0.744 +device: 0.591 +graphic: 0.552 +semantic: 0.501 +boot: 0.159 +user-level: 0.120 +register: 0.076 +assembly: 0.076 +peripherals: 0.065 +permissions: 0.052 +network: 0.035 +ppc: 0.031 +PID: 0.031 +TCG: 0.028 +arm: 0.028 +virtual: 0.026 +VMM: 0.022 +risc-v: 0.022 +files: 0.018 +socket: 0.012 +vnc: 0.008 +hypervisor: 0.004 +kernel: 0.002 +KVM: 0.002 +i386: 0.002 +x86: 0.001 +-------------------- +debug: 0.057 +kernel: 0.056 +assembly: 0.049 +virtual: 0.024 +TCG: 0.023 +files: 0.023 +semantic: 0.015 +architecture: 0.012 +VMM: 0.009 +user-level: 0.007 +performance: 0.005 +register: 0.003 +device: 0.003 +PID: 0.003 +peripherals: 0.003 +boot: 0.003 +graphic: 0.002 +socket: 0.001 +hypervisor: 0.001 +KVM: 0.001 +network: 0.001 +permissions: 0.001 +mistranslation: 0.000 +vnc: 0.000 +ppc: 0.000 +arm: 0.000 +risc-v: 0.000 +i386: 0.000 +x86: 0.000 + +Build on sparc64 fails with "undefined reference to `fdt_check_full'" diff --git a/results/classifier/118/review/2560 b/results/classifier/118/review/2560 new file mode 100644 index 000000000..7794de142 --- /dev/null +++ b/results/classifier/118/review/2560 @@ -0,0 +1,165 @@ +register: 0.903 +permissions: 0.893 +risc-v: 0.887 +device: 0.884 +performance: 0.883 +architecture: 0.883 +peripherals: 0.882 +semantic: 0.881 +mistranslation: 0.866 +debug: 0.855 +assembly: 0.847 +user-level: 0.845 +arm: 0.844 +graphic: 0.842 +socket: 0.841 +TCG: 0.838 +boot: 0.834 +x86: 0.834 +files: 0.826 +virtual: 0.823 +PID: 0.818 +network: 0.804 +VMM: 0.798 +vnc: 0.797 +ppc: 0.785 +kernel: 0.742 +hypervisor: 0.693 +KVM: 0.650 +i386: 0.447 +-------------------- +x86: 0.890 +debug: 0.864 +user-level: 0.214 +assembly: 0.118 +architecture: 0.105 +performance: 0.071 +PID: 0.062 +files: 0.042 +TCG: 0.040 +virtual: 0.026 +hypervisor: 0.011 +semantic: 0.006 +register: 0.006 +kernel: 0.003 +boot: 0.003 +device: 0.002 +graphic: 0.002 +arm: 0.001 +VMM: 0.001 +permissions: 0.001 +risc-v: 0.001 +peripherals: 0.001 +ppc: 0.001 +mistranslation: 0.001 +network: 0.001 +KVM: 0.000 +vnc: 0.000 +socket: 0.000 +i386: 0.000 + +Go garbage collector crashes when using qemu-x86_64 on an aarch64 host +Description of problem: +Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something? + +The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`. + +Output from Go when it crashes: + +``` +$ sudo chroot . go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0xa95b29?, 0x797b1e2a383c?}) + runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c +runtime.(*lfstack).push(0x0?, 0xc0005041c0?) + runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45 +runtime.(*spanSetBlockAlloc).free(...) + runtime/mspanset.go:322 +runtime.(*spanSet).reset(0xf46980) + runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219 +runtime.finishsweep_m() + runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd +runtime.gcStart.func2() + runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f +runtime.systemstack(0x0) + runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a +```` +Steps to reproduce: +0. Use an aarch64 host system! + +1. Set up binfmt to use qemu-x86_64: + +``` +$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 +enabled +interpreter /usr/bin/qemu-x86_64 +flags: OCF +offset 0 +magic 7f454c4602010100000000000000000002003e00 +mask fffffffffffefe00fffffffffffffffffeffffff +``` + +2. Download/extract x86_64 rootfs: + +``` +$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz +``` + +3. Create example app in the x86_64 rootfs: + +``` +package main + +func main() { +} +``` + +4. Build using chroot: + +``` +$ sudo chroot /path/to/x86_64/rootfs apk add go +$ sudo chroot /path/to/x86_64/rootfs go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push +... +``` + +5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU: + +``` +$ sudo chroot . env GOGC=off go build main.go +# might have to mount /dev to build successfully, but Go doesn't panic! +``` +Additional information: +I've bisected this exact crash/failure to: + +``` +commit 2952b642a555207748dd961fcbfdc48f198eebb6 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Feb 13 10:20:27 2024 -1000 + + linux-user: Split out do_munmap + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +Though a different crash starts happening at the commit before that one: + +``` +commit ad87d26e6bb13257409f412224c862fc54025e8b +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jan 2 12:57:55 2024 +1100 + + linux-user: Do early mmap placement only for reserved_va + + For reserved_va, place all non-fixed maps then proceed + as for MAP_FIXED. + + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +FYI @rth7680 diff --git a/results/classifier/118/review/257 b/results/classifier/118/review/257 new file mode 100644 index 000000000..d0db5c180 --- /dev/null +++ b/results/classifier/118/review/257 @@ -0,0 +1,61 @@ +architecture: 0.944 +device: 0.465 +network: 0.361 +files: 0.354 +mistranslation: 0.340 +debug: 0.291 +graphic: 0.265 +arm: 0.243 +semantic: 0.240 +performance: 0.196 +PID: 0.191 +boot: 0.158 +permissions: 0.143 +peripherals: 0.136 +virtual: 0.135 +user-level: 0.131 +ppc: 0.120 +register: 0.098 +risc-v: 0.082 +vnc: 0.071 +TCG: 0.067 +assembly: 0.037 +VMM: 0.034 +socket: 0.019 +hypervisor: 0.017 +i386: 0.009 +kernel: 0.007 +x86: 0.004 +KVM: 0.003 +-------------------- +semantic: 0.065 +files: 0.058 +virtual: 0.057 +debug: 0.037 +x86: 0.034 +user-level: 0.023 +network: 0.009 +arm: 0.008 +architecture: 0.007 +kernel: 0.007 +register: 0.006 +TCG: 0.005 +assembly: 0.004 +VMM: 0.004 +device: 0.002 +hypervisor: 0.002 +PID: 0.002 +peripherals: 0.002 +i386: 0.002 +graphic: 0.001 +risc-v: 0.001 +performance: 0.001 +boot: 0.001 +ppc: 0.001 +socket: 0.001 +KVM: 0.001 +permissions: 0.000 +mistranslation: 0.000 +vnc: 0.000 + +[Archlinux][git]With git revision e58c7a3b, packaging with meson install is broken. diff --git a/results/classifier/118/review/2582 b/results/classifier/118/review/2582 new file mode 100644 index 000000000..0120f43a9 --- /dev/null +++ b/results/classifier/118/review/2582 @@ -0,0 +1,83 @@ +semantic: 0.962 +virtual: 0.882 +kernel: 0.874 +architecture: 0.842 +ppc: 0.828 +device: 0.784 +graphic: 0.771 +PID: 0.707 +permissions: 0.687 +vnc: 0.674 +KVM: 0.625 +VMM: 0.561 +debug: 0.546 +risc-v: 0.511 +network: 0.506 +performance: 0.504 +register: 0.501 +socket: 0.498 +TCG: 0.370 +hypervisor: 0.359 +files: 0.355 +boot: 0.327 +peripherals: 0.302 +arm: 0.292 +assembly: 0.274 +x86: 0.263 +mistranslation: 0.252 +i386: 0.186 +user-level: 0.160 +-------------------- +kernel: 0.973 +KVM: 0.942 +virtual: 0.940 +hypervisor: 0.589 +assembly: 0.562 +debug: 0.470 +semantic: 0.152 +TCG: 0.073 +register: 0.063 +files: 0.035 +PID: 0.020 +device: 0.020 +socket: 0.013 +x86: 0.010 +architecture: 0.008 +network: 0.006 +vnc: 0.005 +performance: 0.005 +boot: 0.003 +VMM: 0.003 +user-level: 0.002 +peripherals: 0.002 +graphic: 0.002 +risc-v: 0.002 +permissions: 0.002 +i386: 0.001 +mistranslation: 0.001 +arm: 0.000 +ppc: 0.000 + +CR4.VMX leaks from L1 into L2 on Intel VMX +Description of problem: +In a nested virtualization setting, `savevm` can cause CR4 bits from leaking from L1 into L2. This causes general-protection faults in certain guests. + +The L2 guest executes this code: + +``` +mov rax, cr4 ; Get CR4 +mov rcx, rax ; Remember the old value +btc rax, 7 ; Toggle CR4.PGE +mov cr4, rax ; #GP! <- Shouldn't happen! +mov cr4, rcx ; Restore old value +``` + +If the guest code is interrupted at the right time (e.g. via `savevm`), Qemu marks CR4 dirty while the guest executes L2 code. Due to really complicated KVM semantics, this will result in L1 CR4 bits (VMXE) leaking into the L2 guest and the L2 will die with a GP: + +Instead of the expected CR4 value, the L2 guest reads a value with VMXE set. When it tries to write this back into CR4, this triggers the general protection fault. +Steps to reproduce: +This is only an issue on **Intel** systems. + +# +Additional information: +See also this discussion where we discussed a (flawed) approach to fixing this in KVM: https://lore.kernel.org/lkml/Zh6WlOB8CS-By3DQ@google.com/t/ diff --git a/results/classifier/118/review/2586 b/results/classifier/118/review/2586 new file mode 100644 index 000000000..e7c4347f8 --- /dev/null +++ b/results/classifier/118/review/2586 @@ -0,0 +1,63 @@ +x86: 0.987 +architecture: 0.922 +kernel: 0.743 +device: 0.705 +semantic: 0.637 +graphic: 0.503 +register: 0.313 +peripherals: 0.251 +arm: 0.230 +ppc: 0.220 +performance: 0.202 +debug: 0.197 +mistranslation: 0.177 +socket: 0.168 +files: 0.150 +network: 0.148 +vnc: 0.140 +assembly: 0.139 +boot: 0.115 +virtual: 0.091 +PID: 0.082 +hypervisor: 0.073 +permissions: 0.060 +user-level: 0.053 +VMM: 0.033 +TCG: 0.028 +risc-v: 0.014 +i386: 0.007 +KVM: 0.005 +-------------------- +kernel: 0.939 +virtual: 0.748 +hypervisor: 0.730 +x86: 0.638 +files: 0.091 +register: 0.050 +TCG: 0.045 +debug: 0.036 +semantic: 0.014 +user-level: 0.012 +network: 0.008 +device: 0.006 +architecture: 0.005 +assembly: 0.005 +PID: 0.004 +KVM: 0.004 +boot: 0.004 +socket: 0.002 +graphic: 0.002 +peripherals: 0.002 +VMM: 0.002 +ppc: 0.002 +performance: 0.001 +permissions: 0.001 +i386: 0.001 +vnc: 0.000 +mistranslation: 0.000 +risc-v: 0.000 +arm: 0.000 + +qemu-system-x86_64: IGD "legacy mode" support with Q35? +Additional information: +Detailed discussion on https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12103 diff --git a/results/classifier/118/review/2600 b/results/classifier/118/review/2600 new file mode 100644 index 000000000..65a02b30f --- /dev/null +++ b/results/classifier/118/review/2600 @@ -0,0 +1,61 @@ +mistranslation: 0.929 +device: 0.836 +user-level: 0.766 +performance: 0.748 +network: 0.647 +semantic: 0.558 +graphic: 0.459 +architecture: 0.432 +debug: 0.420 +permissions: 0.335 +arm: 0.334 +files: 0.329 +hypervisor: 0.274 +boot: 0.270 +virtual: 0.219 +kernel: 0.195 +register: 0.185 +vnc: 0.178 +ppc: 0.172 +peripherals: 0.156 +assembly: 0.095 +socket: 0.080 +i386: 0.065 +x86: 0.050 +risc-v: 0.049 +TCG: 0.027 +VMM: 0.025 +KVM: 0.015 +PID: 0.007 +-------------------- +virtual: 0.966 +hypervisor: 0.962 +user-level: 0.789 +debug: 0.104 +x86: 0.049 +KVM: 0.043 +performance: 0.041 +semantic: 0.030 +TCG: 0.029 +i386: 0.020 +files: 0.017 +assembly: 0.013 +device: 0.010 +kernel: 0.010 +permissions: 0.005 +architecture: 0.005 +boot: 0.005 +register: 0.004 +VMM: 0.004 +arm: 0.003 +ppc: 0.002 +network: 0.002 +graphic: 0.002 +peripherals: 0.002 +PID: 0.002 +socket: 0.001 +risc-v: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +qemu-user MAP_SHARED TB invalidation diff --git a/results/classifier/118/review/2605 b/results/classifier/118/review/2605 new file mode 100644 index 000000000..53b9cc667 --- /dev/null +++ b/results/classifier/118/review/2605 @@ -0,0 +1,61 @@ +architecture: 0.902 +device: 0.816 +arm: 0.729 +performance: 0.660 +x86: 0.583 +network: 0.443 +permissions: 0.417 +files: 0.378 +VMM: 0.335 +semantic: 0.313 +hypervisor: 0.302 +register: 0.301 +mistranslation: 0.296 +socket: 0.280 +graphic: 0.239 +risc-v: 0.218 +vnc: 0.208 +peripherals: 0.180 +PID: 0.179 +assembly: 0.165 +user-level: 0.143 +debug: 0.137 +boot: 0.110 +virtual: 0.105 +kernel: 0.087 +TCG: 0.087 +KVM: 0.045 +ppc: 0.024 +i386: 0.012 +-------------------- +architecture: 0.183 +virtual: 0.063 +VMM: 0.061 +device: 0.043 +arm: 0.037 +files: 0.036 +kernel: 0.029 +user-level: 0.024 +semantic: 0.015 +assembly: 0.014 +hypervisor: 0.007 +boot: 0.006 +TCG: 0.004 +KVM: 0.003 +debug: 0.003 +risc-v: 0.003 +peripherals: 0.003 +PID: 0.002 +vnc: 0.002 +socket: 0.002 +performance: 0.001 +graphic: 0.001 +ppc: 0.001 +permissions: 0.001 +register: 0.000 +mistranslation: 0.000 +x86: 0.000 +network: 0.000 +i386: 0.000 + +amd64/v4 support diff --git a/results/classifier/118/review/2610 b/results/classifier/118/review/2610 new file mode 100644 index 000000000..8f62f7ef5 --- /dev/null +++ b/results/classifier/118/review/2610 @@ -0,0 +1,61 @@ +mistranslation: 0.996 +device: 0.780 +files: 0.771 +graphic: 0.669 +assembly: 0.571 +network: 0.561 +kernel: 0.521 +vnc: 0.518 +ppc: 0.504 +semantic: 0.499 +debug: 0.495 +arm: 0.490 +architecture: 0.486 +register: 0.477 +performance: 0.459 +boot: 0.434 +PID: 0.405 +risc-v: 0.356 +socket: 0.346 +hypervisor: 0.254 +peripherals: 0.226 +TCG: 0.213 +user-level: 0.202 +virtual: 0.198 +VMM: 0.195 +permissions: 0.080 +i386: 0.079 +x86: 0.050 +KVM: 0.049 +-------------------- +user-level: 0.345 +debug: 0.197 +files: 0.090 +virtual: 0.072 +kernel: 0.049 +mistranslation: 0.038 +device: 0.035 +semantic: 0.029 +network: 0.027 +assembly: 0.018 +peripherals: 0.017 +x86: 0.017 +boot: 0.015 +register: 0.013 +permissions: 0.010 +hypervisor: 0.009 +risc-v: 0.008 +socket: 0.007 +ppc: 0.007 +performance: 0.006 +TCG: 0.006 +i386: 0.005 +PID: 0.004 +vnc: 0.004 +KVM: 0.003 +VMM: 0.003 +architecture: 0.002 +arm: 0.001 +graphic: 0.001 + +pl011: incorrect IBRD_MASK and FBRD_MASK diff --git a/results/classifier/118/review/2630 b/results/classifier/118/review/2630 new file mode 100644 index 000000000..6da3fcf86 --- /dev/null +++ b/results/classifier/118/review/2630 @@ -0,0 +1,61 @@ +mistranslation: 0.839 +debug: 0.587 +boot: 0.481 +performance: 0.441 +risc-v: 0.424 +graphic: 0.401 +device: 0.393 +ppc: 0.383 +VMM: 0.371 +permissions: 0.358 +TCG: 0.343 +KVM: 0.321 +PID: 0.318 +semantic: 0.312 +vnc: 0.281 +architecture: 0.272 +peripherals: 0.258 +register: 0.249 +hypervisor: 0.240 +arm: 0.234 +i386: 0.232 +network: 0.186 +virtual: 0.165 +socket: 0.160 +user-level: 0.157 +x86: 0.148 +kernel: 0.137 +files: 0.130 +assembly: 0.043 +-------------------- +user-level: 0.721 +debug: 0.074 +virtual: 0.049 +semantic: 0.013 +risc-v: 0.012 +PID: 0.011 +VMM: 0.011 +performance: 0.010 +files: 0.009 +architecture: 0.005 +device: 0.004 +network: 0.004 +ppc: 0.004 +kernel: 0.003 +KVM: 0.003 +vnc: 0.003 +x86: 0.002 +boot: 0.002 +i386: 0.002 +socket: 0.002 +hypervisor: 0.002 +TCG: 0.002 +graphic: 0.002 +peripherals: 0.001 +arm: 0.001 +mistranslation: 0.001 +register: 0.001 +assembly: 0.000 +permissions: 0.000 + +Issue template broken diff --git a/results/classifier/118/review/2638 b/results/classifier/118/review/2638 new file mode 100644 index 000000000..9ffd14e1c --- /dev/null +++ b/results/classifier/118/review/2638 @@ -0,0 +1,77 @@ +mistranslation: 0.992 +device: 0.777 +socket: 0.720 +network: 0.704 +kernel: 0.652 +permissions: 0.626 +graphic: 0.587 +semantic: 0.586 +files: 0.580 +register: 0.577 +debug: 0.489 +KVM: 0.489 +performance: 0.454 +ppc: 0.452 +PID: 0.436 +risc-v: 0.433 +boot: 0.424 +architecture: 0.416 +arm: 0.405 +hypervisor: 0.395 +i386: 0.379 +x86: 0.362 +user-level: 0.337 +assembly: 0.304 +peripherals: 0.297 +TCG: 0.267 +vnc: 0.210 +VMM: 0.166 +virtual: 0.113 +-------------------- +permissions: 0.598 +TCG: 0.161 +risc-v: 0.161 +VMM: 0.131 +kernel: 0.089 +files: 0.082 +register: 0.063 +KVM: 0.056 +debug: 0.047 +x86: 0.045 +socket: 0.044 +PID: 0.041 +semantic: 0.027 +user-level: 0.026 +i386: 0.025 +vnc: 0.023 +virtual: 0.023 +hypervisor: 0.014 +network: 0.013 +ppc: 0.013 +peripherals: 0.012 +arm: 0.008 +device: 0.007 +boot: 0.006 +architecture: 0.003 +graphic: 0.003 +assembly: 0.002 +mistranslation: 0.002 +performance: 0.002 + +Incorrect SPDX license expression +Description of problem: +In the source code, the syntax of license expressions after the keyword SPDX-License-Identifier is not always correct. + +"GPL-2.0" should be "GPL-2.0-only" + +"GPL-2.0 WITH Linux-syscall-note" should be "GPL-2.0-only WITH Linux-syscall-note" + +"GPL-2.0+" should be "GPL-2.0-or-later" + +"GPL-2.0+ WITH Linux-syscall-note" should be "GPL-2.0-or-later WITH Linux-syscall-note" + +"GPL-v2-only" should be "GPL-2.0-only" + +"LGPL-2.1+" should be "LGPL-2.1-or-later" + +"MIT CC0-1.0" should be "MIT" diff --git a/results/classifier/118/review/2639 b/results/classifier/118/review/2639 new file mode 100644 index 000000000..4211ea553 --- /dev/null +++ b/results/classifier/118/review/2639 @@ -0,0 +1,82 @@ +architecture: 0.832 +debug: 0.828 +graphic: 0.697 +device: 0.599 +ppc: 0.479 +performance: 0.371 +vnc: 0.360 +semantic: 0.351 +risc-v: 0.323 +socket: 0.307 +kernel: 0.275 +PID: 0.271 +arm: 0.267 +network: 0.250 +user-level: 0.242 +mistranslation: 0.228 +files: 0.206 +register: 0.206 +permissions: 0.202 +hypervisor: 0.194 +x86: 0.177 +peripherals: 0.171 +i386: 0.166 +VMM: 0.130 +TCG: 0.130 +virtual: 0.095 +boot: 0.094 +KVM: 0.071 +assembly: 0.061 +-------------------- +debug: 0.995 +hypervisor: 0.395 +kernel: 0.258 +x86: 0.186 +virtual: 0.087 +PID: 0.072 +files: 0.056 +TCG: 0.043 +boot: 0.024 +register: 0.020 +assembly: 0.016 +device: 0.012 +i386: 0.010 +user-level: 0.008 +arm: 0.008 +ppc: 0.008 +peripherals: 0.006 +semantic: 0.005 +graphic: 0.005 +architecture: 0.005 +performance: 0.004 +network: 0.004 +VMM: 0.003 +socket: 0.002 +KVM: 0.002 +risc-v: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +[Regression] v9.1.1: hw/audio/hda audio output stream closes (SPICE) +Description of problem: +Beginning with QEMU 9.1.1, SPICE is unable to route audio from the guest to host. This affects `virt-viewer` as well as `Looking Glass`. Reverting packages to 9.1.0 restores functionality. + +Reported at [Arch Linux forums](https://bbs.archlinux.org/viewtopic.php?id=300475) and [Looking Glass discord](https://discord.com/channels/804108879436316733/1298405109210022038) + +---- + +I've confirmed https://gitlab.com/qemu-project/qemu/-/commit/6d03242a7e47815ed56687ecd13f683d8da3f2fe caused the regression, applying reverse patch to 9.1.1 resolves the issue +Additional information: +Debugging output from the [Looking Glass discord](https://discord.com/channels/804108879436316733/1298405109210022038/1298669405118664767): +``` +00:00:00.633 [I] main.c:1735 | lg_run | Starting session +[New Thread 0x7fffd12006c0 (LWP 10071)] +[New Thread 0x7fffc7e006c0 (LWP 10072)] +00:00:00.633 [I] main.c:553 | main_frameThread | Using DMA buffer support +00:00:01.339 [I] main.c:710 | main_frameThread | Format: FRAME_TYPE_BGRA 2560x1400 (2560x1400) stride:2560 pitch:10240 rotation:0 hdr:0 pq:0 + +Thread 2 "spiceThread" received signal SIGPIPE, Broken pipe. +[Switching to Thread 0x7fffdba006c0 (LWP 10024)] +0x00007ffff712a6ea in send () from /usr/lib/libc.so.6 +``` diff --git a/results/classifier/118/review/2641 b/results/classifier/118/review/2641 new file mode 100644 index 000000000..bcf019abc --- /dev/null +++ b/results/classifier/118/review/2641 @@ -0,0 +1,61 @@ +user-level: 0.949 +graphic: 0.349 +mistranslation: 0.243 +semantic: 0.242 +device: 0.234 +performance: 0.202 +ppc: 0.141 +virtual: 0.122 +arm: 0.103 +register: 0.072 +vnc: 0.050 +TCG: 0.044 +permissions: 0.043 +KVM: 0.041 +socket: 0.040 +VMM: 0.039 +architecture: 0.035 +kernel: 0.027 +risc-v: 0.025 +network: 0.025 +i386: 0.023 +PID: 0.020 +peripherals: 0.017 +boot: 0.017 +debug: 0.012 +files: 0.010 +hypervisor: 0.006 +x86: 0.004 +assembly: 0.003 +-------------------- +user-level: 0.792 +kernel: 0.480 +files: 0.253 +debug: 0.141 +x86: 0.049 +virtual: 0.027 +TCG: 0.020 +semantic: 0.010 +ppc: 0.004 +VMM: 0.004 +i386: 0.003 +KVM: 0.003 +boot: 0.002 +risc-v: 0.002 +assembly: 0.002 +device: 0.001 +performance: 0.001 +graphic: 0.001 +socket: 0.001 +PID: 0.001 +arm: 0.001 +hypervisor: 0.001 +architecture: 0.001 +network: 0.001 +vnc: 0.001 +mistranslation: 0.000 +peripherals: 0.000 +permissions: 0.000 +register: 0.000 + +Possible DEREF_OF_NULL in linux-user/syscall.c diff --git a/results/classifier/118/review/2644 b/results/classifier/118/review/2644 new file mode 100644 index 000000000..2a1b74c86 --- /dev/null +++ b/results/classifier/118/review/2644 @@ -0,0 +1,126 @@ +user-level: 0.840 +mistranslation: 0.813 +peripherals: 0.789 +device: 0.784 +KVM: 0.767 +risc-v: 0.758 +graphic: 0.758 +performance: 0.753 +boot: 0.741 +hypervisor: 0.738 +virtual: 0.738 +permissions: 0.717 +register: 0.714 +x86: 0.711 +semantic: 0.703 +TCG: 0.699 +vnc: 0.686 +arm: 0.679 +VMM: 0.669 +i386: 0.662 +files: 0.660 +network: 0.653 +architecture: 0.642 +debug: 0.634 +ppc: 0.630 +assembly: 0.627 +PID: 0.576 +socket: 0.574 +kernel: 0.538 +-------------------- +boot: 0.846 +virtual: 0.605 +kernel: 0.528 +hypervisor: 0.437 +KVM: 0.193 +debug: 0.165 +x86: 0.105 +PID: 0.063 +files: 0.042 +TCG: 0.040 +register: 0.023 +i386: 0.019 +ppc: 0.010 +assembly: 0.010 +device: 0.010 +architecture: 0.005 +performance: 0.005 +user-level: 0.005 +semantic: 0.004 +VMM: 0.002 +arm: 0.002 +socket: 0.002 +permissions: 0.001 +network: 0.001 +graphic: 0.001 +risc-v: 0.001 +peripherals: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +openbsd 7.5 crashes with QEMU since "virtio-pci: Add lookup subregion of VirtIOPCIRegion MR" +Description of problem: +Attempt to boot OpenBSD 7.5 in QEMU current git HEAD fdf250e5a37830615e324017cb3a503e84b3712c. + +It immediately aborts with + +``` +Thread 6 (Thread 0x7fe06d2006c0 (LWP 2797401) "CPU 0/KVM"): +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 +#1 0x00007fe0764476d3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78 +#2 0x00007fe0763eec4e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007fe0763d6902 in __GI_abort () at abort.c:79 +#4 0x00007fe0763d681e in __assert_fail_base (fmt=0x7fe076562b98 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:94 +#5 0x00007fe0763e6d87 in __assert_fail (assertion=assertion@entry=0x55a00b998b4d "mrs.mr", file=file@entry=0x55a00b998b33 "../hw/virtio/virtio-pci.c", line=line@entry=620, function=function@entry=0x55a00bb596b0 <__PRETTY_FUNCTION__.13> "virtio_address_space_lookup") at assert.c:103 +#6 0x000055a00b49d368 in virtio_address_space_lookup (proxy=proxy@entry=0x55a0213a59d0, off=off@entry=0x7fe06d1f3370, len=len@entry=1) at ../hw/virtio/virtio-pci.c:620 +#7 0x000055a00b4a127f in virtio_address_space_write (proxy=0x55a0213a59d0, addr=<optimized out>, buf=0x55a0213b32c8 "", len=1) at ../hw/virtio/virtio-pci.c:654 +#8 virtio_write_config (pci_dev=<optimized out>, address=<optimized out>, val=<optimized out>, len=<optimized out>) at ../hw/virtio/virtio-pci.c:790 +#9 0x000055a00b6edc30 in memory_region_write_accessor (mr=0x55a01fa1b470, addr=4194520, value=<optimized out>, size=1, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../system/memory.c:497 +#10 0x000055a00b6ed4be in access_with_adjusted_size (addr=addr@entry=4194520, value=0x7fe06d1f34c8, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55a00b6edbb0 <memory_region_write_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 +#11 0x000055a00b6ed7fa in memory_region_dispatch_write (mr=mr@entry=0x55a01fa1b470, addr=addr@entry=4194520, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1560 +#12 0x000055a00b6f593f in flatview_write_continue_step (attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028 "", mr_addr=4194520, l=l@entry=0x7fe06d1f3590, mr=0x55a01fa1b470, len=1) at ../system/physmem.c:2786 +#13 0x000055a00b6f6058 in flatview_write_continue (fv=0x7fdf505079f0, addr=2956984536, attrs=..., ptr=0xb04000d8, len=1, mr_addr=<optimized out>, l=<optimized out>, mr=<optimized out>) at .--Type <RET> for more, q to quit, c to continue without paging-- +./system/physmem.c:2816 +#14 flatview_write (fv=0x7fdf505079f0, addr=addr@entry=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=len@entry=1) at ../system/physmem.c:2847 +#15 0x000055a00b6f97a1 in address_space_write (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=..., buf=0x7fe07988e028, len=1) at ../system/physmem.c:2967 +#16 address_space_rw (as=0x55a00ca34600 <address_space_memory>, addr=2956984536, attrs=attrs@entry=..., buf=buf@entry=0x7fe07988e028, len=1, is_write=<optimized out>) at ../system/physmem.c:2977 +#17 0x000055a00b75c256 in kvm_cpu_exec (cpu=cpu@entry=0x55a01f9cb690) at ../accel/kvm/kvm-all.c:3184 +#18 0x000055a00b75da25 in kvm_vcpu_thread_fn (arg=arg@entry=0x55a01f9cb690) at ../accel/kvm/kvm-accel-ops.c:50 +#19 0x000055a00b94daa8 in qemu_thread_start (args=0x55a01f9d2140) at ../util/qemu-thread-posix.c:541 +#20 0x00007fe0764456d7 in start_thread (arg=<optimized out>) at pthread_create.c:447 +#21 0x00007fe0764c9414 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100 + +``` + +Git bisect points to + +``` +commit ffa8a3e3b2e6ff017113b98d500d6a9e05b1560a (HEAD) +Author: Gao Shiyuan <gaoshiyuan@baidu.com> +Date: Tue Sep 3 20:03:04 2024 +0800 + + virtio-pci: Add lookup subregion of VirtIOPCIRegion MR + + Now virtio_address_space_lookup only lookup common/isr/device/notify + MR and exclude their subregions. + + When VHOST_USER_PROTOCOL_F_HOST_NOTIFIER enable, the notify MR has + host-notifier subregions and we need use host-notifier MR to + notify the hardware accelerator directly instead of eventfd notify. + + Further more, maybe common/isr/device MR also has subregions in + the future, so need memory_region_find for each MR incluing + their subregions. + + Add lookup subregion of VirtIOPCIRegion MR instead of only lookup container MR. + + Fixes: a93c8d8 ("virtio-pci: Replace modern_as with direct access to modern_bar") + Co-developed-by: Zuo Boqun <zuoboqun@baidu.com> + Signed-off-by: Gao Shiyuan <gaoshiyuan@baidu.com> + Signed-off-by: Zuo Boqun <zuoboqun@baidu.com> + Message-Id: <20240903120304.97833-1-gaoshiyuan@baidu.com> + Reviewed-by: Michael S. Tsirkin <mst@redhat.com> + Signed-off-by: Michael S. Tsirkin <mst@redhat.com> +``` + +cc @mstredhat diff --git a/results/classifier/118/review/266 b/results/classifier/118/review/266 new file mode 100644 index 000000000..fcd184123 --- /dev/null +++ b/results/classifier/118/review/266 @@ -0,0 +1,61 @@ +mistranslation: 0.986 +device: 0.742 +semantic: 0.592 +network: 0.416 +files: 0.382 +permissions: 0.364 +graphic: 0.350 +kernel: 0.326 +performance: 0.314 +register: 0.298 +hypervisor: 0.278 +boot: 0.238 +peripherals: 0.231 +arm: 0.217 +debug: 0.208 +user-level: 0.197 +architecture: 0.193 +virtual: 0.137 +ppc: 0.115 +risc-v: 0.114 +socket: 0.112 +assembly: 0.101 +x86: 0.094 +vnc: 0.084 +VMM: 0.070 +TCG: 0.064 +PID: 0.050 +i386: 0.043 +KVM: 0.032 +-------------------- +user-level: 0.828 +assembly: 0.648 +files: 0.625 +kernel: 0.089 +virtual: 0.050 +debug: 0.046 +mistranslation: 0.040 +network: 0.030 +device: 0.030 +x86: 0.022 +performance: 0.018 +semantic: 0.013 +peripherals: 0.008 +hypervisor: 0.007 +i386: 0.005 +boot: 0.003 +permissions: 0.002 +arm: 0.002 +socket: 0.002 +PID: 0.002 +ppc: 0.002 +KVM: 0.001 +architecture: 0.001 +graphic: 0.001 +TCG: 0.001 +VMM: 0.001 +vnc: 0.001 +risc-v: 0.000 +register: 0.000 + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/118/review/2660 b/results/classifier/118/review/2660 new file mode 100644 index 000000000..4109004bc --- /dev/null +++ b/results/classifier/118/review/2660 @@ -0,0 +1,61 @@ +architecture: 0.812 +device: 0.612 +network: 0.468 +mistranslation: 0.439 +performance: 0.437 +graphic: 0.329 +debug: 0.311 +assembly: 0.291 +semantic: 0.235 +x86: 0.169 +permissions: 0.157 +boot: 0.123 +virtual: 0.120 +i386: 0.116 +risc-v: 0.109 +ppc: 0.099 +user-level: 0.097 +vnc: 0.079 +hypervisor: 0.070 +peripherals: 0.065 +PID: 0.058 +socket: 0.052 +arm: 0.048 +register: 0.033 +kernel: 0.030 +files: 0.024 +VMM: 0.023 +TCG: 0.020 +KVM: 0.008 +-------------------- +virtual: 0.184 +kernel: 0.068 +network: 0.056 +files: 0.030 +device: 0.024 +peripherals: 0.024 +x86: 0.019 +user-level: 0.018 +assembly: 0.017 +i386: 0.010 +semantic: 0.009 +debug: 0.008 +architecture: 0.003 +boot: 0.002 +graphic: 0.002 +register: 0.002 +ppc: 0.001 +TCG: 0.001 +performance: 0.001 +permissions: 0.001 +PID: 0.001 +hypervisor: 0.001 +arm: 0.001 +mistranslation: 0.001 +socket: 0.001 +KVM: 0.000 +VMM: 0.000 +risc-v: 0.000 +vnc: 0.000 + +EDK2 subhook submodule missing diff --git a/results/classifier/118/review/2661 b/results/classifier/118/review/2661 new file mode 100644 index 000000000..5773e087a --- /dev/null +++ b/results/classifier/118/review/2661 @@ -0,0 +1,93 @@ +architecture: 0.930 +performance: 0.854 +device: 0.800 +PID: 0.775 +TCG: 0.768 +graphic: 0.763 +peripherals: 0.740 +boot: 0.730 +ppc: 0.728 +files: 0.711 +arm: 0.701 +register: 0.659 +debug: 0.657 +network: 0.653 +socket: 0.620 +kernel: 0.614 +permissions: 0.601 +semantic: 0.531 +mistranslation: 0.480 +assembly: 0.480 +hypervisor: 0.446 +x86: 0.412 +risc-v: 0.411 +vnc: 0.403 +user-level: 0.388 +i386: 0.344 +virtual: 0.319 +VMM: 0.271 +KVM: 0.104 +-------------------- +ppc: 0.997 +virtual: 0.805 +debug: 0.139 +assembly: 0.088 +hypervisor: 0.027 +kernel: 0.019 +device: 0.012 +files: 0.012 +register: 0.011 +TCG: 0.010 +KVM: 0.009 +architecture: 0.008 +PID: 0.008 +VMM: 0.008 +semantic: 0.008 +socket: 0.006 +boot: 0.003 +vnc: 0.003 +network: 0.002 +user-level: 0.002 +permissions: 0.002 +peripherals: 0.002 +performance: 0.001 +risc-v: 0.001 +graphic: 0.001 +mistranslation: 0.001 +arm: 0.000 +x86: 0.000 +i386: 0.000 + +powerpc: MSR_LE implemented incorrectly for processors before PPC970 +Description of problem: +qemu does not emulate MSR_LE correctly for CPUs prior to PPC970. + +The implementation used in this scenario appears to be correct for newer PowerPC CPUs, but not for earlier ones. + +When MSR_LE is enabled on PowerPC G4 and prior CPUs, big endian accesses are performed, with the lower address bits XORed by a constant derived from the size of the access (8-bit: XOR 7, 16-bit: XOR 6, 32-bit: XOR 4, 64-bit and above: no operation). This means that anything loaded in big-endian mode, when byteswapped as 64-bit values, appears in the correct place in little endian mode. + +Any unaligned access is dealt with at the same time. I have not verified exactly what the real hardware does, but the following appears to be correct for 16- and 32-bit accesses (and technically 8-bit accesses too given that all operations but the XOR do nothing in that case): +```c +// sizeof_access is the access size in bytes +size_t temp = ea & (sizeof_access - 1); // get offset of unaligned access +ea &= ~sizeof_access; // align the address +ea ^= (sizeof(uint64_t) - sizeof_access); // perform MSR_LE swizzle +ea -= temp; // correct the address for the unaligned access +``` + +Note that the algorithm can be run again on a swizzled address, which will compute the original non-swizzled address. + +Additionally, GDB memory accesses need to be performed byte-wise using the same algorithm. (there's probably a faster way to do this involving bswap64, though!) + +As for the rest of the system: different chipsets did different things. Some memory controllers (for example those used in early PReP systems) had an endianness swap bit that endianness swapped all of memory and MMIO correctly (given MSR_LE swizzled addresses); later systems with a PCI bus had an endianness swap bit in the PCI host controller (Apple "Bandit", Motorola MPC105/6/7) that endianness swapped PCI address space from the CPU side and provided a correct view of main memory from PCI DMA. + +I'm not sure how to implement any of that, hence testing with mac99, where the PCI host controller is big-endian only (there is a uni-north register to swap PCI endianness, but it isn't implemented in hardware and flipping it does nothing). On such systems, hardware access-related swapping must be handled in software. +Steps to reproduce: +Booting from the correct `nt_arcfw_mac99.iso` will crash on a black screen instead of running the ppcel stage2 bootloader. +Additional information: +The following patch is my implementation. This is my first attempt at QEMU TCG-related code; in some places it may be 'too' safe (running the swizzling algorithm again to revert it in case the EA is used again afterwards), and it also uses the "internal only" `tcg_temp_free_*` functions, to avoid wasting temporary variables. So hopefully some more experienced devs can improve it. + +[msr_le.patch](/uploads/3f829ac58d9943faa0cad7b817569f1d/msr_le.patch) + +The following ISO is the one used for testing. +[nt_arcfw_mac99.iso](/uploads/16aa5406284bab55ada205d6598e399a/nt_arcfw_mac99.iso) diff --git a/results/classifier/118/review/267 b/results/classifier/118/review/267 new file mode 100644 index 000000000..08817275a --- /dev/null +++ b/results/classifier/118/review/267 @@ -0,0 +1,61 @@ +mistranslation: 0.988 +x86: 0.887 +device: 0.784 +architecture: 0.781 +network: 0.592 +arm: 0.516 +graphic: 0.488 +performance: 0.433 +kernel: 0.389 +peripherals: 0.376 +semantic: 0.329 +hypervisor: 0.235 +permissions: 0.231 +assembly: 0.229 +boot: 0.213 +register: 0.191 +VMM: 0.178 +vnc: 0.176 +socket: 0.156 +debug: 0.147 +virtual: 0.139 +ppc: 0.126 +files: 0.109 +TCG: 0.080 +risc-v: 0.073 +PID: 0.056 +user-level: 0.047 +KVM: 0.024 +i386: 0.008 +-------------------- +virtual: 0.981 +hypervisor: 0.913 +x86: 0.613 +user-level: 0.207 +KVM: 0.114 +debug: 0.050 +architecture: 0.047 +semantic: 0.030 +assembly: 0.027 +kernel: 0.020 +files: 0.013 +VMM: 0.008 +boot: 0.006 +device: 0.006 +PID: 0.005 +TCG: 0.005 +performance: 0.004 +register: 0.004 +graphic: 0.002 +peripherals: 0.002 +ppc: 0.002 +risc-v: 0.001 +socket: 0.001 +permissions: 0.001 +mistranslation: 0.001 +i386: 0.000 +network: 0.000 +vnc: 0.000 +arm: 0.000 + +qemu-x86_64 segment prefixes error diff --git a/results/classifier/118/review/2762 b/results/classifier/118/review/2762 new file mode 100644 index 000000000..944c04ee0 --- /dev/null +++ b/results/classifier/118/review/2762 @@ -0,0 +1,65 @@ +architecture: 0.935 +device: 0.861 +graphic: 0.861 +network: 0.778 +mistranslation: 0.672 +arm: 0.637 +virtual: 0.631 +performance: 0.536 +PID: 0.506 +semantic: 0.493 +debug: 0.460 +vnc: 0.427 +risc-v: 0.378 +VMM: 0.318 +socket: 0.243 +hypervisor: 0.238 +TCG: 0.237 +ppc: 0.226 +permissions: 0.222 +register: 0.210 +boot: 0.187 +user-level: 0.138 +files: 0.134 +KVM: 0.116 +peripherals: 0.049 +i386: 0.047 +assembly: 0.040 +x86: 0.039 +kernel: 0.032 +-------------------- +virtual: 0.931 +debug: 0.881 +hypervisor: 0.557 +TCG: 0.215 +register: 0.093 +network: 0.087 +kernel: 0.083 +files: 0.048 +arm: 0.025 +assembly: 0.019 +socket: 0.014 +PID: 0.014 +device: 0.013 +KVM: 0.013 +risc-v: 0.012 +performance: 0.011 +architecture: 0.011 +user-level: 0.008 +VMM: 0.006 +semantic: 0.006 +boot: 0.004 +peripherals: 0.003 +permissions: 0.002 +vnc: 0.001 +graphic: 0.001 +x86: 0.001 +ppc: 0.001 +mistranslation: 0.000 +i386: 0.000 + +virtio-net regression for aarch64 guests +Description of problem: +The host system is running DHCP via dnsmasq 2.88. QEMU 9.1 works properly and completes DHCP handshake. QEMU 9.2 fails the DHCP handshake after DHCPOFFER with "eth0: checksum failure from 10.2.83.1". + +I found by bisecting that the issue was introduced by commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce "virtio-net: Copy received header to buffer". Reverting that commit on 9.2.0 corrects the issue. diff --git a/results/classifier/118/review/2764 b/results/classifier/118/review/2764 new file mode 100644 index 000000000..35285beb2 --- /dev/null +++ b/results/classifier/118/review/2764 @@ -0,0 +1,107 @@ +x86: 0.952 +debug: 0.906 +TCG: 0.866 +device: 0.838 +files: 0.826 +PID: 0.821 +graphic: 0.815 +performance: 0.802 +architecture: 0.782 +mistranslation: 0.780 +socket: 0.775 +network: 0.744 +semantic: 0.737 +kernel: 0.726 +ppc: 0.714 +peripherals: 0.714 +risc-v: 0.704 +register: 0.674 +permissions: 0.673 +user-level: 0.672 +VMM: 0.601 +vnc: 0.601 +hypervisor: 0.578 +arm: 0.536 +boot: 0.473 +i386: 0.403 +KVM: 0.290 +virtual: 0.289 +assembly: 0.274 +-------------------- +user-level: 0.620 +TCG: 0.451 +debug: 0.156 +virtual: 0.138 +hypervisor: 0.101 +register: 0.092 +files: 0.081 +PID: 0.030 +performance: 0.023 +x86: 0.020 +kernel: 0.020 +device: 0.018 +VMM: 0.017 +socket: 0.012 +network: 0.010 +semantic: 0.009 +peripherals: 0.004 +architecture: 0.003 +boot: 0.003 +vnc: 0.003 +assembly: 0.003 +risc-v: 0.003 +ppc: 0.003 +KVM: 0.002 +permissions: 0.002 +graphic: 0.002 +mistranslation: 0.002 +i386: 0.001 +arm: 0.001 + +W32 Docker build fails +Description of problem: +Docker build fails: + +``` +make docker-test-mingw@fedora-win64-cross V=1 J=4 +``` + +with the following error: + +``` +Initialized empty Git repository in /tmp/qemu-test/src/subprojects/dtc/.git/ +fatal: unable to access 'https://gitlab.com/qemu-project/dtc.git/': Could not resolve host: gitlab.com + +../meson.build:2090:16: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', 'b6910bec11614980a21e46fbccc35934b671bd81'] +``` +Steps to reproduce: +1. `make docker-test-mingw@fedora-win64-cross V=1 J=4 DEBUG=1` +2. `cd $QEMU_SRC` +3. `mkdir build` +4. `cd build` +5. `../configure --cross-prefix=x86_64-w64-mingw32-` +Additional information: +The problem can be worked around by changing the line + +``` +subprojects="keycodemapdb libvfio-user berkeley-softfloat-3 berkeley-testfloat-3" +``` + +to + +``` +subprojects="keycodemapdb libvfio-user berkeley-softfloat-3 berkeley-testfloat-3 dtc" +``` + +in `archive-source.sh`. + +Additionally, https://wiki.qemu.org/Hosts/W32#Docker_based_cross_builds is outdated. +``` +make docker-test-mingw@fedora V=1 DEBUG=1 J=4 +``` +should be +``` +make docker-test-mingw@fedora-win64-cross V=1 DEBUG=1 J=4 +``` + +Additionally, i would suggest to create and enter build directory before calling configure and also add the make commands as shown in the "Steps to reproduce" section of this ticket. diff --git a/results/classifier/118/review/2766 b/results/classifier/118/review/2766 new file mode 100644 index 000000000..899a7187d --- /dev/null +++ b/results/classifier/118/review/2766 @@ -0,0 +1,83 @@ +mistranslation: 0.879 +graphic: 0.869 +device: 0.732 +semantic: 0.674 +ppc: 0.668 +PID: 0.628 +user-level: 0.607 +performance: 0.598 +debug: 0.566 +network: 0.537 +x86: 0.497 +files: 0.489 +socket: 0.462 +kernel: 0.452 +architecture: 0.426 +permissions: 0.404 +vnc: 0.352 +hypervisor: 0.352 +risc-v: 0.340 +i386: 0.333 +register: 0.298 +TCG: 0.285 +peripherals: 0.272 +VMM: 0.252 +boot: 0.233 +arm: 0.231 +virtual: 0.228 +assembly: 0.199 +KVM: 0.170 +-------------------- +hypervisor: 0.790 +x86: 0.201 +debug: 0.095 +TCG: 0.041 +files: 0.036 +kernel: 0.023 +virtual: 0.017 +user-level: 0.016 +register: 0.016 +arm: 0.015 +PID: 0.013 +i386: 0.013 +device: 0.009 +semantic: 0.009 +ppc: 0.007 +assembly: 0.005 +network: 0.003 +architecture: 0.003 +permissions: 0.003 +boot: 0.002 +socket: 0.002 +VMM: 0.002 +risc-v: 0.002 +performance: 0.001 +peripherals: 0.001 +vnc: 0.001 +graphic: 0.001 +KVM: 0.001 +mistranslation: 0.000 + +Qemu 9.2: stubs: build issue with --enable-user --disable-system --enable-tools +Description of problem: +Since commit "[stubs: avoid duplicate symbols in libqemuutil.a](https://gitlab.com/qemu-project/qemu/-/commit/388b849fb6c33882b481123568995a749a54f648)", Qemu doesn't build with: + + ./configure --enable-user --disable-system --enable-tools + + /usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function 'device_finalize': \ + /home/autobuild/autobuild/instance-2/output-1/build/host-qemu-9.2.0/build/../hw/core/qdev.c:689:(.text+0x75c): undefined reference to 'qapi_event_send_device_deleted' + collect2: error: ld returned 1 exit status + +See Buildroot automated build results: +http://autobuild.buildroot.org/?reason=host-qemu-9.2.0 + +Indeed, with have_system = false and have_tools = true, Qemu needs the stubs for QAPI events added by stub_ss.add(files('qdev.c')) to provide qapi_event_send_device_deleted. + +Maybe the change in stubs/meson.build should have been: \ + +if not have_system and have_tools \ +stub_ss.add(files('qdev.c')) \ +endif + +Best regards, +Romain diff --git a/results/classifier/118/review/2776 b/results/classifier/118/review/2776 new file mode 100644 index 000000000..b4bb1a5f4 --- /dev/null +++ b/results/classifier/118/review/2776 @@ -0,0 +1,61 @@ +mistranslation: 0.814 +device: 0.792 +network: 0.696 +register: 0.684 +performance: 0.666 +risc-v: 0.559 +kernel: 0.502 +vnc: 0.498 +graphic: 0.497 +files: 0.487 +arm: 0.481 +hypervisor: 0.458 +boot: 0.449 +ppc: 0.448 +peripherals: 0.411 +permissions: 0.410 +user-level: 0.369 +i386: 0.354 +VMM: 0.345 +semantic: 0.336 +x86: 0.289 +KVM: 0.283 +debug: 0.278 +assembly: 0.248 +virtual: 0.247 +architecture: 0.243 +TCG: 0.238 +socket: 0.234 +PID: 0.226 +-------------------- +device: 0.328 +debug: 0.141 +user-level: 0.116 +performance: 0.094 +network: 0.066 +virtual: 0.056 +kernel: 0.021 +assembly: 0.020 +files: 0.018 +semantic: 0.012 +peripherals: 0.011 +x86: 0.011 +boot: 0.010 +ppc: 0.009 +PID: 0.009 +socket: 0.008 +register: 0.007 +architecture: 0.006 +arm: 0.006 +hypervisor: 0.005 +risc-v: 0.005 +TCG: 0.004 +i386: 0.003 +vnc: 0.003 +KVM: 0.002 +mistranslation: 0.002 +VMM: 0.001 +permissions: 0.001 +graphic: 0.001 + +OHCI: Incorrectly reports an overrun error diff --git a/results/classifier/118/review/279 b/results/classifier/118/review/279 new file mode 100644 index 000000000..59e785fb4 --- /dev/null +++ b/results/classifier/118/review/279 @@ -0,0 +1,61 @@ +architecture: 0.961 +x86: 0.948 +device: 0.841 +TCG: 0.793 +network: 0.686 +performance: 0.635 +arm: 0.586 +register: 0.440 +permissions: 0.438 +kernel: 0.412 +semantic: 0.366 +vnc: 0.366 +PID: 0.366 +graphic: 0.346 +virtual: 0.316 +boot: 0.312 +risc-v: 0.308 +peripherals: 0.283 +ppc: 0.263 +files: 0.250 +user-level: 0.234 +VMM: 0.226 +debug: 0.224 +mistranslation: 0.220 +hypervisor: 0.210 +socket: 0.168 +assembly: 0.080 +i386: 0.065 +KVM: 0.004 +-------------------- +architecture: 0.708 +x86: 0.568 +assembly: 0.515 +kernel: 0.365 +debug: 0.072 +performance: 0.068 +ppc: 0.058 +device: 0.056 +TCG: 0.047 +virtual: 0.029 +hypervisor: 0.019 +semantic: 0.014 +files: 0.008 +boot: 0.006 +user-level: 0.006 +register: 0.004 +PID: 0.003 +graphic: 0.002 +arm: 0.002 +KVM: 0.001 +peripherals: 0.001 +VMM: 0.001 +network: 0.001 +permissions: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +i386: 0.000 +vnc: 0.000 +socket: 0.000 + +x86-64 MTTCG Does not update page table entries atomically diff --git a/results/classifier/118/review/280 b/results/classifier/118/review/280 new file mode 100644 index 000000000..7bd0c6ac9 --- /dev/null +++ b/results/classifier/118/review/280 @@ -0,0 +1,61 @@ +architecture: 0.954 +x86: 0.877 +arm: 0.868 +device: 0.856 +kernel: 0.737 +performance: 0.531 +semantic: 0.434 +network: 0.409 +graphic: 0.300 +debug: 0.248 +peripherals: 0.218 +permissions: 0.204 +user-level: 0.170 +boot: 0.166 +hypervisor: 0.154 +mistranslation: 0.149 +PID: 0.143 +virtual: 0.136 +assembly: 0.127 +ppc: 0.120 +files: 0.116 +register: 0.107 +VMM: 0.075 +vnc: 0.068 +socket: 0.067 +TCG: 0.046 +risc-v: 0.024 +i386: 0.009 +KVM: 0.007 +-------------------- +arm: 0.977 +virtual: 0.970 +hypervisor: 0.922 +user-level: 0.043 +semantic: 0.041 +files: 0.030 +register: 0.025 +device: 0.023 +debug: 0.012 +KVM: 0.012 +VMM: 0.010 +performance: 0.009 +architecture: 0.009 +x86: 0.008 +TCG: 0.007 +PID: 0.007 +boot: 0.006 +kernel: 0.005 +network: 0.004 +peripherals: 0.003 +assembly: 0.003 +graphic: 0.002 +socket: 0.002 +permissions: 0.001 +mistranslation: 0.000 +risc-v: 0.000 +vnc: 0.000 +ppc: 0.000 +i386: 0.000 + +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML diff --git a/results/classifier/118/review/2800 b/results/classifier/118/review/2800 new file mode 100644 index 000000000..31fa054c3 --- /dev/null +++ b/results/classifier/118/review/2800 @@ -0,0 +1,67 @@ +architecture: 0.939 +graphic: 0.892 +device: 0.850 +debug: 0.761 +arm: 0.418 +performance: 0.385 +boot: 0.353 +TCG: 0.288 +network: 0.285 +PID: 0.245 +semantic: 0.241 +vnc: 0.239 +files: 0.215 +hypervisor: 0.204 +register: 0.200 +kernel: 0.185 +user-level: 0.166 +socket: 0.159 +VMM: 0.100 +risc-v: 0.097 +virtual: 0.090 +mistranslation: 0.090 +ppc: 0.089 +peripherals: 0.083 +assembly: 0.048 +x86: 0.046 +KVM: 0.036 +permissions: 0.032 +i386: 0.012 +-------------------- +hypervisor: 0.830 +debug: 0.761 +virtual: 0.378 +TCG: 0.254 +arm: 0.186 +user-level: 0.153 +PID: 0.119 +files: 0.085 +assembly: 0.032 +architecture: 0.030 +kernel: 0.030 +register: 0.027 +device: 0.026 +performance: 0.024 +risc-v: 0.023 +semantic: 0.020 +boot: 0.018 +peripherals: 0.011 +network: 0.006 +ppc: 0.004 +socket: 0.003 +VMM: 0.003 +graphic: 0.003 +permissions: 0.002 +vnc: 0.002 +x86: 0.002 +i386: 0.001 +mistranslation: 0.001 +KVM: 0.000 + +-accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334) +Description of problem: +QEMU fails to use -accel i.e., qemu-system-aarch64-unsigned: -accel hvf: Error: ret = HV_DENIED (0xfae94007, at ../accel/hvf/hvf-accel-ops.c:334) +Steps to reproduce: +1. Execute the above QEMU command line on a macOS Sequia 15.3 +Additional information: + diff --git a/results/classifier/118/review/2837 b/results/classifier/118/review/2837 new file mode 100644 index 000000000..ac0248872 --- /dev/null +++ b/results/classifier/118/review/2837 @@ -0,0 +1,61 @@ +mistranslation: 0.950 +graphic: 0.824 +device: 0.786 +network: 0.748 +semantic: 0.462 +files: 0.386 +virtual: 0.302 +peripherals: 0.276 +hypervisor: 0.182 +debug: 0.164 +register: 0.155 +architecture: 0.154 +performance: 0.139 +vnc: 0.137 +kernel: 0.131 +user-level: 0.126 +boot: 0.111 +ppc: 0.083 +arm: 0.076 +risc-v: 0.070 +VMM: 0.064 +permissions: 0.057 +TCG: 0.052 +PID: 0.033 +socket: 0.033 +assembly: 0.029 +KVM: 0.007 +x86: 0.006 +i386: 0.005 +-------------------- +virtual: 0.905 +files: 0.674 +user-level: 0.583 +device: 0.029 +debug: 0.021 +peripherals: 0.008 +semantic: 0.007 +network: 0.006 +performance: 0.004 +hypervisor: 0.003 +PID: 0.003 +arm: 0.002 +boot: 0.002 +kernel: 0.002 +assembly: 0.002 +graphic: 0.001 +ppc: 0.001 +register: 0.001 +TCG: 0.001 +x86: 0.001 +permissions: 0.001 +VMM: 0.001 +socket: 0.001 +mistranslation: 0.000 +vnc: 0.000 +risc-v: 0.000 +i386: 0.000 +architecture: 0.000 +KVM: 0.000 + +qcow2 corruption MinGW64 diff --git a/results/classifier/118/review/28596630 b/results/classifier/118/review/28596630 new file mode 100644 index 000000000..0e9c1baaa --- /dev/null +++ b/results/classifier/118/review/28596630 @@ -0,0 +1,168 @@ +user-level: 0.856 +register: 0.839 +device: 0.835 +architecture: 0.818 +semantic: 0.814 +mistranslation: 0.813 +peripherals: 0.802 +ppc: 0.799 +performance: 0.797 +permissions: 0.791 +graphic: 0.785 +network: 0.780 +hypervisor: 0.775 +kernel: 0.770 +arm: 0.756 +PID: 0.750 +virtual: 0.742 +assembly: 0.725 +debug: 0.704 +risc-v: 0.702 +socket: 0.697 +vnc: 0.674 +TCG: 0.668 +x86: 0.654 +VMM: 0.650 +KVM: 0.649 +files: 0.630 +i386: 0.611 +boot: 0.609 +-------------------- +x86: 0.818 +hypervisor: 0.566 +i386: 0.555 +debug: 0.492 +files: 0.270 +user-level: 0.127 +TCG: 0.124 +register: 0.058 +risc-v: 0.046 +ppc: 0.046 +virtual: 0.044 +arm: 0.042 +VMM: 0.037 +PID: 0.035 +socket: 0.033 +device: 0.026 +network: 0.020 +vnc: 0.016 +performance: 0.015 +kernel: 0.013 +boot: 0.013 +assembly: 0.011 +peripherals: 0.009 +semantic: 0.009 +architecture: 0.006 +KVM: 0.005 +permissions: 0.004 +mistranslation: 0.003 +graphic: 0.002 + +[Qemu-devel] [BUG] [low severity] a strange appearance of message involving slirp while doing "empty" make + +Folks, + +If qemu tree is already fully built, and "make" is attempted, for 3.1, the +outcome is: + +$ make + CHK version_gen.h +$ + +For 4.0-rc0, the outcome seems to be different: + +$ make +make[1]: Entering directory '/home/build/malta-mips64r6/qemu-4.0/slirp' +make[1]: Nothing to be done for 'all'. +make[1]: Leaving directory '/home/build/malta-mips64r6/qemu-4.0/slirp' + CHK version_gen.h +$ + +Not sure how significant is that, but I report it just in case. + +Yours, +Aleksandar + +On 20/03/2019 22.08, Aleksandar Markovic wrote: +> +Folks, +> +> +If qemu tree is already fully built, and "make" is attempted, for 3.1, the +> +outcome is: +> +> +$ make +> +CHK version_gen.h +> +$ +> +> +For 4.0-rc0, the outcome seems to be different: +> +> +$ make +> +make[1]: Entering directory '/home/build/malta-mips64r6/qemu-4.0/slirp' +> +make[1]: Nothing to be done for 'all'. +> +make[1]: Leaving directory '/home/build/malta-mips64r6/qemu-4.0/slirp' +> +CHK version_gen.h +> +$ +> +> +Not sure how significant is that, but I report it just in case. +It's likely because slirp is currently being reworked to become a +separate project, so the makefiles have been changed a little bit. I +guess the message will go away again once slirp has become a stand-alone +library. + + Thomas + +On Fri, 22 Mar 2019 at 04:59, Thomas Huth <address@hidden> wrote: +> +On 20/03/2019 22.08, Aleksandar Markovic wrote: +> +> $ make +> +> make[1]: Entering directory '/home/build/malta-mips64r6/qemu-4.0/slirp' +> +> make[1]: Nothing to be done for 'all'. +> +> make[1]: Leaving directory '/home/build/malta-mips64r6/qemu-4.0/slirp' +> +> CHK version_gen.h +> +> $ +> +> +> +> Not sure how significant is that, but I report it just in case. +> +> +It's likely because slirp is currently being reworked to become a +> +separate project, so the makefiles have been changed a little bit. I +> +guess the message will go away again once slirp has become a stand-alone +> +library. +Well, we'll still need to ship slirp for the foreseeable future... + +I think the cause of this is that the rule in Makefile for +calling the slirp Makefile is not passing it $(SUBDIR_MAKEFLAGS) +like all the other recursive make invocations. If we do that +then we'll suppress the entering/leaving messages for +non-verbose builds. (Some tweaking will be needed as +it looks like the slirp makefile has picked an incompatible +meaning for $BUILD_DIR, which the SUBDIR_MAKEFLAGS will +also be passing to it.) + +thanks +-- PMM + diff --git a/results/classifier/118/review/2865 b/results/classifier/118/review/2865 new file mode 100644 index 000000000..2b8f82f7e --- /dev/null +++ b/results/classifier/118/review/2865 @@ -0,0 +1,112 @@ +architecture: 0.928 +TCG: 0.838 +assembly: 0.741 +mistranslation: 0.694 +device: 0.653 +graphic: 0.618 +kernel: 0.541 +ppc: 0.526 +PID: 0.473 +socket: 0.439 +performance: 0.433 +vnc: 0.390 +risc-v: 0.383 +hypervisor: 0.366 +network: 0.364 +VMM: 0.362 +peripherals: 0.357 +arm: 0.349 +debug: 0.298 +x86: 0.281 +register: 0.261 +boot: 0.235 +semantic: 0.210 +user-level: 0.198 +KVM: 0.187 +files: 0.161 +permissions: 0.161 +i386: 0.152 +virtual: 0.126 +-------------------- +TCG: 0.565 +debug: 0.115 +register: 0.035 +files: 0.031 +kernel: 0.016 +semantic: 0.008 +PID: 0.008 +virtual: 0.007 +VMM: 0.007 +user-level: 0.006 +device: 0.005 +architecture: 0.004 +hypervisor: 0.004 +KVM: 0.003 +ppc: 0.002 +assembly: 0.002 +performance: 0.002 +graphic: 0.002 +peripherals: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +vnc: 0.001 +boot: 0.001 +network: 0.001 +socket: 0.001 +arm: 0.001 +permissions: 0.001 +x86: 0.000 +i386: 0.000 + +loongarch64: wrong implementation of `xvldi` instruction +Description of problem: +Consider this sample program. + +```c++ +#include <cstdio> +#include <cstdint> +#include <lsxintrin.h> +#include <lasxintrin.h> + +void dump_u32(__m256i x) { + uint32_t tmp[32/4]; + __lasx_xvst(x, tmp, 0); + putchar('['); + for (int i=0; i < 32/4; i++) { + if (i > 0) { + putchar(' '); + } + + printf("%08x", tmp[i]); + } + puts("]"); +} + +int main() { + __m256i const1 = __lasx_xvldi(-3832); + dump_u32(const1); +} +``` + +The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: + +``` +[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] +``` + +The same program run under Qemu prints: + +``` +[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] +``` +Additional information: +I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. + +```c + case 1: + /* data: {2{16'0, imm[7:0], 8'0}} */ + data = (t << 24) | (t << 8); + break; +``` + +There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/118/review/2868 b/results/classifier/118/review/2868 new file mode 100644 index 000000000..a4149a8a3 --- /dev/null +++ b/results/classifier/118/review/2868 @@ -0,0 +1,63 @@ +mistranslation: 0.997 +architecture: 0.927 +device: 0.905 +arm: 0.708 +graphic: 0.658 +network: 0.544 +performance: 0.446 +debug: 0.433 +PID: 0.418 +register: 0.384 +semantic: 0.383 +ppc: 0.361 +hypervisor: 0.337 +virtual: 0.309 +files: 0.271 +peripherals: 0.242 +boot: 0.241 +assembly: 0.230 +kernel: 0.227 +socket: 0.220 +VMM: 0.209 +permissions: 0.195 +user-level: 0.160 +risc-v: 0.107 +TCG: 0.090 +vnc: 0.087 +x86: 0.078 +i386: 0.062 +KVM: 0.021 +-------------------- +i386: 0.927 +device: 0.737 +kernel: 0.721 +assembly: 0.245 +x86: 0.238 +PID: 0.050 +TCG: 0.034 +arm: 0.032 +VMM: 0.031 +hypervisor: 0.030 +ppc: 0.025 +files: 0.021 +peripherals: 0.018 +mistranslation: 0.017 +virtual: 0.015 +semantic: 0.014 +debug: 0.011 +user-level: 0.010 +boot: 0.007 +architecture: 0.006 +risc-v: 0.005 +performance: 0.005 +register: 0.004 +KVM: 0.003 +vnc: 0.002 +network: 0.002 +socket: 0.002 +graphic: 0.001 +permissions: 0.000 + +amd iommu pte is only 32bits not 64bits. +Additional information: + diff --git a/results/classifier/118/review/2882 b/results/classifier/118/review/2882 new file mode 100644 index 000000000..acb7b6cc4 --- /dev/null +++ b/results/classifier/118/review/2882 @@ -0,0 +1,150 @@ +register: 0.895 +graphic: 0.889 +permissions: 0.885 +device: 0.878 +peripherals: 0.877 +risc-v: 0.871 +debug: 0.864 +mistranslation: 0.853 +hypervisor: 0.852 +architecture: 0.849 +KVM: 0.845 +assembly: 0.839 +performance: 0.828 +user-level: 0.826 +kernel: 0.824 +x86: 0.819 +semantic: 0.809 +arm: 0.807 +PID: 0.807 +virtual: 0.794 +boot: 0.772 +network: 0.768 +ppc: 0.768 +TCG: 0.764 +vnc: 0.757 +VMM: 0.756 +socket: 0.755 +files: 0.707 +i386: 0.659 +-------------------- +debug: 0.724 +kernel: 0.667 +x86: 0.445 +virtual: 0.389 +hypervisor: 0.328 +TCG: 0.096 +files: 0.045 +register: 0.039 +boot: 0.020 +PID: 0.017 +i386: 0.012 +semantic: 0.011 +device: 0.009 +architecture: 0.005 +arm: 0.005 +socket: 0.004 +risc-v: 0.004 +ppc: 0.004 +network: 0.003 +user-level: 0.003 +performance: 0.003 +assembly: 0.002 +vnc: 0.002 +VMM: 0.002 +graphic: 0.002 +peripherals: 0.002 +permissions: 0.001 +KVM: 0.001 +mistranslation: 0.001 + +Reading ACPI info via fw_cfg in SVSM causes Linux to panic +Description of problem: +We could use some help from a Qemu expert with an Qemu/ACPI/Linux related problem, +working on Coconut SVSM. + +**See https://github.com/coconut-svsm/svsm/issues/646** + +Coconut has code to read ACPI information via fw_cfg, and extract the number of guest CPUs from that. +That code has been used in the past, but since igvm became the default launch method for SVSM, it +was only used in corner-cases, while the information were obtained in some other way (igmv parameter). +Now a commit switches back to the fw_cfg+ACPI method. The information returned by it is correct, but +strangely Linux (guest) is spitting out ACPI related errors and crashes in some cases before reaching user-space. We do not have any clue how this can be related other than through Qemu behavior. +There is no direct way how SVSM can influence the ACPI related behavior of the Linux +guest kernel. + +The problem seems to be caused by simply reading the ACPI data. + +Reverting the bad commit and simply calling the original fw_cfg acpi function causes problems for Linux. +Steps to reproduce: +Boot SVSM bases CVM. SVSM and OVMF boot OK, then Linux prints these errors in some scenarios panics: +``` +[...] +[ 1.857709] ACPI: Added _OSI(Processor Aggregator Device) +[ 1.859436] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 1.860867] ACPI Error: AE_BAD_ADDRESS, Unable to initialize fixed events (20240827/evevent-53) +[ 1.862709] ACPI: Unable to start the ACPI Interpreter +[ 1.863708] ACPI Error: Could not remove SCI handler (20240827/evmisc-251) +[ 1.864942] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MT +X_Namespace] (0x1) (20240827/utmutex-252) +[ 1.866715] ACPI Error: AE_BAD_PARAMETER, Thread 2176690624 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20240827/utmutex-252) +[ 1.869722] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20240 +827/utmutex-289) +[ 1.870826] iommu: Default domain type: Translated +[ 1.871710] iommu: DMA domain TLB invalidation policy: lazy mod +[...] +[ 2.672635] io scheduler bfq registered +[ 2.675679] atomic64_test: passed for x86-64 platform with CX8 and with SSE +[ 2.677596] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 2.679264] ------------[ cut here ]------------ +[ 2.680284] refcount_t: addition on 0; use-after-free. +[ 2.681477] WARNING: CPU: 3 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 +[ 2.683261] Modules linked in: +[ 2.683929] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.6-200.fc41.x86_64 #1 +[ 2.685608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-stable202502-39-gb +483f751 02/02/2022 +[ 2.687729] RIP: 0010:refcount_warn_saturate+0xe5/0x110 +[ 2.688853] Code: e3 7f ff 0f 0b e9 fb 0a 8a 00 80 3d 15 9f 23 02 00 0f 85 5e ff ff ff 48 c7 c7 30 7b e7 8c c6 05 01 9f 23 02 01 e8 fb e2 7f ff <0f> 0b e9 d4 0a 8a 00 48 c7 c7 88 7b e7 8c + c6 05 e5 9e 23 02 01 e8 +[ 2.692768] RSP: 0018:ffffb2ed0001fd90 EFLAGS: 00010282 +[ 2.693894] RAX: 0000000000000000 RBX: ffff975b81060a80 RCX: ffffffff8d967448 +[ 2.695410] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001 +[ 2.696923] RBP: ffffb2ed0001fe38 R08: 0000000000000000 R09: 0720072007200720 +[ 2.698439] R10: 0720072007200720 R11: 0720072007200720 R12: ffff975b81060a80 +[ 2.699955] R13: ffffb2ed0001fe78 R14: 00000000000000dc R15: 00000000000001df +[ 2.701461] FS: 0000000000000000(0000) GS:ffff975cf7d80000(0000) knlGS:0000000000000000 +[ 2.703179] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 2.704400] CR2: 00007f1c1658a3c8 CR3: 000800006082c000 CR4: 00000000003506f0 +[ 2.705910] Call Trace: +[ 2.706451] <TASK> +[ 2.706922] ? srso_return_thunk+0x5/0x5f +[ 2.707820] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.708783] ? show_trace_log_lvl+0x255/0x2f0 +[ 2.709712] ? kobject_get+0x68/0x70 +[ 2.710492] ? refcount_warn_saturate+0xe5/0x110 +[ 2.711480] ? __warn.cold+0x93/0xfa +[ 2.712268] ? refcount_warn_saturate+0xe5/0x110 +[ 2.713262] ? report_bug+0xff/0x140 +[ 2.714036] ? handle_bug+0x58/0x90 +[ 2.714779] ? exc_invalid_op+0x17/0x70 +[ 2.715617] ? asm_exc_invalid_op+0x1a/0x20 +[ 2.716526] ? refcount_warn_saturate+0xe5/0x110 +[ 2.717507] kobject_get+0x68/0x70 +[ 2.718266] kobject_add_internal+0x32/0x250 +[ 2.719196] kobject_add+0x96/0xc0 +[ 2.719923] kobject_create_and_add+0xa3/0xc0 +[ 2.720851] bgrt_init+0x77/0xc0 +[ 2.721578] ? __pfx_bgrt_init+0x10/0x10 +[ 2.722418] do_one_initcall+0x5b/0x310 +[ 2.723272] do_initcalls+0x147/0x170 +[ 2.724086] ? __pfx_kernel_init+0x10/0x10 +[ 2.725174] kernel_init_freeable+0xfb/0x130 +[ 2.726114] kernel_init+0x1a/0x140 +[ 2.726883] ret_from_fork+0x34/0x50 +[ 2.727679] ? __pfx_kernel_init+0x10/0x10 +[ 2.728580] ret_from_fork_asm+0x1a/0x30 +[ 2.729429] </TASK> +[ 2.729926] ---[ end trace 0000000000000000 ]--- +``` +Additional information: + diff --git a/results/classifier/118/review/2896 b/results/classifier/118/review/2896 new file mode 100644 index 000000000..3dab3b6ca --- /dev/null +++ b/results/classifier/118/review/2896 @@ -0,0 +1,61 @@ +architecture: 0.854 +device: 0.771 +network: 0.541 +performance: 0.490 +arm: 0.397 +peripherals: 0.318 +debug: 0.259 +boot: 0.249 +mistranslation: 0.245 +register: 0.232 +user-level: 0.219 +graphic: 0.215 +permissions: 0.208 +socket: 0.136 +semantic: 0.133 +assembly: 0.131 +ppc: 0.130 +vnc: 0.126 +hypervisor: 0.126 +virtual: 0.109 +VMM: 0.100 +files: 0.089 +TCG: 0.089 +risc-v: 0.060 +KVM: 0.045 +PID: 0.037 +kernel: 0.029 +x86: 0.004 +i386: 0.004 +-------------------- +user-level: 0.740 +peripherals: 0.305 +assembly: 0.149 +TCG: 0.120 +arm: 0.114 +kernel: 0.108 +device: 0.106 +VMM: 0.090 +debug: 0.081 +virtual: 0.073 +semantic: 0.044 +architecture: 0.025 +files: 0.019 +ppc: 0.016 +KVM: 0.014 +socket: 0.007 +risc-v: 0.007 +PID: 0.004 +performance: 0.003 +vnc: 0.003 +register: 0.002 +boot: 0.002 +permissions: 0.002 +graphic: 0.002 +hypervisor: 0.002 +network: 0.001 +i386: 0.001 +mistranslation: 0.000 +x86: 0.000 + +How to enable MPU support on Cortex-R5F? diff --git a/results/classifier/118/review/2901 b/results/classifier/118/review/2901 new file mode 100644 index 000000000..d7a78fe58 --- /dev/null +++ b/results/classifier/118/review/2901 @@ -0,0 +1,61 @@ +mistranslation: 0.945 +device: 0.597 +ppc: 0.435 +arm: 0.431 +graphic: 0.420 +TCG: 0.401 +network: 0.360 +VMM: 0.336 +risc-v: 0.297 +performance: 0.290 +vnc: 0.282 +permissions: 0.254 +socket: 0.253 +boot: 0.227 +PID: 0.203 +architecture: 0.189 +semantic: 0.175 +files: 0.172 +x86: 0.156 +hypervisor: 0.147 +i386: 0.139 +virtual: 0.126 +register: 0.084 +debug: 0.075 +user-level: 0.048 +KVM: 0.037 +assembly: 0.031 +kernel: 0.031 +peripherals: 0.030 +-------------------- +files: 0.864 +virtual: 0.141 +hypervisor: 0.066 +x86: 0.062 +user-level: 0.038 +debug: 0.030 +semantic: 0.015 +KVM: 0.014 +kernel: 0.013 +arm: 0.010 +boot: 0.009 +TCG: 0.008 +register: 0.005 +PID: 0.004 +graphic: 0.004 +i386: 0.004 +ppc: 0.004 +network: 0.003 +device: 0.002 +socket: 0.002 +VMM: 0.002 +performance: 0.001 +risc-v: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +vnc: 0.001 +assembly: 0.001 +architecture: 0.001 +permissions: 0.000 + +Critical typo in qemu_source_dir/plugins/loader.c diff --git a/results/classifier/118/review/2910 b/results/classifier/118/review/2910 new file mode 100644 index 000000000..64688829f --- /dev/null +++ b/results/classifier/118/review/2910 @@ -0,0 +1,65 @@ +architecture: 0.871 +device: 0.672 +arm: 0.625 +graphic: 0.349 +semantic: 0.340 +mistranslation: 0.338 +performance: 0.276 +boot: 0.246 +debug: 0.243 +socket: 0.177 +assembly: 0.158 +files: 0.150 +network: 0.122 +PID: 0.117 +TCG: 0.111 +register: 0.107 +vnc: 0.103 +risc-v: 0.102 +kernel: 0.094 +virtual: 0.061 +VMM: 0.060 +user-level: 0.049 +ppc: 0.046 +KVM: 0.031 +peripherals: 0.027 +hypervisor: 0.026 +permissions: 0.016 +i386: 0.003 +x86: 0.002 +-------------------- +arm: 0.980 +architecture: 0.839 +kernel: 0.105 +assembly: 0.078 +register: 0.064 +TCG: 0.044 +debug: 0.032 +VMM: 0.032 +files: 0.032 +semantic: 0.026 +network: 0.018 +user-level: 0.017 +device: 0.016 +virtual: 0.016 +KVM: 0.013 +hypervisor: 0.007 +PID: 0.006 +socket: 0.005 +boot: 0.005 +performance: 0.003 +risc-v: 0.003 +vnc: 0.003 +peripherals: 0.002 +permissions: 0.002 +graphic: 0.001 +ppc: 0.000 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +SME2 support for aarch64? +Additional information: +We've noticed that most `SME2` instructions work, despite `ARM_HWCAP2_A64_SME2` not being set. + +Cheers, Pedro diff --git a/results/classifier/118/review/2911 b/results/classifier/118/review/2911 new file mode 100644 index 000000000..fe477c663 --- /dev/null +++ b/results/classifier/118/review/2911 @@ -0,0 +1,125 @@ +user-level: 0.845 +semantic: 0.839 +permissions: 0.815 +graphic: 0.815 +mistranslation: 0.815 +virtual: 0.788 +debug: 0.769 +assembly: 0.754 +PID: 0.733 +performance: 0.731 +device: 0.727 +architecture: 0.718 +arm: 0.705 +risc-v: 0.704 +register: 0.701 +hypervisor: 0.698 +files: 0.686 +peripherals: 0.679 +boot: 0.677 +TCG: 0.677 +kernel: 0.668 +network: 0.654 +vnc: 0.640 +KVM: 0.623 +ppc: 0.619 +x86: 0.613 +socket: 0.609 +VMM: 0.598 +i386: 0.543 +-------------------- +boot: 0.800 +debug: 0.798 +virtual: 0.744 +assembly: 0.301 +files: 0.138 +user-level: 0.112 +kernel: 0.099 +register: 0.070 +TCG: 0.065 +performance: 0.057 +architecture: 0.053 +PID: 0.045 +VMM: 0.043 +device: 0.028 +x86: 0.014 +hypervisor: 0.013 +semantic: 0.011 +socket: 0.009 +graphic: 0.009 +KVM: 0.006 +peripherals: 0.005 +mistranslation: 0.005 +ppc: 0.004 +vnc: 0.003 +arm: 0.003 +permissions: 0.002 +network: 0.002 +i386: 0.002 +risc-v: 0.002 + +G5/970 emulation not complete enough for OSX ? +Description of problem: +Leopard image that boots on G4 does not boot on G5 +Steps to reproduce: +1. Find preinstalled hdd image on Archive.org: MacOSLeopard.img +2. Try to boot it like above with -cpu 970, or 970FX +3. Observe early hang +Additional information: +``` +cpus[0] = 0x7f794b3e3040 0x7f794b3e5bc0 +cpus[1] = 0x7f794afe3ec0 0x7f794afe6a40 +Trying to write invalid spr 276 (0x114) at 00000000000b6634 +Trying to read invalid spr 277 (0x115) at 00000000000b6638 +Trying to read invalid spr 276 (0x114) at 00000000000b663c +Trying to write invalid spr 277 (0x115) at 00000000000b6658 +Trying to write invalid spr 276 (0x114) at 00000000000b665c +Trying to read invalid spr 276 (0x114) at 00000000000b6660 +Trying to write invalid spr 277 (0x115) at 00000000000b670c +Trying to write invalid spr 276 (0x114) at 00000000000b6710 +Trying to read invalid spr 276 (0x114) at 00000000000b6714 +invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000000 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to write invalid spr 304 (0x130) at 0000000000003e14 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +Trying to read invalid spr 304 (0x130) at 0000000000003e38 +invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008 + +last lin repeats infinitely. +``` + +from my email to qemu-ppc list: + +SPR 304 was already in target/ppc/cpu_init.c + +but sadly after adding those it still dies early :( + +I looked at + +IBM PowerPC 970FX RISC Microprocessor 11.6 SCOM Facility + +but whole thing a bit more complex than pair of regs. + +==== + +11.6.1 Processor Core SCOM SPR Access Each processor (core) has two special purpose registers (SPRs) used to access the SCOM interface: SCOMC and SCOMD. SCOMC and SCOMD are both 64-bit read/write SPRs and are used for SCOM Control and SCOM Data respectively. The interface is implemented as a direct connection to the parallel-to-serial converter, which handles the arbitration between the core and service processor. + +11.6.2 Operating System Protocol to Access SCOM SPRs In the PowerPC 970FX, SCOMC and SCOMD are complete operations. They do not require a software protocol in order to function properly except to disable external (asynchronous) interrupts. Software must check the error bits after performing an SCOMC to ensure that the command successfully completed. Table 11-14 Operating System Code to Access SCOM outlines a general software protocol for using these registers. + +==== + +Low level asm init for OSX XNU kernel seems to live at + +https://github.com/apple-oss-distributions/xnu/blob/xnu-1228/osfmk/ppc/start.s diff --git a/results/classifier/118/review/2927 b/results/classifier/118/review/2927 new file mode 100644 index 000000000..7d75da287 --- /dev/null +++ b/results/classifier/118/review/2927 @@ -0,0 +1,231 @@ +risc-v: 0.813 +ppc: 0.803 +TCG: 0.800 +user-level: 0.781 +VMM: 0.741 +permissions: 0.740 +KVM: 0.715 +PID: 0.699 +graphic: 0.685 +register: 0.673 +device: 0.667 +debug: 0.667 +socket: 0.659 +peripherals: 0.657 +vnc: 0.657 +hypervisor: 0.641 +files: 0.632 +arm: 0.627 +semantic: 0.626 +kernel: 0.622 +mistranslation: 0.621 +assembly: 0.607 +architecture: 0.601 +boot: 0.596 +performance: 0.587 +network: 0.486 +virtual: 0.477 +x86: 0.420 +i386: 0.367 +-------------------- +x86: 0.861 +assembly: 0.697 +debug: 0.111 +kernel: 0.078 +files: 0.028 +TCG: 0.022 +user-level: 0.020 +PID: 0.020 +boot: 0.013 +device: 0.007 +architecture: 0.006 +performance: 0.006 +virtual: 0.005 +register: 0.005 +arm: 0.005 +hypervisor: 0.004 +i386: 0.004 +semantic: 0.003 +graphic: 0.003 +peripherals: 0.002 +network: 0.002 +permissions: 0.001 +socket: 0.001 +ppc: 0.001 +risc-v: 0.001 +VMM: 0.001 +mistranslation: 0.000 +KVM: 0.000 +vnc: 0.000 + +Getting bare metal code running on tricore +Description of problem: +My code is stuck in +Steps to reproduce: +1. Open Infineon Aurix Development Studio (on Windows) +2. Compile project (two examples that I've tested) +a) New -> Project -> Board -> KIT_AURIX_TC277_TFT_DC-Step -> Build +b) the example from here: https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Blinky_LED_1_KIT_TC277_TFT +3. Copy the elf and run qemu on the debian system +Additional information: +When running a blank binary on QEMU with the TriCore TC27x target, the CPU starts executing at address 0x80000020 and enters an infinite loop. +The code seems to be stuck and waiting for some hardware signal. The binary (sample.elf) from this issue qemu-project/qemu#1363 works. + +I know it's probably a rookie problem, but what am I missing? How can I get an example from Infineon running? Or any other example? + +Please let me know if you need additional information! + +```:~/qemu$ ./build/qemu-system-tricore -M KIT_AURIX_TC277_TRB -cpu tc27x -nographic -kernel ../qemu-examples/aurix_tricore_example_bins/Blank_project_TC277.elf -d in_asm +QEMU 9.2.50 monitor - type 'help' for more information +(qemu) ---------------- +IN: _START +0x80000020: +OBJD-T: 91000028d9220681dc02 + +---------------- +IN: _Core0_start +0x80001206: +OBJD-T: 9130002f192200469120003737026e21d92200468ff2838180321b026029602a +OBJD-T: 0d0080043b009820cd42e00f + +---------------- +IN: _Core0_start +0x8000120a: +OBJD-T: 19220046 + +---------------- +IN: _Core0_start +0x8000120e: +OBJD-T: 9120003737026e21d92200468ff2838180321b026029602a0d0080043b009820 +OBJD-T: cd42e00f + +---------------- +IN: _Core0_start +0x80001232: +OBJD-T: 4d00e02fb7021420cd02e00f8212cd4220094dc0e12f8f720021012203260122 +OBJD-T: 02265422542337026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001254: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001256: +OBJD-T: 542337026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001256: +OBJD-T: 5423 + +---------------- +IN: _Core0_start +0x80001258: +OBJD-T: 37026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001264: +OBJD-T: 8f2200305422b7021020a6328f224021742254226f02ffff + +---------------- +IN: _Core0_start +0x80001268: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x8000126a: +OBJD-T: b7021020a6328f224021742254226f02ffff + +---------------- +IN: _Core0_start +0x80001274: +OBJD-T: 7422 + +---------------- +IN: _Core0_start +0x80001276: +OBJD-T: 54226f02ffff + +---------------- +IN: _Core0_start +0x80001276: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001278: +OBJD-T: 6f02ffff + +---------------- +IN: _Core0_start +0x8000127c: +OBJD-T: 8202cdc2200954226f120900 + +---------------- +IN: _Core0_start +0x80001282: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001284: +OBJD-T: 6f120900 + +---------------- +IN: _Core0_start +0x80001296: +OBJD-T: 5422b7021020a6328f324021742254226f02ff7f + +---------------- +IN: _Core0_start +0x80001296: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001298: +OBJD-T: b7021020a6328f324021742254226f02ff7f + +---------------- +IN: _Core0_start +0x800012a2: +OBJD-T: 7422 + +---------------- +IN: _Core0_start +0x800012a4: +OBJD-T: 54226f02ff7f + +---------------- +IN: _Core0_start +0x800012a4: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x800012a6: +OBJD-T: 6f02ff7f + + +(qemu) q +``` + +When I run it with the `-d in_asm,cpu,exec` flag it logs this infinitely often: +``` +Trace 0: 0x7fb5205e9940 [00000000/00000000800012a4/00000002/ff011001] _Core0_start +PC: 800012a4 PSW: 00000980 ICR: 00000000 +PCXI: 00000000 FCX: 00000000 LCX: 00000000 +GPR A00: 00000000 00000000 f0036100 70020000 +GPR A04: 00000000 00000000 00000000 00000000 +GPR A08: 00000000 00000000 70019600 00000000 +GPR A12: 00000000 00000000 00000000 00000000 +GPR D00: 00000000 00000000 00000000 000000fc +GPR D04: 00000000 00000000 00000000 00000000 +GPR D08: 0000003f 00000000 00000000 00000000 +GPR D12: 00000000 00000000 00000000 00000000 +cpu_io_recompile: rewound execution of TB to 00000000800012a4 +``` diff --git a/results/classifier/118/review/2932 b/results/classifier/118/review/2932 new file mode 100644 index 000000000..616fb106b --- /dev/null +++ b/results/classifier/118/review/2932 @@ -0,0 +1,61 @@ +mistranslation: 0.986 +device: 0.613 +graphic: 0.548 +semantic: 0.486 +performance: 0.454 +peripherals: 0.390 +architecture: 0.362 +network: 0.347 +arm: 0.273 +virtual: 0.256 +permissions: 0.187 +user-level: 0.170 +hypervisor: 0.160 +ppc: 0.123 +risc-v: 0.123 +boot: 0.082 +i386: 0.079 +vnc: 0.076 +assembly: 0.068 +x86: 0.055 +socket: 0.045 +register: 0.042 +files: 0.037 +debug: 0.035 +VMM: 0.031 +PID: 0.028 +kernel: 0.025 +TCG: 0.022 +KVM: 0.008 +-------------------- +virtual: 0.963 +hypervisor: 0.786 +debug: 0.655 +user-level: 0.092 +permissions: 0.087 +semantic: 0.078 +device: 0.028 +performance: 0.026 +network: 0.015 +kernel: 0.011 +files: 0.010 +x86: 0.009 +assembly: 0.008 +peripherals: 0.005 +boot: 0.004 +mistranslation: 0.003 +i386: 0.003 +architecture: 0.003 +arm: 0.002 +PID: 0.002 +register: 0.002 +graphic: 0.001 +TCG: 0.001 +risc-v: 0.001 +ppc: 0.001 +VMM: 0.001 +socket: 0.000 +vnc: 0.000 +KVM: 0.000 + +QEMU flag fuzz targets not WAI diff --git a/results/classifier/118/review/2949 b/results/classifier/118/review/2949 new file mode 100644 index 000000000..f78fbfc0b --- /dev/null +++ b/results/classifier/118/review/2949 @@ -0,0 +1,77 @@ +mistranslation: 0.850 +device: 0.739 +graphic: 0.700 +architecture: 0.691 +vnc: 0.647 +performance: 0.633 +network: 0.598 +semantic: 0.494 +peripherals: 0.434 +virtual: 0.429 +x86: 0.420 +i386: 0.410 +PID: 0.393 +register: 0.384 +ppc: 0.376 +files: 0.372 +socket: 0.368 +assembly: 0.364 +hypervisor: 0.333 +risc-v: 0.313 +permissions: 0.312 +debug: 0.280 +kernel: 0.258 +user-level: 0.255 +arm: 0.246 +boot: 0.245 +TCG: 0.240 +VMM: 0.237 +KVM: 0.124 +-------------------- +virtual: 0.900 +debug: 0.828 +vnc: 0.684 +hypervisor: 0.140 +ppc: 0.089 +network: 0.059 +files: 0.048 +kernel: 0.048 +PID: 0.040 +architecture: 0.026 +TCG: 0.023 +assembly: 0.019 +user-level: 0.019 +x86: 0.018 +device: 0.016 +arm: 0.015 +register: 0.014 +peripherals: 0.011 +graphic: 0.011 +i386: 0.011 +boot: 0.010 +semantic: 0.007 +socket: 0.004 +KVM: 0.003 +performance: 0.003 +permissions: 0.003 +risc-v: 0.002 +VMM: 0.002 +mistranslation: 0.000 + +VNC: virtio-gpu outputs not displayed by VNC client +Description of problem: +When combining virtio-gpu multiple outputs with VNC display, only output 0 is enabled. +Additional output are enabled when VNC client sent SetDesktopSize command. + +The following statement assumes that all displays (gtk, sdl) are disabled except VNC: + +# +Steps to reproduce: +1. Start Qemu +2. Start a VNC client on 5900 +3. Start the second VNC client on 5901 +Additional information: +The state of an output is controlled by the [enabled_output_bitmask](https://gitlab.com/qemu-project/qemu/-/blob/master/include/hw/virtio/virtio-gpu.h#L158) which is initialized to `1` at [device realization](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L204), thus VNC0 is always enabled. + +Other devices will set this parameter during inititliazation by calling [dpy_set_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/console.c#L754) which schedules a call to [virtio_gpu_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L89). However VNC calls this function only when handling [VNC_MSG_CLIENT_SET_DESKTOP_SIZE](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L2607) client command.\ +If the client does not support this command or never changes the size of the default window, the respective display will remain disabled. diff --git a/results/classifier/118/review/2953 b/results/classifier/118/review/2953 new file mode 100644 index 000000000..c87609618 --- /dev/null +++ b/results/classifier/118/review/2953 @@ -0,0 +1,126 @@ +semantic: 0.851 +hypervisor: 0.846 +graphic: 0.837 +permissions: 0.833 +KVM: 0.826 +device: 0.821 +register: 0.819 +TCG: 0.810 +ppc: 0.809 +performance: 0.798 +vnc: 0.794 +architecture: 0.792 +debug: 0.781 +peripherals: 0.778 +virtual: 0.777 +assembly: 0.770 +arm: 0.760 +x86: 0.754 +PID: 0.746 +risc-v: 0.740 +VMM: 0.735 +user-level: 0.729 +kernel: 0.701 +files: 0.699 +boot: 0.693 +mistranslation: 0.682 +network: 0.670 +i386: 0.572 +socket: 0.480 +-------------------- +x86: 0.975 +virtual: 0.861 +kernel: 0.748 +hypervisor: 0.581 +boot: 0.151 +register: 0.081 +files: 0.060 +KVM: 0.048 +debug: 0.034 +TCG: 0.023 +PID: 0.023 +device: 0.020 +VMM: 0.019 +user-level: 0.015 +risc-v: 0.012 +semantic: 0.008 +architecture: 0.007 +performance: 0.006 +peripherals: 0.006 +socket: 0.006 +vnc: 0.006 +graphic: 0.006 +ppc: 0.005 +assembly: 0.004 +permissions: 0.003 +i386: 0.002 +network: 0.001 +arm: 0.001 +mistranslation: 0.001 + +"DMAR: DRHD: handling fault status reg 2" with vfio on kernel 6.13.11-200.fc41.x86_64, works with 6.13.9-200.fc41.x86_64 +Description of problem: +Since kernel 6.13.11-200.fc41.x86_64, I cannot use VFIO to pass an NVIDIA GeForce GTX 1070 card to a Windows guest. The same setup works just fine in 6.13.9-200.fc41.x86_64. The issue symptoms are the same regardless if I use kernel command line arguments to isolate cpus or not. + +Symptoms: +- qemu logs show: +``` +2025-05-07T09:59:49.957891Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.1, no available reset mechanism. +2025-05-07T09:59:49.958444Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.0, no available reset mechanism. +2025-05-07T09:59:49.959119Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.1, no available reset mechanism. +2025-05-07T09:59:49.959635Z qemu-system-x86_64: vfio: Cannot reset device 0000:36:00.0, no available reset mechanism. +``` +- in dmesg I see: +``` +kernel: DMAR: DRHD: handling fault status reg 2 +kernel: DMAR: [INTR-REMAP] Request device [36:00.0] fault index 0x50 [fault reason 0x22] Present field in the IRTE entry is clear +``` +- the VM hangs at boot (please see the notes below (*)). +Steps to reproduce: +Boot the same libvirt domain in kernel 6.13.9-200.fc41.x86_64 (works) and any other more recent kernel (>= 6.13.11-200.fc41.x86_64). +Additional information: +(*) Note that in a working kernel, the boot process is in any case finicky, and it shows these phases: +1. tianocore logo shows, and one single cpu is fully utilized by the guest +2. slowly, the loader find the Windows bootloader, and prints a message that it is loading and running it +3. some time passes, while cpus seem idle +4. finally the spinning wheel of the Windows bootloader appears + +Phase 1-3 can take anywhere from 0 to 60 seconds, in an apparently random manner. + +When running on the faulty kernels, it seems that the virtual machine gets stuck in phase 1, and I must use `virsh destroy` to interrupt it. + +lspci output: +``` +-[0000:00]-+-00.0 Intel Corporation Tiger Lake-UP3/H35 4 cores Host Bridge/DRAM Registers + +-02.0 Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] + +-04.0 Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant + +-06.0-[01]----00.0 Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 + +-07.0-[02-33]-- + +-0a.0 Intel Corporation Tigerlake Telemetry Aggregator Driver + +-0d.0 Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller + +-0d.2 Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 + +-14.0 Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller + +-14.2 Intel Corporation Tiger Lake-LP Shared SRAM + +-15.0 Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 + +-15.1 Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 + +-15.2 Intel Corporation Tiger Lake-LP Serial IO I2C Controller #2 + +-16.0 Intel Corporation Tiger Lake-LP Management Engine Interface + +-1c.0-[34]----00.0 Intel Corporation Wi-Fi 6 AX200 + +-1c.5-[35]----00.0 Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader + +-1d.0-[36]--+-00.0 NVIDIA Corporation GP104 [GeForce GTX 1070] + | \-00.1 NVIDIA Corporation GP104 High Definition Audio Controller + +-1f.0 Intel Corporation Tiger Lake-LP LPC Controller + +-1f.3 Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller + +-1f.4 Intel Corporation Tiger Lake-LP SMBus Controller + \-1f.5 Intel Corporation Tiger Lake-LP SPI Controller +``` + +kernel command line arguments (optimized with cpu isolation): +``` +intel_pstate=per_cpu_perf_limits rd.driver.blacklist=nouveau modprobe.blacklist=nouveau module_blacklist=nouveau default_hugepagesz=1G hugepagesz=1G hugepages=13 i2c_i801.disable_features=0x10 rd.driver.pre=vfio_pci,vfio,vfio_iommu_type1 vfio-pci.ids=10de:1b81,10de:10f0 modprobe.blacklist=xpad systemd.unit=multi-user.target systemd.wants=bluetooth.service isolcpus=domain,managed_irq,1-3,5-7 rcu_nocbs=1-3,5-7 irqaffinity=0,4 nospectre_v2 +``` + +kernel command line arguments (without cpu isolation, same symptoms): +``` +intel_pstate=per_cpu_perf_limits rd.driver.blacklist=nouveau modprobe.blacklist=nouveau module_blacklist=nouveau default_hugepagesz=1G hugepagesz=1G hugepages=13 rd.driver.pre=vfio_pci,vfio,vfio_iommu_type1 vfio-pci.ids=10de:1b81,10de:10f0 modprobe.blacklist=xpad systemd.unit=multi-user.target systemd.wants=bluetooth.service +``` diff --git a/results/classifier/118/review/2954 b/results/classifier/118/review/2954 new file mode 100644 index 000000000..9effbdeeb --- /dev/null +++ b/results/classifier/118/review/2954 @@ -0,0 +1,79 @@ +x86: 0.903 +graphic: 0.850 +semantic: 0.823 +device: 0.755 +architecture: 0.746 +ppc: 0.656 +i386: 0.654 +boot: 0.579 +peripherals: 0.519 +vnc: 0.469 +mistranslation: 0.466 +kernel: 0.465 +virtual: 0.460 +KVM: 0.407 +VMM: 0.351 +hypervisor: 0.337 +PID: 0.336 +network: 0.325 +user-level: 0.322 +socket: 0.309 +arm: 0.264 +debug: 0.260 +permissions: 0.255 +register: 0.249 +TCG: 0.231 +risc-v: 0.223 +files: 0.204 +performance: 0.197 +assembly: 0.110 +-------------------- +device: 0.629 +boot: 0.545 +virtual: 0.117 +debug: 0.101 +x86: 0.049 +hypervisor: 0.041 +TCG: 0.029 +peripherals: 0.024 +user-level: 0.013 +files: 0.007 +register: 0.007 +PID: 0.005 +architecture: 0.004 +socket: 0.004 +semantic: 0.003 +assembly: 0.003 +network: 0.002 +kernel: 0.002 +VMM: 0.002 +arm: 0.002 +performance: 0.001 +KVM: 0.001 +risc-v: 0.001 +graphic: 0.001 +permissions: 0.001 +i386: 0.001 +ppc: 0.001 +mistranslation: 0.000 +vnc: 0.000 + +SD card is not visible by UEFI +Description of problem: +SD card is not visible by OVMF UEFI, so it's not possible to boot from it: +``` +UEFI Interactive Shell v2.2 +EDK II +UEFI v2.70 (EDK II, 0x00010000) +Mapping table + BLK0: Alias(s): + PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0) +Press ESC in 1 seconds to skip startup.nsh or any other key to continue. +Shell> +``` +It is visible by SeaBIOS though, if we remove the OVMF part from the commandline: +``` +qemu-system-x86_64 -device sdhci-pci -drive if=none,file=Fedora-IoT-ostree-41-20241027.0.x86_64.iso,format=raw,id=MMC1 -device sd-card,drive=MMC1 +``` + +@philmd diff --git a/results/classifier/118/review/2956 b/results/classifier/118/review/2956 new file mode 100644 index 000000000..24d9b5136 --- /dev/null +++ b/results/classifier/118/review/2956 @@ -0,0 +1,274 @@ +risc-v: 0.838 +KVM: 0.838 +x86: 0.827 +permissions: 0.825 +ppc: 0.817 +architecture: 0.809 +debug: 0.809 +VMM: 0.808 +boot: 0.804 +device: 0.803 +arm: 0.801 +virtual: 0.794 +user-level: 0.792 +kernel: 0.791 +vnc: 0.787 +semantic: 0.779 +assembly: 0.776 +peripherals: 0.770 +PID: 0.769 +socket: 0.766 +graphic: 0.760 +performance: 0.759 +network: 0.750 +register: 0.744 +hypervisor: 0.738 +mistranslation: 0.730 +files: 0.724 +TCG: 0.722 +i386: 0.594 +-------------------- +hypervisor: 0.889 +x86: 0.779 +KVM: 0.765 +virtual: 0.697 +debug: 0.385 +kernel: 0.234 +TCG: 0.121 +device: 0.076 +files: 0.055 +PID: 0.053 +architecture: 0.044 +semantic: 0.035 +socket: 0.030 +register: 0.026 +user-level: 0.021 +VMM: 0.014 +peripherals: 0.011 +assembly: 0.007 +boot: 0.005 +risc-v: 0.004 +network: 0.004 +performance: 0.003 +permissions: 0.002 +ppc: 0.002 +graphic: 0.002 +vnc: 0.001 +mistranslation: 0.001 +i386: 0.000 +arm: 0.000 + +AMD SEV-SNP: vhost-user-fs-pci iommu_platform=true is not supported by the device +Description of problem: +Trying to make use of `vhost-user-fs-pci` with `sev-snp-guest` enabled doesn't work. +The system reports that `vhost-user-fs-pci` doesn't support IOMMU but as far as I understand +we need IOMMU for the virtio protocol to fully function. +Steps to reproduce: +1. Ensure you are running on a system with AMD SNP support: +``` +sudo dmesg | grep -i sev +[ 0.000000] SEV-SNP: RMP table physical range [0x000000bfbd000000 - 0x000000c07d8fffff] +[ 0.003807] SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x000000c07d800000] +[ 8.085220] ccp 0000:06:00.5: sev enabled +[ 16.226155] ccp 0000:06:00.5: SEV API:1.55 build:28 +[ 16.226162] ccp 0000:06:00.5: SEV-SNP API:1.55 build:28 +[ 16.239284] kvm_amd: SEV enabled (ASIDs 15 - 1006) +[ 16.239289] kvm_amd: SEV-ES enabled (ASIDs 1 - 14) +[ 16.239292] kvm_amd: SEV-SNP enabled (ASIDs 1 - 14) +``` +2. Use an OVMF which supports AMD SNP: https://github.com/tianocore/edk2.git branch: edk2-stable202502 +3. Launch the virtiofs daemon process. +4. Launch qemu with device `vhost-user-fs-pci` +5. The qemu process will terminate with the following error message: + +``` +qemu-system-x86_64: -device vhost-user-fs-pci,chardev=fs0,tag=cfg: iommu_platform=true is not supported by the device +``` +Additional information: +It does launch if I disable any AMD SEV-SNP functionality from the VM: + +``` +sudo ./qemu-system-x86_64 \ + -nodefaults \ + -enable-kvm \ + -cpu host \ + -object memory-backend-memfd,id=mem0,size=2048M,share=on \ + -machine q35,memory-backend=mem0 \ + -smp cpus=1 \ + -drive file=ubuntu.qcow2,if=none,id=disk0,format=qcow2 \ + -device virtio-blk-pci,drive=disk0 \ + -device amd-iommu \ + -chardev socket,id=fs0,path=/var/run/virtiofs/cfg.sock \ + -device vhost-user-fs-pci,chardev=fs0,tag=cfg \ + -bios ./ovmf-dist/x86_64/OVMF.fd \ + -kernel ./linux-guest-6.12.15-1-/boot/vmlinuz-6.12.15-1 \ + -initrd ./initrd/initrd.img \ + -append 'console=ttyS0' \ + -display none + -nographic + -chardev stdio,id=stdio0,signal=off \ + -serial chardev:stdio0 \ + -D /tmp/qemu-vmm.log \ + -d 'guest_errors,unimp,trace:virtio*' +``` + +BTW: I've also managed to reproduce the same bug on AMD's fork: +- Repo: https://github.com/AMDESE/qemu.git +- Branch: snp-latest + +Configure flags: +``` + --target-list=x86_64-softmmu \ + --prefix=/builder/out/qemu-dist \ + --sysconfdir=/builder/out/qemu-dist/etc \ + --libdir=/builder/out/qemu-dist/lib \ + --libexecdir=/builder/out/qemu-dist/lib/qemu \ + --localstatedir=/builder/out/qemu-dist/var \ + --ninja=/usr/bin/ninja \ + --python=/usr/bin/python3 \ + --with-pkgversion=qemu \ + --cc=/usr/bin/x86_64-linux-gnu-gcc-13 \ + --static \ + --disable-cocoa \ + --disable-curses \ + --disable-dbus-display \ + --disable-gtk \ + --disable-gtk-clipboard \ + --disable-opengl \ + --disable-png \ + --disable-sdl \ + --disable-sdl-image \ + --disable-spice \ + --disable-spice-protocol \ + --disable-virglrenderer \ + --disable-vnc \ + --disable-vnc-jpeg \ + --disable-vnc-sasl \ + --disable-vte \ + --disable-alsa \ + --disable-coreaudio \ + --disable-dsound \ + --disable-jack \ + --disable-oss \ + --disable-pa \ + --disable-pipewire \ + --disable-sndio \ + --disable-vvfat \ + --disable-vdi \ + --disable-qed \ + --disable-qcow1 \ + --disable-bochs \ + --disable-cloop \ + --disable-dmg \ + --disable-parallels \ + --disable-vpc \ + --disable-vmdk \ + --disable-vhdx \ + --disable-bzip2 \ + --disable-lzfse \ + --disable-snappy \ + --disable-lzo \ + --disable-netmap \ + --disable-l2tpv3 \ + --disable-slirp-smbd \ + --disable-vde \ + --disable-vmnet \ + --disable-vhost-user-blk-server \ + --disable-vfio-user-server \ + --disable-curl \ + --disable-glusterfs \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-libssh \ + --disable-mpath \ + --disable-rbd \ + --disable-vduse-blk-export \ + --disable-virtfs \ + --disable-fuse \ + --disable-fuse-lseek \ + --disable-blkio \ + --disable-nettle \ + --disable-gcrypt \ + --disable-gnutls \ + --disable-crypto-afalg \ + --disable-libkeyutils \ + --disable-libkeyutils \ + --disable-auth-pam \ + --disable-keyring \ + --disable-selinux \ + --disable-u2f \ + --disable-brlapi \ + --disable-canokey \ + --disable-hvf \ + --disable-hv-balloon \ + --disable-libdaxctl \ + --disable-libudev \ + --disable-libusb \ + --disable-nvmm \ + --disable-rdma \ + --disable-smartcard \ + --disable-usb-redir \ + --disable-whpx \ + --disable-xen \ + --disable-xen-pci-passthrough \ + --disable-guest-agent \ + --disable-guest-agent-msi \ + --disable-colo-proxy \ + --disable-rutabaga-gfx \ + --disable-vhost-crypto \ + --disable-capstone \ + --disable-docs \ + --disable-gettext \ + --disable-iconv \ + --disable-libdw \ + --disable-pixman \ + --disable-sparse \ + --disable-xkbcommon \ + --disable-attr \ + --disable-gio \ + --disable-multiprocess \ + --disable-plugins \ + --disable-qpl \ + --disable-replication \ + --disable-uadk \ + --disable-libvduse \ + --disable-libpmem \ + --disable-user \ + --disable-bsd-user \ + --disable-linux-user \ + --disable-tcg \ + --disable-debug-tcg \ + --disable-tcg-interpreter \ + --disable-hexagon-idef-parser \ + --disable-qom-cast-debug \ + --enable-kvm \ + --enable-system \ + --enable-pie \ + --enable-lto \ + --enable-af-xdp \ + --enable-slirp \ + --enable-vhost-kernel \ + --enable-vhost-net \ + --enable-vhost-user \ + --enable-vhost-vdpa \ + --enable-bpf \ + --enable-coroutine-pool \ + --enable-linux-aio \ + --enable-linux-io-uring \ + --enable-malloc-trim \ + --enable-membarrier \ + --enable-cap-ng \ + --enable-seccomp \ + --enable-stack-protector \ + --enable-tpm \ + --enable-zstd \ + --enable-numa \ + --enable-fdt=disabled \ + --enable-install-blobs \ + --enable-tools \ + --enable-trace-backends=log \ + --enable-strip \ + --x86-version=4 \ + --extra-cflags=-O2 -fno-semantic-interposition -fdevirtualize-at-ltrans -flto=auto -fuse-linker-plugin -falign-functions=32 -D_FORTIFY_SOURCE=2 -Wno-deprecated-declarations -Wno-error=stringop-overflow -Wformat -Werror=format-security -Werror=implicit-function-declaration -fstack-protector-strong -fstack-clash-protection -fcf-protection -fipa-pta \ + --extra-ldflags=-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--as-needed +``` diff --git a/results/classifier/118/review/297 b/results/classifier/118/review/297 new file mode 100644 index 000000000..88a9c861c --- /dev/null +++ b/results/classifier/118/review/297 @@ -0,0 +1,61 @@ +mistranslation: 0.977 +ppc: 0.853 +device: 0.840 +debug: 0.441 +boot: 0.435 +risc-v: 0.350 +graphic: 0.282 +semantic: 0.206 +TCG: 0.173 +architecture: 0.163 +PID: 0.162 +i386: 0.159 +vnc: 0.153 +performance: 0.110 +arm: 0.096 +network: 0.091 +virtual: 0.078 +KVM: 0.068 +register: 0.062 +VMM: 0.055 +peripherals: 0.052 +kernel: 0.043 +assembly: 0.031 +user-level: 0.031 +x86: 0.017 +hypervisor: 0.016 +permissions: 0.015 +socket: 0.007 +files: 0.006 +-------------------- +semantic: 0.826 +peripherals: 0.749 +user-level: 0.389 +device: 0.192 +virtual: 0.090 +mistranslation: 0.040 +files: 0.030 +VMM: 0.011 +debug: 0.006 +register: 0.005 +TCG: 0.005 +performance: 0.005 +risc-v: 0.004 +PID: 0.003 +graphic: 0.003 +boot: 0.002 +kernel: 0.002 +assembly: 0.002 +i386: 0.001 +vnc: 0.001 +socket: 0.001 +KVM: 0.001 +network: 0.001 +architecture: 0.001 +x86: 0.001 +ppc: 0.001 +hypervisor: 0.000 +permissions: 0.000 +arm: 0.000 + +SD card size constraint conceptually wrong diff --git a/results/classifier/118/review/2971 b/results/classifier/118/review/2971 new file mode 100644 index 000000000..dfff0e870 --- /dev/null +++ b/results/classifier/118/review/2971 @@ -0,0 +1,104 @@ +TCG: 0.920 +architecture: 0.918 +vnc: 0.780 +device: 0.770 +ppc: 0.768 +performance: 0.742 +PID: 0.714 +kernel: 0.693 +assembly: 0.671 +network: 0.667 +hypervisor: 0.630 +socket: 0.623 +permissions: 0.616 +risc-v: 0.599 +graphic: 0.579 +files: 0.566 +VMM: 0.553 +semantic: 0.515 +arm: 0.499 +debug: 0.475 +boot: 0.473 +virtual: 0.460 +peripherals: 0.432 +register: 0.419 +KVM: 0.396 +user-level: 0.389 +x86: 0.317 +i386: 0.308 +mistranslation: 0.282 +-------------------- +TCG: 0.494 +debug: 0.162 +hypervisor: 0.131 +performance: 0.112 +semantic: 0.079 +files: 0.072 +kernel: 0.071 +architecture: 0.036 +assembly: 0.034 +PID: 0.016 +VMM: 0.014 +virtual: 0.011 +register: 0.009 +device: 0.007 +user-level: 0.006 +arm: 0.006 +x86: 0.005 +boot: 0.005 +network: 0.003 +peripherals: 0.003 +ppc: 0.002 +vnc: 0.001 +risc-v: 0.001 +graphic: 0.001 +permissions: 0.001 +socket: 0.001 +KVM: 0.001 +mistranslation: 0.001 +i386: 0.000 + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/118/review/2985 b/results/classifier/118/review/2985 new file mode 100644 index 000000000..c9915b97c --- /dev/null +++ b/results/classifier/118/review/2985 @@ -0,0 +1,68 @@ +TCG: 0.944 +device: 0.877 +performance: 0.788 +network: 0.711 +ppc: 0.661 +vnc: 0.658 +semantic: 0.652 +graphic: 0.645 +files: 0.578 +kernel: 0.502 +mistranslation: 0.502 +peripherals: 0.485 +socket: 0.483 +debug: 0.478 +VMM: 0.450 +arm: 0.437 +risc-v: 0.416 +architecture: 0.405 +boot: 0.387 +register: 0.371 +PID: 0.324 +i386: 0.283 +hypervisor: 0.272 +x86: 0.242 +virtual: 0.172 +KVM: 0.138 +user-level: 0.087 +assembly: 0.083 +permissions: 0.059 +-------------------- +performance: 0.949 +hypervisor: 0.816 +user-level: 0.419 +kernel: 0.177 +virtual: 0.104 +TCG: 0.093 +KVM: 0.092 +PID: 0.084 +register: 0.064 +files: 0.042 +x86: 0.019 +assembly: 0.017 +device: 0.015 +VMM: 0.011 +risc-v: 0.009 +arm: 0.009 +debug: 0.008 +semantic: 0.007 +ppc: 0.006 +socket: 0.005 +boot: 0.005 +architecture: 0.004 +peripherals: 0.004 +i386: 0.003 +network: 0.003 +permissions: 0.003 +graphic: 0.002 +vnc: 0.001 +mistranslation: 0.000 + +throttle group limit feature request for discard +Additional information: +- Need to add particular options in [ThrottleGroupProperties](https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html#object-QMP-block-core.ThrottleGroupProperties) which like this +```txt +x-discard-iops-total +x-discard-iops-total-max +.... +``` diff --git a/results/classifier/118/review/312 b/results/classifier/118/review/312 new file mode 100644 index 000000000..4d44d254b --- /dev/null +++ b/results/classifier/118/review/312 @@ -0,0 +1,61 @@ +architecture: 0.915 +device: 0.884 +performance: 0.432 +graphic: 0.407 +arm: 0.355 +ppc: 0.348 +debug: 0.181 +mistranslation: 0.153 +user-level: 0.123 +semantic: 0.109 +network: 0.075 +virtual: 0.061 +risc-v: 0.057 +hypervisor: 0.056 +register: 0.046 +boot: 0.029 +socket: 0.028 +TCG: 0.027 +peripherals: 0.020 +VMM: 0.017 +kernel: 0.010 +assembly: 0.009 +vnc: 0.009 +PID: 0.008 +files: 0.007 +permissions: 0.007 +x86: 0.001 +i386: 0.001 +KVM: 0.000 +-------------------- +ppc: 0.988 +virtual: 0.933 +user-level: 0.545 +assembly: 0.364 +register: 0.076 +debug: 0.057 +hypervisor: 0.031 +performance: 0.020 +peripherals: 0.019 +files: 0.018 +device: 0.012 +architecture: 0.008 +kernel: 0.005 +semantic: 0.005 +TCG: 0.003 +graphic: 0.003 +PID: 0.002 +x86: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +socket: 0.001 +boot: 0.001 +arm: 0.001 +VMM: 0.000 +KVM: 0.000 +network: 0.000 +permissions: 0.000 +vnc: 0.000 +i386: 0.000 + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/118/review/314 b/results/classifier/118/review/314 new file mode 100644 index 000000000..d47f7e8f7 --- /dev/null +++ b/results/classifier/118/review/314 @@ -0,0 +1,61 @@ +user-level: 0.909 +performance: 0.829 +architecture: 0.779 +mistranslation: 0.740 +network: 0.738 +device: 0.718 +semantic: 0.604 +debug: 0.597 +virtual: 0.581 +i386: 0.572 +peripherals: 0.544 +graphic: 0.458 +x86: 0.427 +assembly: 0.398 +arm: 0.373 +VMM: 0.319 +hypervisor: 0.226 +vnc: 0.160 +boot: 0.107 +socket: 0.105 +permissions: 0.104 +register: 0.085 +files: 0.048 +TCG: 0.047 +ppc: 0.039 +kernel: 0.037 +risc-v: 0.018 +PID: 0.017 +KVM: 0.003 +-------------------- +virtual: 0.976 +i386: 0.968 +x86: 0.968 +hypervisor: 0.938 +KVM: 0.774 +assembly: 0.671 +debug: 0.617 +user-level: 0.508 +VMM: 0.251 +semantic: 0.037 +TCG: 0.023 +kernel: 0.020 +performance: 0.016 +files: 0.015 +device: 0.009 +network: 0.008 +PID: 0.008 +register: 0.006 +socket: 0.006 +architecture: 0.003 +peripherals: 0.003 +boot: 0.003 +ppc: 0.002 +graphic: 0.002 +arm: 0.001 +risc-v: 0.001 +vnc: 0.001 +permissions: 0.000 +mistranslation: 0.000 + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip diff --git a/results/classifier/118/review/323 b/results/classifier/118/review/323 new file mode 100644 index 000000000..66313453e --- /dev/null +++ b/results/classifier/118/review/323 @@ -0,0 +1,61 @@ +architecture: 0.897 +socket: 0.873 +network: 0.864 +device: 0.850 +files: 0.645 +PID: 0.632 +arm: 0.597 +peripherals: 0.539 +VMM: 0.518 +hypervisor: 0.507 +graphic: 0.494 +debug: 0.487 +kernel: 0.486 +register: 0.465 +performance: 0.464 +virtual: 0.435 +boot: 0.434 +vnc: 0.416 +semantic: 0.384 +ppc: 0.372 +TCG: 0.371 +permissions: 0.365 +i386: 0.280 +risc-v: 0.277 +mistranslation: 0.261 +x86: 0.237 +assembly: 0.179 +user-level: 0.096 +KVM: 0.030 +-------------------- +hypervisor: 0.980 +virtual: 0.937 +socket: 0.890 +network: 0.692 +semantic: 0.040 +KVM: 0.038 +device: 0.034 +files: 0.032 +PID: 0.030 +x86: 0.023 +TCG: 0.023 +user-level: 0.022 +assembly: 0.018 +register: 0.012 +kernel: 0.012 +debug: 0.012 +ppc: 0.005 +i386: 0.005 +arm: 0.004 +VMM: 0.003 +graphic: 0.001 +boot: 0.001 +vnc: 0.001 +performance: 0.001 +architecture: 0.001 +permissions: 0.000 +risc-v: 0.000 +peripherals: 0.000 +mistranslation: 0.000 + +qemu 5.2.0: Add reconnect option support for netdev socket diff --git a/results/classifier/118/review/333 b/results/classifier/118/review/333 new file mode 100644 index 000000000..b5c56799a --- /dev/null +++ b/results/classifier/118/review/333 @@ -0,0 +1,61 @@ +architecture: 0.863 +device: 0.837 +arm: 0.742 +performance: 0.697 +network: 0.605 +mistranslation: 0.332 +debug: 0.327 +graphic: 0.311 +risc-v: 0.306 +boot: 0.304 +ppc: 0.175 +vnc: 0.119 +register: 0.104 +TCG: 0.097 +permissions: 0.068 +socket: 0.060 +peripherals: 0.053 +semantic: 0.050 +VMM: 0.048 +files: 0.048 +PID: 0.046 +kernel: 0.040 +user-level: 0.038 +virtual: 0.036 +assembly: 0.010 +hypervisor: 0.002 +i386: 0.001 +x86: 0.001 +KVM: 0.001 +-------------------- +architecture: 0.697 +assembly: 0.594 +debug: 0.151 +kernel: 0.112 +arm: 0.053 +register: 0.036 +files: 0.030 +performance: 0.029 +virtual: 0.024 +user-level: 0.024 +TCG: 0.017 +peripherals: 0.013 +device: 0.012 +VMM: 0.011 +KVM: 0.011 +semantic: 0.006 +hypervisor: 0.005 +PID: 0.005 +network: 0.003 +graphic: 0.003 +boot: 0.003 +risc-v: 0.002 +mistranslation: 0.001 +vnc: 0.001 +socket: 0.001 +permissions: 0.000 +ppc: 0.000 +i386: 0.000 +x86: 0.000 + +random errors on aarch64 when executing __aarch64_cas8_acq_rel diff --git a/results/classifier/118/review/345 b/results/classifier/118/review/345 new file mode 100644 index 000000000..c23d3f228 --- /dev/null +++ b/results/classifier/118/review/345 @@ -0,0 +1,61 @@ +mistranslation: 0.885 +device: 0.828 +graphic: 0.557 +debug: 0.443 +arm: 0.430 +performance: 0.396 +assembly: 0.290 +network: 0.222 +architecture: 0.219 +ppc: 0.159 +boot: 0.129 +peripherals: 0.118 +PID: 0.056 +risc-v: 0.043 +vnc: 0.040 +virtual: 0.039 +socket: 0.037 +hypervisor: 0.036 +permissions: 0.030 +VMM: 0.030 +TCG: 0.022 +semantic: 0.015 +register: 0.012 +files: 0.012 +user-level: 0.011 +i386: 0.007 +x86: 0.005 +kernel: 0.004 +KVM: 0.001 +-------------------- +debug: 0.900 +network: 0.848 +mistranslation: 0.739 +kernel: 0.640 +virtual: 0.078 +assembly: 0.077 +files: 0.060 +semantic: 0.046 +device: 0.038 +x86: 0.028 +peripherals: 0.024 +KVM: 0.022 +TCG: 0.022 +user-level: 0.019 +arm: 0.015 +VMM: 0.014 +architecture: 0.012 +performance: 0.012 +hypervisor: 0.011 +PID: 0.010 +i386: 0.008 +socket: 0.007 +graphic: 0.006 +risc-v: 0.006 +ppc: 0.005 +boot: 0.003 +register: 0.003 +vnc: 0.002 +permissions: 0.000 + +Sector translation bug in scsi_unmap_complete_noio diff --git a/results/classifier/118/review/348 b/results/classifier/118/review/348 new file mode 100644 index 000000000..e830b2b58 --- /dev/null +++ b/results/classifier/118/review/348 @@ -0,0 +1,61 @@ +user-level: 0.941 +network: 0.824 +performance: 0.627 +debug: 0.576 +device: 0.463 +socket: 0.387 +graphic: 0.371 +architecture: 0.346 +semantic: 0.301 +mistranslation: 0.281 +peripherals: 0.206 +PID: 0.176 +TCG: 0.174 +boot: 0.174 +i386: 0.162 +virtual: 0.147 +arm: 0.144 +VMM: 0.122 +x86: 0.114 +vnc: 0.100 +ppc: 0.098 +register: 0.078 +permissions: 0.075 +kernel: 0.038 +assembly: 0.015 +files: 0.012 +hypervisor: 0.011 +risc-v: 0.007 +KVM: 0.003 +-------------------- +virtual: 0.963 +hypervisor: 0.715 +user-level: 0.618 +network: 0.289 +VMM: 0.039 +TCG: 0.027 +debug: 0.025 +socket: 0.018 +register: 0.018 +semantic: 0.016 +files: 0.016 +PID: 0.015 +KVM: 0.011 +assembly: 0.008 +device: 0.006 +performance: 0.005 +x86: 0.004 +kernel: 0.004 +boot: 0.003 +graphic: 0.002 +ppc: 0.002 +vnc: 0.002 +peripherals: 0.002 +architecture: 0.002 +arm: 0.001 +permissions: 0.001 +i386: 0.001 +risc-v: 0.001 +mistranslation: 0.000 + +qemu-user fails to run container using systemd-networkd: "Could not create manager: Protocol not supported" diff --git a/results/classifier/118/review/359 b/results/classifier/118/review/359 new file mode 100644 index 000000000..ddbf73965 --- /dev/null +++ b/results/classifier/118/review/359 @@ -0,0 +1,61 @@ +mistranslation: 0.871 +files: 0.861 +architecture: 0.797 +device: 0.795 +socket: 0.746 +network: 0.721 +VMM: 0.673 +arm: 0.603 +peripherals: 0.586 +performance: 0.563 +register: 0.521 +vnc: 0.474 +ppc: 0.470 +PID: 0.469 +kernel: 0.465 +virtual: 0.461 +semantic: 0.434 +boot: 0.414 +debug: 0.409 +graphic: 0.407 +permissions: 0.354 +i386: 0.349 +hypervisor: 0.305 +TCG: 0.302 +x86: 0.299 +risc-v: 0.230 +KVM: 0.229 +user-level: 0.181 +assembly: 0.088 +-------------------- +files: 0.804 +semantic: 0.115 +VMM: 0.073 +virtual: 0.038 +TCG: 0.035 +network: 0.026 +hypervisor: 0.023 +user-level: 0.017 +register: 0.014 +x86: 0.012 +KVM: 0.012 +device: 0.007 +debug: 0.006 +risc-v: 0.006 +boot: 0.005 +i386: 0.004 +arm: 0.004 +mistranslation: 0.003 +ppc: 0.003 +permissions: 0.003 +kernel: 0.003 +PID: 0.003 +architecture: 0.002 +peripherals: 0.002 +graphic: 0.002 +socket: 0.002 +performance: 0.002 +assembly: 0.002 +vnc: 0.001 + +In the "tests/qtests/meson.build" line 92 need dbus-vmstate1.h and dbus-vmstate1.c files, but in "tests/qtests/" not include this files. diff --git a/results/classifier/118/review/361 b/results/classifier/118/review/361 new file mode 100644 index 000000000..b68733527 --- /dev/null +++ b/results/classifier/118/review/361 @@ -0,0 +1,61 @@ +architecture: 0.937 +mistranslation: 0.634 +semantic: 0.465 +x86: 0.451 +graphic: 0.432 +risc-v: 0.354 +performance: 0.350 +i386: 0.307 +debug: 0.305 +ppc: 0.294 +arm: 0.263 +vnc: 0.253 +device: 0.243 +boot: 0.163 +TCG: 0.154 +PID: 0.141 +KVM: 0.134 +VMM: 0.095 +permissions: 0.092 +kernel: 0.078 +register: 0.027 +virtual: 0.021 +assembly: 0.014 +network: 0.006 +socket: 0.006 +user-level: 0.006 +hypervisor: 0.004 +files: 0.002 +peripherals: 0.001 +-------------------- +architecture: 0.219 +virtual: 0.069 +user-level: 0.043 +kernel: 0.038 +semantic: 0.027 +assembly: 0.023 +KVM: 0.017 +performance: 0.016 +hypervisor: 0.014 +risc-v: 0.009 +debug: 0.006 +x86: 0.006 +TCG: 0.005 +files: 0.005 +ppc: 0.004 +socket: 0.004 +device: 0.003 +VMM: 0.003 +register: 0.002 +graphic: 0.002 +boot: 0.002 +PID: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +arm: 0.001 +permissions: 0.001 +vnc: 0.000 +i386: 0.000 +network: 0.000 + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/118/review/364 b/results/classifier/118/review/364 new file mode 100644 index 000000000..485c3b77e --- /dev/null +++ b/results/classifier/118/review/364 @@ -0,0 +1,61 @@ +mistranslation: 0.988 +architecture: 0.881 +device: 0.767 +performance: 0.616 +arm: 0.551 +graphic: 0.471 +debug: 0.404 +assembly: 0.259 +semantic: 0.230 +network: 0.202 +hypervisor: 0.131 +files: 0.127 +register: 0.116 +boot: 0.097 +user-level: 0.077 +virtual: 0.074 +vnc: 0.067 +VMM: 0.061 +ppc: 0.049 +kernel: 0.043 +permissions: 0.040 +PID: 0.027 +peripherals: 0.023 +socket: 0.018 +TCG: 0.016 +risc-v: 0.008 +KVM: 0.005 +x86: 0.003 +i386: 0.002 +-------------------- +virtual: 0.953 +hypervisor: 0.926 +assembly: 0.580 +debug: 0.336 +arm: 0.263 +architecture: 0.171 +user-level: 0.042 +files: 0.022 +semantic: 0.016 +kernel: 0.015 +TCG: 0.011 +register: 0.010 +performance: 0.009 +device: 0.005 +KVM: 0.005 +VMM: 0.004 +PID: 0.002 +graphic: 0.002 +peripherals: 0.001 +boot: 0.001 +risc-v: 0.001 +socket: 0.000 +ppc: 0.000 +network: 0.000 +mistranslation: 0.000 +vnc: 0.000 +permissions: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/118/review/367 b/results/classifier/118/review/367 new file mode 100644 index 000000000..e8433a60d --- /dev/null +++ b/results/classifier/118/review/367 @@ -0,0 +1,61 @@ +architecture: 0.952 +device: 0.812 +graphic: 0.797 +debug: 0.449 +performance: 0.372 +network: 0.292 +files: 0.250 +register: 0.215 +arm: 0.214 +user-level: 0.182 +semantic: 0.166 +permissions: 0.142 +hypervisor: 0.122 +boot: 0.107 +peripherals: 0.097 +mistranslation: 0.073 +virtual: 0.070 +PID: 0.063 +vnc: 0.060 +assembly: 0.050 +ppc: 0.049 +socket: 0.042 +VMM: 0.038 +TCG: 0.025 +kernel: 0.024 +x86: 0.010 +risc-v: 0.009 +i386: 0.003 +KVM: 0.002 +-------------------- +virtual: 0.959 +hypervisor: 0.928 +arm: 0.801 +user-level: 0.087 +debug: 0.073 +architecture: 0.033 +device: 0.025 +TCG: 0.023 +semantic: 0.020 +KVM: 0.020 +files: 0.018 +assembly: 0.016 +PID: 0.012 +performance: 0.010 +register: 0.006 +kernel: 0.006 +graphic: 0.003 +socket: 0.003 +VMM: 0.003 +ppc: 0.001 +boot: 0.001 +risc-v: 0.001 +peripherals: 0.001 +network: 0.001 +mistranslation: 0.000 +vnc: 0.000 +permissions: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-system-aarch64 crash on qemu 6.0 - Windows 10 diff --git a/results/classifier/118/review/374 b/results/classifier/118/review/374 new file mode 100644 index 000000000..6de5caf7a --- /dev/null +++ b/results/classifier/118/review/374 @@ -0,0 +1,61 @@ +mistranslation: 0.809 +ppc: 0.798 +device: 0.639 +architecture: 0.607 +graphic: 0.424 +register: 0.343 +semantic: 0.317 +performance: 0.312 +boot: 0.295 +vnc: 0.279 +risc-v: 0.274 +PID: 0.268 +i386: 0.263 +socket: 0.237 +files: 0.236 +debug: 0.197 +arm: 0.185 +x86: 0.183 +TCG: 0.173 +virtual: 0.164 +permissions: 0.155 +VMM: 0.153 +network: 0.103 +kernel: 0.080 +assembly: 0.030 +peripherals: 0.023 +KVM: 0.021 +hypervisor: 0.018 +user-level: 0.006 +-------------------- +ppc: 0.866 +semantic: 0.207 +virtual: 0.037 +user-level: 0.027 +files: 0.022 +peripherals: 0.021 +device: 0.015 +mistranslation: 0.009 +debug: 0.008 +architecture: 0.007 +boot: 0.005 +performance: 0.004 +assembly: 0.004 +network: 0.003 +risc-v: 0.003 +PID: 0.003 +register: 0.003 +kernel: 0.002 +socket: 0.001 +TCG: 0.001 +graphic: 0.001 +VMM: 0.001 +arm: 0.001 +vnc: 0.000 +x86: 0.000 +hypervisor: 0.000 +KVM: 0.000 +permissions: 0.000 +i386: 0.000 + +Indentation should be done with spaces, not with TABs, in the PPC subsystem diff --git a/results/classifier/118/review/375 b/results/classifier/118/review/375 new file mode 100644 index 000000000..d162b8857 --- /dev/null +++ b/results/classifier/118/review/375 @@ -0,0 +1,61 @@ +x86: 0.986 +peripherals: 0.907 +device: 0.875 +architecture: 0.823 +performance: 0.595 +network: 0.572 +arm: 0.531 +socket: 0.460 +semantic: 0.386 +PID: 0.358 +graphic: 0.338 +risc-v: 0.328 +boot: 0.314 +files: 0.308 +debug: 0.298 +mistranslation: 0.284 +register: 0.272 +permissions: 0.258 +vnc: 0.210 +VMM: 0.165 +TCG: 0.143 +virtual: 0.112 +ppc: 0.109 +assembly: 0.090 +user-level: 0.078 +kernel: 0.047 +i386: 0.037 +hypervisor: 0.022 +KVM: 0.002 +-------------------- +x86: 0.310 +debug: 0.106 +peripherals: 0.101 +PID: 0.053 +semantic: 0.043 +user-level: 0.035 +virtual: 0.033 +files: 0.021 +device: 0.021 +TCG: 0.010 +register: 0.010 +kernel: 0.008 +VMM: 0.005 +hypervisor: 0.005 +boot: 0.004 +assembly: 0.004 +architecture: 0.003 +performance: 0.003 +socket: 0.003 +ppc: 0.001 +risc-v: 0.001 +graphic: 0.001 +KVM: 0.001 +network: 0.000 +mistranslation: 0.000 +vnc: 0.000 +permissions: 0.000 +arm: 0.000 +i386: 0.000 + +MacOS 11.4 (x86_64) Host - USB passthrough appears to be broken diff --git a/results/classifier/118/review/376 b/results/classifier/118/review/376 new file mode 100644 index 000000000..2e4a8611c --- /dev/null +++ b/results/classifier/118/review/376 @@ -0,0 +1,61 @@ +mistranslation: 0.817 +device: 0.681 +architecture: 0.572 +graphic: 0.473 +register: 0.371 +boot: 0.306 +semantic: 0.296 +performance: 0.284 +risc-v: 0.272 +kernel: 0.269 +debug: 0.268 +files: 0.253 +socket: 0.248 +vnc: 0.233 +i386: 0.227 +ppc: 0.218 +arm: 0.213 +network: 0.191 +permissions: 0.182 +x86: 0.168 +virtual: 0.151 +PID: 0.105 +hypervisor: 0.091 +TCG: 0.042 +assembly: 0.042 +peripherals: 0.037 +VMM: 0.032 +user-level: 0.015 +KVM: 0.007 +-------------------- +semantic: 0.152 +device: 0.054 +virtual: 0.037 +user-level: 0.037 +files: 0.020 +architecture: 0.018 +x86: 0.015 +debug: 0.014 +peripherals: 0.013 +mistranslation: 0.008 +i386: 0.007 +register: 0.006 +boot: 0.005 +assembly: 0.004 +performance: 0.004 +PID: 0.004 +ppc: 0.004 +socket: 0.003 +kernel: 0.003 +TCG: 0.003 +risc-v: 0.002 +network: 0.002 +VMM: 0.002 +arm: 0.001 +graphic: 0.001 +KVM: 0.001 +vnc: 0.001 +hypervisor: 0.001 +permissions: 0.000 + +Indentation should be done with spaces, not with TABs, in the SH4 subsystem diff --git a/results/classifier/118/review/388 b/results/classifier/118/review/388 new file mode 100644 index 000000000..66da5d3a0 --- /dev/null +++ b/results/classifier/118/review/388 @@ -0,0 +1,61 @@ +mistranslation: 0.839 +architecture: 0.767 +peripherals: 0.673 +performance: 0.665 +network: 0.625 +permissions: 0.531 +hypervisor: 0.417 +device: 0.410 +semantic: 0.406 +debug: 0.390 +graphic: 0.330 +kernel: 0.330 +VMM: 0.280 +boot: 0.247 +socket: 0.244 +assembly: 0.242 +KVM: 0.238 +TCG: 0.230 +PID: 0.224 +arm: 0.220 +i386: 0.215 +x86: 0.211 +register: 0.169 +virtual: 0.161 +user-level: 0.161 +vnc: 0.159 +ppc: 0.150 +risc-v: 0.142 +files: 0.060 +-------------------- +permissions: 0.688 +device: 0.208 +peripherals: 0.095 +user-level: 0.056 +hypervisor: 0.038 +kernel: 0.030 +semantic: 0.030 +virtual: 0.008 +arm: 0.007 +assembly: 0.006 +TCG: 0.004 +socket: 0.004 +debug: 0.003 +VMM: 0.003 +KVM: 0.003 +architecture: 0.002 +x86: 0.002 +PID: 0.002 +risc-v: 0.001 +graphic: 0.001 +i386: 0.001 +performance: 0.001 +ppc: 0.001 +network: 0.001 +files: 0.001 +vnc: 0.001 +boot: 0.000 +register: 0.000 +mistranslation: 0.000 + +Can not pass hw device names as alsa input and output devices diff --git a/results/classifier/118/review/392 b/results/classifier/118/review/392 new file mode 100644 index 000000000..935a48422 --- /dev/null +++ b/results/classifier/118/review/392 @@ -0,0 +1,61 @@ +mistranslation: 0.988 +semantic: 0.877 +performance: 0.865 +architecture: 0.556 +device: 0.520 +graphic: 0.459 +hypervisor: 0.420 +network: 0.354 +i386: 0.340 +kernel: 0.333 +files: 0.314 +x86: 0.225 +virtual: 0.204 +peripherals: 0.180 +user-level: 0.150 +KVM: 0.141 +assembly: 0.127 +debug: 0.116 +boot: 0.073 +VMM: 0.061 +TCG: 0.056 +PID: 0.041 +arm: 0.034 +risc-v: 0.033 +permissions: 0.030 +vnc: 0.024 +ppc: 0.024 +register: 0.012 +socket: 0.010 +-------------------- +semantic: 0.241 +user-level: 0.135 +peripherals: 0.130 +kernel: 0.120 +device: 0.120 +files: 0.097 +hypervisor: 0.086 +assembly: 0.055 +virtual: 0.041 +TCG: 0.038 +x86: 0.035 +VMM: 0.029 +KVM: 0.028 +network: 0.019 +architecture: 0.018 +debug: 0.017 +PID: 0.014 +permissions: 0.009 +boot: 0.009 +register: 0.009 +i386: 0.008 +socket: 0.008 +risc-v: 0.008 +ppc: 0.006 +arm: 0.005 +performance: 0.004 +graphic: 0.002 +vnc: 0.002 +mistranslation: 0.001 + +`-hda` and `-drive` differ with respect to path handling diff --git a/results/classifier/118/review/397212 b/results/classifier/118/review/397212 new file mode 100644 index 000000000..fd0f6c5df --- /dev/null +++ b/results/classifier/118/review/397212 @@ -0,0 +1,275 @@ +risc-v: 0.940 +permissions: 0.911 +mistranslation: 0.911 +graphic: 0.902 +performance: 0.895 +debug: 0.891 +architecture: 0.887 +user-level: 0.882 +device: 0.881 +virtual: 0.880 +assembly: 0.872 +boot: 0.867 +semantic: 0.864 +arm: 0.862 +PID: 0.859 +socket: 0.851 +register: 0.848 +ppc: 0.836 +network: 0.822 +vnc: 0.814 +files: 0.798 +peripherals: 0.786 +x86: 0.681 +hypervisor: 0.679 +VMM: 0.672 +KVM: 0.651 +kernel: 0.616 +TCG: 0.597 +i386: 0.371 +-------------------- +x86: 0.922 +virtual: 0.862 +KVM: 0.803 +graphic: 0.153 +debug: 0.075 +hypervisor: 0.045 +TCG: 0.036 +files: 0.027 +register: 0.026 +PID: 0.012 +vnc: 0.007 +semantic: 0.007 +network: 0.006 +performance: 0.005 +socket: 0.004 +device: 0.004 +kernel: 0.002 +boot: 0.002 +user-level: 0.002 +architecture: 0.002 +assembly: 0.002 +VMM: 0.001 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.001 +permissions: 0.001 +peripherals: 0.001 +arm: 0.000 +i386: 0.000 + +Scrolling artifacts on some guests + +Screen doesn't refresh properly when scrolling (see the attachment). + +The behavior is seen on RHEL 4.8 and SLES 11, but not on RHEL 5.3. However, on RHEL5.3, scrolling is very sluggish. It seems to be a trade-off between quick movement and frequent / accurate refreshing. + +Command line: + +qemu-system-x86_64 -m 2048 -drive file=/scratch/images/SLES-11-GMC-x86_64.raw -net nic,vlan=0,macaddr=DE:AD:BE:EF:88:95,model=rtl8139 -net tap -vnc :40 -boot cd -monitor stdio -smp 4 + + + +From your command line, I suspect you're testing a copy of KVM. Is this reproducible with the upstream QEMU and if so, with what version (either 0.10.5 or specific git commit)? + +Yes, reproducible upstream. + +commit 9af4aed6c749786edb780e5de1795377f515e8f7 +Author: Andre Przywara <email address hidden> +Date: Thu Jul 2 16:45:43 2009 +0200 + + +Two Fedora 11 (qemu-0.10.x) bugs on this too: + + https://bugzilla.redhat.com/503156 + https://bugzilla.redhat.com/507626 + +Glauber posted a patch here: + + http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01498.html + + +Description of problem: +after for example catting a large file inside an xterm there are text artifacts remaining inside the xterm window. Scrolling up and down the xterm makes things even worse. + +Not sure if it's related to window scaling, please reassign appropriately if not a virt-manager bug. + +Screenshot attached + +Version-Release number of selected component (if applicable): +virt-manager-0.7.0-5.fc11.i586 + +How reproducible: +always + +Steps to Reproduce: +1. start VM +2. open xterm inside VM +3. cat large file (/var/log/messages) and scroll to make things worse + +Actual results: +text appears garbled + +Expected results: +text appears normal without artifacts + +Additional info: + +Created attachment 345887 +garbled-xterm.png + +Yeah, I can reproduce this, even with vncviewer - doesn't seem reproducible outside of KVM, though + +Moving to qemu + + +This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. +Changing version to '11'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +bug #507626 is probably a dup of this + +Similar bug report for Ubuntu: + +https://bugs.launchpad.net/qemu/+bug/397212 + +Glauber posted a patch here: + +http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01498.html + +*** Bug 507626 has been marked as a duplicate of this bug. *** + +Glauber, do you plan to push updated builds with this patch for F-11? I don't see this patch incorporated on any of the recent koji builds..? + +The patched was NACKed upstream by Gerd. He believes there is a better way to solve it. As such, I indent to wait for the real fix, or write it myself it Gerd takes too long + +Gerd has posted an updated patch here: + +http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg02107.html + +my test machine is down presently, so haven't had chance to test it yet. + +Have been playing with this a bit, and unfortunately applying the patch in comment #10 against 0.10.5 requires picking up a fair amount of the recent vnc logic changes (vnc.c and vnc.h) - not sure how you'd recommend proceeding here? One option would be to pull vnc.[c,h] from the current HEAD and add the patch, I suppose.. not sure what else might break. + +So, the upstream commit is: + + http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=3e28c9adf4 + +and it depends on the fix for bug #501131 which we also want back-ported + +(Note the vnc copyrect patch isn't applied to the stable-0.11 branch for F-12 yet, either) + +What I'd really like to see is both of these fixes back-ported to the stable-0.10 branch and sent upstream to qemu-devel + +This should be in the 0.10.7 release shortly: + + http://git.savannah.gnu.org/cgit/qemu.git/commit/?h=stable-0.10&id=74ccfe8b7e + +Will push this to updates-testing soon: + +* Fri Sep 11 2009 Mark McLoughlin <email address hidden> - 2:0.10.6-5 +- Fix vnc segfault on disconnect (#501131) +- Fix vnc screen corruption with e.g. xterm (#503156) +- Rebase vnc sasl patches on top of these two vnc fixes + +qemu-0.10.6-5.fc11 has been submitted as an update for Fedora 11. +http://admin.fedoraproject.org/updates/qemu-0.10.6-5.fc11 + +Created attachment 360920 +Windows XP guest with grabled screen + +As the image attached in Comment #16 shows, this update doesn't fix the problem for me. This is using: + +# rpm -qa | grep qemu +qemu-system-x86-0.10.6-5.fc11.x86_64 +qemu-img-0.10.6-5.fc11.x86_64 +qemu-common-0.10.6-5.fc11.x86_64 + +Thanks for testing Jonathan + +No problem. Alas, if anything, the screen tearing has gotten worse with this version, rather than better - previously resizing the window in the guest triggered a redraw which would clean up the garbage (at least until scrolled again), but now that trick no longer works. + +Why on earth was version 2:qemu-0.10.6-5.fc11.x86_64 released +with this "bugfix" that has made the graphics looks worse? + +Good question in Comment #20. Surely that's a mistake Mark? + +Sorry about that, guys + +This 'fix' will be in 0.10.7, so I'm inclined to leave it in for the moment and try and get it fixed + +If we don't get progress, I'll revert it soon + +Is it worth pushing a build of the 0.10.7 rc to updates-testing? + +Anything new on this bug? + +It's been open for 5 months now. + +It's realllllyyy annoying, it makes Windows even harder to use :-( + +*** Bug 528939 has been marked as a duplicate of this bug. *** + +What would the implications of pushing qemu 0.11 to FC11 be - would that work with libvirt and friends? If so, any chance of doing such a push? + +We don't have any immediate plans to update qemu in Fedora 11 to 0.11. See: + + http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html + +Honestly, it should be a lot easier to fix this bug than deal with the fallout from the inevitable regressions that would be caused by a re-base. It's just a question of someone finding the time to debug it. + +(In reply to comment #27) +> We don't have any immediate plans to update qemu in Fedora 11 to 0.11. See: +> +> http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html +> +> Honestly, it should be a lot easier to fix this bug than deal with the fallout +> from the inevitable regressions that would be caused by a re-base. It's just a +> question of someone finding the time to debug it. + +Bah ... + +Is there some way to workaround this bug? + +Is there another way to connect to the output other than VNC? + +I've been using virt-manager. + +Patrick - you could presumably run a VNC server inside your guest and connect to that, rather than the QEMU vnc client. + +The problem with backporting a fix is that there's been a lot of code churn with the vnc related stuff in qemu, so to actually fix it would require some knowledge of the vnc stuff, rather than mechanical adding and removing of commits (I know, as I tried that sometime ago). The people with that knowledge are too busy pushing forward than looking back at old releases (understandably - it's more interesting). + +qemu-0.10.6-9.fc11 has been submitted as an update for Fedora 11. +http://admin.fedoraproject.org/updates/qemu-0.10.6-9.fc11 + +Patrick and Jonathan: okay, let's try and hit this bad boy with our big stick + +I'm pretty sure it's a problem with qemu's implementation of the CopyRect extension, so I've just disabled that extension in qemu-0.10.6-9.fc11 - that should fix the problem + +AFAIK, CopyRect works fine in qemu-0.11.0 in Fedora 12 + +Could you confirm that qemu-0.10.6-9.fc11 fixes the issue? (comment here and bump the karma in bodhi if so) + +Thanks! + +* Fri Oct 23 2009 Mark McLoughlin <email address hidden> - 2:0.10.6-9 +- Disable the vnc CopyRect encoding since it's still broken (#503156) + +Mark: qemu-0.10.6-9.fc11 does indeed fix the issue for me. Thanks very much for taking the time to look at this. + +(In reply to comment #32) +> Mark: qemu-0.10.6-9.fc11 does indeed fix the issue for me. Thanks very much for +> taking the time to look at this. + +Me too, thanks! + +I commented on the web page (showed up as anonymous), but how do I bump bodhi karma? + +qemu-0.10.6-9.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. + If you want to test the update, you can install it with + su -c 'yum --enablerepo=updates-testing update qemu'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10754 + +qemu-0.10.6-9.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. + diff --git a/results/classifier/118/review/398 b/results/classifier/118/review/398 new file mode 100644 index 000000000..fa37e9844 --- /dev/null +++ b/results/classifier/118/review/398 @@ -0,0 +1,61 @@ +architecture: 0.864 +device: 0.698 +performance: 0.598 +arm: 0.560 +graphic: 0.454 +permissions: 0.373 +files: 0.288 +virtual: 0.239 +mistranslation: 0.235 +debug: 0.220 +hypervisor: 0.219 +semantic: 0.218 +peripherals: 0.212 +network: 0.212 +user-level: 0.207 +ppc: 0.167 +PID: 0.166 +register: 0.126 +VMM: 0.124 +boot: 0.114 +vnc: 0.106 +TCG: 0.101 +socket: 0.088 +x86: 0.071 +risc-v: 0.053 +kernel: 0.038 +assembly: 0.034 +i386: 0.032 +KVM: 0.010 +-------------------- +arm: 0.978 +virtual: 0.947 +hypervisor: 0.935 +files: 0.439 +user-level: 0.048 +semantic: 0.031 +boot: 0.029 +architecture: 0.029 +device: 0.018 +TCG: 0.017 +register: 0.014 +socket: 0.006 +kernel: 0.005 +KVM: 0.005 +PID: 0.004 +assembly: 0.003 +performance: 0.003 +permissions: 0.003 +network: 0.002 +debug: 0.002 +graphic: 0.002 +VMM: 0.002 +ppc: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +risc-v: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-system-aarch64 could not open 'ubuntu-16.04-server-cloudimg-arm64-uefi1.img' qemu6.0 on windows 10 diff --git a/results/classifier/118/review/421 b/results/classifier/118/review/421 new file mode 100644 index 000000000..d28227a0b --- /dev/null +++ b/results/classifier/118/review/421 @@ -0,0 +1,61 @@ +mistranslation: 0.992 +semantic: 0.791 +network: 0.735 +device: 0.646 +performance: 0.466 +graphic: 0.361 +permissions: 0.332 +user-level: 0.263 +peripherals: 0.205 +architecture: 0.186 +virtual: 0.144 +debug: 0.133 +arm: 0.128 +register: 0.104 +hypervisor: 0.092 +boot: 0.072 +PID: 0.039 +assembly: 0.039 +socket: 0.038 +VMM: 0.038 +TCG: 0.028 +vnc: 0.026 +ppc: 0.020 +files: 0.012 +kernel: 0.011 +risc-v: 0.010 +x86: 0.008 +KVM: 0.008 +i386: 0.005 +-------------------- +virtual: 0.975 +hypervisor: 0.965 +network: 0.921 +peripherals: 0.828 +KVM: 0.672 +user-level: 0.336 +device: 0.331 +semantic: 0.043 +socket: 0.020 +TCG: 0.018 +files: 0.012 +VMM: 0.011 +x86: 0.009 +graphic: 0.007 +ppc: 0.005 +vnc: 0.005 +debug: 0.005 +assembly: 0.003 +i386: 0.002 +arm: 0.002 +architecture: 0.002 +register: 0.001 +kernel: 0.001 +risc-v: 0.001 +performance: 0.001 +boot: 0.001 +PID: 0.000 +permissions: 0.000 +mistranslation: 0.000 + +Please clarify what network card is available with qemu-system-sparc64 diff --git a/results/classifier/118/review/424450 b/results/classifier/118/review/424450 new file mode 100644 index 000000000..52a3d18bb --- /dev/null +++ b/results/classifier/118/review/424450 @@ -0,0 +1,85 @@ +register: 0.866 +device: 0.832 +mistranslation: 0.740 +vnc: 0.739 +semantic: 0.676 +ppc: 0.672 +kernel: 0.662 +socket: 0.656 +network: 0.616 +risc-v: 0.614 +graphic: 0.600 +performance: 0.586 +permissions: 0.584 +architecture: 0.545 +boot: 0.509 +i386: 0.498 +TCG: 0.478 +x86: 0.471 +PID: 0.470 +files: 0.463 +peripherals: 0.456 +VMM: 0.450 +arm: 0.442 +debug: 0.407 +hypervisor: 0.331 +virtual: 0.329 +user-level: 0.299 +assembly: 0.288 +KVM: 0.262 +-------------------- +debug: 0.884 +register: 0.761 +x86: 0.562 +peripherals: 0.187 +arm: 0.137 +user-level: 0.127 +i386: 0.079 +ppc: 0.077 +device: 0.077 +kernel: 0.076 +virtual: 0.063 +files: 0.029 +hypervisor: 0.023 +semantic: 0.023 +risc-v: 0.020 +architecture: 0.017 +assembly: 0.016 +performance: 0.012 +TCG: 0.011 +VMM: 0.010 +PID: 0.009 +network: 0.008 +socket: 0.005 +boot: 0.004 +permissions: 0.001 +KVM: 0.001 +graphic: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +FDC reset should reset the MSR + +I believe that the MSR resgister should also be reset to zero on a software reset. All of the FDC hardware I have does this. +The current code leaves the MSR as 0x80, which means that the controller is ready for a write. The controller should not +be ready for a write while in reset. + +fdc.c Line 899 + /* Reset */ + if (!(value & FD_DOR_nRESET)) { + + fdctrl->msr = 0x00; + if (fdctrl->dor & FD_DOR_nRESET) { + FLOPPY_DPRINTF("controller enter RESET state\n"); + } + } else { + +Is there a test case that this fixes? + +I know of no test case. The reason for the bug report is that I have been doing some studies of the FDC and have noticed that the MSR register is 0x00 during reset. Before and after the reset it is 0x80, but during the reset it is zero. I just wanted to make QEMU more like the hardware. + +Thanks, +Ben + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/442 b/results/classifier/118/review/442 new file mode 100644 index 000000000..ad0505e16 --- /dev/null +++ b/results/classifier/118/review/442 @@ -0,0 +1,61 @@ +user-level: 0.865 +performance: 0.851 +graphic: 0.799 +device: 0.748 +debug: 0.527 +architecture: 0.440 +semantic: 0.171 +network: 0.126 +register: 0.104 +boot: 0.095 +mistranslation: 0.091 +peripherals: 0.080 +permissions: 0.064 +PID: 0.050 +virtual: 0.049 +VMM: 0.037 +ppc: 0.032 +hypervisor: 0.031 +files: 0.017 +vnc: 0.017 +kernel: 0.016 +i386: 0.013 +TCG: 0.012 +socket: 0.011 +assembly: 0.010 +x86: 0.008 +risc-v: 0.006 +arm: 0.004 +KVM: 0.001 +-------------------- +virtual: 0.920 +hypervisor: 0.496 +user-level: 0.286 +PID: 0.091 +debug: 0.043 +ppc: 0.015 +files: 0.014 +assembly: 0.013 +device: 0.011 +arm: 0.011 +kernel: 0.010 +register: 0.010 +VMM: 0.010 +TCG: 0.009 +KVM: 0.009 +semantic: 0.008 +x86: 0.005 +performance: 0.004 +permissions: 0.004 +graphic: 0.004 +boot: 0.002 +architecture: 0.002 +peripherals: 0.001 +socket: 0.001 +risc-v: 0.001 +network: 0.001 +i386: 0.000 +mistranslation: 0.000 +vnc: 0.000 + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error diff --git a/results/classifier/118/review/443 b/results/classifier/118/review/443 new file mode 100644 index 000000000..a14c79858 --- /dev/null +++ b/results/classifier/118/review/443 @@ -0,0 +1,61 @@ +architecture: 0.968 +device: 0.888 +performance: 0.712 +arm: 0.700 +hypervisor: 0.615 +mistranslation: 0.374 +semantic: 0.358 +graphic: 0.314 +register: 0.262 +permissions: 0.255 +files: 0.253 +network: 0.239 +boot: 0.204 +assembly: 0.195 +user-level: 0.195 +debug: 0.163 +virtual: 0.126 +peripherals: 0.110 +vnc: 0.053 +risc-v: 0.050 +ppc: 0.041 +socket: 0.023 +kernel: 0.016 +PID: 0.012 +VMM: 0.006 +x86: 0.006 +TCG: 0.005 +i386: 0.003 +KVM: 0.002 +-------------------- +virtual: 0.990 +hypervisor: 0.980 +arm: 0.923 +architecture: 0.168 +user-level: 0.083 +boot: 0.043 +device: 0.030 +semantic: 0.019 +debug: 0.005 +files: 0.005 +performance: 0.004 +assembly: 0.003 +PID: 0.002 +register: 0.002 +VMM: 0.001 +graphic: 0.001 +kernel: 0.001 +peripherals: 0.001 +KVM: 0.001 +permissions: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +socket: 0.001 +ppc: 0.000 +TCG: 0.000 +network: 0.000 +x86: 0.000 +vnc: 0.000 +i386: 0.000 + +QEMU on Windows aarch64 diff --git a/results/classifier/118/review/45 b/results/classifier/118/review/45 new file mode 100644 index 000000000..32e1477d5 --- /dev/null +++ b/results/classifier/118/review/45 @@ -0,0 +1,61 @@ +architecture: 0.960 +device: 0.568 +graphic: 0.441 +performance: 0.376 +boot: 0.375 +semantic: 0.344 +assembly: 0.321 +mistranslation: 0.304 +virtual: 0.299 +arm: 0.282 +debug: 0.273 +user-level: 0.202 +files: 0.165 +peripherals: 0.165 +VMM: 0.155 +hypervisor: 0.151 +network: 0.148 +PID: 0.140 +socket: 0.116 +kernel: 0.106 +permissions: 0.078 +TCG: 0.066 +register: 0.057 +vnc: 0.050 +KVM: 0.044 +ppc: 0.042 +risc-v: 0.010 +x86: 0.005 +i386: 0.002 +-------------------- +virtual: 0.961 +hypervisor: 0.952 +boot: 0.807 +architecture: 0.788 +semantic: 0.093 +kernel: 0.078 +device: 0.058 +user-level: 0.055 +KVM: 0.048 +TCG: 0.033 +debug: 0.021 +files: 0.012 +VMM: 0.010 +assembly: 0.008 +peripherals: 0.003 +register: 0.002 +PID: 0.002 +graphic: 0.002 +performance: 0.001 +arm: 0.001 +risc-v: 0.001 +socket: 0.000 +permissions: 0.000 +mistranslation: 0.000 +ppc: 0.000 +vnc: 0.000 +network: 0.000 +i386: 0.000 +x86: 0.000 + +qemu-system-aarch64: no function defined to set boot device list for this architecture diff --git a/results/classifier/118/review/450 b/results/classifier/118/review/450 new file mode 100644 index 000000000..5430d59ac --- /dev/null +++ b/results/classifier/118/review/450 @@ -0,0 +1,61 @@ +mistranslation: 0.963 +network: 0.854 +device: 0.847 +performance: 0.816 +semantic: 0.553 +debug: 0.527 +permissions: 0.465 +graphic: 0.440 +files: 0.412 +architecture: 0.383 +register: 0.347 +peripherals: 0.313 +boot: 0.283 +assembly: 0.272 +VMM: 0.211 +i386: 0.177 +arm: 0.176 +ppc: 0.156 +socket: 0.140 +hypervisor: 0.133 +x86: 0.127 +TCG: 0.125 +user-level: 0.124 +risc-v: 0.121 +virtual: 0.115 +PID: 0.096 +kernel: 0.087 +vnc: 0.065 +KVM: 0.035 +-------------------- +performance: 0.429 +debug: 0.362 +kernel: 0.221 +assembly: 0.150 +device: 0.124 +network: 0.117 +x86: 0.063 +virtual: 0.062 +hypervisor: 0.051 +peripherals: 0.038 +KVM: 0.035 +files: 0.025 +architecture: 0.023 +user-level: 0.013 +permissions: 0.012 +TCG: 0.012 +arm: 0.010 +VMM: 0.009 +semantic: 0.006 +i386: 0.006 +boot: 0.006 +socket: 0.005 +register: 0.004 +risc-v: 0.004 +ppc: 0.004 +PID: 0.004 +vnc: 0.002 +graphic: 0.002 +mistranslation: 0.000 + +sdhci: Assertion wpnum < sd->wpgrps_size failed diff --git a/results/classifier/118/review/457 b/results/classifier/118/review/457 new file mode 100644 index 000000000..e6cfb2314 --- /dev/null +++ b/results/classifier/118/review/457 @@ -0,0 +1,61 @@ +TCG: 0.936 +performance: 0.811 +device: 0.807 +network: 0.763 +architecture: 0.633 +mistranslation: 0.633 +semantic: 0.584 +ppc: 0.577 +graphic: 0.539 +debug: 0.483 +socket: 0.482 +arm: 0.432 +assembly: 0.415 +vnc: 0.396 +files: 0.379 +register: 0.338 +kernel: 0.329 +PID: 0.285 +boot: 0.220 +permissions: 0.199 +peripherals: 0.192 +VMM: 0.187 +risc-v: 0.177 +hypervisor: 0.146 +virtual: 0.109 +x86: 0.054 +user-level: 0.048 +KVM: 0.006 +i386: 0.005 +-------------------- +virtual: 0.920 +hypervisor: 0.898 +TCG: 0.748 +debug: 0.325 +kernel: 0.323 +files: 0.136 +performance: 0.043 +semantic: 0.029 +user-level: 0.028 +architecture: 0.016 +device: 0.015 +PID: 0.013 +assembly: 0.009 +register: 0.007 +VMM: 0.006 +graphic: 0.004 +KVM: 0.003 +boot: 0.003 +peripherals: 0.002 +mistranslation: 0.001 +risc-v: 0.001 +socket: 0.001 +network: 0.001 +vnc: 0.000 +permissions: 0.000 +x86: 0.000 +arm: 0.000 +i386: 0.000 +ppc: 0.000 + +qemu-system-s390x segfaults in do_tb_phys_invalidate at ../accel/tcg/translate-all.c:1482 diff --git a/results/classifier/118/review/47 b/results/classifier/118/review/47 new file mode 100644 index 000000000..1499dfae2 --- /dev/null +++ b/results/classifier/118/review/47 @@ -0,0 +1,61 @@ +mistranslation: 0.993 +risc-v: 0.603 +graphic: 0.415 +semantic: 0.381 +device: 0.293 +network: 0.258 +arm: 0.244 +peripherals: 0.236 +performance: 0.221 +permissions: 0.210 +debug: 0.191 +architecture: 0.185 +hypervisor: 0.163 +files: 0.147 +virtual: 0.143 +vnc: 0.095 +register: 0.094 +x86: 0.090 +boot: 0.079 +socket: 0.070 +user-level: 0.069 +TCG: 0.068 +VMM: 0.063 +ppc: 0.059 +assembly: 0.056 +kernel: 0.035 +KVM: 0.035 +PID: 0.028 +i386: 0.018 +-------------------- +files: 0.857 +user-level: 0.195 +network: 0.111 +virtual: 0.090 +semantic: 0.049 +TCG: 0.039 +risc-v: 0.033 +debug: 0.032 +i386: 0.025 +x86: 0.019 +assembly: 0.012 +device: 0.008 +boot: 0.005 +VMM: 0.004 +PID: 0.003 +register: 0.003 +kernel: 0.003 +arm: 0.002 +ppc: 0.002 +hypervisor: 0.001 +KVM: 0.001 +mistranslation: 0.001 +graphic: 0.001 +vnc: 0.001 +architecture: 0.001 +socket: 0.001 +permissions: 0.001 +performance: 0.001 +peripherals: 0.001 + +A typo in target/riscv/insn32-64.decode diff --git a/results/classifier/118/review/486 b/results/classifier/118/review/486 new file mode 100644 index 000000000..740ef8293 --- /dev/null +++ b/results/classifier/118/review/486 @@ -0,0 +1,61 @@ +mistranslation: 0.990 +virtual: 0.826 +peripherals: 0.729 +semantic: 0.697 +user-level: 0.623 +graphic: 0.475 +device: 0.452 +assembly: 0.451 +debug: 0.325 +performance: 0.309 +architecture: 0.299 +VMM: 0.292 +ppc: 0.262 +permissions: 0.207 +register: 0.200 +x86: 0.172 +PID: 0.157 +i386: 0.152 +network: 0.119 +TCG: 0.117 +vnc: 0.116 +socket: 0.075 +risc-v: 0.073 +boot: 0.061 +KVM: 0.059 +files: 0.051 +hypervisor: 0.051 +kernel: 0.042 +arm: 0.007 +-------------------- +device: 0.734 +peripherals: 0.730 +virtual: 0.499 +semantic: 0.443 +user-level: 0.306 +debug: 0.066 +kernel: 0.040 +VMM: 0.033 +KVM: 0.027 +i386: 0.013 +x86: 0.011 +ppc: 0.010 +TCG: 0.009 +register: 0.009 +files: 0.009 +assembly: 0.007 +performance: 0.007 +hypervisor: 0.007 +permissions: 0.006 +graphic: 0.006 +vnc: 0.005 +risc-v: 0.004 +boot: 0.003 +arm: 0.003 +architecture: 0.002 +PID: 0.002 +socket: 0.002 +mistranslation: 0.001 +network: 0.001 + +/dev/input/mouse0: is not an evdev device diff --git a/results/classifier/118/review/494 b/results/classifier/118/review/494 new file mode 100644 index 000000000..303c75262 --- /dev/null +++ b/results/classifier/118/review/494 @@ -0,0 +1,61 @@ +assembly: 0.840 +user-level: 0.794 +device: 0.742 +performance: 0.684 +graphic: 0.638 +debug: 0.363 +arm: 0.344 +architecture: 0.186 +semantic: 0.151 +permissions: 0.146 +network: 0.138 +register: 0.105 +peripherals: 0.095 +mistranslation: 0.092 +virtual: 0.073 +files: 0.056 +boot: 0.043 +ppc: 0.041 +PID: 0.041 +VMM: 0.035 +socket: 0.028 +vnc: 0.025 +kernel: 0.019 +TCG: 0.017 +risc-v: 0.014 +hypervisor: 0.013 +i386: 0.009 +x86: 0.007 +KVM: 0.002 +-------------------- +virtual: 0.872 +user-level: 0.303 +x86: 0.261 +hypervisor: 0.090 +debug: 0.074 +assembly: 0.062 +performance: 0.019 +i386: 0.012 +files: 0.011 +KVM: 0.009 +device: 0.009 +PID: 0.008 +TCG: 0.007 +semantic: 0.006 +arm: 0.005 +VMM: 0.005 +kernel: 0.004 +boot: 0.002 +peripherals: 0.002 +graphic: 0.002 +risc-v: 0.001 +ppc: 0.001 +permissions: 0.001 +register: 0.001 +architecture: 0.001 +socket: 0.001 +mistranslation: 0.000 +vnc: 0.000 +network: 0.000 + +cmake crashes on qemu-alpha-user with Illegal Instruction diff --git a/results/classifier/118/review/500 b/results/classifier/118/review/500 new file mode 100644 index 000000000..b573f1b54 --- /dev/null +++ b/results/classifier/118/review/500 @@ -0,0 +1,61 @@ +mistranslation: 0.896 +kernel: 0.706 +performance: 0.673 +network: 0.534 +debug: 0.411 +architecture: 0.398 +VMM: 0.391 +TCG: 0.386 +semantic: 0.381 +graphic: 0.374 +files: 0.373 +vnc: 0.340 +PID: 0.297 +KVM: 0.291 +boot: 0.283 +assembly: 0.262 +register: 0.260 +device: 0.247 +arm: 0.245 +risc-v: 0.241 +ppc: 0.163 +virtual: 0.147 +x86: 0.138 +hypervisor: 0.130 +i386: 0.130 +user-level: 0.119 +permissions: 0.093 +peripherals: 0.093 +socket: 0.083 +-------------------- +debug: 0.742 +kernel: 0.139 +TCG: 0.110 +KVM: 0.109 +device: 0.082 +peripherals: 0.055 +register: 0.042 +x86: 0.037 +virtual: 0.027 +risc-v: 0.026 +VMM: 0.025 +ppc: 0.020 +files: 0.017 +assembly: 0.014 +hypervisor: 0.013 +semantic: 0.011 +user-level: 0.011 +arm: 0.009 +network: 0.009 +performance: 0.007 +boot: 0.005 +i386: 0.005 +PID: 0.005 +vnc: 0.003 +socket: 0.002 +graphic: 0.002 +architecture: 0.002 +permissions: 0.001 +mistranslation: 0.000 + +6.1.0-rc0 Regression: Parameter 'audiodev' is missing diff --git a/results/classifier/118/review/502107 b/results/classifier/118/review/502107 new file mode 100644 index 000000000..f3478d4bf --- /dev/null +++ b/results/classifier/118/review/502107 @@ -0,0 +1,181 @@ +mistranslation: 0.851 +user-level: 0.778 +risc-v: 0.760 +semantic: 0.545 +permissions: 0.471 +debug: 0.461 +peripherals: 0.444 +ppc: 0.362 +graphic: 0.342 +virtual: 0.342 +PID: 0.334 +network: 0.326 +assembly: 0.321 +device: 0.312 +hypervisor: 0.311 +performance: 0.303 +VMM: 0.301 +TCG: 0.297 +kernel: 0.291 +arm: 0.290 +architecture: 0.289 +register: 0.285 +socket: 0.261 +KVM: 0.242 +vnc: 0.234 +boot: 0.229 +files: 0.228 +x86: 0.221 +i386: 0.112 +-------------------- +KVM: 0.995 +virtual: 0.947 +boot: 0.945 +hypervisor: 0.905 +x86: 0.846 +register: 0.762 +kernel: 0.715 +assembly: 0.672 +user-level: 0.343 +PID: 0.307 +debug: 0.151 +vnc: 0.033 +ppc: 0.025 +VMM: 0.019 +device: 0.012 +files: 0.010 +TCG: 0.006 +risc-v: 0.006 +semantic: 0.006 +architecture: 0.005 +performance: 0.004 +peripherals: 0.002 +graphic: 0.002 +socket: 0.002 +network: 0.002 +i386: 0.001 +permissions: 0.001 +arm: 0.001 +mistranslation: 0.000 + +qemu-kvm 0.12.1.2 crashes booting Ubuntu 9.10 with "-vga std" + +I have an Ubuntu VM that works fine without "-vga std" but crashes if I add "-vga std". This is the full command line: + +qemu-system-x86_64 -vga std -drive +cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc +:3102 -usbdevice tablet -enable-kvm & + +I get this error: + + KVM internal error. Suberror: 1 +rax 00007f789177e000 rbx 0000000000000000 rcx 0000000000000000 rdx +0000000000000000 +rsi 0000000000000000 rdi 00007f789177e000 rsp 00007fff361775e8 rbp +00007fff36177600 +r8 000000000000ff80 r9 0000000000200000 r10 0000000000000000 r11 +00007f789100a3f0 +r12 00000000004017c0 r13 00007fff36178cf0 r14 0000000000000000 r15 +0000000000000000 +rip 00007f789100aa7b rflags 00013206 +cs 0033 (00000000/ffffffff p 1 dpl 3 db 0 s 1 type b l 1 g 1 avl 0) +ds 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +es 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +ss 002b (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) +fs 0000 (7f78917906f0/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +tr 0040 (ffff880001a09440/00002087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) +ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) +gdt ffff8800019fa000/7f +idt ffffffff818fd000/fff +cr0 80050033 cr2 2408000 cr3 379d4000 cr4 6f0 cr8 0 efer d01 +emulation failure, check dmesg for details + +I'm running kernel 2.6.32, and I have the kvm stuff compiled directly into the +kernel. There's nothing in dmesg about kvm at all. + +Note that in the VM grub comes up, but the VM dies when I boot the kernel. + +This command line works: + +qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k +en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm & + +That is, removing "-vga std" fixes the problem. + +I recently added this option to both my Ubuntu and Windows XP VMs. The Windows VM still works fine. If Windows can detect that the graphics card has changed, then Ubuntu should also have no problem. That being said, I added the std option when using 0.12.1.1, so there may be a qemu regression. + +I have reported this bug elsewhere: http://bugs.gentoo.org/show_bug.cgi?id=299211 + +Clarification: Qemu doesn't quite crash. The process is still running, and I can attach a VNC client (which gives me a black screen). It's just not DOING anything. I can get into the monitor, so if there's some diagnostic thing you'd like me to enter into the monitor, please let me know. + + +since this morning (probably since i installed kernel 2.6.32-12 in host and guest) the behavior changed. +the guest does not crash any more with 'unaligned pointer error' but gets into an endless loop when loading grub, see attachment + +this happens only with '-vga std' option, standard cirrus emulation works fine. + +sorry for the wrong attachment, here is the correct one + +Confirmed, I'm seeing the same thing. + +Since the last update, the behavior has changed for me and returned to the previous one. +No more boot-loop but instead unaligned pointer error, see screenshot. This happens immediately after Grub takes control (Grub loading). + +Again, this happens only with '-vga std' option. Without vga-switch the virtual machine boots fine. + +This is still the case with version 0.12.3. Crash when booting Ubuntu (after grub), but no crash with Windows. + + +still not resolved: guest=Ubuntu 10.10, host=Fedora14 + +crashes with -vga std or -vga vmware + +works with -vga cirrus + + +PS: qemu-kvm -version = 0.13.0 + +PPS: Ubuntu 10.10 crashes also with qemu-kvm -vga qxl -spice ... + + +Some notes of interest: + +- the unaligned pointer error also seems to happen in real systems with certain ATI cards. +- rebuilding grub with mm-debug makes Ubuntu boot without unaligned/out of range pointer messages with -vga std. +- adding debug messages (with grub_printf()) to grub memalign/free functions in kern/mm.c triggers other reported behaviors including the boot loop, and more worrisomely, KVM_INTERNAL_ERROR_EMULATION. + +These results obtained with stock Ubuntu 10.10 grub2 in guest (1.98+20100804-5ubuntu3) and 3.1.6-1.fc16.x86_64 host. + +see also http://bugs.debian.org/616487 and http://bugs.debian.org/653068 - it appears this prob happens with grub with qxl (spice) and vmware "adaptors" + +and it still happens even in version 1.0 + +It turns out that my previous attempt to reproduce the vga crash using an image generated by grub-mkrescue (which is easier to work with than dealing with a full Ubuntu image) is invalid due to bad instrumentation in the "normal" module init and a stack overflow produced similar results including the boot loop and internal emulation error. It suggests, however, that the vga problem and other grub-related crashes are also caused by memory corruption in guest. + +See also LP#717445: + + https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/717445 + +which is exactly the same issue but reported against grub. And I tend to think more and more it is a grub bug after all, not qemu/kvm/bios bug. + +Yes, memory corruption in guest explains the unaligned/out of range pointer error (issued when grub2 releases a block of memory, and grub uses dynamic allocation quite a lot) and the boot loop. This corruption most likely originates in the vga code fixed in revision 2470 as reported in Bug #717445. So the real issue seems to be the crash in case of memory corruption instead of handling the issue in a more graceful way (for instance, no error is displayed if qemu/virt-manager is not launched from a terminal). Regardless of the circumstances that caused the kvm internal emulation error, I believe qemu should notify and recover instead of simply crash and burn. + +Note: this is already marked as FIXME in kvm-all.c: + + if (run->internal.suberror == KVM_INTERNAL_ERROR_EMULATION) { + fprintf(stderr, "emulation failure\n"); + if (!kvm_arch_stop_on_emulation_error(env)) { + cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE); + return EXCP_INTERRUPT; + } + } + /* FIXME: Should trigger a qmp message to let management know + * something went wrong. + */ + + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (v2.8)? + +There hasn't been a reply to my question in the last comment within months, so I assume nobody cares about this anymore. So I'm closing this ticket now... + diff --git a/results/classifier/118/review/514 b/results/classifier/118/review/514 new file mode 100644 index 000000000..eb05ad3a2 --- /dev/null +++ b/results/classifier/118/review/514 @@ -0,0 +1,85 @@ +architecture: 0.850 +register: 0.815 +ppc: 0.796 +device: 0.778 +arm: 0.773 +graphic: 0.745 +debug: 0.649 +performance: 0.646 +semantic: 0.631 +mistranslation: 0.623 +x86: 0.583 +vnc: 0.549 +PID: 0.519 +assembly: 0.514 +files: 0.512 +VMM: 0.478 +risc-v: 0.476 +boot: 0.468 +socket: 0.457 +i386: 0.456 +TCG: 0.451 +permissions: 0.448 +kernel: 0.439 +network: 0.427 +peripherals: 0.383 +hypervisor: 0.370 +KVM: 0.335 +user-level: 0.300 +virtual: 0.265 +-------------------- +arm: 0.990 +debug: 0.804 +performance: 0.536 +TCG: 0.135 +kernel: 0.098 +semantic: 0.080 +register: 0.035 +files: 0.023 +architecture: 0.017 +hypervisor: 0.015 +PID: 0.012 +assembly: 0.009 +user-level: 0.008 +virtual: 0.005 +device: 0.005 +boot: 0.004 +mistranslation: 0.003 +risc-v: 0.002 +permissions: 0.002 +VMM: 0.002 +peripherals: 0.001 +KVM: 0.001 +socket: 0.001 +network: 0.001 +graphic: 0.001 +vnc: 0.001 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +MTE reports false positive for "str" instruction with the SP as the base register. +Description of problem: +When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access. +Steps to reproduce: +Clang version: clang version 12.0.1. +I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code: +``` +0000000000000c14 <test_func>: + c14: a9bc7bfd stp x29, x30, [sp, #-64]! + c18: f9000bf7 str x23, [sp, #16] + ... +``` +Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch. +When cpu executes firs instruction "stp x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault": +ESR_EL1=0x96000051. + +According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access: +``` +A Tag Unchecked access will be generated for a load or store that uses either of the following: +• A base register only, with the SP as the base register. +• A base register plus immediate offset addressing form, with the SP as the base register. +``` +Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset. +Additional information: + diff --git a/results/classifier/118/review/52 b/results/classifier/118/review/52 new file mode 100644 index 000000000..b8f5c01e0 --- /dev/null +++ b/results/classifier/118/review/52 @@ -0,0 +1,61 @@ +architecture: 0.941 +device: 0.830 +ppc: 0.791 +network: 0.740 +performance: 0.676 +peripherals: 0.507 +register: 0.487 +graphic: 0.481 +permissions: 0.387 +arm: 0.340 +TCG: 0.326 +socket: 0.319 +risc-v: 0.312 +debug: 0.308 +files: 0.290 +vnc: 0.284 +VMM: 0.278 +PID: 0.267 +virtual: 0.263 +hypervisor: 0.249 +semantic: 0.226 +boot: 0.156 +mistranslation: 0.143 +user-level: 0.131 +kernel: 0.067 +assembly: 0.061 +KVM: 0.004 +i386: 0.003 +x86: 0.001 +-------------------- +ppc: 0.994 +architecture: 0.820 +assembly: 0.058 +device: 0.048 +virtual: 0.039 +kernel: 0.031 +semantic: 0.008 +debug: 0.008 +register: 0.006 +files: 0.004 +PID: 0.004 +user-level: 0.004 +TCG: 0.003 +boot: 0.002 +peripherals: 0.002 +socket: 0.002 +VMM: 0.002 +network: 0.002 +hypervisor: 0.001 +performance: 0.001 +graphic: 0.001 +risc-v: 0.001 +permissions: 0.001 +KVM: 0.001 +mistranslation: 0.000 +vnc: 0.000 +arm: 0.000 +i386: 0.000 +x86: 0.000 + +PowerPC64: tlbivax does not work for addresses above 4G diff --git a/results/classifier/118/review/521 b/results/classifier/118/review/521 new file mode 100644 index 000000000..e60e861e7 --- /dev/null +++ b/results/classifier/118/review/521 @@ -0,0 +1,61 @@ +semantic: 0.897 +mistranslation: 0.802 +performance: 0.700 +device: 0.563 +graphic: 0.262 +virtual: 0.235 +assembly: 0.205 +debug: 0.183 +boot: 0.164 +register: 0.159 +i386: 0.143 +user-level: 0.139 +VMM: 0.133 +peripherals: 0.130 +architecture: 0.125 +network: 0.123 +arm: 0.101 +ppc: 0.091 +files: 0.073 +hypervisor: 0.066 +TCG: 0.061 +socket: 0.055 +kernel: 0.054 +risc-v: 0.038 +vnc: 0.036 +x86: 0.029 +permissions: 0.023 +KVM: 0.022 +PID: 0.020 +-------------------- +debug: 0.898 +virtual: 0.150 +assembly: 0.089 +network: 0.055 +x86: 0.037 +user-level: 0.032 +kernel: 0.024 +performance: 0.015 +device: 0.014 +VMM: 0.013 +files: 0.007 +semantic: 0.005 +peripherals: 0.005 +boot: 0.005 +i386: 0.005 +permissions: 0.003 +TCG: 0.003 +hypervisor: 0.003 +PID: 0.003 +arm: 0.002 +socket: 0.001 +ppc: 0.001 +architecture: 0.001 +KVM: 0.001 +register: 0.001 +graphic: 0.001 +risc-v: 0.001 +mistranslation: 0.000 +vnc: 0.000 + +Assert mr != NULL through megaraid diff --git a/results/classifier/118/review/521994 b/results/classifier/118/review/521994 new file mode 100644 index 000000000..3400ab3e9 --- /dev/null +++ b/results/classifier/118/review/521994 @@ -0,0 +1,254 @@ +mistranslation: 0.888 +VMM: 0.888 +ppc: 0.884 +peripherals: 0.869 +debug: 0.845 +user-level: 0.832 +TCG: 0.815 +register: 0.809 +arm: 0.798 +virtual: 0.789 +KVM: 0.787 +vnc: 0.784 +hypervisor: 0.758 +semantic: 0.752 +permissions: 0.731 +device: 0.713 +assembly: 0.709 +x86: 0.703 +boot: 0.679 +architecture: 0.675 +PID: 0.673 +risc-v: 0.657 +socket: 0.649 +graphic: 0.639 +network: 0.628 +performance: 0.612 +files: 0.611 +kernel: 0.441 +i386: 0.395 +-------------------- +x86: 0.981 +debug: 0.966 +i386: 0.798 +boot: 0.747 +virtual: 0.068 +device: 0.038 +TCG: 0.032 +files: 0.029 +semantic: 0.029 +PID: 0.024 +socket: 0.016 +register: 0.016 +hypervisor: 0.016 +performance: 0.014 +assembly: 0.013 +user-level: 0.012 +architecture: 0.010 +VMM: 0.008 +peripherals: 0.008 +KVM: 0.006 +graphic: 0.005 +risc-v: 0.005 +permissions: 0.004 +vnc: 0.003 +network: 0.003 +ppc: 0.003 +arm: 0.002 +kernel: 0.002 +mistranslation: 0.001 + +Windows 98 doesn't detect mouse on qemu and SeaBIOS. + +A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the result is + +fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit +commit fd646122418ecefcde228d43821d07da79dd99bb +Author: Anthony Liguori <email address hidden> +Date: Fri Oct 30 09:06:09 2009 -0500 + + Switch pc bios from pc-bios to seabios + + SeaBIOS is a port of pc-bios to GCC. Besides using a more modern tool chain, + SeaBIOS introduces a number of new features including PMM support, better + BEV and BCV support, and better PnP support. + + Signed-off-by: Anthony Liguori <email address hidden> + +I got following messages with DEBUG_BIOS + +Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) +Ram Size=0x08000000 (0x0000000000000000 high) +CPU Mhz=2271 +Found 1 cpu(s) max supported 1 cpu(s) +PIIX3/PIIX4 init: elcr=00 0c +PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 +PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 +PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 +region 4: 0x0000c000 +PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 +PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 +region 0: 0xe0000000 +region 1: 0xe2000000 +region 6: 0xe2010000 +MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224 +SMBIOS ptr=0x000f8990 table=0x07fffef0 +ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30 +Scan for VGA option rom +Running option rom at c000:0003 +VGABios $Id$ +Turning on vga console +Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) + +Found 0 lpt ports +Found 0 serial ports +ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9) +ATA controller 1 at 170/374/c008 (irq 15 dev 9) +ps2 irq but no data. +ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63 +ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56 +ps2_recvbyte timeout +keyboard initialized +Scan for option roms +Returned 53248 bytes of ZoneHigh +e820 map has 6 items: + 0: 0000000000000000 - 000000000009f400 = 1 + 1: 000000000009f400 - 00000000000a0000 = 2 + 2: 00000000000f0000 - 0000000000100000 = 2 + 3: 0000000000100000 - 0000000007ffd000 = 1 + 4: 0000000007ffd000 - 0000000008000000 = 2 + 5: 00000000fffc0000 - 0000000100000000 = 2 +enter handle_19: + NULL +Booting from Hard Disk... +Booting from 0000:7c00 +pnp call arg1=5 +pnp call arg1=0 +ps2_recvbyte timeout +ps2_recvbyte timeout +ps2_recvbyte timeout +ps2_recvbyte timeout + +Running 10.04 beta on three different machines and on all the Win95 guest ps2 mouse emulation does not work. + +I also confirm from Lubuntu 10.04 beta2. +Win98 on qemu doesn't detect mouse. +The sound also doesn't works. +I used the same image on Ubuntu 9.04 and it worked. +Bye +Francesco bat + +I confirm that mouse is no more detected from version QEMU-0.12 running a Windows 3.1 on XP-PRO +In fact mouse seems to be "detected" (arrow is present and there is no warning message about lack of mouse) but the arrow doesn't move. (I created a new install with QEMU-0.12.3) +Bye +José + + +I confirm another time on Ubuntu 10.04 stable. +Win98 doesn't detect mouse. +Also the audio doesn't work ! +Bye +Francesco bat + +I confirm this same bug appears in Windows 95, Windows Me and several XFree86 and X.Org versions, as well as DOS based Microsoft Mouse drivers. + +I confirm also that mouse is not detected on Kubuntu 10.04 running qemu and Windows 98. + +I did find a workaround - I removed the BOCH BIOS package and QEMU package from my Lucid Install, and instead used the respective QEMU packages from 8.04 - this worked for me. I don't know if the most recent updates to the BIOS and QEMU packages will fix this or not - I might not try until I get confirmation that the new 10.04 packages are working. + +Apologies if I'm spamming this venue - truly just trying to be of assistance. Just got done installing the new updates to packages + qemu bochsbios qemu-kvm seabios vgabios - still did not fix the failure to recognize the mouse. + +this is fix for other mouse-stuck problem, or maybe the same. + +SeaBIOS 6.0 solved problem for me. + +Yes! Using SeaBIOS 6.0 worked for me as well. Thanks LightBit. I've been waiting for this for quite a while. + +Looks to be fixed by + +commit 14ac15d3ac8e0ef1c91204e2ac772b6412a6b99e +Author: Anthony Liguori <email address hidden> +Date: Tue May 11 07:56:30 2010 -0500 + + Update SeaBIOS + + - 7d09d0e Fix virtio compile errors on various gcc versions. + - 89acfa3 Support for booting from virtio disks + - 6d66316 smbios: avoid counting io hole as ram + - e5cd945 Fix error causing USB HID "boot" protocol to not be enabled. + - 0e88576 Add support for USB mice. + - dd5a8a6 When USB keyboard active, don't send keyboard commands to ps2 port. + - 5718d56 Document usb-hid.c functions. + - e438b0c Further parallelize init when using CONFIG_THREAD_OPTIONROMS. + - f59b5ac Handle unknown function addresses in tools/checkstack.py. + - 9ba1dea Simplify build by manually resolving external symbols in layoutrom.py. + - 698d3f9 USB EHCI should yield() whil waiting for controller to ack reset. + - f9a774c Add __attribute__((__malloc__)) declaration to internal malloc funcs. + - b7045ce Minor - remove redundant check from ata_try_dma. + - 67f6d37 Fix possible unitialized variable issue in usb msc. + - a7eb8fc Some improvements to optionrom preemption support. + - d28b0fe Refactor USB hub code. + - ba28541 Prep version for next release. + - 12bffd5 Update version to 0.6.0. + - 87ab2fb Improve USB EHCI timing. + - d705e5a Disable inlining on old compilers. + - bca0736 Force use of indirect function calls in inline assembler. + - d7eb27e Don't move EBDA while an optionrom is running (CONFIG_THREAD_OPTIONROMS). + - 7415270 Call to int1552 (from int1346) should set regs->dl. + - 9dc243e Adjust debug levels of device discovery. + - d9c9361 Default CONFIG_COREBOOT_FLASH on; make depend on CONFIG_COREBOOT. + - c35e1e5 Restore segment limits in handle_1589 code. + - 11cc662 Extend time for rtc to be ready. + - 4ed378a Backup and restore registers when calling out to user funcs. + - 68c5139 Enable irqs in kbd/clock calls that caller might "spin" on. + - f628244 Process event on ps2 keyboard irq even if event already read. + - a5d8458 Revert "Unify ps2 port data processing." + - b9ed5e2 Handle variable length return of ps2 port GETID command. + - 67a9eec Prevent ps2 irqs from messing up ps2 init. + - 6704cf9 Revert "Rework disabling of ps2 port irqs." + - 808939c Fix smp cpu detect on gcc 4.5. + - a979c1c Improvements to tools/checkstack.py. + - 190cc62 Add USB EHCI controller support. + - 0770d67 Some USB UHCI and OHCI fixes and cleanups. + - bfe7ca7 Minor - USB OHCI interrupt queue should be one larger. + - 09e2f7c Reduce size of USB 'struct uhci_td'. + - 406fad6 Dynamically allocate USB controller structures. + - 4547eb9 Replace USB encoded 'u32 endp' scheme with explicit struct fields. + - 8ebcac0 Further parallelize USB init by launching a thread per usb port. + - e908665 Introduce simple "mutex" locking code. + - 3b79f8b Only compile usb-hub.c and paravirt.c with 32bit code. + - 357bdfa Prefer passing a USB "pipe" structure over a USB endp encoding. + - 7fb8ba8 Add a generic "internal error" warning function. + + Signed-off-by: Anthony Liguori <email address hidden> + +:040000 040000 e1b3c6d95f0d7cbd709b4b6c28bdb91a0ee1a69b 2e871a4a7ac2e8d4c2fdceb585da8295e3f8348e M pc-bios +:040000 040000 4e12b72f4dca9f76592f70e3b9649a634d5894ff 06c34280852bb7a4809b180d7ba897993727caee M roms + +Looks like this is fixed in qemu. + +Im using Mint 19.3 based on Ubuntu 18.04 with QEMU 2.11 from repository, keyboard is working but mouse not in Win98. + + Could someone else to restest it? + + Here is my Qemu starting script: +qemu-system-x86_64 -m 512 \ +-machine type=pc-i440fx-bionic \ +-smp 1,sockets=1,cores=1,threads=1 \ +-vga cirrus \ +-rtc clock=host,base=localtime \ +-parallel none \ +-balloon none \ +-mem-prealloc \ +-serial none \ +-parallel none \ +-L . \ +-soundhw sb16,adlib,pcspk \ +-boot order=cd \ +-no-acpi \ +-hda ./Win98-System.vmdk \ +-cdrom ./Win98SE-ENG.iso \ +-k en-us \ +-net nic,model=rtl8139 -net user + diff --git a/results/classifier/118/review/524 b/results/classifier/118/review/524 new file mode 100644 index 000000000..96e77aa4c --- /dev/null +++ b/results/classifier/118/review/524 @@ -0,0 +1,61 @@ +architecture: 0.841 +device: 0.802 +performance: 0.792 +network: 0.672 +kernel: 0.635 +semantic: 0.592 +debug: 0.497 +permissions: 0.423 +register: 0.395 +arm: 0.392 +graphic: 0.383 +ppc: 0.357 +x86: 0.351 +i386: 0.340 +hypervisor: 0.337 +socket: 0.313 +mistranslation: 0.263 +PID: 0.261 +boot: 0.251 +user-level: 0.143 +assembly: 0.143 +virtual: 0.131 +vnc: 0.118 +files: 0.115 +risc-v: 0.061 +VMM: 0.046 +TCG: 0.040 +peripherals: 0.016 +KVM: 0.002 +-------------------- +debug: 0.825 +user-level: 0.772 +virtual: 0.609 +kernel: 0.371 +performance: 0.051 +assembly: 0.044 +semantic: 0.035 +hypervisor: 0.028 +x86: 0.023 +files: 0.009 +permissions: 0.006 +device: 0.004 +boot: 0.004 +graphic: 0.003 +PID: 0.003 +i386: 0.002 +architecture: 0.002 +ppc: 0.002 +TCG: 0.001 +VMM: 0.001 +risc-v: 0.001 +register: 0.001 +arm: 0.001 +mistranslation: 0.001 +peripherals: 0.001 +KVM: 0.001 +network: 0.000 +socket: 0.000 +vnc: 0.000 + +Giving -smp option a negative argument makes QEMU dump core diff --git a/results/classifier/118/review/531 b/results/classifier/118/review/531 new file mode 100644 index 000000000..d0d980c78 --- /dev/null +++ b/results/classifier/118/review/531 @@ -0,0 +1,61 @@ +architecture: 0.905 +performance: 0.848 +device: 0.827 +network: 0.755 +socket: 0.626 +arm: 0.624 +vnc: 0.551 +graphic: 0.496 +boot: 0.493 +ppc: 0.462 +kernel: 0.431 +hypervisor: 0.418 +risc-v: 0.405 +i386: 0.385 +semantic: 0.369 +register: 0.346 +TCG: 0.342 +VMM: 0.337 +x86: 0.330 +debug: 0.329 +KVM: 0.320 +permissions: 0.293 +peripherals: 0.280 +virtual: 0.246 +PID: 0.227 +assembly: 0.212 +files: 0.212 +mistranslation: 0.138 +user-level: 0.098 +-------------------- +performance: 0.709 +kernel: 0.667 +assembly: 0.474 +peripherals: 0.113 +x86: 0.044 +architecture: 0.038 +files: 0.036 +virtual: 0.034 +device: 0.019 +boot: 0.011 +KVM: 0.008 +debug: 0.007 +semantic: 0.006 +arm: 0.006 +ppc: 0.006 +risc-v: 0.006 +user-level: 0.005 +i386: 0.004 +hypervisor: 0.004 +socket: 0.003 +PID: 0.002 +TCG: 0.002 +graphic: 0.002 +VMM: 0.002 +vnc: 0.001 +register: 0.001 +network: 0.000 +mistranslation: 0.000 +permissions: 0.000 + +Replace DMA processing in I/O handlers by asynchronous BH diff --git a/results/classifier/118/review/532 b/results/classifier/118/review/532 new file mode 100644 index 000000000..1df40846d --- /dev/null +++ b/results/classifier/118/review/532 @@ -0,0 +1,61 @@ +architecture: 0.930 +device: 0.886 +network: 0.830 +peripherals: 0.721 +socket: 0.654 +performance: 0.617 +graphic: 0.510 +boot: 0.446 +arm: 0.367 +semantic: 0.314 +kernel: 0.264 +register: 0.248 +debug: 0.222 +virtual: 0.197 +hypervisor: 0.187 +files: 0.174 +mistranslation: 0.168 +vnc: 0.162 +i386: 0.153 +assembly: 0.149 +permissions: 0.140 +ppc: 0.138 +x86: 0.132 +VMM: 0.109 +PID: 0.104 +KVM: 0.098 +user-level: 0.073 +TCG: 0.023 +risc-v: 0.012 +-------------------- +peripherals: 0.753 +kernel: 0.750 +assembly: 0.289 +x86: 0.100 +performance: 0.033 +debug: 0.020 +TCG: 0.014 +virtual: 0.013 +i386: 0.011 +device: 0.010 +architecture: 0.009 +semantic: 0.009 +ppc: 0.008 +hypervisor: 0.006 +files: 0.006 +register: 0.005 +PID: 0.004 +arm: 0.003 +graphic: 0.002 +user-level: 0.002 +boot: 0.001 +VMM: 0.001 +risc-v: 0.001 +socket: 0.001 +KVM: 0.001 +network: 0.000 +vnc: 0.000 +permissions: 0.000 +mistranslation: 0.000 + +USB-EHCI: Replace DMA processing in I/O handlers by asynchronous BH diff --git a/results/classifier/118/review/536 b/results/classifier/118/review/536 new file mode 100644 index 000000000..2090528a1 --- /dev/null +++ b/results/classifier/118/review/536 @@ -0,0 +1,61 @@ +assembly: 0.987 +architecture: 0.800 +performance: 0.719 +device: 0.689 +debug: 0.610 +graphic: 0.532 +network: 0.240 +hypervisor: 0.172 +ppc: 0.145 +semantic: 0.135 +user-level: 0.127 +mistranslation: 0.122 +boot: 0.120 +peripherals: 0.104 +register: 0.096 +arm: 0.085 +kernel: 0.071 +virtual: 0.050 +vnc: 0.046 +VMM: 0.024 +TCG: 0.022 +permissions: 0.022 +x86: 0.019 +socket: 0.018 +risc-v: 0.012 +PID: 0.012 +i386: 0.010 +KVM: 0.009 +files: 0.006 +-------------------- +debug: 0.571 +assembly: 0.330 +kernel: 0.128 +user-level: 0.073 +x86: 0.068 +virtual: 0.056 +files: 0.049 +arm: 0.047 +device: 0.014 +peripherals: 0.012 +i386: 0.011 +PID: 0.008 +TCG: 0.007 +performance: 0.007 +ppc: 0.006 +hypervisor: 0.006 +VMM: 0.005 +network: 0.004 +KVM: 0.004 +risc-v: 0.003 +semantic: 0.003 +graphic: 0.003 +boot: 0.002 +socket: 0.002 +architecture: 0.002 +register: 0.002 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +Null-ptr dereference in ich9_apm_ctrl_changed diff --git a/results/classifier/118/review/541 b/results/classifier/118/review/541 new file mode 100644 index 000000000..24af3792a --- /dev/null +++ b/results/classifier/118/review/541 @@ -0,0 +1,61 @@ +mistranslation: 0.913 +device: 0.702 +semantic: 0.688 +performance: 0.648 +graphic: 0.620 +arm: 0.294 +ppc: 0.291 +x86: 0.277 +i386: 0.258 +vnc: 0.253 +boot: 0.233 +KVM: 0.230 +VMM: 0.196 +architecture: 0.190 +network: 0.186 +debug: 0.158 +TCG: 0.138 +PID: 0.130 +hypervisor: 0.113 +assembly: 0.107 +kernel: 0.104 +user-level: 0.103 +permissions: 0.066 +register: 0.065 +files: 0.059 +virtual: 0.047 +socket: 0.042 +peripherals: 0.030 +risc-v: 0.028 +-------------------- +debug: 0.661 +virtual: 0.169 +semantic: 0.083 +files: 0.080 +kernel: 0.068 +device: 0.063 +x86: 0.056 +performance: 0.055 +user-level: 0.024 +ppc: 0.018 +hypervisor: 0.017 +assembly: 0.013 +PID: 0.010 +network: 0.009 +VMM: 0.009 +peripherals: 0.008 +KVM: 0.008 +TCG: 0.007 +i386: 0.006 +graphic: 0.005 +boot: 0.005 +permissions: 0.003 +architecture: 0.002 +arm: 0.002 +socket: 0.002 +mistranslation: 0.002 +risc-v: 0.001 +vnc: 0.001 +register: 0.001 + +Heap-use-after-free through ehci_flush_qh diff --git a/results/classifier/118/review/547 b/results/classifier/118/review/547 new file mode 100644 index 000000000..eb55bf7a1 --- /dev/null +++ b/results/classifier/118/review/547 @@ -0,0 +1,61 @@ +architecture: 0.940 +device: 0.897 +performance: 0.886 +graphic: 0.659 +debug: 0.382 +semantic: 0.303 +hypervisor: 0.247 +mistranslation: 0.220 +arm: 0.157 +x86: 0.154 +user-level: 0.116 +risc-v: 0.108 +boot: 0.085 +virtual: 0.073 +ppc: 0.061 +register: 0.049 +network: 0.048 +vnc: 0.046 +assembly: 0.027 +permissions: 0.019 +i386: 0.018 +PID: 0.013 +peripherals: 0.011 +TCG: 0.010 +files: 0.007 +socket: 0.005 +kernel: 0.004 +VMM: 0.003 +KVM: 0.000 +-------------------- +virtual: 0.925 +performance: 0.697 +PID: 0.680 +debug: 0.586 +hypervisor: 0.531 +user-level: 0.187 +assembly: 0.154 +x86: 0.128 +kernel: 0.054 +device: 0.041 +register: 0.010 +files: 0.010 +arm: 0.008 +semantic: 0.006 +peripherals: 0.004 +graphic: 0.003 +ppc: 0.003 +TCG: 0.003 +architecture: 0.003 +socket: 0.002 +network: 0.001 +i386: 0.001 +boot: 0.001 +permissions: 0.001 +KVM: 0.001 +VMM: 0.000 +risc-v: 0.000 +mistranslation: 0.000 +vnc: 0.000 + +e1000: Loop blocking QEMU with high CPU usage diff --git a/results/classifier/118/review/564 b/results/classifier/118/review/564 new file mode 100644 index 000000000..a62049f23 --- /dev/null +++ b/results/classifier/118/review/564 @@ -0,0 +1,73 @@ +x86: 0.923 +graphic: 0.870 +device: 0.818 +architecture: 0.815 +ppc: 0.782 +boot: 0.697 +files: 0.686 +mistranslation: 0.630 +virtual: 0.580 +permissions: 0.550 +PID: 0.518 +performance: 0.490 +i386: 0.471 +socket: 0.442 +semantic: 0.440 +user-level: 0.414 +network: 0.376 +peripherals: 0.367 +register: 0.365 +kernel: 0.317 +arm: 0.275 +VMM: 0.243 +TCG: 0.227 +hypervisor: 0.219 +debug: 0.178 +vnc: 0.172 +risc-v: 0.109 +KVM: 0.036 +assembly: 0.015 +-------------------- +virtual: 0.953 +x86: 0.737 +debug: 0.594 +boot: 0.204 +hypervisor: 0.162 +user-level: 0.124 +TCG: 0.087 +files: 0.081 +socket: 0.079 +register: 0.035 +PID: 0.030 +kernel: 0.014 +device: 0.013 +semantic: 0.012 +performance: 0.011 +assembly: 0.011 +architecture: 0.007 +graphic: 0.007 +ppc: 0.006 +network: 0.005 +permissions: 0.005 +KVM: 0.004 +risc-v: 0.003 +VMM: 0.003 +peripherals: 0.002 +vnc: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +Enable opengl virtio-gpu virgl vulkan in windows build +Additional information: +``` +PS E:\scoopg\apps\qemu\current> ./qemu-system-x86_64.exe -drive file=E:\groot_02\vdisks\gparted-live.iso,if=virtio -boot c -m 4096 -machine type=pc,accel=whpx,kernel-irqchip=off -smp 8,sockets=1,cores=8,threads=1 -vga virtio -display sdl,gl=on +E:\scoopg\apps\qemu\current\qemu-system-x86_64.exe: OpenGL support is disabled +``` + +``` +PS E:\scoopg\apps\qemu\current> E:\scoopg\apps\qemu\current\qemu-system-x86_64.exe --version +QEMU emulator version 6.0.93 (v6.1.0-rc3-11879-ge232c1bc00-dirty) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +``` +# diff --git a/results/classifier/118/review/566 b/results/classifier/118/review/566 new file mode 100644 index 000000000..09384c3cf --- /dev/null +++ b/results/classifier/118/review/566 @@ -0,0 +1,61 @@ +user-level: 0.855 +device: 0.783 +architecture: 0.712 +arm: 0.677 +debug: 0.604 +performance: 0.520 +graphic: 0.506 +boot: 0.393 +semantic: 0.388 +PID: 0.356 +network: 0.336 +mistranslation: 0.286 +permissions: 0.263 +ppc: 0.227 +virtual: 0.218 +assembly: 0.181 +VMM: 0.178 +TCG: 0.170 +files: 0.162 +kernel: 0.138 +hypervisor: 0.126 +register: 0.125 +vnc: 0.123 +peripherals: 0.088 +risc-v: 0.085 +socket: 0.065 +x86: 0.051 +i386: 0.035 +KVM: 0.029 +-------------------- +user-level: 0.340 +virtual: 0.049 +x86: 0.032 +files: 0.029 +assembly: 0.016 +debug: 0.012 +device: 0.010 +i386: 0.006 +semantic: 0.003 +TCG: 0.003 +boot: 0.003 +VMM: 0.002 +performance: 0.002 +PID: 0.002 +arm: 0.002 +network: 0.001 +graphic: 0.001 +ppc: 0.001 +permissions: 0.001 +kernel: 0.001 +register: 0.001 +peripherals: 0.001 +risc-v: 0.001 +socket: 0.000 +mistranslation: 0.000 +KVM: 0.000 +architecture: 0.000 +vnc: 0.000 +hypervisor: 0.000 + +Fail to build linux-user on Alpine diff --git a/results/classifier/118/review/568 b/results/classifier/118/review/568 new file mode 100644 index 000000000..749acb12b --- /dev/null +++ b/results/classifier/118/review/568 @@ -0,0 +1,86 @@ +mistranslation: 0.905 +graphic: 0.858 +semantic: 0.796 +device: 0.733 +debug: 0.724 +architecture: 0.686 +performance: 0.683 +VMM: 0.679 +PID: 0.605 +ppc: 0.575 +risc-v: 0.514 +socket: 0.473 +permissions: 0.456 +register: 0.434 +user-level: 0.431 +hypervisor: 0.410 +vnc: 0.364 +arm: 0.364 +TCG: 0.357 +peripherals: 0.355 +assembly: 0.342 +files: 0.334 +boot: 0.154 +virtual: 0.147 +x86: 0.145 +kernel: 0.117 +network: 0.112 +KVM: 0.072 +i386: 0.067 +-------------------- +virtual: 0.948 +debug: 0.667 +files: 0.193 +TCG: 0.153 +performance: 0.107 +graphic: 0.063 +user-level: 0.044 +KVM: 0.039 +hypervisor: 0.037 +device: 0.030 +x86: 0.027 +VMM: 0.023 +risc-v: 0.012 +PID: 0.012 +register: 0.010 +semantic: 0.008 +kernel: 0.007 +i386: 0.006 +socket: 0.005 +network: 0.005 +peripherals: 0.005 +architecture: 0.004 +vnc: 0.004 +boot: 0.003 +ppc: 0.002 +assembly: 0.002 +permissions: 0.002 +arm: 0.001 +mistranslation: 0.001 + +video memory option not working with Mac OS or Windows guest +Description of problem: +The vgamem_mb option tells the guest how much video memory it has access to. When I used this command '-device VGA,vgamem_mb=128', I expect the guest to report there is 128 MB of video memory. What actually happens is the guest does not seem to know how much video memory is actually available. +Steps to reproduce: +**Mac OS guest:** +1. Run a Mac OS guest with this command: -device VGA,vgamem_mb=128 +2. In Mac OS X open the System Information application -> /Applications/Utilities/System Information. +3. Click on "Graphics/Displays". +4. Look at the 'VRAM (Total)' field. +The field only shows 3 MB of video ram. + +**Windows guest:** +1. Run a Windows (Windows XP in my case) guest with this command: -device VGA,vgamem_mb=128 +2. Click on Start->Run. +3. Enter 'dxdiag'. +4. Push the OK button. +5. Click on the Display tap in the DirectX Diagnostic Tool. +6. Look at the Approv. Total Memory field. +The field should say 128 MB but actually says N/A. +Additional information: +**Mac OS 8.5<br>** +<br><br><br> +**Windows XP<br>** +<br><br><br> +**Windows 7<br>** + diff --git a/results/classifier/118/review/568053 b/results/classifier/118/review/568053 new file mode 100644 index 000000000..18b4c0be2 --- /dev/null +++ b/results/classifier/118/review/568053 @@ -0,0 +1,71 @@ +ppc: 0.930 +mistranslation: 0.900 +graphic: 0.805 +semantic: 0.767 +architecture: 0.707 +device: 0.547 +network: 0.432 +files: 0.414 +virtual: 0.311 +peripherals: 0.302 +permissions: 0.285 +performance: 0.278 +socket: 0.255 +user-level: 0.240 +TCG: 0.221 +debug: 0.193 +hypervisor: 0.181 +VMM: 0.180 +PID: 0.177 +i386: 0.156 +vnc: 0.151 +boot: 0.136 +x86: 0.134 +arm: 0.127 +register: 0.104 +kernel: 0.095 +assembly: 0.051 +risc-v: 0.030 +KVM: 0.019 +-------------------- +x86: 0.161 +user-level: 0.108 +files: 0.090 +TCG: 0.072 +hypervisor: 0.068 +register: 0.015 +virtual: 0.014 +device: 0.010 +debug: 0.007 +semantic: 0.007 +i386: 0.006 +kernel: 0.006 +network: 0.005 +architecture: 0.002 +PID: 0.002 +boot: 0.002 +VMM: 0.002 +peripherals: 0.001 +assembly: 0.001 +permissions: 0.001 +performance: 0.001 +graphic: 0.001 +socket: 0.001 +arm: 0.001 +ppc: 0.001 +risc-v: 0.001 +KVM: 0.001 +vnc: 0.001 +mistranslation: 0.000 + +requires MSYS coreutils ext sub-package to build on Windows + +When I try to build QEMU on Windows without the MSYS coreutils ext sub-package installed, the build fails because it cannot find dd. + + + +pc-bios/optionrom/signrom.sh uses 'dd'. + +signrom.sh has been removed/rewritten by this commit: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0d6b9cc7420dd2d531b48508f0d4 + diff --git a/results/classifier/118/review/574 b/results/classifier/118/review/574 new file mode 100644 index 000000000..f31481774 --- /dev/null +++ b/results/classifier/118/review/574 @@ -0,0 +1,61 @@ +architecture: 0.891 +device: 0.868 +network: 0.860 +performance: 0.852 +mistranslation: 0.812 +files: 0.783 +register: 0.646 +debug: 0.631 +semantic: 0.617 +VMM: 0.582 +vnc: 0.579 +socket: 0.575 +arm: 0.544 +graphic: 0.536 +boot: 0.474 +kernel: 0.462 +PID: 0.425 +ppc: 0.357 +risc-v: 0.313 +user-level: 0.241 +peripherals: 0.178 +virtual: 0.178 +TCG: 0.171 +permissions: 0.163 +assembly: 0.122 +hypervisor: 0.077 +KVM: 0.054 +x86: 0.019 +i386: 0.008 +-------------------- +debug: 0.549 +user-level: 0.542 +virtual: 0.064 +files: 0.048 +TCG: 0.018 +semantic: 0.015 +x86: 0.013 +network: 0.012 +assembly: 0.010 +arm: 0.010 +performance: 0.009 +VMM: 0.009 +KVM: 0.007 +ppc: 0.007 +device: 0.006 +register: 0.006 +boot: 0.005 +kernel: 0.003 +PID: 0.003 +risc-v: 0.003 +hypervisor: 0.002 +graphic: 0.002 +i386: 0.002 +architecture: 0.002 +peripherals: 0.002 +socket: 0.002 +vnc: 0.002 +permissions: 0.001 +mistranslation: 0.000 + +ui/sdl2: warning: redundant redeclaration of 'direct_waitqueue_init' diff --git a/results/classifier/118/review/584516 b/results/classifier/118/review/584516 new file mode 100644 index 000000000..67e13eadd --- /dev/null +++ b/results/classifier/118/review/584516 @@ -0,0 +1,116 @@ +user-level: 0.888 +permissions: 0.888 +files: 0.885 +debug: 0.879 +mistranslation: 0.860 +register: 0.855 +network: 0.852 +virtual: 0.850 +graphic: 0.843 +device: 0.840 +vnc: 0.836 +assembly: 0.836 +performance: 0.835 +architecture: 0.834 +socket: 0.831 +KVM: 0.829 +risc-v: 0.814 +ppc: 0.811 +VMM: 0.802 +peripherals: 0.796 +semantic: 0.794 +kernel: 0.789 +boot: 0.789 +PID: 0.779 +arm: 0.778 +TCG: 0.769 +hypervisor: 0.765 +x86: 0.703 +i386: 0.685 +-------------------- +debug: 0.999 +KVM: 0.863 +virtual: 0.833 +hypervisor: 0.755 +kernel: 0.254 +files: 0.114 +PID: 0.082 +x86: 0.056 +assembly: 0.045 +register: 0.038 +TCG: 0.037 +user-level: 0.025 +ppc: 0.013 +performance: 0.011 +architecture: 0.007 +VMM: 0.006 +device: 0.006 +semantic: 0.005 +socket: 0.002 +boot: 0.002 +network: 0.002 +arm: 0.002 +graphic: 0.002 +peripherals: 0.001 +vnc: 0.001 +risc-v: 0.001 +permissions: 0.001 +i386: 0.001 +mistranslation: 0.000 + +opensuse 11.2 guest hangs after live migration with clocksource=kvm-clock + +i would like to debug a problem that I encountered some time ago with opensuse 11.2 and also +with Ubuntu (karmic/lucid). + +If I run an opensuse guest 64-bit and do not touch the clocksource settings the guest almost +everytime hangs after live migration at: + +(gdb) thread apply all bt + +Thread 2 (Thread 0x7f846782a950 (LWP 27356)): +#0 0x00007f8467d24cd7 in ioctl () from /lib/libc.so.6 +#1 0x000000000042b945 in kvm_run (env=0x2468170) + at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921 +#2 0x000000000042cea2 in kvm_cpu_exec (env=0x2468170) + at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 +#3 0x000000000042d62c in kvm_main_loop_cpu (env=0x2468170) + at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 +#4 0x000000000042d76d in ap_main_loop (_env=0x2468170) + at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 +#5 0x00007f8468caa3ba in start_thread () from /lib/libpthread.so.0 +#6 0x00007f8467d2cfcd in clone () from /lib/libc.so.6 +#7 0x0000000000000000 in ?? () + +Thread 1 (Thread 0x7f84692d96f0 (LWP 27353)): +#0 0x00007f8467d25742 in select () from /lib/libc.so.6 +#1 0x000000000040c25a in main_loop_wait (timeout=1000) + at /usr/src/qemu-kvm-0.12.4/vl.c:3994 +#2 0x000000000042dcf1 in kvm_main_loop () + at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126 +#3 0x000000000040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212 +#4 0x000000000041054b in main (argc=31, argv=0x7fffa91351c8, + envp=0x7fffa91352c8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252 + +If I run the same guest with kernel parameter clocksource=acpi_pm, the migration succeeds reliably. + +The hosts runs: +/kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3 + +I invoke qemu-kvm with: +/usr/bin/qemu-kvm-0.12.4 -net none -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'test' -boot order=dc,menu=on -k de -pidfile /var/run/qemu/vm-149.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=vm -usb -usbdevice tablet + +The Guest is: +OpenSuse 11.2 64-bit with Kernel 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 x86_64 +The clocksource automatically choosen is kvm-clock. + +Feedback appreciated. I have observed the same problem with 0.12.2 and also with old binaries provided by Ubuntu Karmic (kvm-88). + +Update: + +Problem still exists with lastest GIT. Ubuntu 9.10 and 10.04 64-bit guests are also affected. + +This bug ticket is quite old already ... 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/review/589827 b/results/classifier/118/review/589827 new file mode 100644 index 000000000..ca92d59cf --- /dev/null +++ b/results/classifier/118/review/589827 @@ -0,0 +1,82 @@ +mistranslation: 0.880 +device: 0.490 +network: 0.462 +semantic: 0.377 +graphic: 0.360 +vnc: 0.298 +x86: 0.295 +performance: 0.283 +ppc: 0.270 +socket: 0.267 +kernel: 0.249 +user-level: 0.212 +architecture: 0.206 +risc-v: 0.164 +arm: 0.146 +register: 0.141 +PID: 0.139 +files: 0.128 +peripherals: 0.125 +boot: 0.114 +TCG: 0.089 +debug: 0.088 +virtual: 0.085 +VMM: 0.084 +permissions: 0.080 +assembly: 0.033 +hypervisor: 0.030 +i386: 0.030 +KVM: 0.029 +-------------------- +x86: 0.964 +network: 0.913 +virtual: 0.837 +user-level: 0.377 +hypervisor: 0.304 +TCG: 0.044 +device: 0.031 +files: 0.020 +debug: 0.016 +PID: 0.008 +kernel: 0.007 +socket: 0.006 +ppc: 0.004 +peripherals: 0.004 +boot: 0.004 +semantic: 0.004 +assembly: 0.003 +KVM: 0.003 +arm: 0.003 +register: 0.003 +VMM: 0.002 +architecture: 0.002 +risc-v: 0.002 +i386: 0.001 +vnc: 0.001 +performance: 0.001 +permissions: 0.001 +graphic: 0.001 +mistranslation: 0.000 + +QEMU netdev tap type id name is not used on linux host + +Tested with 0.12.3, 0.12.4, and latest git as of 4 jun 2010. +The new -netdev type seems to ignore manual specifications of tap ifname. + + qemu-system-x86_64 -hda disk.img -netdev tap,id=ids_e0 -device e1000,netdev=ids_e0 + **creates tap0 instead of ids_e0. tap0 passes traffic, ids_e0 doesn't exist +(I tried -netdev type=tap as well for brevity) + +QEMU creates a tap0 (or appropriate) interface and does not name this "ids_e0" as would be expected. I also tried 'pre' creating the tap interface. + +Previous alterantive was + qemu-system-x86_64 -hda disk.img -net nic,model=e1000,vlan=99 -net tap,ifname=ids_e0,vlan=99 + **creates ids_e0 as expected, and passes traffic as expected. + +Thanks to IRC, the correct syntax is: -netdev tap,id=asa1_eth0_tap,ifname=asa1_eth0_tap -device e1000,netdev=asa1_eth0_tap,mac=00:aa:cd:dd:01:01 + +(noted, fd=h option doesn't work on -netdev) + + +The "id=..." is only the QEMU-internal name of the netdev, not the name of the tap device. So this is not a bug --> closing this ticket. + diff --git a/results/classifier/118/review/59 b/results/classifier/118/review/59 new file mode 100644 index 000000000..7f3c106fb --- /dev/null +++ b/results/classifier/118/review/59 @@ -0,0 +1,61 @@ +mistranslation: 0.981 +device: 0.676 +network: 0.599 +performance: 0.566 +register: 0.561 +arm: 0.537 +risc-v: 0.537 +semantic: 0.533 +TCG: 0.528 +files: 0.525 +permissions: 0.495 +vnc: 0.489 +architecture: 0.462 +ppc: 0.451 +PID: 0.410 +VMM: 0.399 +kernel: 0.390 +graphic: 0.373 +debug: 0.350 +socket: 0.350 +KVM: 0.335 +boot: 0.319 +x86: 0.293 +i386: 0.242 +assembly: 0.147 +hypervisor: 0.146 +virtual: 0.124 +user-level: 0.103 +peripherals: 0.007 +-------------------- +files: 0.865 +kernel: 0.067 +virtual: 0.062 +debug: 0.048 +semantic: 0.026 +device: 0.022 +x86: 0.018 +i386: 0.012 +register: 0.009 +assembly: 0.007 +user-level: 0.006 +boot: 0.006 +architecture: 0.005 +risc-v: 0.005 +PID: 0.003 +peripherals: 0.003 +network: 0.003 +arm: 0.003 +mistranslation: 0.002 +VMM: 0.002 +graphic: 0.002 +ppc: 0.001 +KVM: 0.001 +TCG: 0.001 +socket: 0.001 +hypervisor: 0.001 +performance: 0.001 +vnc: 0.000 +permissions: 0.000 + +ide/core.c ATA Major Version reporting incorrect diff --git a/results/classifier/118/review/591666 b/results/classifier/118/review/591666 new file mode 100644 index 000000000..9a858c4fd --- /dev/null +++ b/results/classifier/118/review/591666 @@ -0,0 +1,227 @@ +mistranslation: 0.888 +device: 0.883 +user-level: 0.881 +peripherals: 0.875 +risc-v: 0.870 +register: 0.853 +hypervisor: 0.843 +semantic: 0.839 +assembly: 0.834 +kernel: 0.829 +graphic: 0.824 +architecture: 0.816 +TCG: 0.811 +socket: 0.811 +PID: 0.810 +debug: 0.809 +arm: 0.804 +vnc: 0.801 +ppc: 0.800 +boot: 0.792 +permissions: 0.791 +virtual: 0.788 +KVM: 0.772 +files: 0.764 +performance: 0.750 +VMM: 0.728 +network: 0.717 +x86: 0.633 +i386: 0.582 +-------------------- +virtual: 0.966 +hypervisor: 0.750 +KVM: 0.449 +x86: 0.372 +kernel: 0.236 +debug: 0.214 +vnc: 0.025 +socket: 0.017 +TCG: 0.016 +files: 0.016 +register: 0.015 +performance: 0.012 +PID: 0.011 +device: 0.009 +network: 0.006 +boot: 0.006 +user-level: 0.004 +semantic: 0.003 +peripherals: 0.003 +architecture: 0.002 +ppc: 0.002 +risc-v: 0.002 +VMM: 0.002 +i386: 0.002 +graphic: 0.002 +permissions: 0.001 +assembly: 0.001 +mistranslation: 0.001 +arm: 0.001 + +broken "pci_add auto storage" + +Doing: +(qemu) pci_add auto storage file=/dev/ram0,if=virtio +Results in: +OK domain 0, bus 0, slot 5, function 0 + +However no device is actually added to the guest. +QEMU: Latest git code (June 9) from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git +(seems to be broken from 0.12.1.2) +KVM: Compiled from git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git +checked out (refs/remotes/origin/stable-2.6.32) + +Both guest and host are Ubuntu 9.10 with 2.6.32 kernel. +Guest kernel has ACPI enabled (specifically, the PCI slot detection driver) + +Guest executed with the following parameters: + -boot c -drive file=/home/eranr/kvm_images/ubuntu-9.10-2.6.32-perf.img,if=ide,boot=on -m 4096 -net nic,model=virtio -net tap,ifname=qtap0,script=no -vnc :0 -smp 1,cores=1,threads=0 -monitor tcp:localhost:6001,server,nowait + +Hi Eran, + +Could you lauch "lspci" command on guestOS to see whether there is a new pci device hot-plug in? + +On the other hand, the guestOS need to be configured with "CONFIG_VIRTIO_PCI", otherwise it can not +contain the driver to monitor the virtio-pci device. + +Thanks + +If configure guest kernel correctly, it seems that virtio for block is OK! +Could you help or send me your configure file to have a second check + +Thanks + + +======== version info =============== +QEMU 0.14.50 monitor +host kernel: 2.6.39 +guest kernel: 2.6.32 + + + +======== config file for kernel info =================== +See attachment + +=========Doing on qemu monitor ================ +QEMU 0.14.50 monitor - type 'help' for more information +(qemu) pci_add auto storage file=/dev/ram0,if=virtio +OK domain 0, bus 0, slot 3, function 0 + + +=========Doing on guest console =============== +1. ---see the disk on guest +root@qemux86-64:~# dmesg | grep 'vda' +[ 245.440217] vda: unknown partition table +root@qemux86-64:~# fdisk -l + +Disk /dev/sda: 2147 MB, 2147483648 bytes +255 heads, 63 sectors/track, 261 cylinders +Units = cylinders of 16065 * 512 = 8225280 bytes + +Disk /dev/sda doesn't contain a valid partition table + +Disk /dev/vda: 16 MB, 16777216 bytes +16 heads, 63 sectors/track, 32 cylinders +Units = cylinders of 1008 * 512 = 516096 bytes + +Disk /dev/vda doesn't contain a valid partition table + +2. --- write content to virtio disk + +root@qemux86-64:~# echo 'helloHypervisor' > /dev/vda +root@qemux86-64:~# head /dev/vda +helloHypervisor + + + +=========Doing on host console ============= + +[root@oc8440477808 linux-2.6.39]# head /dev/ram0 +helloHypervisor + + +========= conclusion ==================== +Host get the data which is passed through virtio device on guest. The data is "helloHpervisor" + +So, the kernel version 2.6.32 can support virtio block device with correct +config, especially the following must be choosen: + + +CONFIG_VIRTIO=y +CONFIG_VIRTIO_RING=y +CONFIG_VIRTIO_PCI=y +CONFIG_VIRTIO_BALLOON=y +CONFIG_VIRTIO_BLK=y + + + + + + + + + + +Did you remember to load PCI hotplug modules into the guest? +sudo modprobe acpiphp +sudo modprobe pci_hotplug + + +this is vikas pandey, + +1:would u please give me ur kernel and initrd source to me ..am also trying to add pci and usb device in guest os .. + +2: +i am using qemu and i am abe to run some of kernel image and initrd which is available on qemu site for testing purpose. +now my ami is to connect the host usb and access the content after running iso image or specifing kernel and initrd image on qemu . + +for this task i have followed some procedure which is inlined.... +//************************************************************************************************************************************************************************ + +cat /etc/lsb-release +Host pc discription : +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=11.04 +DISTRIB_CODENAME=natty +DISTRIB_DESCRIPTION="Ubuntu 11.04" +==>uname -a +Linux vikas-ThinkCentre-A70 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux + +QEMU emulator version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard + +fist i have checked with iso images +step 1: +dd of=ubuntuimage bs=1024 seek=10485760 count=0 +step 2: +qemu -hda ubuntuimage -cdrom m1040_wifi.iso -usbdevice host:1e3d:2093 -m 192 -boot d +usb_create: no bus specified, using "usb.0" for "usb-host" +(it is a problem which is not permitting guest os to access completly even media will be detected on console while booting on qemu and we can add usb in qemu but in qemue gues os shelll it is not detecting any where ) +husb: open device 1.6 +husb: config #1 need -1 +husb: 1 interfaces claimed for configuration 1 +husb: grabbed usb device 1.6 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 +husb: config #1 need 1 +husb: 1 interfaces claimed for configuration 1 +=========>2nd i have used kernel and initrd image +step >qemu-system-arm -kernel zImage.integrator -initrd arm_root.img -hda ubuntuimage -usb -usbdevice host:1e3d:2093 -m 128 +segmantation fault +//******************************************************************************************************************************************** +please suggest me as soon as possible ,and please tell me that is it compulsary that use kvm and libvirt with qemu for using host usb or not.. +because i have also tried alot with libvirt but every time it is having some different -2 error currently error related with libvirt is .. +==>virsh -c qemu:///system list + +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_0.9.3' not found (required by virsh) +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_0.9.0' not found (required by virsh) +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_PRIVATE_0.9.3' not found (required by virsh) +virsh: /usr/lib/libvirt.so.0: version `LIBVIRT_0.9.2' not found (required by virsh + +plese tell me now what should ido... +thanks& regards + + + + +The "pci_add" command has been removed since QEMU 2.3.0, so I guess we can close this bug ... if you still can reproduce the problem with the latest version, please feel free to open this ticket again. + diff --git a/results/classifier/118/review/594 b/results/classifier/118/review/594 new file mode 100644 index 000000000..9795f2804 --- /dev/null +++ b/results/classifier/118/review/594 @@ -0,0 +1,61 @@ +mistranslation: 0.970 +performance: 0.834 +device: 0.764 +semantic: 0.705 +network: 0.682 +arm: 0.587 +kernel: 0.574 +risc-v: 0.479 +boot: 0.478 +ppc: 0.456 +architecture: 0.427 +vnc: 0.403 +TCG: 0.402 +VMM: 0.399 +hypervisor: 0.349 +KVM: 0.347 +PID: 0.347 +debug: 0.331 +i386: 0.318 +socket: 0.243 +x86: 0.242 +peripherals: 0.230 +permissions: 0.196 +assembly: 0.171 +graphic: 0.170 +files: 0.135 +register: 0.087 +user-level: 0.085 +virtual: 0.076 +-------------------- +assembly: 0.444 +performance: 0.369 +x86: 0.111 +debug: 0.108 +device: 0.056 +virtual: 0.051 +peripherals: 0.039 +mistranslation: 0.035 +architecture: 0.031 +semantic: 0.028 +VMM: 0.023 +user-level: 0.023 +TCG: 0.021 +kernel: 0.021 +risc-v: 0.018 +files: 0.017 +hypervisor: 0.012 +arm: 0.011 +network: 0.010 +ppc: 0.009 +PID: 0.009 +register: 0.007 +i386: 0.006 +KVM: 0.006 +boot: 0.005 +vnc: 0.004 +socket: 0.003 +graphic: 0.001 +permissions: 0.001 + +faults due to a amo instruction result in load faults instead of store/amo faults diff --git a/results/classifier/118/review/602 b/results/classifier/118/review/602 new file mode 100644 index 000000000..3d4aa6c74 --- /dev/null +++ b/results/classifier/118/review/602 @@ -0,0 +1,73 @@ +mistranslation: 0.915 +device: 0.799 +x86: 0.733 +graphic: 0.691 +risc-v: 0.675 +network: 0.643 +kernel: 0.630 +ppc: 0.616 +vnc: 0.614 +architecture: 0.544 +PID: 0.535 +socket: 0.526 +semantic: 0.478 +user-level: 0.454 +register: 0.446 +files: 0.435 +debug: 0.426 +TCG: 0.404 +boot: 0.386 +performance: 0.366 +arm: 0.346 +i386: 0.309 +VMM: 0.279 +permissions: 0.273 +hypervisor: 0.230 +virtual: 0.226 +peripherals: 0.185 +KVM: 0.185 +assembly: 0.180 +-------------------- +kernel: 0.830 +debug: 0.608 +TCG: 0.395 +virtual: 0.180 +network: 0.178 +files: 0.128 +hypervisor: 0.103 +register: 0.077 +x86: 0.059 +KVM: 0.042 +PID: 0.030 +risc-v: 0.026 +VMM: 0.017 +socket: 0.015 +user-level: 0.014 +semantic: 0.008 +device: 0.006 +assembly: 0.004 +architecture: 0.003 +ppc: 0.002 +boot: 0.002 +performance: 0.002 +vnc: 0.002 +mistranslation: 0.002 +peripherals: 0.001 +graphic: 0.001 +arm: 0.001 +i386: 0.001 +permissions: 0.000 + +Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation +Description of problem: +In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests. E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI. +Steps to reproduce: +1. https://cirrus-ci.com/task/5914289870471168 +Additional information: +The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014). + +The fix is something like: + +``` +__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno); +``` diff --git a/results/classifier/118/review/620 b/results/classifier/118/review/620 new file mode 100644 index 000000000..53f31381c --- /dev/null +++ b/results/classifier/118/review/620 @@ -0,0 +1,61 @@ +architecture: 0.923 +device: 0.826 +arm: 0.762 +network: 0.734 +debug: 0.498 +performance: 0.445 +boot: 0.375 +PID: 0.318 +files: 0.293 +graphic: 0.288 +socket: 0.286 +register: 0.285 +risc-v: 0.283 +ppc: 0.250 +VMM: 0.236 +semantic: 0.226 +hypervisor: 0.226 +kernel: 0.221 +vnc: 0.218 +peripherals: 0.211 +virtual: 0.189 +TCG: 0.165 +mistranslation: 0.130 +permissions: 0.111 +assembly: 0.064 +KVM: 0.045 +x86: 0.017 +i386: 0.015 +user-level: 0.011 +-------------------- +debug: 0.980 +arm: 0.934 +virtual: 0.933 +hypervisor: 0.465 +architecture: 0.418 +user-level: 0.226 +semantic: 0.016 +files: 0.009 +device: 0.007 +TCG: 0.006 +assembly: 0.005 +kernel: 0.005 +register: 0.004 +graphic: 0.002 +performance: 0.001 +boot: 0.001 +VMM: 0.001 +PID: 0.001 +risc-v: 0.001 +socket: 0.000 +peripherals: 0.000 +KVM: 0.000 +network: 0.000 +mistranslation: 0.000 +permissions: 0.000 +ppc: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 + +QEMU gdbstub should add memtag support for aarch64 MTE diff --git a/results/classifier/118/review/623 b/results/classifier/118/review/623 new file mode 100644 index 000000000..b5a78f56e --- /dev/null +++ b/results/classifier/118/review/623 @@ -0,0 +1,68 @@ +x86: 0.986 +device: 0.869 +architecture: 0.845 +virtual: 0.808 +graphic: 0.778 +hypervisor: 0.769 +permissions: 0.762 +files: 0.749 +network: 0.716 +socket: 0.714 +vnc: 0.690 +boot: 0.672 +arm: 0.671 +register: 0.629 +semantic: 0.622 +kernel: 0.569 +VMM: 0.559 +PID: 0.544 +user-level: 0.539 +mistranslation: 0.517 +ppc: 0.488 +TCG: 0.454 +risc-v: 0.392 +debug: 0.388 +performance: 0.372 +i386: 0.363 +peripherals: 0.281 +assembly: 0.266 +KVM: 0.112 +-------------------- +virtual: 0.831 +user-level: 0.236 +permissions: 0.152 +debug: 0.142 +files: 0.116 +TCG: 0.061 +register: 0.051 +hypervisor: 0.034 +x86: 0.020 +boot: 0.015 +PID: 0.007 +device: 0.007 +semantic: 0.005 +assembly: 0.005 +network: 0.005 +kernel: 0.003 +socket: 0.002 +ppc: 0.002 +risc-v: 0.002 +graphic: 0.002 +performance: 0.001 +architecture: 0.001 +VMM: 0.001 +vnc: 0.001 +peripherals: 0.001 +KVM: 0.001 +mistranslation: 0.000 +arm: 0.000 +i386: 0.000 + +Allow direct access to windows disks on hyper-V as well as virtiofsd, DAX +Additional information: +Depends on, first needs fixing of, Issue #346 / Issue #430 , Essentially accel=whpx is not working/is broken/has regression. +``` +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/review/638 b/results/classifier/118/review/638 new file mode 100644 index 000000000..c2a2f2c99 --- /dev/null +++ b/results/classifier/118/review/638 @@ -0,0 +1,73 @@ +mistranslation: 0.840 +graphic: 0.800 +device: 0.796 +network: 0.784 +vnc: 0.760 +debug: 0.744 +files: 0.733 +socket: 0.696 +PID: 0.678 +performance: 0.649 +architecture: 0.646 +register: 0.610 +kernel: 0.587 +virtual: 0.545 +VMM: 0.532 +ppc: 0.471 +risc-v: 0.458 +semantic: 0.455 +permissions: 0.428 +boot: 0.418 +TCG: 0.376 +arm: 0.353 +hypervisor: 0.332 +i386: 0.251 +peripherals: 0.198 +KVM: 0.193 +x86: 0.193 +assembly: 0.152 +user-level: 0.102 +-------------------- +kernel: 0.886 +debug: 0.881 +virtual: 0.405 +files: 0.326 +hypervisor: 0.274 +TCG: 0.112 +KVM: 0.110 +PID: 0.057 +VMM: 0.045 +device: 0.039 +arm: 0.036 +boot: 0.031 +x86: 0.022 +user-level: 0.016 +performance: 0.016 +semantic: 0.015 +peripherals: 0.013 +register: 0.008 +risc-v: 0.006 +i386: 0.005 +assembly: 0.005 +architecture: 0.003 +ppc: 0.003 +network: 0.003 +graphic: 0.002 +socket: 0.002 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +exynos4210_uart.c: SIGSEGV when loadvm +Description of problem: +Line 619 of hw/char/exynos4210_uart.c cast the object incorrectly. + +The function will be called with Exynos4210UartFIFO as opaque because it is set as `vmstate_exynos4210_uart_fifo.post_load` + +# +Steps to reproduce: +1. Create a VM with exynos4210_uart +2. savevm +3. loadvm +Additional information: + diff --git a/results/classifier/118/review/652 b/results/classifier/118/review/652 new file mode 100644 index 000000000..e0f1de840 --- /dev/null +++ b/results/classifier/118/review/652 @@ -0,0 +1,88 @@ +architecture: 0.877 +files: 0.741 +debug: 0.723 +ppc: 0.717 +device: 0.704 +mistranslation: 0.698 +semantic: 0.665 +TCG: 0.655 +performance: 0.644 +graphic: 0.640 +permissions: 0.551 +PID: 0.544 +register: 0.478 +vnc: 0.474 +VMM: 0.464 +risc-v: 0.445 +network: 0.429 +socket: 0.426 +hypervisor: 0.387 +boot: 0.382 +arm: 0.351 +i386: 0.350 +x86: 0.330 +virtual: 0.295 +KVM: 0.266 +user-level: 0.254 +kernel: 0.234 +assembly: 0.207 +peripherals: 0.205 +-------------------- +debug: 0.761 +architecture: 0.286 +mistranslation: 0.220 +x86: 0.180 +TCG: 0.125 +files: 0.121 +i386: 0.053 +PID: 0.030 +register: 0.026 +semantic: 0.023 +virtual: 0.018 +arm: 0.012 +assembly: 0.007 +VMM: 0.007 +network: 0.006 +socket: 0.005 +permissions: 0.005 +kernel: 0.004 +device: 0.004 +hypervisor: 0.004 +risc-v: 0.003 +boot: 0.003 +ppc: 0.002 +performance: 0.002 +vnc: 0.002 +peripherals: 0.002 +user-level: 0.002 +graphic: 0.001 +KVM: 0.001 + +Tricore: wrong implementation of OPC1_16_SRO_LD_H in target/tricore/translate.c +Description of problem: +The translation of the 16bit opcode LD.HD[15], A[b], off4 (SRO) is not done properly. +Page 210 of +https://www.infineon.com/dgdl/Infineon-TC2xx_Architecture_vol2-UM-v01_00-EN.pdf?fileId=5546d46269bda8df0169ca1bf33124a8 +as +D[15] = sign_ext(M(A[b] + zero_ext(2 * off4), half-word)); +1) Implemented in target/tricore/translate.c as + case OPC1_16_SRO_LD_H: + gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address, MO_LESW); + break; + +2) Should be + case OPC1_16_SRO_LD_H: + gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address * 2, MO_LESW); + break; + +Detected: +testsuite gcc9.1.0 delta analysis of Infineon Instruction Set Simulator vs. qemu-system-tricore +fix from 2) is successfull + +Confidence Level for bugfix high. +Is according to spec. and in line with reference Instruction Set Simulator from Infineon. + +Motivation +Reexecution of gcc/g++/libstdc++ testsuites with qemu + +I honor the implementation work which was done by bkoppelmann, vo_lumit@gmx.de diff --git a/results/classifier/118/review/657329 b/results/classifier/118/review/657329 new file mode 100644 index 000000000..bf2c3b2d3 --- /dev/null +++ b/results/classifier/118/review/657329 @@ -0,0 +1,113 @@ +architecture: 0.820 +register: 0.765 +device: 0.693 +graphic: 0.618 +x86: 0.611 +i386: 0.606 +ppc: 0.599 +performance: 0.572 +semantic: 0.569 +PID: 0.467 +files: 0.382 +socket: 0.261 +hypervisor: 0.210 +mistranslation: 0.208 +vnc: 0.204 +arm: 0.183 +boot: 0.182 +kernel: 0.176 +network: 0.160 +permissions: 0.151 +risc-v: 0.148 +VMM: 0.145 +user-level: 0.144 +virtual: 0.137 +TCG: 0.125 +peripherals: 0.123 +assembly: 0.122 +KVM: 0.105 +debug: 0.103 +-------------------- +x86: 0.754 +user-level: 0.571 +debug: 0.548 +files: 0.061 +virtual: 0.052 +TCG: 0.041 +hypervisor: 0.029 +architecture: 0.013 +performance: 0.009 +kernel: 0.009 +register: 0.007 +device: 0.007 +semantic: 0.006 +assembly: 0.006 +PID: 0.004 +peripherals: 0.004 +boot: 0.002 +graphic: 0.002 +network: 0.002 +ppc: 0.002 +vnc: 0.002 +risc-v: 0.002 +i386: 0.001 +permissions: 0.001 +socket: 0.001 +VMM: 0.001 +mistranslation: 0.000 +arm: 0.000 +KVM: 0.000 + +APIC unusable on QEMU + +The APIC is unusable with QEMU using x86-64 system emulation. Problem exists in the latest stable QEMU 0.12.5 as well as the latest git head. I am using Mac OS X 10.6, 64-bit version of QEMU. + +The QEMU binary was configured with: + + ./configure --target-list=i386-softmmu,x86_64-softmmubck-i-search: conf_ + +Problem is that the hw/apic.c file (as well as a few other naughty files) rely on the cpu_single_env global - which is set to NULL in cpu-exec.c. + +Below is a test reading the local APIC version register: + +Before taking it out: + +(qemu) xp 0xfee00030 +00000000fee00030: 0x00000000 +(qemu) + +After: + +(qemu) xp 0xfee00030 +00000000fee00030: 0x00050011 +(qemu) + +Quick fix below. I don't know if there are any side effects with this, if this is OK maybe we can fix it like this for the stable versions and fix the HEAD to not rely on the cpu_single_env global. + +diff --git a/cpu-exec.c b/cpu-exec.c +index dbdfdcc..3e966d7 100644 +--- a/cpu-exec.c ++++ b/cpu-exec.c +@@ -674,7 +674,17 @@ int cpu_exec(CPUState *env1) + env = (void *) saved_env_reg; + + /* fail safe : never use cpu_single_env outside cpu_exec() */ ++#warning fixup devices which rely on this ++#if 0 ++ /* ++ * Hello. This is wrapped around an #if 0 ... #endif because that's ++ * what should happen. However, certain naughty devices (like the APIC ++ * for instance, and a few others), access this global variable. ++ * ++ * So this is here for now ... until we fix up those devices. ++ */ + cpu_single_env = NULL; ++#endif + return ret; + } + +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/review/660 b/results/classifier/118/review/660 new file mode 100644 index 000000000..842b9ae8e --- /dev/null +++ b/results/classifier/118/review/660 @@ -0,0 +1,69 @@ +user-level: 0.955 +graphic: 0.815 +device: 0.636 +debug: 0.475 +arm: 0.416 +mistranslation: 0.302 +semantic: 0.285 +virtual: 0.260 +boot: 0.168 +performance: 0.119 +network: 0.116 +TCG: 0.113 +register: 0.110 +architecture: 0.109 +i386: 0.108 +kernel: 0.098 +x86: 0.076 +PID: 0.065 +KVM: 0.062 +peripherals: 0.055 +ppc: 0.054 +VMM: 0.054 +vnc: 0.042 +risc-v: 0.036 +socket: 0.034 +hypervisor: 0.034 +files: 0.022 +permissions: 0.022 +assembly: 0.009 +-------------------- +virtual: 0.785 +debug: 0.598 +user-level: 0.595 +TCG: 0.099 +semantic: 0.035 +device: 0.026 +x86: 0.024 +kernel: 0.022 +files: 0.020 +register: 0.019 +peripherals: 0.019 +graphic: 0.007 +hypervisor: 0.007 +VMM: 0.007 +architecture: 0.004 +KVM: 0.004 +assembly: 0.004 +performance: 0.004 +i386: 0.002 +ppc: 0.002 +boot: 0.001 +network: 0.001 +socket: 0.001 +PID: 0.001 +arm: 0.001 +risc-v: 0.000 +vnc: 0.000 +permissions: 0.000 +mistranslation: 0.000 + +User emulation does not use host GPU +Description of problem: + +Steps to reproduce: +1. Make a Arch Linux chroot (though any Linux system should work) on Linux +2. run `glxinfo | grep OpenGL +3. It's using llvmpipe, not whatever GPU/driver that the hosts use +Additional information: + diff --git a/results/classifier/118/review/673009 b/results/classifier/118/review/673009 new file mode 100644 index 000000000..979638954 --- /dev/null +++ b/results/classifier/118/review/673009 @@ -0,0 +1,200 @@ +mistranslation: 0.884 +graphic: 0.841 +TCG: 0.832 +VMM: 0.827 +user-level: 0.823 +KVM: 0.803 +ppc: 0.766 +register: 0.764 +hypervisor: 0.760 +risc-v: 0.745 +virtual: 0.743 +x86: 0.741 +vnc: 0.721 +semantic: 0.712 +performance: 0.712 +debug: 0.675 +permissions: 0.659 +device: 0.656 +PID: 0.640 +peripherals: 0.632 +arm: 0.629 +i386: 0.627 +boot: 0.622 +architecture: 0.611 +assembly: 0.609 +socket: 0.583 +kernel: 0.566 +files: 0.547 +network: 0.546 +-------------------- +i386: 0.968 +x86: 0.946 +debug: 0.691 +virtual: 0.650 +hypervisor: 0.397 +KVM: 0.121 +files: 0.113 +boot: 0.088 +PID: 0.068 +performance: 0.045 +TCG: 0.037 +register: 0.033 +VMM: 0.023 +user-level: 0.021 +semantic: 0.018 +kernel: 0.015 +device: 0.013 +network: 0.011 +assembly: 0.010 +socket: 0.009 +architecture: 0.007 +ppc: 0.004 +graphic: 0.003 +permissions: 0.002 +vnc: 0.002 +peripherals: 0.002 +mistranslation: 0.001 +risc-v: 0.001 +arm: 0.000 + +Latest git crashes in if_start with netBSD guest + +The latest version in git (cfd07e7abb1ef39373cd4ce312b015d61b9eea8d) crashes when running a NetBSD guest + +Host OS: Debian Linux/x86_64 5.0 +C Compiler: 4.4.5 +Guest OS:NetBSD/i386 5.0.2 +Command Line: +Build Configure: ./configure --enable-linux-aio --enable-io-thread --enable-kvm +GIT commit: d33ea50a958b2e050d2b28e5f17e3b55e91c6d74 + +*** glibc detected *** /home/njh/src/qemu/i386-softmmu/qemu: free(): invalid pointer: 0x00000000025bd290 *** +======= Backtrace: ========= +/lib/libc.so.6(+0x71ad6)[0x7f15dfe0bad6] +/home/njh/src/qemu/i386-softmmu/qemu[0x492ff3] +/home/njh/src/qemu/i386-softmmu/qemu[0x494082] +/home/njh/src/qemu/i386-softmmu/qemu[0x49b38e] +/home/njh/src/qemu/i386-softmmu/qemu[0x49710a] +/home/njh/src/qemu/i386-softmmu/qemu[0x4947c7] +/home/njh/src/qemu/i386-softmmu/qemu[0x5181cc] +/home/njh/src/qemu/i386-softmmu/qemu[0x518c67] +/lib/libc.so.6(__libc_start_main+0xfd)[0x7f15dfdb8c4d] +/home/njh/src/qemu/i386-softmmu/qemu[0x407699] +======= Memory map: ======== +00400000-006a1000 r-xp 00000000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008a0000-008c4000 rw-p 002a0000 08:03 406539 /home/njh/src/qemu/i386-softmmu/qemu +008c4000-010ae000 rw-p 00000000 00:00 0 +010ae000-010af000 rwxp 00000000 00:00 0 +010af000-010c7000 rw-p 00000000 00:00 0 +023a8000-024ab000 rw-p 00000000 00:00 0 +024ab000-024bb000 rw-p 00000000 00:00 0 +024bb000-025d5000 rw-p 00000000 00:00 0 +40a6f000-42a6f000 rwxp 00000000 00:00 0 +7f15d292b000-7f15d2941000 r-xp 00000000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2941000-7f15d2b40000 ---p 00016000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b40000-7f15d2b41000 rw-p 00015000 08:03 131218 /lib/libgcc_s.so.1 +7f15d2b41000-7f15d2b46000 r-xp 00000000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2b46000-7f15d2d45000 ---p 00005000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d45000-7f15d2d46000 rw-p 00004000 08:03 43471 /usr/lib/libXfixes.so.3.1.0 +7f15d2d46000-7f15d2d4f000 r-xp 00000000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2d4f000-7f15d2f4f000 ---p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f4f000-7f15d2f50000 rw-p 00009000 08:03 45831 /usr/lib/libXcursor.so.1.0.2 +7f15d2f50000-7f15d2f9d000 rw-p 00000000 00:00 0 +7f15d3025000-7f15d319a000 r--p 00000000 08:03 298138 /usr/lib/locale/locale-archive +7f15d319a000-7f15d31a2000 r-xp 00000000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d31a2000-7f15d33a1000 ---p 00008000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a1000-7f15d33a2000 rw-p 00007000 08:03 41266 /usr/lib/libXrandr.so.2.2.0 +7f15d33a2000-7f15d33ab000 r-xp 00000000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d33ab000-7f15d35ab000 ---p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ab000-7f15d35ac000 rw-p 00009000 08:03 74608 /usr/lib/libXrender.so.1.3.0 +7f15d35ac000-7f15d35bd000 r-xp 00000000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d35bd000-7f15d37bd000 ---p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37bd000-7f15d37be000 rw-p 00011000 08:03 29479 /usr/lib/libXext.so.6.4.0 +7f15d37d2000-7f15d37d3000 ---p 00000000 00:00 0 +7f15d37d3000-7f15d3c36000 rw-p 00000000 00:00 0 +7f15d3c49000-7f15d3d63000 rw-s 00000000 00:04 2195492 /SYSV00000000 (deleted) +7f15d3d63000-7f15d3d64000 rw-p 00000000 00:00 0 +7f15d3d64000-7f15d4564000 rw-p 00000000 00:00 0 +7f15d4564000-7f15d4566000 rw-p 00000000 00:00 0 +7f15d4566000-7f15dc566000 rw-p 00000000 00:00 0 +7f15dc566000-7f15dc567000 rw-p 00000000 00:00 0 +7f15dc567000-7f15dc568000 ---p 00000000 00:00 0 +7f15dc568000-7f15de76a000 rw-p 00000000 00:00 0 +7f15de76a000-7f15de76f000 r-xp 00000000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de76f000-7f15de96e000 ---p 00005000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96e000-7f15de96f000 rw-p 00004000 08:03 47085 /usr/lib/libXdmcp.so.6.0.0 +7f15de96f000-7f15de971000 r-xp 00000000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15de971000-7f15deb71000 ---p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb71000-7f15deb72000 rw-p 00002000 08:03 68458 /usr/lib/libXau.so.6.0.0 +7f15deb72000-7f15deb91000 r-xp 00000000 08:03 134345 /lib/libx86.so.1 +7f15deb91000-7f15ded91000 ---p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded91000-7f15ded93000 rw-p 0001f000 08:03 134345 /lib/libx86.so.1 +7f15ded93000-7f15ded94000 rw-p 00000000 00:00 0 +7f15ded94000-7f15dedb0000 r-xp 00000000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15dedb0000-7f15defaf000 ---p 0001c000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defaf000-7f15defb0000 rw-p 0001b000 08:03 13392 /usr/lib/libxcb.so.1.1.0 +7f15defb0000-7f15deffd000 r-xp 00000000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15deffd000-7f15df1fc000 ---p 0004d000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df1fc000-7f15df205000 rw-p 0004c000 08:03 2979 /usr/lib/libvga.so.1.4.3 +7f15df205000-7f15df20e000 rw-p 00000000 00:00 0 +7f15df20e000-7f15df224000 r-xp 00000000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df224000-7f15df423000 ---p 00016000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df423000-7f15df425000 rw-p 00015000 08:03 12136 /usr/lib/libdirect-1.2.so.9.0.1 +7f15df425000-7f15df42e000 r-xp 00000000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df42e000-7f15df62e000 ---p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62e000-7f15df62f000 rw-p 00009000 08:03 11944 /usr/lib/libfusion-1.2.so.9.0.1 +7f15df62f000-7f15df6ae000 r-xp 00000000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df6ae000-7f15df8ad000 ---p 0007f000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8ad000-7f15df8b1000 rw-p 0007e000 08:03 11998 /usr/lib/libdirectfb-1.2.so.9.0.1 +7f15df8b1000-7f15df98f000 r-xp 00000000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15df98f000-7f15dfb8e000 ---p 000de000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb8e000-7f15dfb96000 rw-p 000dd000 08:03 92358 /usr/lib/libasound.so.2.0.0 +7f15dfb96000-7f15dfb98000 r-xp 00000000 08:03 163705 /lib/libdl-2.11.2.so +7f15dfb98000-7f15dfd98000 ---p 00002000 08:03 163705 /lib/libdl-2.11.2.so + +GDB output: + +Thread 3 (Thread 3756): +#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 +#1 0x00007f15e182a0e9 in _L_lock_953 () from /lib/libpthread.so.0 +#2 0x00007f15e1829f0b in __pthread_mutex_lock (mutex=0x10690c0) at pthread_mutex_lock.c:61 +#3 0x00000000004914f9 in qemu_mutex_lock (mutex=0x10690c0) at qemu-thread.c:50 +#4 0x0000000000408c4c in qemu_mutex_lock_iothread () at /home/njh/src/qemu/cpus.c:737 +#5 0x000000000041af8e in kvm_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/kvm-all.c:878 +#6 0x00000000004a7885 in cpu_x86_exec (env1=<value optimized out>) at /home/njh/src/qemu/cpu-exec.c:338 +#7 0x00000000004086e8 in qemu_cpu_exec (env=0x23e3c40) at /home/njh/src/qemu/cpus.c:896 +#8 0x00000000004099e4 in kvm_cpu_thread_fn (arg=<value optimized out>) at /home/njh/src/qemu/cpus.c:613 +#9 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#10 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#11 0x0000000000000000 in ?? () + +Thread 2 (Thread 3757): +#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:211 +#1 0x000000000042ca0b in cond_timedwait (unused=<value optimized out>) at posix-aio-compat.c:104 +#2 aio_thread (unused=<value optimized out>) at posix-aio-compat.c:325 +#3 0x00007f15e18278ba in start_thread (arg=<value optimized out>) at pthread_create.c:300 +#4 0x00007f15dfe6902d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 +#5 0x0000000000000000 in ?? () +Current language: auto +The current source language is "auto; currently asm". + +Thread 1 (Thread 3755): +#0 0x00007f15dfdcc165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 +#1 0x00007f15dfdcef70 in *__GI_abort () at abort.c:92 +#2 0x00007f15dfe0227b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 +#3 0x00007f15dfe0bad6 in malloc_printerr (action=3, str=0x7f15dfebfb75 "free(): invalid pointer", ptr=<value optimized out>) at malloc.c:6267 +#4 0x0000000000492ff3 in if_start (slirp=0x23aa400) at slirp/if.c:205 +#5 0x0000000000494082 in ip_output (so=<value optimized out>, m0=0x25d3ff0) at slirp/ip_output.c:160 +#6 0x000000000049b38e in udp_output (so=0xeab, m=0xeab, addr=<value optimized out>) at slirp/udp.c:299 +#7 0x000000000049710a in sorecvfrom (so=0x2529380) at slirp/socket.c:527 +#8 0x00000000004947c7 in slirp_select_poll (readfds=0x7fff99a79390, writefds=<value optimized out>, xfds=0x7fff99a79290, select_error=<value optimized out>) + at slirp/slirp.c:542 +#9 0x00000000005181cc in main_loop_wait (nonblocking=<value optimized out>) at /home/njh/src/qemu/vl.c:1266 +#10 0x0000000000518c67 in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:1309 +#11 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /home/njh/src/qemu/vl.c:2999 + +I assume this problem has been fixed nowadays ... or can you still somehow reproduce it with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/688 b/results/classifier/118/review/688 new file mode 100644 index 000000000..ed63d143f --- /dev/null +++ b/results/classifier/118/review/688 @@ -0,0 +1,107 @@ +mistranslation: 0.881 +graphic: 0.863 +virtual: 0.857 +performance: 0.801 +architecture: 0.755 +semantic: 0.755 +files: 0.720 +user-level: 0.666 +device: 0.645 +PID: 0.581 +permissions: 0.512 +assembly: 0.489 +debug: 0.468 +register: 0.449 +kernel: 0.437 +hypervisor: 0.431 +VMM: 0.431 +vnc: 0.413 +boot: 0.398 +network: 0.397 +risc-v: 0.344 +arm: 0.323 +socket: 0.311 +x86: 0.271 +ppc: 0.261 +peripherals: 0.259 +TCG: 0.250 +KVM: 0.230 +i386: 0.208 +-------------------- +virtual: 0.991 +user-level: 0.763 +files: 0.588 +hypervisor: 0.236 +debug: 0.057 +TCG: 0.037 +register: 0.026 +PID: 0.014 +x86: 0.012 +semantic: 0.008 +VMM: 0.008 +kernel: 0.008 +device: 0.007 +vnc: 0.005 +socket: 0.005 +performance: 0.004 +risc-v: 0.003 +peripherals: 0.003 +assembly: 0.003 +KVM: 0.002 +graphic: 0.002 +network: 0.002 +architecture: 0.002 +boot: 0.001 +permissions: 0.001 +i386: 0.001 +ppc: 0.001 +arm: 0.000 +mistranslation: 0.000 + +Shrinking an image with qemu-img does not reduce image file size +Description of problem: +I have a macOS 10.9 VM using a qcow2 image that was 151GB. The image was originally converted from a VMware image with: +``` +qemu-img convert macOS-10.9.vmdk -O qcow2 -o preallocation=falloc macOS-10.9.qcow2 +``` +This resulted in `macOS-10.9.qcow2` being 151GB big: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +After reducing the filesystem size from within macOS to 25GB with DiskUtil, I shut down the VM and resized the image to 30GB with: +``` +qemu-img resize -f qcow2 --shrink macOS-10.9.qcow2 30G +``` +This succeeded. However, the file still consumes 151GB of space: +``` +$ du -h macOS-10.9.qcow2 +151G macOS-10.9.qcow2 +``` +Even though `qemu-img info` shows: +``` +$ qemu-img info macOS-10.9.qcow2 +image: macOS-10.9.qcow2 +file format: qcow2 +virtual size: 30 GiB (32212254720 bytes) +disk size: 30 GiB +cluster_size: 65536 +Format specific information: + compat: 1.1 + compression type: zlib + lazy refcounts: false + refcount bits: 16 + corrupt: false + extended l2: false +``` +The size inside the VM is also reported as being 30GB. + +The whole point of resizing that image was to free up disk space on the host. But this doesn't seem to be happening. + +My filesystem is ext4. +Steps to reproduce: +1. Create a vmdk image with `qemu-img create -f vmdk test.vmdk 5G` +2. Convert the vmdk image to qcow2 with `qemu-img convert test.vmdk -O qcow2 -o preallocation=falloc test.qcow2` +3. Shrink the new image with `qemu-img resize -f qcow2 --shrink test.qcow2 3G` + +The resulting `test.qcow2` file should be 3GB, but it's not. It's 5GB. diff --git a/results/classifier/118/review/690 b/results/classifier/118/review/690 new file mode 100644 index 000000000..2f8cb99a4 --- /dev/null +++ b/results/classifier/118/review/690 @@ -0,0 +1,79 @@ +architecture: 0.979 +x86: 0.946 +arm: 0.926 +device: 0.851 +kernel: 0.849 +graphic: 0.838 +user-level: 0.824 +performance: 0.774 +files: 0.767 +virtual: 0.734 +semantic: 0.720 +debug: 0.704 +VMM: 0.684 +register: 0.675 +hypervisor: 0.652 +permissions: 0.646 +PID: 0.632 +risc-v: 0.627 +vnc: 0.621 +network: 0.605 +socket: 0.603 +ppc: 0.596 +TCG: 0.530 +boot: 0.521 +peripherals: 0.490 +mistranslation: 0.469 +assembly: 0.172 +KVM: 0.086 +i386: 0.011 +-------------------- +arm: 0.908 +TCG: 0.352 +debug: 0.169 +virtual: 0.135 +hypervisor: 0.129 +files: 0.078 +register: 0.071 +user-level: 0.059 +performance: 0.022 +PID: 0.019 +network: 0.016 +kernel: 0.015 +device: 0.009 +semantic: 0.008 +socket: 0.008 +architecture: 0.007 +permissions: 0.004 +VMM: 0.004 +boot: 0.004 +assembly: 0.004 +peripherals: 0.002 +x86: 0.002 +ppc: 0.001 +graphic: 0.001 +vnc: 0.001 +KVM: 0.001 +risc-v: 0.001 +i386: 0.001 +mistranslation: 0.000 + +32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error) +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago. + +Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters. + +The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value: +``` +[0 ... 53248] - No error at all +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted +``` +Steps to reproduce: +1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz) +2. `$ make # will build the docker container` +3. `$ make run # will enter the container` +4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh` +Additional information: +A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748 diff --git a/results/classifier/118/review/691424 b/results/classifier/118/review/691424 new file mode 100644 index 000000000..05295779b --- /dev/null +++ b/results/classifier/118/review/691424 @@ -0,0 +1,148 @@ +semantic: 0.906 +debug: 0.892 +register: 0.883 +virtual: 0.876 +performance: 0.871 +boot: 0.871 +network: 0.870 +permissions: 0.868 +assembly: 0.863 +architecture: 0.859 +device: 0.859 +mistranslation: 0.854 +graphic: 0.853 +peripherals: 0.850 +socket: 0.836 +user-level: 0.822 +PID: 0.818 +kernel: 0.803 +arm: 0.796 +hypervisor: 0.785 +ppc: 0.772 +vnc: 0.768 +files: 0.758 +KVM: 0.750 +risc-v: 0.747 +VMM: 0.738 +TCG: 0.677 +x86: 0.659 +i386: 0.626 +-------------------- +debug: 0.517 +virtual: 0.066 +files: 0.037 +KVM: 0.034 +hypervisor: 0.021 +user-level: 0.011 +TCG: 0.010 +i386: 0.009 +x86: 0.008 +vnc: 0.008 +graphic: 0.008 +semantic: 0.003 +network: 0.003 +arm: 0.002 +PID: 0.002 +kernel: 0.002 +device: 0.002 +boot: 0.001 +performance: 0.001 +VMM: 0.001 +architecture: 0.001 +assembly: 0.001 +ppc: 0.001 +permissions: 0.001 +risc-v: 0.001 +register: 0.001 +peripherals: 0.001 +socket: 0.001 +mistranslation: 0.001 + +qemu/kvm SDL over ssh -X broken + +qemu/kvm by default uses SDL to render the output of its emulated VGA graphics. +This is broken over ssh -X since quite a while. +The only workaround I know, is to use qemu -vnc :0 +and connect using vncviewer + + +How To Reproduce: +1. zypper in qemu +2. ssh -X localhost qemu -cdrom ANYISOFILE + +Actual Results: +qemu hangs in an endless loop on the BIOS display screen + +Expected Results: +should boot up the iso as 0.10 versions did + +Reproducible: Always + + +this is what broke it: +$ git bisect bad +c18a2c360e3100bbd71162cf922dcd8c429a8b71 is first bad commit +commit c18a2c360e3100bbd71162cf922dcd8c429a8b71 +Author: Stefano Stabellini <email address hidden> +Date: Wed Jun 24 11:58:25 2009 +0100 + + sdl zooming + + Hi all, + this patch implements zooming capabilities for the sdl interface. + A new sdl_zoom_blit function is added that is able to scale and blit a + portion of a surface into another. + This way we can enable SDL_RESIZABLE and have a real_screen surface with + a different size than the guest surface and let sdl_zoom_blit take care + of the problem. + + Signed-off-by: Stefano Stabellini <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +:100644 100644 a06c9bfc22cc6de1c6e5e9068d6bf59d89613767 f8dc5065dd27010bfdbb6bcfb0c6e3af25024cdb M Makefile +:100644 100644 417217582363a87ee67e746ba798e285a64b6cdc 35183399f65de6f50f3baa4767ab7d4d11d45bca M console.h +:100644 100644 178b5532b8d9dd2194a8662fbfdcd49b4bc04222 d81399e51276e1c97fa1f7272ef16ea4c312b51b M sdl.c +:000000 100644 0000000000000000000000000000000000000000 56d3604fc3d79e4cc4622be8437c78bf70075da3 A sdl_zoom.c +:000000 100644 0000000000000000000000000000000000000000 33dc63408b43a37fd6b1acde3fa62b1a51315e75 A sdl_zoom.h +:000000 100644 0000000000000000000000000000000000000000 64bbca849bd3af678c2259b4d8cc0e48c6a6b43c A sdl_zoom_template.h + + +This problem occurs on both Debian and openSUSE. + +One possible way to get X11-forwarding back on qemu master is to disable zoom by this patch. + +But I do not know why the do_sdl_resize function should be problematic. +There is probably a better solution. + +Hi, + +I tried this with a current (git) build, and I'm not able to reproduce it. + +I do see a problem with a bad initial SDL window size (its much too small) on a remote machine over a moderate-level network (wireless LAN). I don't see that when ssh-ing to localhost (even though both hosts are basically the same). + +I do see differences between current (git) qemu and the 0.12.5 version. Current git boots the ISO, but doesn't appear to get to the login screen. + +I'm not sure what the differences between our configurations are. I have SDL 1.2.14-6ubuntu3 + +Still investigation. + +Brad + + + +I now found that it depends on my client side. The bug happens when I ssh -XC from my netbook with 1024x600(intel) to a server, but when I ssh -XC to the same server from my laptop with 1024x768(fbdev), then it works. +So might be that the scaling code that made the difference in my bisecting, is only used for small screens. + +I can confirm this: + +My client: + +Ubuntu 12.04 LTS via ssh -X with Gnome - Terminal 3.4.1.1 and compiz enabled +3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:29:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + +Can you still reproduce this issue with the latest version of QEMU, with the latest version of SDL? + +It seems to be working now with current versions, so has probably been fixed somewhere. + +OK, thanks a lot for testing it again! + diff --git a/results/classifier/118/review/692 b/results/classifier/118/review/692 new file mode 100644 index 000000000..0b00a5bb4 --- /dev/null +++ b/results/classifier/118/review/692 @@ -0,0 +1,61 @@ +mistranslation: 0.887 +device: 0.724 +network: 0.636 +kernel: 0.624 +performance: 0.466 +arm: 0.466 +semantic: 0.441 +architecture: 0.418 +VMM: 0.378 +i386: 0.294 +KVM: 0.292 +TCG: 0.288 +ppc: 0.280 +boot: 0.276 +vnc: 0.245 +assembly: 0.234 +x86: 0.233 +graphic: 0.230 +virtual: 0.207 +files: 0.203 +hypervisor: 0.194 +risc-v: 0.177 +socket: 0.171 +peripherals: 0.164 +user-level: 0.139 +PID: 0.137 +debug: 0.097 +register: 0.069 +permissions: 0.066 +-------------------- +user-level: 0.390 +kernel: 0.344 +files: 0.257 +semantic: 0.154 +PID: 0.095 +debug: 0.070 +virtual: 0.070 +assembly: 0.065 +x86: 0.046 +TCG: 0.039 +VMM: 0.029 +KVM: 0.025 +device: 0.020 +performance: 0.016 +arm: 0.016 +ppc: 0.012 +risc-v: 0.011 +hypervisor: 0.011 +socket: 0.011 +architecture: 0.011 +peripherals: 0.011 +boot: 0.009 +i386: 0.007 +network: 0.005 +vnc: 0.003 +graphic: 0.003 +permissions: 0.003 +mistranslation: 0.002 +register: 0.001 + +remove_fd_in_watch does not call g_source_unref diff --git a/results/classifier/118/review/701 b/results/classifier/118/review/701 new file mode 100644 index 000000000..1b994ca90 --- /dev/null +++ b/results/classifier/118/review/701 @@ -0,0 +1,61 @@ +user-level: 0.807 +device: 0.705 +PID: 0.564 +arm: 0.537 +architecture: 0.472 +TCG: 0.425 +semantic: 0.418 +permissions: 0.405 +performance: 0.366 +mistranslation: 0.366 +boot: 0.304 +virtual: 0.304 +register: 0.286 +ppc: 0.278 +network: 0.257 +risc-v: 0.254 +files: 0.212 +VMM: 0.206 +graphic: 0.204 +vnc: 0.176 +debug: 0.139 +kernel: 0.089 +socket: 0.042 +KVM: 0.042 +assembly: 0.033 +peripherals: 0.023 +i386: 0.021 +hypervisor: 0.007 +x86: 0.003 +-------------------- +network: 0.705 +virtual: 0.400 +user-level: 0.136 +kernel: 0.050 +files: 0.038 +debug: 0.027 +TCG: 0.019 +x86: 0.018 +semantic: 0.013 +VMM: 0.005 +peripherals: 0.005 +performance: 0.004 +i386: 0.004 +boot: 0.003 +ppc: 0.002 +device: 0.002 +graphic: 0.002 +PID: 0.002 +KVM: 0.002 +risc-v: 0.001 +register: 0.001 +architecture: 0.001 +permissions: 0.001 +socket: 0.001 +assembly: 0.001 +vnc: 0.000 +hypervisor: 0.000 +arm: 0.000 +mistranslation: 0.000 + +Setup a gitlab shared runner for linux-user testing diff --git a/results/classifier/118/review/710 b/results/classifier/118/review/710 new file mode 100644 index 000000000..a2550c7c9 --- /dev/null +++ b/results/classifier/118/review/710 @@ -0,0 +1,61 @@ +assembly: 0.819 +architecture: 0.767 +device: 0.709 +kernel: 0.531 +performance: 0.514 +graphic: 0.448 +hypervisor: 0.416 +debug: 0.393 +peripherals: 0.351 +network: 0.319 +files: 0.295 +register: 0.286 +x86: 0.253 +mistranslation: 0.238 +semantic: 0.205 +virtual: 0.150 +KVM: 0.139 +user-level: 0.118 +boot: 0.105 +VMM: 0.104 +socket: 0.100 +arm: 0.099 +permissions: 0.076 +i386: 0.029 +ppc: 0.026 +vnc: 0.024 +TCG: 0.022 +risc-v: 0.018 +PID: 0.016 +-------------------- +debug: 0.672 +assembly: 0.567 +boot: 0.501 +TCG: 0.243 +kernel: 0.177 +device: 0.148 +virtual: 0.050 +performance: 0.047 +register: 0.043 +files: 0.037 +KVM: 0.029 +user-level: 0.024 +PID: 0.024 +VMM: 0.019 +semantic: 0.014 +peripherals: 0.009 +architecture: 0.005 +arm: 0.004 +risc-v: 0.004 +hypervisor: 0.003 +socket: 0.002 +graphic: 0.002 +permissions: 0.001 +network: 0.001 +vnc: 0.001 +ppc: 0.001 +mistranslation: 0.001 +x86: 0.000 +i386: 0.000 + +maybe-uninitialized warning building target/m68k/ with -O3 diff --git a/results/classifier/118/review/713 b/results/classifier/118/review/713 new file mode 100644 index 000000000..e96584f9a --- /dev/null +++ b/results/classifier/118/review/713 @@ -0,0 +1,61 @@ +mistranslation: 0.984 +semantic: 0.680 +peripherals: 0.462 +graphic: 0.393 +performance: 0.267 +device: 0.258 +VMM: 0.167 +kernel: 0.159 +user-level: 0.153 +ppc: 0.152 +arm: 0.126 +vnc: 0.104 +i386: 0.101 +risc-v: 0.095 +socket: 0.093 +TCG: 0.083 +permissions: 0.082 +network: 0.068 +PID: 0.066 +register: 0.065 +virtual: 0.048 +architecture: 0.046 +hypervisor: 0.045 +KVM: 0.038 +boot: 0.038 +files: 0.036 +assembly: 0.035 +x86: 0.030 +debug: 0.016 +-------------------- +files: 0.685 +virtual: 0.431 +kernel: 0.146 +semantic: 0.039 +debug: 0.035 +device: 0.031 +network: 0.027 +user-level: 0.013 +performance: 0.009 +assembly: 0.009 +boot: 0.005 +peripherals: 0.005 +i386: 0.004 +register: 0.004 +PID: 0.004 +architecture: 0.003 +VMM: 0.002 +socket: 0.002 +TCG: 0.002 +mistranslation: 0.002 +x86: 0.002 +permissions: 0.002 +hypervisor: 0.001 +arm: 0.001 +ppc: 0.001 +KVM: 0.001 +vnc: 0.001 +risc-v: 0.001 +graphic: 0.001 + +Missing safe-syscall.inc.S for mips diff --git a/results/classifier/118/review/72 b/results/classifier/118/review/72 new file mode 100644 index 000000000..19c8ab276 --- /dev/null +++ b/results/classifier/118/review/72 @@ -0,0 +1,61 @@ +mistranslation: 0.857 +virtual: 0.779 +graphic: 0.769 +performance: 0.640 +VMM: 0.577 +semantic: 0.552 +peripherals: 0.529 +vnc: 0.481 +ppc: 0.453 +device: 0.422 +architecture: 0.381 +risc-v: 0.380 +TCG: 0.372 +debug: 0.351 +PID: 0.275 +user-level: 0.263 +KVM: 0.238 +register: 0.232 +permissions: 0.230 +assembly: 0.189 +i386: 0.093 +network: 0.064 +x86: 0.062 +boot: 0.062 +hypervisor: 0.045 +arm: 0.041 +files: 0.016 +kernel: 0.015 +socket: 0.009 +-------------------- +peripherals: 0.976 +user-level: 0.801 +virtual: 0.779 +i386: 0.070 +files: 0.049 +x86: 0.048 +VMM: 0.037 +graphic: 0.027 +device: 0.020 +debug: 0.016 +architecture: 0.013 +semantic: 0.012 +performance: 0.011 +assembly: 0.010 +network: 0.008 +KVM: 0.007 +ppc: 0.005 +vnc: 0.005 +kernel: 0.005 +TCG: 0.005 +risc-v: 0.005 +PID: 0.002 +register: 0.002 +socket: 0.002 +hypervisor: 0.002 +boot: 0.001 +mistranslation: 0.001 +arm: 0.000 +permissions: 0.000 + +mouse offset or invisible wall 2.11.0-3 diff --git a/results/classifier/118/review/729 b/results/classifier/118/review/729 new file mode 100644 index 000000000..9aac23711 --- /dev/null +++ b/results/classifier/118/review/729 @@ -0,0 +1,94 @@ +ppc: 0.853 +semantic: 0.823 +arm: 0.802 +graphic: 0.783 +architecture: 0.694 +user-level: 0.638 +vnc: 0.625 +device: 0.600 +risc-v: 0.586 +debug: 0.572 +mistranslation: 0.561 +performance: 0.511 +permissions: 0.481 +assembly: 0.417 +kernel: 0.407 +socket: 0.387 +VMM: 0.387 +network: 0.379 +PID: 0.359 +virtual: 0.359 +files: 0.306 +TCG: 0.306 +i386: 0.300 +x86: 0.291 +boot: 0.290 +hypervisor: 0.262 +KVM: 0.260 +peripherals: 0.244 +register: 0.189 +-------------------- +arm: 0.948 +user-level: 0.725 +TCG: 0.287 +files: 0.069 +debug: 0.058 +virtual: 0.046 +semantic: 0.016 +PID: 0.015 +register: 0.014 +device: 0.009 +architecture: 0.007 +boot: 0.003 +performance: 0.002 +socket: 0.002 +VMM: 0.002 +peripherals: 0.002 +network: 0.002 +graphic: 0.001 +KVM: 0.001 +assembly: 0.001 +permissions: 0.001 +risc-v: 0.001 +hypervisor: 0.001 +vnc: 0.001 +kernel: 0.001 +mistranslation: 0.000 +ppc: 0.000 +x86: 0.000 +i386: 0.000 + +Environment variables are not passed with user-space semihosting +Description of problem: +Environment variables are not passed to the emulated process, either inherited (as I might expect it to work in user-space?) or by specifying the values through the QEMU command-line. Note that setting the environment variable from within the app before calling `getenv` does work, so it isn't just a case of some system no-ops for the platform. +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> +#include <cstdlib> + +int main(int argc, char* argv[]) { + char* env = std::getenv("TEST"); + if (env) + std::cout << "Env TEST: " << env << "\n"; + else + std::cout << "Env TEST not set.\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 -E TEST=val123 ./a.out +Env TEST not set. +``` diff --git a/results/classifier/118/review/746 b/results/classifier/118/review/746 new file mode 100644 index 000000000..b3b542657 --- /dev/null +++ b/results/classifier/118/review/746 @@ -0,0 +1,61 @@ +mistranslation: 0.986 +files: 0.890 +semantic: 0.795 +VMM: 0.771 +vnc: 0.765 +device: 0.762 +network: 0.732 +register: 0.711 +ppc: 0.705 +risc-v: 0.701 +TCG: 0.694 +debug: 0.692 +socket: 0.686 +arm: 0.665 +kernel: 0.663 +architecture: 0.638 +graphic: 0.622 +hypervisor: 0.578 +permissions: 0.576 +boot: 0.551 +KVM: 0.536 +performance: 0.534 +peripherals: 0.501 +user-level: 0.481 +virtual: 0.466 +i386: 0.454 +x86: 0.440 +assembly: 0.361 +PID: 0.264 +-------------------- +files: 0.864 +TCG: 0.084 +register: 0.038 +virtual: 0.033 +VMM: 0.015 +assembly: 0.014 +semantic: 0.013 +kernel: 0.011 +risc-v: 0.011 +debug: 0.008 +KVM: 0.007 +hypervisor: 0.007 +arm: 0.006 +boot: 0.005 +mistranslation: 0.005 +user-level: 0.005 +x86: 0.004 +ppc: 0.004 +vnc: 0.004 +network: 0.004 +i386: 0.004 +socket: 0.003 +device: 0.003 +PID: 0.003 +peripherals: 0.001 +architecture: 0.001 +performance: 0.001 +permissions: 0.000 +graphic: 0.000 + +Current file VERSION of tag 6.2.0-rc2 contains 6.2.92, not 6.1.92 diff --git a/results/classifier/118/review/750 b/results/classifier/118/review/750 new file mode 100644 index 000000000..12b36b18f --- /dev/null +++ b/results/classifier/118/review/750 @@ -0,0 +1,93 @@ +architecture: 0.923 +graphic: 0.887 +network: 0.874 +semantic: 0.865 +vnc: 0.858 +ppc: 0.832 +files: 0.827 +device: 0.816 +user-level: 0.815 +arm: 0.778 +debug: 0.776 +socket: 0.737 +risc-v: 0.703 +PID: 0.688 +x86: 0.676 +permissions: 0.635 +virtual: 0.630 +mistranslation: 0.616 +TCG: 0.606 +VMM: 0.574 +register: 0.571 +performance: 0.560 +boot: 0.528 +kernel: 0.514 +peripherals: 0.486 +hypervisor: 0.439 +i386: 0.286 +assembly: 0.262 +KVM: 0.113 +-------------------- +debug: 0.908 +virtual: 0.712 +user-level: 0.310 +files: 0.297 +x86: 0.274 +kernel: 0.193 +architecture: 0.160 +performance: 0.117 +PID: 0.088 +TCG: 0.084 +hypervisor: 0.038 +register: 0.024 +device: 0.022 +network: 0.020 +semantic: 0.011 +vnc: 0.007 +socket: 0.007 +boot: 0.006 +graphic: 0.003 +assembly: 0.003 +VMM: 0.003 +peripherals: 0.003 +i386: 0.002 +KVM: 0.001 +permissions: 0.001 +arm: 0.001 +ppc: 0.001 +risc-v: 0.001 +mistranslation: 0.000 + +/proc/cpuinfo doesn't present guest cpuinfo for most architectures (including M1 Macs) +Description of problem: +I tried to start Blender inside an amd docker container, emulated on M1 Mac, running noVNC to access the the GUI via Chrome. +From Blender versions 2.8 and higher I get the following error message: + +``` + ArchError: Could not find 'cpu MHz' in /proc/cpuinfo + Function: Arch_InitTickTimer + File: /home/sybren/buildbot-builder/linux_glibc217_x86_64_cmake/build_deps/deps/build/usd/src/external_usd/pxr/base/arch/timing.cpp + Line: 133 +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +``` + +I posted the problem to Blender [here](https://developer.blender.org/T92956) as well as to docker [here](https://github.com/docker/for-mac/issues/6047). +Steps to reproduce: +You need: +- ✅ M1 Mac +- ✅ Docker Desktop 4.1.1 (69879) + +Setup the Container: + +1. Unzip the attached file +2. In a terminal go to the unzipped folder +3. run `source build-and-launch.sh` to build the image and spin up a container +4. open a browser and go to [http://localhost:6901](http://localhost:6901) +5. login using password `pass` +6. see the README.txt on the Desktop you just logged into +7. == Follow the README instructions == + + + +[blender-bug-report-202111091146.zip](/uploads/340ada45a9ee0585cfc0cdfcc1932fb4/blender-bug-report-202111091146.zip) diff --git a/results/classifier/118/review/757702 b/results/classifier/118/review/757702 new file mode 100644 index 000000000..5d5092da1 --- /dev/null +++ b/results/classifier/118/review/757702 @@ -0,0 +1,901 @@ +ppc: 0.863 +risc-v: 0.835 +semantic: 0.809 +peripherals: 0.805 +arm: 0.790 +architecture: 0.790 +socket: 0.773 +virtual: 0.773 +mistranslation: 0.767 +hypervisor: 0.765 +debug: 0.763 +permissions: 0.760 +user-level: 0.756 +VMM: 0.738 +performance: 0.735 +vnc: 0.731 +register: 0.719 +network: 0.717 +device: 0.711 +PID: 0.707 +kernel: 0.706 +KVM: 0.703 +assembly: 0.701 +graphic: 0.695 +boot: 0.649 +files: 0.619 +x86: 0.585 +TCG: 0.536 +i386: 0.290 +-------------------- +arm: 0.964 +assembly: 0.451 +architecture: 0.381 +debug: 0.102 +semantic: 0.040 +kernel: 0.039 +virtual: 0.028 +TCG: 0.026 +files: 0.019 +PID: 0.011 +hypervisor: 0.010 +register: 0.009 +device: 0.006 +VMM: 0.004 +boot: 0.003 +socket: 0.002 +network: 0.002 +user-level: 0.002 +performance: 0.002 +vnc: 0.002 +KVM: 0.001 +risc-v: 0.001 +peripherals: 0.001 +graphic: 0.001 +permissions: 0.001 +mistranslation: 0.000 +ppc: 0.000 +i386: 0.000 +x86: 0.000 + +ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it + +ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). The undefined instruction exception executes at <exception_base> + 0x4, where <exception_base> can be 0x0 or 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, seems like this is a new bug. As as example, if we try to execute value "0xec019800" in qemu 0.14.0 then it should cause undefined exception at <exception_base>+0x4 since "0xec019800" is an undefined instruction. + +I can't reproduce this (either with current trunk or with qemu 0.14.0 release version). Also, if we were directing UNDEF exceptions to the SVC entry point I think it would cause fairly obvious breakage of Linux guests. + +I'm going to attach the test program I used to confirm that we are correctly directing the exception to the 0x4 vector: + +./arm-softmmu/qemu-system-arm -kernel ~/linaro/qemu-misc-tests/undef-exc.axf -semihosting +Starting test +In undef vector + +I'll also attach the binary, since it's only 2K and the source needs armcc to build. + +If you can provide a simple test program and qemu command line which demonstrates the behaviour you think is incorrect I can investigate further. + + + + + + +> ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions +>are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). + +PS: please don't use arbitrary UNDEF instruction patterns for this (the one you quoted is in the STC instruction space for example). There's an officially-defined "permanently UNDEF" space: + cond 0111 1111 xxxx xxxx xxxx 1111 xxxx +available for this purpose, which will mean you don't have to worry about newer versions of the architecture allocating the UNDEF patterns you were using. + + +Hi, + +You are right, I have deliberately used an instruction from a "permanently +UNDEF" space. I have used this instruction because thats this are the only +UNDEF instructions with maximum payload of 20 bits. + +Also, the instruction "0xec019800" does not belong to STC instruction space. +GNU object dump does not display it as undefined instruction due to internal +bug, but it is definitely an undefined instruction. +May be the undefined instructions from "permanently UNDEF" space are only +executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU +0.13.0. + +PFA, my test elf file. The UNDEF instruction that i have reported is +at location 0x100058 in this elf file. The execution of elf file starts from +0x100000. + +I have launched qemu with command: ./qemu-system-arm -s -S -M realview-pb-a8 +-serial stdio -kernel ../../../xvisor/tests/armv7/pb-a8/arm_test.elf +I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf +--eval-command="target remote localhost:1234" + +Please let me know if you are not able to reproduce the bug. + +--Anup + +On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell <email address hidden>wrote: + +> > ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions +> >are very useful for replacing sensitive non-priviledged instructions of +> guest operating systems (virtualization). +> +> PS: please don't use arbitrary UNDEF instruction patterns for this (the one +> you quoted is in the STC instruction space for example). There's an +> officially-defined "permanently UNDEF" space: +> cond 0111 1111 xxxx xxxx xxxx 1111 xxxx +> available for this purpose, which will mean you don't have to worry about +> newer versions of the architecture allocating the UNDEF patterns you were +> using. +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +Hi + +The correct command to launch qemu will be: ./qemu-system-arm -s -S -M +realview-pb-a8 -serial stdio -kernel arm_test.elf +Sorry, for mistake in previous mail. + +--Anup + +On Tue, Apr 12, 2011 at 3:48 PM, Anup Patel +<email address hidden>wrote: + +> Hi, +> +> You are right, I have deliberately used an instruction from a "permanently +> UNDEF" space. I have used this instruction because thats this are the only +> UNDEF instructions with maximum payload of 20 bits. +> +> Also, the instruction "0xec019800" does not belong to STC instruction +> space. GNU object dump does not display it as undefined instruction due to +> internal bug, but it is definitely an undefined instruction. +> May be the undefined instructions from "permanently UNDEF" space are only +> executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU +> 0.13.0. +> +> PFA, my test elf file. The UNDEF instruction that i have reported is +> at location 0x100058 in this elf file. The execution of elf file starts from +> 0x100000. +> +> I have launched qemu with command: ./qemu-system-arm -s -S -M +> realview-pb-a8 -serial stdio -kernel +> ../../../xvisor/tests/armv7/pb-a8/arm_test.elf +> I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf +> --eval-command="target remote localhost:1234" +> +> Please let me know if you are not able to reproduce the bug. +> +> --Anup +> +> On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell <email address hidden>wrote: +> +>> > ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions +>> >are very useful for replacing sensitive non-priviledged instructions of +>> guest operating systems (virtualization). +>> +>> PS: please don't use arbitrary UNDEF instruction patterns for this (the +>> one you quoted is in the STC instruction space for example). There's an +>> officially-defined "permanently UNDEF" space: +>> cond 0111 1111 xxxx xxxx xxxx 1111 xxxx +>> available for this purpose, which will mean you don't have to worry about +>> newer versions of the architecture allocating the UNDEF patterns you were +>> using. +>> +>> -- +>> You received this bug notification because you are a direct subscriber +>> of the bug. +>> https://bugs.launchpad.net/bugs/757702 +>> +>> Title: +>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions are very useful for replacing +>> sensitive non-priviledged instructions of guest operating systems +>> (virtualization). The undefined instruction exception executes at +>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>> seems like this is a new bug. As as example, if we try to execute +>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>> instruction. +>> +>> To unsubscribe from this bug, go to: +>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>> +> +> + + +> Also, the instruction "0xec019800" does not belong to STC instruction space. + +Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 imm:8 +For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in STC space. This is not "permanently UNDEF", it might be allocated to do something in future. + +> PFA, my test elf file. + +Thanks. Your test case appears to be broken in that it doesn't actually set up the vector table at address 0: +cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble ~/Desktop/arm_test.elf |less + +[...] +Disassembly of section .text: + +00100000 <_start_vect>: + 100000: e59ff018 ldr pc, [pc, #24] ; 100020 <__reset> + 100004: e59ff018 ldr pc, [pc, #24] ; 100024 <__undefined_instruction> + 100008: e59ff018 ldr pc, [pc, #24] ; 100028 <__software_interrupt> + 10000c: e59ff018 ldr pc, [pc, #24] ; 10002c <__prefetch_abort> + 100010: e59ff018 ldr pc, [pc, #24] ; 100030 <__data_abort> + 100014: e59ff018 ldr pc, [pc, #24] ; 100034 <__not_used> + 100018: e59ff018 ldr pc, [pc, #24] ; 100038 <__irq> + 10001c: e59ff018 ldr pc, [pc, #24] ; 10003c <__fiq> + +So what happens is: +0x00100000: e59ff018 ldr pc, [pc, #24] # qemu starts us at the ELF entry point +0x00100054: e3a08000 mov r8, #0 ; 0x0 +0x00100054: e3a08000 mov r8, #0 ; 0x0 +0x00100058: ec019800 stc 8, cr9, [r1], {0} # here's our UNDEF +0x00000004: 00000000 andeq r0, r0, r0 # jump to UNDEF vector at 0x4 as expected +...but since nothing was loaded at address 0 the code is all NOPs and we just execute through it... +0x00000008: 00000000 andeq r0, r0, r0 +0x0000000c: 00000000 andeq r0, r0, r0 +0x00000010: 00000000 andeq r0, r0, r0 +...etc... + +and eventually we fall into the actual image start at 0x100000, and we go round in a big loop. + +You can tell we're going to the correct vector if you ask gdb to put a breakpoint there with "break *0x4" -- we hit it after executing the undef. + + +Actually, the undefined instruction that I have used is documented as +undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a +reference manual: +1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions" +2. Refer "A8.6.188 STC, STC2" + +So you see one can easily get confused that this instruction belongs to STC +space. Actually speaking this UNDEF instruction spans not only in STC space +but also in LDC space. + +--Anup + +On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell <email address hidden>wrote: + +> > Also, the instruction "0xec019800" does not belong to STC instruction +> space. +> +> Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 +> imm:8 +> For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in +> STC space. This is not "permanently UNDEF", it might be allocated to do +> something in future. +> +> > PFA, my test elf file. +> +> Thanks. Your test case appears to be broken in that it doesn't actually set +> up the vector table at address 0: +> cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble +> ~/Desktop/arm_test.elf |less +> +> [...] +> Disassembly of section .text: +> +> 00100000 <_start_vect>: +> 100000: e59ff018 ldr pc, [pc, #24] ; 100020 <__reset> +> 100004: e59ff018 ldr pc, [pc, #24] ; 100024 +> <__undefined_instruction> +> 100008: e59ff018 ldr pc, [pc, #24] ; 100028 +> <__software_interrupt> +> 10000c: e59ff018 ldr pc, [pc, #24] ; 10002c +> <__prefetch_abort> +> 100010: e59ff018 ldr pc, [pc, #24] ; 100030 +> <__data_abort> +> 100014: e59ff018 ldr pc, [pc, #24] ; 100034 +> <__not_used> +> 100018: e59ff018 ldr pc, [pc, #24] ; 100038 <__irq> +> 10001c: e59ff018 ldr pc, [pc, #24] ; 10003c <__fiq> +> +> So what happens is: +> 0x00100000: e59ff018 ldr pc, [pc, #24] # qemu starts us at the ELF +> entry point +> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +> 0x00100058: ec019800 stc 8, cr9, [r1], {0} # here's our UNDEF +> 0x00000004: 00000000 andeq r0, r0, r0 # jump to UNDEF vector +> at 0x4 as expected +> ...but since nothing was loaded at address 0 the code is all NOPs and we +> just execute through it... +> 0x00000008: 00000000 andeq r0, r0, r0 +> 0x0000000c: 00000000 andeq r0, r0, r0 +> 0x00000010: 00000000 andeq r0, r0, r0 +> ...etc... +> +> and eventually we fall into the actual image start at 0x100000, and we +> go round in a big loop. +> +> You can tell we're going to the correct vector if you ask gdb to put a +> breakpoint there with "break *0x4" -- we hit it after executing the +> undef. +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +Also, in the test case hits 0x8 after encountering UNDEF instruction at +0x100058. +The test case is not broken it failed in initialization sequence itself. + +PS: I had download most recent version of QEMU 0.14.0 and build it my self. + +On Tue, Apr 12, 2011 at 4:33 PM, Anup Patel +<email address hidden>wrote: + +> Actually, the undefined instruction that I have used is documented as +> undefined at two places in "ARM Instruction Set Encoding" section of ARMv7a +> reference manual: +> 1. Refer "Table A5-22 Supervisor Call, and coprocessor instructions" +> 2. Refer "A8.6.188 STC, STC2" +> +> So you see one can easily get confused that this instruction belongs to STC +> space. Actually speaking this UNDEF instruction spans not only in STC space +> but also in LDC space. +> +> --Anup +> +> On Tue, Apr 12, 2011 at 4:19 PM, Peter Maydell <email address hidden>wrote: +> +>> > Also, the instruction "0xec019800" does not belong to STC instruction +>> space. +>> +>> Yes it does. STC encoding A1 is: cond:4 110 p u d w 0 rn:4 crd:4 coproc:4 +>> imm:8 +>> For STC the combination of P=0 U=0 D=0 W=0 is UNDEFINED, but it's still in +>> STC space. This is not "permanently UNDEF", it might be allocated to do +>> something in future. +>> +>> > PFA, my test elf file. +>> +>> Thanks. Your test case appears to be broken in that it doesn't actually +>> set up the vector table at address 0: +>> cam-vm-266:karmic:qemu-misc-tests$ objdump --disassemble +>> ~/Desktop/arm_test.elf |less +>> +>> [...] +>> Disassembly of section .text: +>> +>> 00100000 <_start_vect>: +>> 100000: e59ff018 ldr pc, [pc, #24] ; 100020 <__reset> +>> 100004: e59ff018 ldr pc, [pc, #24] ; 100024 +>> <__undefined_instruction> +>> 100008: e59ff018 ldr pc, [pc, #24] ; 100028 +>> <__software_interrupt> +>> 10000c: e59ff018 ldr pc, [pc, #24] ; 10002c +>> <__prefetch_abort> +>> 100010: e59ff018 ldr pc, [pc, #24] ; 100030 +>> <__data_abort> +>> 100014: e59ff018 ldr pc, [pc, #24] ; 100034 +>> <__not_used> +>> 100018: e59ff018 ldr pc, [pc, #24] ; 100038 <__irq> +>> 10001c: e59ff018 ldr pc, [pc, #24] ; 10003c <__fiq> +>> +>> So what happens is: +>> 0x00100000: e59ff018 ldr pc, [pc, #24] # qemu starts us at the +>> ELF entry point +>> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +>> 0x00100054: e3a08000 mov r8, #0 ; 0x0 +>> 0x00100058: ec019800 stc 8, cr9, [r1], {0} # here's our UNDEF +>> 0x00000004: 00000000 andeq r0, r0, r0 # jump to UNDEF +>> vector at 0x4 as expected +>> ...but since nothing was loaded at address 0 the code is all NOPs and we +>> just execute through it... +>> 0x00000008: 00000000 andeq r0, r0, r0 +>> 0x0000000c: 00000000 andeq r0, r0, r0 +>> 0x00000010: 00000000 andeq r0, r0, r0 +>> ...etc... +>> +>> and eventually we fall into the actual image start at 0x100000, and we +>> go round in a big loop. +>> +>> You can tell we're going to the correct vector if you ask gdb to put a +>> breakpoint there with "break *0x4" -- we hit it after executing the +>> undef. +>> +>> -- +>> You received this bug notification because you are a direct subscriber +>> of the bug. +>> https://bugs.launchpad.net/bugs/757702 +>> +>> Title: +>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions are very useful for replacing +>> sensitive non-priviledged instructions of guest operating systems +>> (virtualization). The undefined instruction exception executes at +>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>> seems like this is a new bug. As as example, if we try to execute +>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>> instruction. +>> +>> To unsubscribe from this bug, go to: +>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>> +> +> + + +Sorry, I didn't notice the footnote in table A5-22; I see what you mean now. It's still not permanently-UNDEF space though and you'd really be better off using that instead. In any case, qemu does properly UNDEF the instruction so this is a bit of a diversion. + + +> Also, in the test case hits 0x8 after encountering UNDEF instruction at 0x100058. + +So if you run qemu like this: +qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S + +and run arm-none-gnueabi-gdb with no arguments and in gdb type these commands: + +(gdb) target remote :1234 +Remote debugging using :1234 +0x00100000 in ?? () +(gdb) break *0x4 +Breakpoint 1 at 0x4 +(gdb) break *0x8 +Breakpoint 2 at 0x8 +(gdb) c +Continuing. + +...what does gdb do? +(For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I expect.) + + +I see 0x00000008 (). + +I am using qemu-0.14.0.tar.gz available for QEMU Downloads. + +--Anup + +On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <email address hidden>wrote: + +> > Also, in the test case hits 0x8 after encountering UNDEF instruction +> at 0x100058. +> +> So if you run qemu like this: +> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S +> +> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +> commands: +> +> (gdb) target remote :1234 +> Remote debugging using :1234 +> 0x00100000 in ?? () +> (gdb) break *0x4 +> Breakpoint 1 at 0x4 +> (gdb) break *0x8 +> Breakpoint 2 at 0x8 +> (gdb) c +> Continuing. +> +> ...what does gdb do? +> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I +> expect.) +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +Try this out one last time. I am sure you will be able to replicate the +problem. + +Run qemu like this: +qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S + +and run arm-none-gnueabi-gdb with no arguments and in gdb type these +commands: + +(gdb) target remote :1234 +Remote debugging using :1234 +0x00100000 in ?? () +(gdb) si +0x00100054 in ?? () +(gdb) si +0x00100054 in ?? () +(gdb) si +0x00000008 in ?? () + +(I expect it to jump to 0x00000004 after 0x00100054) + +--Anup + +On Tue, Apr 12, 2011 at 5:40 PM, Anup Patel +<email address hidden>wrote: + +> I see 0x00000008 (). +> +> I am using qemu-0.14.0.tar.gz available for QEMU Downloads. +> +> --Anup +> +> +> On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <email address hidden>wrote: +> +>> > Also, in the test case hits 0x8 after encountering UNDEF instruction +>> at 0x100058. +>> +>> So if you run qemu like this: +>> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S +>> +>> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +>> commands: +>> +>> (gdb) target remote :1234 +>> Remote debugging using :1234 +>> 0x00100000 in ?? () +>> (gdb) break *0x4 +>> Breakpoint 1 at 0x4 +>> (gdb) break *0x8 +>> Breakpoint 2 at 0x8 +>> (gdb) c +>> Continuing. +>> +>> ...what does gdb do? +>> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I +>> expect.) +>> +>> -- +>> You received this bug notification because you are a direct subscriber +>> of the bug. +>> https://bugs.launchpad.net/bugs/757702 +>> +>> Title: +>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> ARMv7a has lot of undefined instruction from its instruction opcode +>> space. This undefined instructions are very useful for replacing +>> sensitive non-priviledged instructions of guest operating systems +>> (virtualization). The undefined instruction exception executes at +>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>> seems like this is a new bug. As as example, if we try to execute +>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>> instruction. +>> +>> To unsubscribe from this bug, go to: +>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>> +> +> + + +Hi, + +Were you able to replicate the problem with the steps that I had mentioned ? +The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow +the execution flow using "si" command of GDB. +You will definitely hit the problem. + +--Anup + +On Tue, Apr 12, 2011 at 5:57 PM, Anup Patel +<email address hidden>wrote: + +> Try this out one last time. I am sure you will be able to replicate the +> problem. +> +> Run qemu like this: +> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s -S +> +> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +> commands: +> +> (gdb) target remote :1234 +> Remote debugging using :1234 +> 0x00100000 in ?? () +> (gdb) si +> 0x00100054 in ?? () +> (gdb) si +> 0x00100054 in ?? () +> (gdb) si +> 0x00000008 in ?? () +> +> (I expect it to jump to 0x00000004 after 0x00100054) +> +> --Anup +> +> On Tue, Apr 12, 2011 at 5:40 PM, Anup Patel <<email address hidden> +> > wrote: +> +>> I see 0x00000008 (). +>> +>> I am using qemu-0.14.0.tar.gz available for QEMU Downloads. +>> +>> --Anup +>> +>> +>> On Tue, Apr 12, 2011 at 5:12 PM, Peter Maydell <email address hidden>wrote: +>> +>>> > Also, in the test case hits 0x8 after encountering UNDEF instruction +>>> at 0x100058. +>>> +>>> So if you run qemu like this: +>>> qemu-system-arm -M realview-pb-a8 -serial stdio -kernel arm_test.elf -s +>>> -S +>>> +>>> and run arm-none-gnueabi-gdb with no arguments and in gdb type these +>>> commands: +>>> +>>> (gdb) target remote :1234 +>>> Remote debugging using :1234 +>>> 0x00100000 in ?? () +>>> (gdb) break *0x4 +>>> Breakpoint 1 at 0x4 +>>> (gdb) break *0x8 +>>> Breakpoint 2 at 0x8 +>>> (gdb) c +>>> Continuing. +>>> +>>> ...what does gdb do? +>>> (For me it says "Breakpoint 1, 0x00000004 in ?? ()" which is what I +>>> expect.) +>>> +>>> -- +>>> You received this bug notification because you are a direct subscriber +>>> of the bug. +>>> https://bugs.launchpad.net/bugs/757702 +>>> +>>> Title: +>>> Undefined instruction exception starts at offset 0x8 instead of 0x4 +>>> +>>> Status in QEMU: +>>> New +>>> +>>> Bug description: +>>> ARMv7a has lot of undefined instruction from its instruction opcode +>>> space. This undefined instructions are very useful for replacing +>>> sensitive non-priviledged instructions of guest operating systems +>>> (virtualization). The undefined instruction exception executes at +>>> <exception_base> + 0x4, where <exception_base> can be 0x0 or +>>> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +>>> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +>>> seems like this is a new bug. As as example, if we try to execute +>>> value "0xec019800" in qemu 0.14.0 then it should cause undefined +>>> exception at <exception_base>+0x4 since "0xec019800" is an undefined +>>> instruction. +>>> +>>> To unsubscribe from this bug, go to: +>>> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +>>> +>> +>> +> + + +> Were you able to replicate the problem with the steps that I had mentioned ? +> The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow +> the execution flow using "si" command of GDB. +> You will definitely hit the problem. + +Ah, I had to find a different gdb to reproduce this with (arm-none-eabi-gdb from the 2010.09 codesourcery toolchain). That gdb does single-step-insn by asking the target to single step, and you get the behaviour above. The gdb I was using does single-step-insn by setting breakpoints at where it thinks the next insn will be, which means that "si" on the UNDEF never returns because gdb has set a bp at 0x10005c which we of course never hit. With the codesourcery gdb I see 'si' having the behaviour you describe above. + +However: + +(gdb) target remote :1234 +Remote debugging using :1234 +0x00100000 in ?? () +(gdb) break *0x4 +Breakpoint 1 at 0x4 +(gdb) si +0x00100054 in ?? () +(gdb) si +0x00100058 in ?? () +(gdb) si + +Breakpoint 1, 0x00000004 in ?? () + +ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's just that the singlestep doesn't do what you expect: instead of stopping before we execute the instruction at the UNDEF vector, we first execute it and then stop afterwards [this sort of makes a twisted kind of sense if you think about it -- we never actually executed the UNDEF insn because we took the exception first, so single-step executes exactly one instruction which is the one at 0x4. However it's hopelessly confusing for the user so I'd consider it a bug.] + +Can you confirm that if you set the breakpoint as I do in the transcript above you see the same output? + +So I think that what is happening here is that misbehaviour by qemu's gdb interface is confusing you, rather than the actual qemu ARM implementation being wrong. + +If you revise your test program so that it installs some actual code into the vectors rather than leaving them all as NOPs I think this will be more obvious. + + +I think you are right. This seems to be more of a GDB issue. + +Any ways thanks for your support. + +--Anup + +On Wed, Apr 13, 2011 at 5:24 PM, Peter Maydell <email address hidden>wrote: + +> > Were you able to replicate the problem with the steps that I had +> mentioned ? +> > The key thing is is if you don't set breakpoint at 0x4 or 0x8 just follow +> > the execution flow using "si" command of GDB. +> > You will definitely hit the problem. +> +> Ah, I had to find a different gdb to reproduce this with (arm-none-eabi- +> gdb from the 2010.09 codesourcery toolchain). That gdb does single-step- +> insn by asking the target to single step, and you get the behaviour +> above. The gdb I was using does single-step-insn by setting breakpoints +> at where it thinks the next insn will be, which means that "si" on the +> UNDEF never returns because gdb has set a bp at 0x10005c which we of +> course never hit. With the codesourcery gdb I see 'si' having the +> behaviour you describe above. +> +> However: +> +> (gdb) target remote :1234 +> Remote debugging using :1234 +> 0x00100000 in ?? () +> (gdb) break *0x4 +> Breakpoint 1 at 0x4 +> (gdb) si +> 0x00100054 in ?? () +> (gdb) si +> 0x00100058 in ?? () +> (gdb) si +> +> Breakpoint 1, 0x00000004 in ?? () +> +> ie if we set an explicit breakpoint at 0x4 we do hit it. I think it's +> just that the singlestep doesn't do what you expect: instead of stopping +> before we execute the instruction at the UNDEF vector, we first execute +> it and then stop afterwards [this sort of makes a twisted kind of sense +> if you think about it -- we never actually executed the UNDEF insn +> because we took the exception first, so single-step executes exactly one +> instruction which is the one at 0x4. However it's hopelessly confusing +> for the user so I'd consider it a bug.] +> +> Can you confirm that if you set the breakpoint as I do in the transcript +> above you see the same output? +> +> So I think that what is happening here is that misbehaviour by qemu's +> gdb interface is confusing you, rather than the actual qemu ARM +> implementation being wrong. +> +> If you revise your test program so that it installs some actual code +> into the vectors rather than leaving them all as NOPs I think this will +> be more obvious. +> +> -- +> You received this bug notification because you are a direct subscriber +> of the bug. +> https://bugs.launchpad.net/bugs/757702 +> +> Title: +> Undefined instruction exception starts at offset 0x8 instead of 0x4 +> +> Status in QEMU: +> New +> +> Bug description: +> ARMv7a has lot of undefined instruction from its instruction opcode +> space. This undefined instructions are very useful for replacing +> sensitive non-priviledged instructions of guest operating systems +> (virtualization). The undefined instruction exception executes at +> <exception_base> + 0x4, where <exception_base> can be 0x0 or +> 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at +> 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, +> seems like this is a new bug. As as example, if we try to execute +> value "0xec019800" in qemu 0.14.0 then it should cause undefined +> exception at <exception_base>+0x4 since "0xec019800" is an undefined +> instruction. +> +> To unsubscribe from this bug, go to: +> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe +> + + +> I think you are right. This seems to be more of a GDB issue. + +The debug stub is still part of QEMU, so let's not close this bug just yet :-) + + +Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + +This is still a bug, we shouldn't have let it expire. + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ba3c35d9c4026361fd3 + diff --git a/results/classifier/118/review/761469 b/results/classifier/118/review/761469 new file mode 100644 index 000000000..cdba1ed57 --- /dev/null +++ b/results/classifier/118/review/761469 @@ -0,0 +1,223 @@ +user-level: 0.906 +semantic: 0.887 +permissions: 0.886 +mistranslation: 0.881 +debug: 0.877 +graphic: 0.862 +register: 0.860 +hypervisor: 0.857 +virtual: 0.856 +assembly: 0.854 +device: 0.850 +boot: 0.849 +PID: 0.846 +vnc: 0.841 +peripherals: 0.841 +performance: 0.840 +VMM: 0.839 +network: 0.829 +arm: 0.826 +risc-v: 0.825 +architecture: 0.799 +ppc: 0.795 +KVM: 0.732 +files: 0.731 +TCG: 0.690 +socket: 0.660 +kernel: 0.626 +x86: 0.498 +i386: 0.486 +-------------------- +network: 0.988 +virtual: 0.980 +KVM: 0.651 +kernel: 0.122 +hypervisor: 0.075 +debug: 0.045 +TCG: 0.037 +device: 0.026 +x86: 0.022 +PID: 0.015 +user-level: 0.009 +VMM: 0.009 +files: 0.008 +arm: 0.007 +socket: 0.006 +register: 0.006 +risc-v: 0.004 +architecture: 0.004 +semantic: 0.004 +performance: 0.003 +i386: 0.003 +ppc: 0.003 +peripherals: 0.002 +graphic: 0.002 +assembly: 0.002 +boot: 0.001 +permissions: 0.001 +vnc: 0.001 +mistranslation: 0.001 + +multicast VPN breaks IPv6 Duplicate Address Detection + +The multicast VPN facility in Qemu uses Multicast Loopback to make sure that other Qemu processes on the Host server receive the transmission. The side effect of this is that the process sending the packet also gets the packet back on its receive channel and currently this is not filtered but passed directly to the Virtual Machine. + +You can see this effect by running tcpdump in the virtual machine. Every packet sent appears to be duplicated. + +For IPv4 it doesn't appear to cause much of a problem, however with IPv6 the duplicate neighbor solicitation packet is precisely what the system uses to detect duplicate addresses. So IPv6 addresses fail to establish. + +If you run 'ip addr' on a virtual Linux machine with IPv6 enabled you will see 'dadfailed' next to the link local address. 'ping6' will then not work. + +Checked against 0.12.1. + +Description of problem: + +Virtual NIC of type "mcast" receives copies of what it sent, resulting in many disastrous behaviors if you add one to a Linux software ethernet bridge. + +Version-Release number of selected component (if applicable): + + +How reproducible: + +Always. + + +Steps to Reproduce: +1. create a kvm/qemu guest with an mcast NIC as eth0 +2. create a bridge br0 in the guest, enabling STP +3. add eth0 to br0 as its only slave + +Actual results: + +Once STP starts sending frames, the host starts reporting: + +eth0: received packet with own address as source address + +Expected results: + +eth0 should not receive copies of what it sends. + +Additional info: + +This happens as above when the NIC goes into promiscuous mode. I have not bothered to verify whether it happens for multicast or broadcast traffic in non-promiscuous mode. + +Things become more obvious and destructive if you add another slave to the bridge. Any incoming broadcast or multicast traffic from the other slave gets bridged into the mcast NIC, reflected back, and creating a kind of psuedo-loop. This confuses the user, upsets everyone on the other LAN, and also confuses the Linux software bridge as it starts falsely discovering all the reflected MACs as if they are reachable behind the mcast NIC. + +With a manually created list of the MAC addresses actually behind the mcast LAN, one can create draconian ebtables filters to drop all reflected packets via a command like: + +ebtables -t nat -A PREROUTING -i ethX --among-src-file ! /etc/mcast-mac-addrs -j dnat --dnat-target DROP + +This will drop the bad frames before they confuse the bridging code, and you end up with a working bridged mcast network. This proves that the problem is reflected packets coming back to the sender via the mcast NIC. + +This would presumably break all IPv6 duplicate address detection, so guests don't work with IPv6? + +I am not using IPv6 in my test environment, so I cannot confirm nor deny. The network goes haywire very rapidly if one does this experiment without the ebtables rule above, leading one to rip cables out of walls as fast as one can. + +It is a great DoS attack on the victim LAN that you bridge into such an mcast tunnel, as it reflects all broadcast traffic such as mDNS and probably confuses hardware switches as well as the Linux software bridge. As such, I won't be performing more detailed tests of this failure mode in my environment! + +Your initial description doesn't entirely make sense. The QEMU 'mcast' nic type is totally isolated from the host network, but in the steps to reproduce you're talking about setting up bridges in the host which implies the 'tap' nic type in QEMU. + +Please provide the exact QEMU command line you are invoking, and the output of 'ifconfig -a', 'brctl show' and 'route -n' on the host OS. + +No, I described setting up a bridge in the guest with the mcast NIC! + +So the bug-triggering guest needs only one NIC, eth0, which is defined like this: + + <interface type='mcast'> + <mac address='...'/> + <source address='...' port='5558'/> + </interface> + +(with actual local MAC and multicast address assignments). + +After booting that guest, use brctl to create a bridge br0, and simply slave that virtual eth0 to the bridge (as its only "physical" port). This will exhibit the problem, with no real networks involved. + +When I mentioned the host LAN, I had created a second NIC in a privileged guest, so it had one mcast NIC and one tap NIC already bridged into the host LAN by libvirt. Then that guest bridged its two NICs, allowing other unprivileged guests to use an mcast NIC to participate in the host LAN. Because of this mcast bug, you can only do this once this privileged guest has the severe ebtables workaround I reported. + +But this extra step is unnecessary to demonstrate the bug. It is only interesting in that it does something useful once the ebtables workaround is in place (allowing unprivileged guests to participate in a real LAN). + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +I found this bug too. + +Simple way how to reproduce: + +Run kvm guest 1 and 2, with net something like this: +g1:-net nic,vlan=0,model=virtio,macaddr=52:54:00:00:01:01 -net socket,vlan=0,mcast=239.255.0.1:4097 + +g2: -net nic,vlan=0,model=virtio,macaddr=52:54:00:00:02:01 -net socket,vlan=0,mcast=239.255.0.1:4097 + +This should give you two running vm on same net. + +Now in each guest configure ip addresses: +g1: ifconfig eth0 192.168.1.1 +g2: ifconfig eth0 192.168.1.2 + +now on g2 ping 192.168.1.1 + +and on g1 run tcpdump -i eth0 icmp +and every second you will get: +time ip 192.168.1.2 ... ICMP echo request +time ip 192.168.1.1 ... ICMP echo reply +time ip 192.168.1.1 ... ICMP echo reply + +There shouldn't be two echo replies, but only one. + +Another effect is, that Duplicate Address Detection (for ipv6) simply doesn't work (this is what original bug is talking about). + + +Of course, solution is not to disable loopback for mcast socket, because there must be chance to run more then one VM on same host on same mcast address:port. + +Solution may be to detect sending socket ip:port pair and simply drop packets received from this ip:port. + +Just one extra note, I was able to reproduce this bug on qemu-system-x86-0.13.0-1.fc14.i686 + +Logged as Qemu bug on Launchpad: + +https://bugs.launchpad.net/qemu/+bug/761469 + + +This message is a reminder that Fedora 13 is nearing its end of life. +Approximately 30 (thirty) days from now Fedora will stop maintaining +and issuing updates for Fedora 13. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as WONTFIX if it remains open with a Fedora +'version' of '13'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version prior to Fedora 13's end of life. + +Bug Reporter: Thank you for reporting this issue and we are sorry that +we may not be able to fix it before Fedora 13 is end of life. If you +would still like to see this bug fixed and are able to reproduce it +against a later version of Fedora please change the 'version' of this +bug to the applicable version. If you are unable to change the version, +please add a comment here and someone will do it for you. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +The process we are following is described here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +Bug is reproducible on fc14 too + +F14 is end-of-life now. If anyone is still affected by this bug with newer qemu versions, I'd recommend following up in the (still open) upstream bug report mentioned in Comment #10 + +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. + +Since there hasn't been a reply within the last months, I'm closing this now. + diff --git a/results/classifier/118/review/764252 b/results/classifier/118/review/764252 new file mode 100644 index 000000000..ad0924278 --- /dev/null +++ b/results/classifier/118/review/764252 @@ -0,0 +1,78 @@ +mistranslation: 0.963 +device: 0.853 +graphic: 0.747 +semantic: 0.707 +user-level: 0.697 +network: 0.678 +permissions: 0.594 +VMM: 0.586 +kernel: 0.581 +vnc: 0.581 +register: 0.580 +files: 0.572 +socket: 0.571 +architecture: 0.559 +risc-v: 0.551 +PID: 0.541 +performance: 0.496 +virtual: 0.490 +boot: 0.464 +KVM: 0.445 +TCG: 0.429 +ppc: 0.424 +i386: 0.394 +debug: 0.365 +assembly: 0.337 +hypervisor: 0.320 +arm: 0.309 +x86: 0.294 +peripherals: 0.248 +-------------------- +arm: 0.606 +hypervisor: 0.061 +TCG: 0.038 +virtual: 0.033 +user-level: 0.033 +VMM: 0.033 +x86: 0.027 +socket: 0.016 +semantic: 0.016 +PID: 0.013 +device: 0.009 +kernel: 0.006 +files: 0.004 +network: 0.004 +peripherals: 0.003 +i386: 0.003 +architecture: 0.003 +debug: 0.003 +register: 0.002 +risc-v: 0.002 +performance: 0.002 +boot: 0.001 +permissions: 0.001 +assembly: 0.001 +KVM: 0.001 +ppc: 0.001 +graphic: 0.000 +vnc: 0.000 +mistranslation: 0.000 + +wishlist: kirkwood support + +This is a feature request for qemu to emulate the Marvell Kirkwood chipset. It is used by Sheevaplug, Guruplug, and many NAS devices. + +This was added in 2011, is there a plan to integrate support for kirkwood? + +With "this" I mean the bugreport, not the feature requested. + +If somebody wants to write and submit code I will review it. I am not aware of anybody who is working on kirkwood emulation support or with plans to do so. + + +Apparently nobody submitted code for this, and I assume nobody is interested in this kirkwood platform nowadays any more, so I'm closing this ticket now. + +For the record, I still regularly use a Kirkwood device (a QNAP NAS). Being able to compile software for it in qemu would be handy once in a while, though it's not a high priority for me. + +My offer from comment #3 to review code if anybody wants to submit it still stands, but given the amount of work required to implement a model of a new SoC in QEMU I'm not surprised nobody's ever taken me up on it. + + diff --git a/results/classifier/118/review/793 b/results/classifier/118/review/793 new file mode 100644 index 000000000..8eba6c280 --- /dev/null +++ b/results/classifier/118/review/793 @@ -0,0 +1,61 @@ +mistranslation: 0.997 +graphic: 0.740 +performance: 0.615 +device: 0.527 +permissions: 0.480 +debug: 0.396 +semantic: 0.319 +ppc: 0.238 +assembly: 0.187 +arm: 0.169 +user-level: 0.159 +network: 0.148 +register: 0.129 +vnc: 0.126 +peripherals: 0.125 +virtual: 0.111 +VMM: 0.109 +hypervisor: 0.082 +boot: 0.079 +TCG: 0.078 +risc-v: 0.072 +socket: 0.063 +kernel: 0.044 +x86: 0.038 +PID: 0.035 +KVM: 0.032 +i386: 0.028 +files: 0.027 +architecture: 0.008 +-------------------- +virtual: 0.813 +hypervisor: 0.305 +debug: 0.073 +user-level: 0.047 +device: 0.042 +files: 0.027 +kernel: 0.017 +semantic: 0.016 +x86: 0.016 +peripherals: 0.015 +assembly: 0.011 +PID: 0.008 +KVM: 0.006 +register: 0.005 +VMM: 0.004 +TCG: 0.004 +boot: 0.003 +graphic: 0.002 +architecture: 0.002 +i386: 0.002 +socket: 0.002 +arm: 0.002 +risc-v: 0.001 +mistranslation: 0.001 +performance: 0.001 +ppc: 0.001 +network: 0.000 +permissions: 0.000 +vnc: 0.000 + +Wrong pci express bus type - qemu 6.1.0-5 diff --git a/results/classifier/118/review/814 b/results/classifier/118/review/814 new file mode 100644 index 000000000..dd2a78bdb --- /dev/null +++ b/results/classifier/118/review/814 @@ -0,0 +1,97 @@ +user-level: 0.874 +mistranslation: 0.857 +graphic: 0.824 +hypervisor: 0.818 +risc-v: 0.817 +permissions: 0.811 +register: 0.809 +debug: 0.808 +assembly: 0.800 +virtual: 0.791 +peripherals: 0.790 +device: 0.787 +semantic: 0.785 +architecture: 0.774 +network: 0.773 +socket: 0.772 +TCG: 0.772 +PID: 0.769 +files: 0.764 +ppc: 0.760 +arm: 0.749 +KVM: 0.746 +boot: 0.745 +vnc: 0.743 +performance: 0.738 +kernel: 0.717 +VMM: 0.681 +i386: 0.640 +x86: 0.504 +-------------------- +virtual: 0.940 +debug: 0.831 +x86: 0.811 +TCG: 0.691 +hypervisor: 0.440 +boot: 0.305 +register: 0.166 +PID: 0.160 +vnc: 0.133 +VMM: 0.130 +socket: 0.085 +risc-v: 0.080 +user-level: 0.074 +device: 0.063 +semantic: 0.028 +kernel: 0.025 +files: 0.019 +KVM: 0.012 +network: 0.007 +performance: 0.006 +i386: 0.005 +architecture: 0.005 +assembly: 0.003 +graphic: 0.003 +peripherals: 0.002 +permissions: 0.002 +mistranslation: 0.001 +ppc: 0.000 +arm: 0.000 + +On Windows, qcow2 is corrupted on expansion +Description of problem: +On Windows, the qcow2 loses blocks on account of which the filesystem withing is corrupted as data is copied to it, just the same way as in #727 VHDX is corrupted on expansion on both Linux/Windows. + +After filing a bug for WNBD https://github.com/cloudbase/wnbd/issues/63 , I was suggested to try raw and qcow2. In the process I found that qcow2 is also affected. But it is also true that the kernel-5.15.4 ... 5.15.13 series have also been buggy https://bugzilla.kernel.org/show_bug.cgi?id=215460 . +On Linux, qcow2 never showed any signs of corruption. +On Windows, however, qcow2 does corrupt. + +It is possible that, as Linux is so much more efficient at files and disk-IO, the kernel-block-code, qemu-block-code and qemu-qcow2-code do not hit the bug, and so the corruption does not show up as easily in Linux. Windows, being a little slower at this, might be causing the bug to show up in this qcow2 test. Possibly, the issue more likely to show up on slower machines. I am using an 2013-era intel-4rth gen i7-4700mq Haswell machine. + +It is possible that, the resolution for this issue and that for #727 could be the same or very closely related. The bug may not be in qcow2.c or vhdx.c but maybe in the qemu/block subsystem. If the data-block that arrives from the VM-interface/nbd-interface which has to be written to file, but never gets to the virtual-disk code, not allocated and written to, then the data-block is lost. +Steps to reproduce: +1. Prepare virtual-disk1 as empty qcow2. In my-setup, the qcow2 file resides on an 150 GiB ExFAT partition on 512 GiB SSD. I use ExFAT as the ExFAT-filesystem does not have a concept of sparse files, eliminating that factor from troubleshooting. + ```qemu-img.exe create -f qcow2 H:\gkpics01.qcow2 99723771904``` +2. Prepare virtual-disk2 VHDX with synthetic generated data (sgdata). Scriptlets to recreate sgdata are described in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 . In my-setup, the vhdx file resides on an 1 TiB NTFS partition on a 2 TiB HDD. +3. Start qemu with arguments as given above. +4. Inside VM, boot and bringup livecd desktop, close the installer and open a terminal +5. Use gdisk to put an ext4 partition on /dev/sda +6. Put ext4 partition on sda1 ```mkfs.ext4 -L fs_gkpics01 /dev/sda1``` +7. Create mount directories ```mkdir /mnt/a /mnt/b``` +8. Mount the empty partition from virtual-disk-1 ```mount -t ext4 /dev/sda1 /mnt/a``` +9. Mount the sgdata partition from virtual-disk-2 ```mount.ntfs-3g /dev/sdb2 /mnt/b``` or ```mount -t ntfs3 /dev/sdb2 /mnt/b``` +10. Keep a terminal tab open with ```dmesg -w``` running +11. Rsync sgdata ```( sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date )``` +12. Check sha256sum ```( sdate=`date` ; cd /mnt/a/photos001 ; shas256sum -c ./find.CHECKSUM --quiet ; echo $sdate ; date )``` + corruption will show even without needing to unmount-remount or reboot-remount. + +- About 1.4 GiB free-space left on the ext4 partition. +- Compared to #727, The number of files corrupted are less ``` sha256sum: WARNING: 31 computed checksums did not match ``` +- After, VM guest OS warm reboot, a recheck of the sha256sum shows the same 31 files as corrupted +- After, qemu poweroff, restart qemu, VM guest OS cold boot, a recheck of the sha256sum shows the same 31 files as corrupted +- df shows: sda1 has 95271336 1k-blocks, of which 88840860 are used, 1544820 available, 99% used. The numbers don't add up. Either file-blocks are lost in lost-clusters or the ext4-filesystem has a large journal or the file-system-metadata is too large, or the ext4-filesystem has large cluster-size which results in inefficient space usage. +- An ```unmount /dev/sda1 ; fsck -y /dev/sda1 ; mount -t ext4 /dev/sda1 /mnt/a``` did not find any lost clusters. + +The reason I don't think this is a kernel bug, is because the raw-file as virtual-disk-1 doesn't show this issue. Also, it happens regardless of whether sgdata is on ntfs-3g or ntfs3-paragon. +Additional information: + diff --git a/results/classifier/118/review/822 b/results/classifier/118/review/822 new file mode 100644 index 000000000..299cc479d --- /dev/null +++ b/results/classifier/118/review/822 @@ -0,0 +1,76 @@ +x86: 0.906 +ppc: 0.887 +graphic: 0.878 +device: 0.860 +architecture: 0.813 +files: 0.780 +network: 0.772 +VMM: 0.751 +PID: 0.742 +performance: 0.734 +arm: 0.727 +TCG: 0.727 +vnc: 0.708 +socket: 0.686 +hypervisor: 0.685 +debug: 0.671 +risc-v: 0.671 +i386: 0.654 +permissions: 0.648 +user-level: 0.647 +kernel: 0.646 +semantic: 0.639 +virtual: 0.605 +peripherals: 0.577 +KVM: 0.560 +mistranslation: 0.539 +boot: 0.472 +register: 0.459 +assembly: 0.288 +-------------------- +ppc: 0.935 +hypervisor: 0.401 +files: 0.210 +TCG: 0.181 +x86: 0.152 +debug: 0.116 +user-level: 0.062 +register: 0.046 +kernel: 0.041 +virtual: 0.027 +PID: 0.016 +device: 0.013 +VMM: 0.012 +semantic: 0.011 +architecture: 0.010 +network: 0.010 +risc-v: 0.010 +performance: 0.006 +vnc: 0.005 +KVM: 0.004 +socket: 0.004 +assembly: 0.004 +i386: 0.004 +peripherals: 0.004 +graphic: 0.003 +boot: 0.003 +mistranslation: 0.001 +arm: 0.001 +permissions: 0.001 + +hw/ppc/vof.c:1033: undefined reference to `fdt_get_max_phandle' in qemu-6.1.1, qemu-6.2.0 +Description of problem: +Compilation of the source code of 6.1.1 and 6.2.0 fails in the qemu-system-ppc target ath the linking stage. Specifically the error in both cases is +usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: libqemu-ppc-softmmu.fa.p/hw_ppc_vof.c.o: in function `vof_build_dt': +/home/silviu/qemu-work/qemu-6.1.1/build/../hw/ppc/vof.c:1033: undefined reference to `fdt_get_max_phandle' + +(same error for 6.2.0) + +This system has qemu-5.2.0 installed, which is the default for Funtoo currently. There were no compilation errors with 5.2.0. +gcc is version 9.2.0 +Steps to reproduce: +1. download qemu-6.1.1.tar.xz/qemu-6.2.0.tar.xz and uncompress +2. configure +3. make[error.txt](/uploads/c9a987870eff85e586ddb29a113f64a7/error.txt) +Additional information: +the final part of the build log attached as text diff --git a/results/classifier/118/review/825 b/results/classifier/118/review/825 new file mode 100644 index 000000000..83c2c3fa4 --- /dev/null +++ b/results/classifier/118/review/825 @@ -0,0 +1,98 @@ +register: 0.874 +peripherals: 0.864 +graphic: 0.850 +virtual: 0.847 +device: 0.837 +mistranslation: 0.828 +arm: 0.816 +semantic: 0.813 +debug: 0.806 +permissions: 0.805 +user-level: 0.795 +assembly: 0.793 +boot: 0.793 +hypervisor: 0.784 +PID: 0.774 +vnc: 0.773 +performance: 0.771 +architecture: 0.748 +risc-v: 0.739 +VMM: 0.737 +ppc: 0.732 +kernel: 0.730 +TCG: 0.710 +socket: 0.699 +network: 0.664 +KVM: 0.625 +files: 0.578 +x86: 0.490 +i386: 0.392 +-------------------- +virtual: 0.089 +TCG: 0.071 +x86: 0.052 +ppc: 0.046 +debug: 0.043 +files: 0.033 +kernel: 0.024 +hypervisor: 0.020 +PID: 0.018 +KVM: 0.017 +i386: 0.016 +register: 0.016 +VMM: 0.016 +risc-v: 0.015 +socket: 0.014 +network: 0.011 +semantic: 0.010 +device: 0.009 +performance: 0.006 +user-level: 0.005 +peripherals: 0.004 +permissions: 0.003 +vnc: 0.003 +arm: 0.003 +graphic: 0.003 +boot: 0.002 +architecture: 0.002 +assembly: 0.001 +mistranslation: 0.001 + +compilation error - "VIRTIO_F_VERSION" +Description of problem: +Encountered problem while "make" + +.... +`[65/2464] Compiling C object subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o +FAILED: subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o +cc -m64 -mcx16 -Isubprojects/libvhost-user/libvhost-user.a.p -Isubprojects/libvhost-user -I../subprojects/libvhost-user -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -pthread -D_GNU_SOURCE -MD -MQ subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -MF subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o.d -o subprojects/libvhost-user/libvhost-user.a.p/libvhost-user.c.o -c ../subprojects/libvhost-user/libvhost-user.c +../subprojects/libvhost-user/libvhost-user.c: In function 'vu_get_features_exec': +../subprojects/libvhost-user/libvhost-user.c:508:17: error: 'VIRTIO_F_VERSION_1' undeclared (first use in this function); did you mean 'INFLIGHT_VERSION'? + 1ULL << VIRTIO_F_VERSION_1 | + ^~~~~~~~~~~~~~~~~~ + INFLIGHT_VERSION +../subprojects/libvhost-user/libvhost-user.c:508:17: note: each undeclared identifier is reported only once for each function it appears in +../subprojects/libvhost-user/libvhost-user.c: In function 'vu_set_features_exec': +../subprojects/libvhost-user/libvhost-user.c:542:30: error: 'VIRTIO_F_VERSION_1' undeclared (first use in this function); did you mean 'INFLIGHT_VERSION'? + if (!vu_has_feature(dev, VIRTIO_F_VERSION_1)) { + ^~~~~~~~~~~~~~~~~~ + INFLIGHT_VERSION +../subprojects/libvhost-user/libvhost-user.c: In function 'generate_faults': +../subprojects/libvhost-user/libvhost-user.c:612:13: error: unused variable 'ret' [-Werror=unused-variable] + int ret; + ^~~ +../subprojects/libvhost-user/libvhost-user.c:611:22: error: unused variable 'dev_region' [-Werror=unused-variable] + VuDevRegion *dev_region = &dev->regions[i]; + ^~~~~~~~~~ +cc1: all warnings being treated as errors +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:163: run-ninja] Error 1 +make[1]: Leaving directory '/users/oneuser/qemu/qemu/build' +make: *** [GNUmakefile:11: all] Error 2 +` +Steps to reproduce: +1. ./configure --prefix=/users/oneuser/qemu/myqemu-1 --enable-kvm --target-list=x86_64-softmmu +2. make +3. +Additional information: +Please let me know if more info is needed. diff --git a/results/classifier/118/review/826 b/results/classifier/118/review/826 new file mode 100644 index 000000000..ada28e420 --- /dev/null +++ b/results/classifier/118/review/826 @@ -0,0 +1,76 @@ +register: 0.976 +architecture: 0.965 +graphic: 0.822 +performance: 0.656 +device: 0.639 +mistranslation: 0.592 +ppc: 0.546 +debug: 0.513 +network: 0.489 +assembly: 0.432 +semantic: 0.404 +user-level: 0.308 +hypervisor: 0.307 +kernel: 0.268 +vnc: 0.261 +peripherals: 0.252 +arm: 0.229 +files: 0.228 +PID: 0.215 +socket: 0.178 +virtual: 0.172 +risc-v: 0.133 +boot: 0.132 +i386: 0.101 +permissions: 0.097 +x86: 0.080 +VMM: 0.061 +TCG: 0.048 +KVM: 0.015 +-------------------- +debug: 0.908 +assembly: 0.712 +architecture: 0.304 +TCG: 0.164 +register: 0.103 +files: 0.046 +kernel: 0.040 +hypervisor: 0.039 +device: 0.025 +PID: 0.023 +risc-v: 0.013 +VMM: 0.012 +semantic: 0.012 +performance: 0.010 +virtual: 0.010 +peripherals: 0.008 +user-level: 0.007 +vnc: 0.007 +arm: 0.005 +network: 0.004 +boot: 0.003 +ppc: 0.003 +graphic: 0.003 +permissions: 0.002 +socket: 0.002 +mistranslation: 0.001 +KVM: 0.001 +x86: 0.001 +i386: 0.000 + +AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated +Description of problem: +During execution of the following SVE2 instruction: +`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` +with the following register state: +``` +(gdb) p $p3 +$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} +(gdb) p $z14.d.u +$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} +(gdb) p $x9 +$3 = 0x0 +``` +QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. +Additional information: +A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/118/review/828 b/results/classifier/118/review/828 new file mode 100644 index 000000000..8de939125 --- /dev/null +++ b/results/classifier/118/review/828 @@ -0,0 +1,71 @@ +mistranslation: 0.944 +network: 0.879 +graphic: 0.792 +device: 0.736 +x86: 0.652 +architecture: 0.621 +hypervisor: 0.579 +semantic: 0.564 +debug: 0.551 +PID: 0.461 +ppc: 0.437 +vnc: 0.424 +performance: 0.378 +kernel: 0.341 +i386: 0.330 +socket: 0.329 +boot: 0.324 +register: 0.309 +risc-v: 0.282 +arm: 0.275 +files: 0.257 +user-level: 0.222 +peripherals: 0.218 +VMM: 0.210 +TCG: 0.204 +virtual: 0.193 +KVM: 0.147 +permissions: 0.122 +assembly: 0.104 +-------------------- +hypervisor: 0.983 +x86: 0.974 +virtual: 0.926 +user-level: 0.831 +TCG: 0.125 +VMM: 0.101 +debug: 0.099 +register: 0.061 +network: 0.029 +kernel: 0.013 +semantic: 0.012 +files: 0.011 +boot: 0.010 +device: 0.008 +KVM: 0.007 +PID: 0.005 +performance: 0.003 +assembly: 0.003 +socket: 0.003 +architecture: 0.003 +ppc: 0.003 +mistranslation: 0.002 +risc-v: 0.002 +graphic: 0.001 +vnc: 0.001 +permissions: 0.001 +peripherals: 0.001 +arm: 0.000 +i386: 0.000 + +using qemu-system-x86_64 to start multiple windows 10 guests concurrently , the mac address of the guests is incorrect +Description of problem: +I plan to run multiple windows 10 guests concurrently, I choose NAT network and specify a unique MAC addr for each guest. and I choose dnsmasq as a dhcp server. but I found that all guests MAC addresses are the same as the guest started first. +This situation also occurs in windows 8. But the strange thing is that this never happened to windows7 guests. +I'm Chinese and my English is pool, please forgive my bad expressions. +Steps to reproduce: +1.make a windows 10 image +2.qemu-system-x86_64 command assign unique MAC addr +3. python multiprocess lib running command above +Additional information: + diff --git a/results/classifier/118/review/829 b/results/classifier/118/review/829 new file mode 100644 index 000000000..a45b079c8 --- /dev/null +++ b/results/classifier/118/review/829 @@ -0,0 +1,74 @@ +user-level: 0.926 +graphic: 0.848 +performance: 0.841 +device: 0.788 +mistranslation: 0.696 +arm: 0.669 +architecture: 0.594 +boot: 0.572 +permissions: 0.561 +files: 0.554 +semantic: 0.545 +network: 0.477 +PID: 0.476 +ppc: 0.472 +TCG: 0.470 +risc-v: 0.467 +debug: 0.452 +vnc: 0.424 +i386: 0.417 +socket: 0.411 +x86: 0.379 +kernel: 0.361 +VMM: 0.319 +register: 0.313 +peripherals: 0.310 +KVM: 0.215 +virtual: 0.190 +hypervisor: 0.172 +assembly: 0.105 +-------------------- +arm: 0.998 +user-level: 0.817 +TCG: 0.420 +debug: 0.330 +virtual: 0.323 +VMM: 0.031 +files: 0.018 +PID: 0.014 +register: 0.013 +semantic: 0.012 +architecture: 0.008 +boot: 0.007 +device: 0.005 +performance: 0.005 +assembly: 0.004 +network: 0.004 +mistranslation: 0.002 +permissions: 0.002 +hypervisor: 0.002 +peripherals: 0.002 +socket: 0.001 +graphic: 0.001 +kernel: 0.001 +risc-v: 0.001 +vnc: 0.001 +KVM: 0.001 +x86: 0.000 +ppc: 0.000 +i386: 0.000 + +user space emulation: openat() seems to defeat sysroot path translation +Description of problem: +It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot. This seems to be interacting badly sometimes with certain usage patterns. This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied. + +In particular, the sequence which fails is: +* create a file in `/tmp/`. +* open `/tmp` itself. This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`. +* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected. +Steps to reproduce: +1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2 +2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c) +3. Try to run under `qemu-arm`. + +This code passes in non-emulated situations, but fails under user-space emulation. Presumably it would also pass under full system emulation. diff --git a/results/classifier/118/review/83 b/results/classifier/118/review/83 new file mode 100644 index 000000000..b0b1c4221 --- /dev/null +++ b/results/classifier/118/review/83 @@ -0,0 +1,61 @@ +architecture: 0.939 +mistranslation: 0.859 +device: 0.813 +performance: 0.658 +x86: 0.619 +hypervisor: 0.395 +register: 0.394 +graphic: 0.374 +boot: 0.370 +arm: 0.351 +risc-v: 0.316 +socket: 0.204 +ppc: 0.182 +virtual: 0.171 +semantic: 0.165 +vnc: 0.149 +TCG: 0.144 +kernel: 0.113 +network: 0.095 +PID: 0.095 +user-level: 0.090 +VMM: 0.089 +debug: 0.085 +permissions: 0.080 +peripherals: 0.040 +assembly: 0.028 +files: 0.015 +KVM: 0.001 +i386: 0.001 +-------------------- +hypervisor: 0.751 +virtual: 0.367 +performance: 0.139 +user-level: 0.048 +mistranslation: 0.034 +device: 0.031 +semantic: 0.024 +TCG: 0.018 +files: 0.016 +register: 0.016 +architecture: 0.015 +assembly: 0.009 +kernel: 0.004 +graphic: 0.004 +peripherals: 0.003 +debug: 0.003 +x86: 0.003 +boot: 0.001 +PID: 0.001 +arm: 0.000 +ppc: 0.000 +risc-v: 0.000 +socket: 0.000 +VMM: 0.000 +vnc: 0.000 +network: 0.000 +KVM: 0.000 +permissions: 0.000 +i386: 0.000 + +QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit diff --git a/results/classifier/118/review/853 b/results/classifier/118/review/853 new file mode 100644 index 000000000..3e98d64e1 --- /dev/null +++ b/results/classifier/118/review/853 @@ -0,0 +1,70 @@ +mistranslation: 0.925 +x86: 0.793 +device: 0.740 +semantic: 0.733 +files: 0.669 +graphic: 0.511 +network: 0.507 +architecture: 0.392 +vnc: 0.374 +kernel: 0.344 +register: 0.339 +i386: 0.336 +socket: 0.321 +debug: 0.304 +ppc: 0.280 +virtual: 0.270 +permissions: 0.253 +arm: 0.242 +boot: 0.230 +peripherals: 0.226 +VMM: 0.220 +performance: 0.220 +hypervisor: 0.209 +TCG: 0.190 +risc-v: 0.169 +user-level: 0.162 +PID: 0.158 +KVM: 0.136 +assembly: 0.052 +-------------------- +hypervisor: 0.933 +files: 0.765 +user-level: 0.701 +semantic: 0.444 +debug: 0.268 +x86: 0.157 +TCG: 0.120 +virtual: 0.059 +device: 0.016 +register: 0.013 +peripherals: 0.008 +network: 0.007 +kernel: 0.007 +ppc: 0.004 +architecture: 0.003 +graphic: 0.003 +boot: 0.002 +PID: 0.002 +performance: 0.002 +risc-v: 0.001 +i386: 0.001 +mistranslation: 0.001 +arm: 0.001 +permissions: 0.001 +socket: 0.001 +VMM: 0.000 +vnc: 0.000 +assembly: 0.000 +KVM: 0.000 + +Quaint English in qemu-options.hx +Description of problem: +qemu-options.hx contains grammar that a native English-speaking person would never use. I had to read a sentence in that file very slowly and more than once to understand it. +Steps to reproduce: +1. Install QEMU +2. Run a command to display documentation that includes qemu-options.hx for instance "man qemu-system-x86_64" +3. Observe "This option defines where is connected the drive ..." +4. Scratch head, figure out that "This option defines where the drive is connected ..." is the meaning. +Additional information: +It is very difficult to report QEMU documentation bugs. diff --git a/results/classifier/118/review/864490 b/results/classifier/118/review/864490 new file mode 100644 index 000000000..dee249bde --- /dev/null +++ b/results/classifier/118/review/864490 @@ -0,0 +1,79 @@ +mistranslation: 0.855 +device: 0.802 +architecture: 0.793 +graphic: 0.755 +performance: 0.708 +semantic: 0.614 +register: 0.599 +permissions: 0.593 +PID: 0.568 +socket: 0.557 +debug: 0.554 +assembly: 0.547 +files: 0.544 +ppc: 0.537 +boot: 0.531 +kernel: 0.529 +user-level: 0.521 +vnc: 0.510 +hypervisor: 0.500 +x86: 0.497 +network: 0.472 +VMM: 0.469 +risc-v: 0.469 +TCG: 0.444 +arm: 0.438 +virtual: 0.390 +peripherals: 0.388 +KVM: 0.277 +i386: 0.267 +-------------------- +virtual: 0.876 +hypervisor: 0.660 +network: 0.372 +debug: 0.221 +TCG: 0.042 +socket: 0.033 +performance: 0.026 +register: 0.023 +VMM: 0.020 +x86: 0.018 +files: 0.016 +user-level: 0.014 +PID: 0.010 +device: 0.008 +semantic: 0.005 +risc-v: 0.005 +kernel: 0.004 +KVM: 0.004 +architecture: 0.002 +assembly: 0.002 +vnc: 0.001 +boot: 0.001 +ppc: 0.001 +permissions: 0.001 +i386: 0.001 +graphic: 0.001 +peripherals: 0.001 +mistranslation: 0.000 +arm: 0.000 + +Windows 2008 x64 (SBS Server) freezes randomly when using more than 1 CPU core + +This issue has been giving headache to us since a long time. +Difficult to reproduce as it happens randomly. +We had this issue when we ran Windows 2008 x64 or Windows SBS Server guests in either XEN 3.3 or Proxmox environments. +When only one CPU core is assigned to the guest, everything is fine. If 2 or more cores are assigned, the guest stops responding after several hours - and in the host machine one of the cores is using 100%. The only thing that helps is resetting the guest. + +I am ready to provide logs/crashdumps if needed, because we want to help resolve this issue. I saw some posts on the web of people having the same problems - for some of the workaround was to fix some BIOS settings, but we did not have success with those (e.g. disabling C1E Support and Intel C-State ) + +Server is running on Intel® Core™ i7-920 Quad-Core, 24 Gig RAM. + +Hi, + +Is this bug tracker active or I posted to the wrong place? + +thx + +Since nobody replied here within the last years: I think you should rather report problems with XEN / Proxmox to the XEN or Proxmox bugtracker instead. + diff --git a/results/classifier/118/review/870 b/results/classifier/118/review/870 new file mode 100644 index 000000000..f7c744f55 --- /dev/null +++ b/results/classifier/118/review/870 @@ -0,0 +1,72 @@ +mistranslation: 0.970 +device: 0.785 +graphic: 0.726 +architecture: 0.713 +permissions: 0.686 +performance: 0.619 +kernel: 0.433 +semantic: 0.424 +x86: 0.352 +network: 0.321 +PID: 0.317 +vnc: 0.298 +risc-v: 0.271 +i386: 0.252 +debug: 0.237 +socket: 0.207 +KVM: 0.199 +ppc: 0.199 +TCG: 0.198 +peripherals: 0.189 +arm: 0.163 +register: 0.163 +VMM: 0.160 +boot: 0.154 +files: 0.125 +hypervisor: 0.121 +user-level: 0.082 +virtual: 0.082 +assembly: 0.048 +-------------------- +assembly: 0.739 +debug: 0.598 +TCG: 0.151 +virtual: 0.122 +register: 0.117 +semantic: 0.092 +kernel: 0.044 +user-level: 0.040 +hypervisor: 0.035 +VMM: 0.028 +KVM: 0.024 +i386: 0.019 +x86: 0.015 +PID: 0.014 +risc-v: 0.013 +performance: 0.010 +files: 0.009 +architecture: 0.007 +device: 0.007 +ppc: 0.006 +network: 0.004 +permissions: 0.003 +vnc: 0.003 +socket: 0.003 +peripherals: 0.001 +boot: 0.001 +graphic: 0.001 +arm: 0.001 +mistranslation: 0.001 + +Throws a #GP when it should throw a #SS +Description of problem: +When stacks are switched as part of a 64-bit mode privilege-level change (resulting from an interrupt), IA-32e mode loads only an inner-level RSP from the TSS. If the value of rsp from tss is a non-canonical form. It will trigger #SS. But when I test it in qemu it throws #GP instead of #SS +Steps to reproduce: +In order to confirm that it is the #SS triggered by the non-canonical address, We can verify on a real machine. +1. Set the value of the current core's `TSS.IST7` to the the non-canonical address. +2. Set the `ist` field of the interrupt 4 (Overflow Exception) descriptor to 7. +3. Execute the `INT 4` instruction in Ring 3 and it will be taken over by the #SS handler. + +Repeat the above steps in qemu this exception will be taken over by #GP +Additional information: + diff --git a/results/classifier/118/review/884401 b/results/classifier/118/review/884401 new file mode 100644 index 000000000..1265b44de --- /dev/null +++ b/results/classifier/118/review/884401 @@ -0,0 +1,130 @@ +register: 0.885 +assembly: 0.882 +graphic: 0.877 +permissions: 0.875 +virtual: 0.872 +socket: 0.869 +semantic: 0.866 +network: 0.851 +debug: 0.845 +arm: 0.844 +architecture: 0.839 +device: 0.832 +user-level: 0.827 +kernel: 0.826 +peripherals: 0.823 +performance: 0.808 +PID: 0.800 +files: 0.791 +hypervisor: 0.781 +x86: 0.770 +vnc: 0.769 +VMM: 0.760 +TCG: 0.750 +boot: 0.746 +mistranslation: 0.739 +risc-v: 0.729 +ppc: 0.679 +KVM: 0.668 +i386: 0.444 +-------------------- +virtual: 0.985 +KVM: 0.975 +hypervisor: 0.968 +x86: 0.902 +VMM: 0.074 +peripherals: 0.053 +device: 0.036 +user-level: 0.035 +debug: 0.028 +files: 0.021 +PID: 0.012 +TCG: 0.010 +register: 0.007 +boot: 0.006 +kernel: 0.005 +ppc: 0.004 +architecture: 0.003 +semantic: 0.003 +socket: 0.003 +assembly: 0.002 +graphic: 0.002 +performance: 0.002 +i386: 0.001 +network: 0.001 +risc-v: 0.001 +permissions: 0.001 +vnc: 0.001 +arm: 0.000 +mistranslation: 0.000 + +PCI Passthrough for Digium TCE400P Codec Card Not working + +trying to use a Digium TCE400P Codec card on a Virtual instance using the following information: + +lspci <enter> + +02:08.0 Ethernet controller: Digium, Inc. Wildcard TCE400P transcoder base card (rev 11) + +lspci -n <enter> + +02:08.0 0200: d161:8004 (rev 11) + +virsh nodedev-list | grep pci + +pci_0000_02_08_0 + +printf %x 02 +2 + +printf %x 08 +8 + +printf %x 0 +0 + +bus='0x02' +slot='0x08' +function='0x0' + +# virsh edit vmanager +<hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0x02' slot='0x08' function='0x0'/> + </source> +</hostdev> + +I have SELINUX disabled at this time. + +virsh start vmanager I get the following error message: + +[root@twins qemu]# virsh start vmanager +error: Failed to start domain vmanager +error: internal error Process exited while reading console log output: char device redirected to /dev/pts/2 +Unable to assign device: PCI region 1 at address 0xdf1fe000 has size 0x400, which is not a multiple of 4K +qemu-kvm: -device pci-assign,host=02:08.0,id=hostdev0,configfd=23,bus=pci.0,addr=0x6: Device 'pci-assign' could not be initialized + + + +Version Numbers: + +[root@twins qemu]# yum list | grep qemu +gpxe-roms-qemu.noarch 0.9.7-6.3.el6_0.1 @updates +qemu-img.x86_64 2:0.12.1.2-2.113.el6_0.8 @updates +qemu-kvm.x86_64 2:0.12.1.2-2.113.el6_0.8 @updates +qemu-kvm-tools.x86_64 2:0.12.1.2-2.113.el6_0.8 updates + +Here is what my grub.conf looks like (see the addition of the intel_iommu=on: + +title CentOS Linux (2.6.32-71.29.1.el6.x86_64) + root (hd0,0) + kernel /vmlinuz-2.6.32-71.29.1.el6.x86_64 ro root=/dev/mapper/vg_twins-lv_root rd_LVM_LV=vg_twins/lv_root rd_LVM_LV=vg_twins/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=128M rhgb quiet intel_iommu=on + initrd /initramfs-2.6.32-71.29.1.el6.x86_64.img + + +This is a distro bug, not an upstream bug. The error message indicates the version of qemu-kvm you're using doesn't support sub-4k MMIO BARs. This has already been fixed in RHEL6.1. + +According to the comment to Alex, this should have been fixed in newer versions, so setting status to "Fix Released" now. + +Oh, I meant "comment from Alex", not "comment to Alex", sorry! + diff --git a/results/classifier/118/review/886255 b/results/classifier/118/review/886255 new file mode 100644 index 000000000..dc0e8ea22 --- /dev/null +++ b/results/classifier/118/review/886255 @@ -0,0 +1,173 @@ +mistranslation: 0.856 +peripherals: 0.854 +user-level: 0.843 +ppc: 0.812 +risc-v: 0.806 +register: 0.803 +hypervisor: 0.799 +virtual: 0.788 +KVM: 0.786 +network: 0.782 +boot: 0.776 +debug: 0.770 +permissions: 0.763 +graphic: 0.762 +device: 0.761 +performance: 0.750 +vnc: 0.746 +TCG: 0.739 +VMM: 0.720 +x86: 0.704 +architecture: 0.699 +arm: 0.694 +kernel: 0.664 +semantic: 0.653 +PID: 0.652 +assembly: 0.652 +socket: 0.649 +files: 0.633 +i386: 0.596 +-------------------- +debug: 0.996 +virtual: 0.935 +hypervisor: 0.885 +x86: 0.871 +boot: 0.862 +KVM: 0.848 +TCG: 0.206 +files: 0.172 +graphic: 0.081 +register: 0.075 +PID: 0.056 +device: 0.037 +performance: 0.030 +semantic: 0.026 +kernel: 0.022 +user-level: 0.012 +VMM: 0.010 +assembly: 0.006 +network: 0.005 +socket: 0.004 +risc-v: 0.003 +vnc: 0.002 +architecture: 0.002 +peripherals: 0.001 +permissions: 0.001 +mistranslation: 0.000 +ppc: 0.000 +i386: 0.000 +arm: 0.000 + +Qemu master branch - RHEL 6.1 guest fails to boot + +Guest: RHEL 6.1 64 bit DVD + +Kernel: Latest Fedora, also reproduces with Avi's kvm.git kernel based on 3.1: 2.6.40.6-0.fc15.x86_64 + +qemu version: + +11/04 00:25:30 DEBUG|virt_utils:2587| Git repo qemu uri: git://git.qemu.org/qemu.git +11/04 00:25:30 DEBUG|virt_utils:2590| Git repo qemu branch: master +11/04 00:25:30 DEBUG|virt_utils:3189| Configure options for git_repo_qemu: ['--target-list=x86_64-softmmu'] +11/04 00:25:30 DEBUG|virt_utils:2496| Initializing new git repo at /usr/local/autotest/tests/kvm/src/qemu for receiving git repo 11/04 00:25:30 INFO |virt_utils:2505| Fetching git [REP 'git://git.qemu.org/qemu.git' BRANCH 'master'] -> /usr/local/autotest/tests/kvm/src/qemu +11/04 00:25:30 DEBUG|base_utils:0074| Running 'git fetch -q -f -u -t git://git.qemu.org/qemu.git master:master' +11/04 00:34:41 INFO |virt_utils:2531| Commit hash for qemu is 932eacc158c064935c7bab920c88a93a629e1ca4 (no tag found) + +On guest boot screenshots (one of them attached), you can see the message + +"Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization" + +Network card info +11/04 00:44:55 DEBUG| virt_test:0041| bridge = virbr0 +11/04 00:44:55 DEBUG| virt_test:0041| nic_mode = tap +11/04 00:44:55 DEBUG| virt_test:0041| nic_model = virtio + +Commented excerpt of the test log: + +11/04 00:44:57 INFO | kvm_vm:0790| Running qemu command: +/usr/local/autotest/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -monitor unix:'/tmp/monitor-humanmonitor1-20111104-003602-LPJY',server,nowait -qmp unix:'/tmp/monitor-qmpmonitor1-20111104-003602-LPJY',server,nowait -serial unix:'/tmp/serial-20111104-003602-LPJY',server,nowait -drive file='/tmp/kvm_autotest_root/images/rhel6.1-64.qcow2',index=0,if=virtio,cache=none -device virtio-net-pci,netdev=id3HQgQx,mac='9a:16:a5:3c:05:25',id='id0AfUVE' -netdev tap,id=id3HQgQx,fd=23 -m 2048 -smp 2 -vnc :0 -enable-kvm +11/04 00:44:59 DEBUG|kvm_monito:0624| (monitor qmpmonitor1) Sending command 'qmp_capabilities' +11/04 00:44:59 DEBUG| kvm_vm:0851| VM appears to be alive with PID 9827 +11/04 00:44:59 DEBUG|virt_env_p:0318| Starting screendump thread +11/04 00:44:59 DEBUG| virt_vm:0654| Attempting to log into 'vm1' (timeout 720s) + +... here it starts booting ... + +11/04 00:44:59 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:01 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:03 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:05 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:07 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:09 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:11 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:13 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:15 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:17 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:19 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:21 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 +11/04 00:45:23 DEBUG| virt_vm:0660| Cannot find IP address for MAC address 9a:16:a5:3c:05:25 + +... here it gets an IP from the DHCP server ... + +11/04 00:45:24 DEBUG|virt_env_p:0438| (address cache) Adding cache entry: 9a:16:a5:3c:05:25 ---> 192.168.122.195 + +... ok, let's try to login ... + +11/04 00:45:25 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' + +... ouch, not possible to login ... + +11/04 00:45:25 DEBUG| virt_vm:0660| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') + +... message above repeats until ... + +11/04 00:56:59 ERROR| virt_test:0095| Test failed: LoginError: Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG|virt_env_p:0147| Postprocessing VM 'vm1' +11/04 00:56:59 DEBUG|virt_env_p:0166| Param 'kill_vm' specified, killing VM +11/04 00:56:59 DEBUG| kvm_vm:0885| Destroying VM with PID 9827 +11/04 00:56:59 DEBUG| kvm_vm:0889| Trying to shutdown VM with shell command +11/04 00:56:59 DEBUG|virt_utils:0710| Trying to login with command 'ssh -o UserKnownHostsFile=/dev/null -o PreferredAuthentications=password -p 22 root@192.168.122.195' +11/04 00:56:59 DEBUG| kvm_vm:0893| Client said 'connection refused' (output: 'ssh: connect to host 192.168.122.195 port 22: Connection refused\n') +11/04 00:56:59 DEBUG| kvm_vm:0908| Trying to kill VM with monitor command +11/04 00:56:59 INFO | aexpect:0783| [qemu output] (Process terminated with status 0) +11/04 00:57:00 DEBUG| kvm_vm:0916| VM is down +11/04 00:57:00 DEBUG| virt_vm:0318| Checking image file /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img' +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img info /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] image: /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] file format: qcow2 +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] virtual size: 10G (10737418240 bytes) +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] disk size: 2.1G +11/04 00:57:00 DEBUG|base_utils:0106| [stdout] cluster_size: 65536 +11/04 00:57:00 DEBUG|base_utils:0074| Running '/usr/local/autotest/tests/kvm/qemu-img check /tmp/kvm_autotest_root/images/rhel6.1-64.qcow2' + + + +We are currently investigating the failure. One of our suspects is that on kvm autotest, each new qemu process instance might have a new NIC mac address, and that might be triggering some condition in qemu in conjunction to the guest init scripts. + +It is important to note that this problem does not affect qemu-kvm.git, or RHEL based branches for that matter. + +I can't reproduce this with an Ubuntu guest. I suspect it has something to do with how you're configuring networking. + +A little more investigation shows that empty ssh keys are being generated on the first boot, so now it doesn't look like a network problem anymore. now we are trying to figure out just on qemu this phenomenon is happening. + +We've identified that the following commit resolved the issue + + commit 47113ab6b8c5659ad94c69aacca572f731ebb0ac + Author: Wen Congyang <email address hidden> + Date: Fri Nov 4 10:45:58 2011 +0800 + reenable vm_clock when resuming all vcpus + + We disable vm_clock when pausing all vcpus, but we forget to + reenable it when resuming all vcpus. It will cause that the + guest can not be rebooted. + + Tested-by: Zhi Yong Wu <email address hidden> + Reviewed-by: Paolo Bonzini <email address hidden> + Signed-off-by: Wen Congyang <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +That's good, you can close the issue. + +Marking as fixed, according to comment #5 + diff --git a/results/classifier/118/review/886621 b/results/classifier/118/review/886621 new file mode 100644 index 000000000..4a37b6f37 --- /dev/null +++ b/results/classifier/118/review/886621 @@ -0,0 +1,359 @@ +architecture: 0.852 +peripherals: 0.844 +permissions: 0.827 +mistranslation: 0.824 +graphic: 0.811 +risc-v: 0.805 +virtual: 0.801 +register: 0.791 +semantic: 0.780 +vnc: 0.754 +device: 0.753 +TCG: 0.753 +hypervisor: 0.752 +performance: 0.708 +KVM: 0.704 +ppc: 0.700 +arm: 0.687 +VMM: 0.681 +assembly: 0.649 +debug: 0.618 +PID: 0.589 +user-level: 0.540 +kernel: 0.520 +files: 0.500 +socket: 0.471 +network: 0.451 +x86: 0.430 +boot: 0.377 +i386: 0.221 +-------------------- +kernel: 0.935 +hypervisor: 0.675 +debug: 0.613 +virtual: 0.152 +x86: 0.115 +VMM: 0.102 +assembly: 0.093 +TCG: 0.074 +PID: 0.073 +register: 0.055 +semantic: 0.041 +performance: 0.036 +files: 0.027 +boot: 0.018 +KVM: 0.006 +device: 0.005 +user-level: 0.004 +architecture: 0.004 +graphic: 0.002 +permissions: 0.002 +risc-v: 0.001 +i386: 0.001 +network: 0.001 +ppc: 0.001 +socket: 0.001 +mistranslation: 0.001 +peripherals: 0.001 +vnc: 0.000 +arm: 0.000 + +Mac OS X Lion: segmentation fault + + +Process: qemu [5680] +Path: /usr/local/xeos-build/qemu/bin/qemu +Identifier: qemu +Version: ??? (???) +Code Type: X86-64 (Native) +Parent Process: make [5677] + +Date/Time: 2011-11-05 18:53:25.574 +0100 +OS Version: Mac OS X 10.7.2 (11C74) +Report Version: 9 +Sleep/Wake UUID: 3C81B8F7-0321-4621-923C-AB655F2CC701 + +Interval Since Last Report: 503994 sec +Crashes Since Last Report: 35 +Per-App Crashes Since Last Report: 9 +Anonymous UUID: 28E7367A-4697-43A4-8D12-005F1917DFD3 + +Crashed Thread: 0 Dispatch queue: com.apple.main-thread + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000003a + +VM Regions Near 0x3a: +--> + __TEXT 0000000107c75000-0000000107ebc000 [ 2332K] r-x/rwx SM=COW /usr/local/xeos-build/qemu/bin/qemu + +Application Specific Information: +objc[5680]: garbage collection is OFF + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 qemu 0x0000000107d9d0ed 0x107c75000 + 1212653 +1 qemu 0x0000000107dabc39 0x107c75000 + 1272889 +2 ??? 0x000000010c3b007c 0 + 4500160636 + +Thread 1:: Dispatch queue: com.apple.libdispatch-manager +0 libsystem_kernel.dylib 0x00007fff85abb7e6 kevent + 10 +1 libdispatch.dylib 0x00007fff8e7b15be _dispatch_mgr_invoke + 923 +2 libdispatch.dylib 0x00007fff8e7b014e _dispatch_mgr_thread + 54 + +Thread 2: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 3: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 4: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 5: +0 libsystem_kernel.dylib 0x00007fff85abb036 __sigwait + 10 +1 libsystem_c.dylib 0x00007fff8583aaab sigwait + 68 +2 qemu 0x0000000107d221ef 0x107c75000 + 709103 +3 libsystem_c.dylib 0x00007fff858848bf _pthread_start + 335 +4 libsystem_c.dylib 0x00007fff85887b75 thread_start + 13 + +Thread 0 crashed with X86 Thread State (64-bit): + rax: 0x5433ade07f7c29e7 rbx: 0x0000000000000010 rcx: 0x0000000000000000 rdx: 0x0000000000002000 + rdi: 0x0000000000000010 rsi: 0x0000000000000000 rbp: 0x00007fff678714a0 rsp: 0x00007fff67871470 + r8: 0x0000000109fe8000 r9: 0x0000000000000fff r10: 0x00007fa7c185c01d r11: 0x0000000000000246 + r12: 0x00000001087ae368 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000001f80 + rip: 0x0000000107d9d0ed rfl: 0x0000000000010202 cr2: 0x000000000000003a +Logical CPU: 6 + +Binary Images: + 0x107c75000 - 0x107ebbff7 +qemu (??? - ???) <FECE8C8E-BD8E-34F1-B222-32D79C7A0037> /usr/local/xeos-build/qemu/bin/qemu + 0x1087cb000 - 0x1088b5fe7 +libglib-2.0.0.dylib (2704.0.0 - compatibility 2704.0.0) <5E6151CC-61F8-3335-A6FA-EFDD71474FA6> /usr/local/macmade/sw/glib/lib/libglib-2.0.0.dylib + 0x108917000 - 0x10891ffff +libintl.8.dylib (9.1.0 - compatibility 9.0.0) <7D75E177-3172-2F78-1E08-1118A3D2D2A9> /usr/local/webstart/sw/gettext/lib/libintl.8.dylib + 0x108928000 - 0x108949fff +libpng12.0.dylib (23.0.0 - compatibility 23.0.0) <FDE69E98-1D25-EEA1-99CF-F0A04A9AD7FF> /usr/local/webstart/sw/lib-png/lib/libpng12.0.dylib + 0x10895a000 - 0x10897aff7 +libjpeg.62.dylib (63.0.0 - compatibility 63.0.0) <AD465C8A-66A4-E794-CA9A-96FB1B4D6CF0> /usr/local/webstart/sw/lib-jpeg/lib/libjpeg.62.dylib + 0x108987000 - 0x108a67ff7 +libiconv.2.dylib (8.0.0 - compatibility 8.0.0) <54A03BBE-E505-9FF1-79AA-D4D5139BBF9C> /usr/local/webstart/sw/lib-iconv/lib/libiconv.2.dylib + 0x7fff67875000 - 0x7fff678a9ac7 dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld + 0x7fff8547d000 - 0x7fff8547efff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib + 0x7fff8582b000 - 0x7fff8582efff com.apple.help (1.3.2 - 42) <AB67588E-7227-3993-927F-C9E6DAC507FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help + 0x7fff8582f000 - 0x7fff85835fff libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib + 0x7fff85836000 - 0x7fff85913fef libsystem_c.dylib (763.12.0 - compatibility 1.0.0) <FF69F06E-0904-3C08-A5EF-536FAFFFDC22> /usr/lib/system/libsystem_c.dylib + 0x7fff85914000 - 0x7fff85914fff com.apple.audio.units.AudioUnit (1.7.1 - 1.7.1) <04C10813-CCE5-3333-8C72-E8E35E417B3B> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit + 0x7fff85915000 - 0x7fff8591bfff IOSurface (??? - ???) <06FA3FDD-E6D5-391F-B60D-E98B169DAB1B> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface + 0x7fff85964000 - 0x7fff85972fff com.apple.NetAuth (1.0 - 3.0) <F384FFFD-70F6-3B1C-A886-F5B446E456E7> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth + 0x7fff85aa4000 - 0x7fff85ac4fff libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib + 0x7fff85ac5000 - 0x7fff85b10ff7 com.apple.SystemConfiguration (1.11.1 - 1.11) <F832FE21-5509-37C6-B1F1-48928F31BE45> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration + 0x7fff85c2a000 - 0x7fff85c39ff7 com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL + 0x7fff85c3a000 - 0x7fff85c3eff7 com.apple.CommonPanels (1.2.5 - 94) <0BB2C436-C9D5-380B-86B5-E355A7711259> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels + 0x7fff85ebb000 - 0x7fff85fbefff libsqlite3.dylib (9.6.0 - compatibility 9.0.0) <7F60B0FF-4946-3639-89AB-B540D318B249> /usr/lib/libsqlite3.dylib + 0x7fff85fbf000 - 0x7fff86063fef com.apple.ink.framework (1.3.2 - 110) <F69DBD44-FEC8-3C14-8131-CC0245DBBD42> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink + 0x7fff860c5000 - 0x7fff860cafff libpam.2.dylib (3.0.0 - compatibility 3.0.0) <D952F17B-200A-3A23-B9B2-7C1F7AC19189> /usr/lib/libpam.2.dylib + 0x7fff860dd000 - 0x7fff86147fff com.apple.framework.IOKit (2.0 - ???) <87D55F1D-CDB5-3D13-A5F9-98EA4E22F8EE> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit + 0x7fff86148000 - 0x7fff8614ffff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib + 0x7fff8627e000 - 0x7fff862abfe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib + 0x7fff862ac000 - 0x7fff86314ff7 com.apple.Symbolication (1.2 - 89) <1D7F9E72-B1B6-30CF-AC8A-23A763930A92> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication + 0x7fff86315000 - 0x7fff86316ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib + 0x7fff8633a000 - 0x7fff8634cff7 libbsm.0.dylib (??? - ???) <349BB16F-75FA-363F-8D98-7A9C3FA90A0D> /usr/lib/libbsm.0.dylib + 0x7fff8634d000 - 0x7fff863b5ff7 com.apple.audio.CoreAudio (4.0.1 - 4.0.1) <7966E3BE-376B-371A-A21D-9BD763C0BAE7> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio + 0x7fff86411000 - 0x7fff86423ff7 libsasl2.2.dylib (3.15.0 - compatibility 3.0.0) <6245B497-784B-355C-98EF-2DC6B45BF05C> /usr/lib/libsasl2.2.dylib + 0x7fff86428000 - 0x7fff86462fff libncurses.5.4.dylib (5.4.0 - compatibility 5.4.0) <387DE593-9CC5-38C7-911B-A5F2264D34F2> /usr/lib/libncurses.5.4.dylib + 0x7fff86463000 - 0x7fff864a2ff7 libGLImage.dylib (??? - ???) <2D1D8488-EC5F-3229-B983-CFDE0BB37586> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib + 0x7fff864a3000 - 0x7fff86545ff7 com.apple.securityfoundation (5.0 - 55005) <0D59908C-A61B-389E-AF37-741ACBBA6A94> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation + 0x7fff86546000 - 0x7fff865cbff7 com.apple.Heimdal (2.1 - 2.0) <C92E327E-CB5F-3C9B-92B0-F1680095C8A3> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal + 0x7fff865cc000 - 0x7fff865d0fff libCGXType.A.dylib (600.0.0 - compatibility 64.0.0) <5EEAD17D-006C-3855-8093-C7A4A97EE0D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib + 0x7fff865d1000 - 0x7fff8664cff7 com.apple.print.framework.PrintCore (7.1 - 366.1) <3F140DEB-9F87-3672-97CC-F983752581AC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore + 0x7fff8664d000 - 0x7fff86654ff7 com.apple.CommerceCore (1.0 - 17) <AA783B87-48D4-3CA6-8FF6-0316396022F4> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore + 0x7fff86655000 - 0x7fff86655fff com.apple.Accelerate.vecLib (3.7 - vecLib 3.7) <C06A140F-6114-3B8B-B080-E509303145B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff86656000 - 0x7fff8665afff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib + 0x7fff8665b000 - 0x7fff86768fff libJP2.dylib (??? - ???) <6052C973-9354-35CB-AAB9-31D00D8786F9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib + 0x7fff86769000 - 0x7fff867acff7 libRIP.A.dylib (600.0.0 - compatibility 64.0.0) <2B1571E1-8E87-364E-BC36-C9C9B5D3EAC4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib + 0x7fff867ad000 - 0x7fff86d91fff libBLAS.dylib (??? - ???) <C34F6D88-187F-33DC-8A68-C0C9D1FA36DF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib + 0x7fff86d92000 - 0x7fff86da4ff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib + 0x7fff87016000 - 0x7fff8701cfff libGFXShared.dylib (??? - ???) <343AE6C0-EB02-333C-8D35-DF6093B92758> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib + 0x7fff8701d000 - 0x7fff87290fff com.apple.CoreImage (7.82 - 1.0.1) <282801B6-5D80-3E2C-88A4-00FE29906D5A> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage + 0x7fff872da000 - 0x7fff87315fff com.apple.LDAPFramework (3.0 - 120.1) <0C23534F-A8E7-3144-B2B2-50F9875101E2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP + 0x7fff87322000 - 0x7fff87524fff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib + 0x7fff87a4c000 - 0x7fff87a4dfff libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib + 0x7fff87b4f000 - 0x7fff87b4ffff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib + 0x7fff87b50000 - 0x7fff87ba7fff libTIFF.dylib (??? - ???) <FF0D9A24-6956-3F03-81EA-3EEAD22C9DB8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib + 0x7fff87c87000 - 0x7fff8839a587 com.apple.CoreGraphics (1.600.0 - ???) <A9F2451E-6F60-350E-A6E5-539669B53074> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics + 0x7fff8839b000 - 0x7fff883b1ff7 com.apple.ImageCapture (7.0 - 7.0) <69E6E2E1-777E-332E-8BCF-4F0611517DD0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture + 0x7fff883b2000 - 0x7fff883b9fff com.apple.NetFS (4.0 - 4.0) <B9F41443-679A-31AD-B0EB-36557DAF782B> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS + 0x7fff883d7000 - 0x7fff884b5fff com.apple.ImageIO.framework (3.1.1 - 3.1.1) <13E549F8-5BD6-3BAE-8C33-1D0BD269C081> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO + 0x7fff884b6000 - 0x7fff884b6fff com.apple.Cocoa (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa + 0x7fff884b7000 - 0x7fff884b7fff com.apple.ApplicationServices (41 - 41) <03F3FA8F-8D2A-3AB6-A8E3-40B001116339> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices + 0x7fff884b8000 - 0x7fff8861efff com.apple.CFNetwork (520.2.5 - 520.2.5) <406712D9-3F0C-3763-B4EB-868D01F1F042> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork + 0x7fff8861f000 - 0x7fff88943fff com.apple.HIToolbox (1.8 - ???) <A3BE7C59-52E6-3A7F-9B30-24B7DD3E95F2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x7fff88944000 - 0x7fff88961ff7 com.apple.openscripting (1.3.3 - ???) <A64205E6-D3C5-3E12-B1A0-72243151AF7D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting + 0x7fff88962000 - 0x7fff88c3aff7 com.apple.security (7.0 - 55010) <93713FF4-FE86-3B4C-8150-5FCC7F3320C8> /System/Library/Frameworks/Security.framework/Versions/A/Security + 0x7fff88c5b000 - 0x7fff88cbbfff libvDSP.dylib (325.4.0 - compatibility 1.0.0) <3A7521E6-5510-3FA7-AB65-79693A7A5839> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib + 0x7fff88cbf000 - 0x7fff88d43ff7 com.apple.ApplicationServices.ATS (317.5.0 - ???) <FE629F2D-6BC0-3A58-9844-D8B9A6808A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS + 0x7fff88d81000 - 0x7fff88e48ff7 com.apple.ColorSync (4.7.0 - 4.7.0) <F325A9D7-7203-36B7-8C1C-B6A4D5CC73A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync + 0x7fff88e59000 - 0x7fff88e6dff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <04C31EF0-912A-3004-A08F-CEC27030E0B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis + 0x7fff88e6e000 - 0x7fff88e79ff7 com.apple.speech.recognition.framework (4.0.19 - 4.0.19) <7ADAAF5B-1D78-32F2-9FFF-D2E3FBB41C2B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition + 0x7fff88f54000 - 0x7fff88f55fff libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib + 0x7fff89095000 - 0x7fff89148fff com.apple.CoreText (220.11.0 - ???) <4EA8E2DF-542D-38D5-ADB9-C0DAA73F898B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText + 0x7fff8932e000 - 0x7fff894cdfff com.apple.QuartzCore (1.7 - 270.0) <E8FC9AA4-A5CB-384B-AD29-7190A1387D3E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore + 0x7fff894f6000 - 0x7fff89530fe7 com.apple.DebugSymbols (2.1 - 87) <E9000AB8-CCE4-3636-871D-E17703814B68> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols + 0x7fff89531000 - 0x7fff8958cff7 com.apple.HIServices (1.10 - ???) <BAB8B422-7047-3D2D-8E0A-13FCF153E4E7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices + 0x7fff89a1d000 - 0x7fff89a6bfff libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib + 0x7fff89a6c000 - 0x7fff89ac0ff7 com.apple.ScalableUserInterface (1.0 - 1) <1873D7BE-2272-31A1-8F85-F70C4D706B3B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface + 0x7fff89ac1000 - 0x7fff89ae0fff libresolv.9.dylib (46.0.0 - compatibility 1.0.0) <33263568-E6F3-359C-A4FA-66AD1300F7D4> /usr/lib/libresolv.9.dylib + 0x7fff89b26000 - 0x7fff89b65fff com.apple.AE (527.7 - 527.7) <B82F7ABC-AC8B-3507-B029-969DD5CA813D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE + 0x7fff89fd5000 - 0x7fff8a1a9fff com.apple.CoreFoundation (6.7.1 - 635.15) <FE4A86C2-3599-3CF8-AD1A-822F1FEA820F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7fff8a1aa000 - 0x7fff8a1d3fff libJPEG.dylib (??? - ???) <64D079F9-256A-323B-A837-84628B172F21> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib + 0x7fff8a929000 - 0x7fff8a94dfff com.apple.Kerberos (1.0 - 1) <1F826BCE-DA8F-381D-9C4C-A36AA0EA1CB9> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos + 0x7fff8a94e000 - 0x7fff8a94efff com.apple.CoreServices (53 - 53) <043C8026-8EDD-3241-B090-F589E24062EF> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices + 0x7fff8a94f000 - 0x7fff8a9c4ff7 libc++.1.dylib (19.0.0 - compatibility 1.0.0) <C0EFFF1B-0FEB-3F99-BE54-506B35B555A9> /usr/lib/libc++.1.dylib + 0x7fff8af21000 - 0x7fff8afa4fef com.apple.Metadata (10.7.0 - 627.20) <E00156B0-663A-35EF-A307-A2CEB00F1845> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata + 0x7fff8b02d000 - 0x7fff8b036ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib + 0x7fff8b06d000 - 0x7fff8b10cfff com.apple.LaunchServices (480.21 - 480.21) <6BFADEA9-5BC1-3B53-A013-488EB7F1AB57> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices + 0x7fff8b10d000 - 0x7fff8b14efff com.apple.QD (3.12 - ???) <4F3C5629-97C7-3E55-AF3C-ACC524929DA2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD + 0x7fff8b14f000 - 0x7fff8b251ff7 libxml2.2.dylib (10.3.0 - compatibility 10.0.0) <D46F371D-6422-31B7-BCE0-D80713069E0E> /usr/lib/libxml2.2.dylib + 0x7fff8b2f6000 - 0x7fff8b2f9fff libCoreVMClient.dylib (??? - ???) <E034C772-4263-3F48-B083-25A758DD6228> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib + 0x7fff8b2fd000 - 0x7fff8b402ff7 libFontParser.dylib (??? - ???) <B9A53808-C97E-3293-9C33-1EA9D4E83EC8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib + 0x7fff8b41e000 - 0x7fff8b449ff7 libxslt.1.dylib (3.24.0 - compatibility 3.0.0) <8051A3FC-7385-3EA9-9634-78FC616C3E94> /usr/lib/libxslt.1.dylib + 0x7fff8b49e000 - 0x7fff8b4a3fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib + 0x7fff8b656000 - 0x7fff8b65bfff libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib + 0x7fff8b65c000 - 0x7fff8b695fe7 libssl.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <79AAEC98-1258-3DA4-B1C0-4120049D390B> /usr/lib/libssl.0.9.8.dylib + 0x7fff8b696000 - 0x7fff8b69bff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib + 0x7fff8b6c6000 - 0x7fff8b6d1ff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib + 0x7fff8b909000 - 0x7fff8bd36fff libLAPACK.dylib (??? - ???) <4F2E1055-2207-340B-BB45-E4F16171EE0D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib + 0x7fff8bd37000 - 0x7fff8bd42fff com.apple.CommonAuth (2.1 - 2.0) <BFDD0A8D-4BEA-39EC-98B3-2E083D7B1ABD> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth + 0x7fff8bd43000 - 0x7fff8bd76ff7 com.apple.GSS (2.1 - 2.0) <9A2C9736-DA10-367A-B376-2C7A584E6C7A> /System/Library/Frameworks/GSS.framework/Versions/A/GSS + 0x7fff8bd77000 - 0x7fff8bd78ff7 libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib + 0x7fff8bd79000 - 0x7fff8bd7dfff libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib + 0x7fff8bdac000 - 0x7fff8bdc8ff7 com.apple.GenerationalStorage (1.0 - 125) <31F60175-E38D-3C63-8D95-32CFE7062BCB> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage + 0x7fff8bdcd000 - 0x7fff8bdf5ff7 com.apple.CoreVideo (1.7 - 70.1) <98F917B2-FB53-3EA3-B548-7E97B38309A7> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo + 0x7fff8bdf6000 - 0x7fff8be0dfff com.apple.MultitouchSupport.framework (220.62.1 - 220.62.1) <F21C79C0-4B5A-3645-81A6-74F8EFA900CE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport + 0x7fff8be0e000 - 0x7fff8be34ff7 com.apple.framework.familycontrols (3.0 - 300) <41A6DFC2-EAF5-390A-83A1-C8832528705C> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls + 0x7fff8c071000 - 0x7fff8c155def libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <C5F2392D-B481-3A9D-91BE-3D039FFF4DEC> /usr/lib/libobjc.A.dylib + 0x7fff8c156000 - 0x7fff8c17dfff com.apple.PerformanceAnalysis (1.10 - 10) <2A058167-292E-3C3A-B1F8-49813336E068> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis + 0x7fff8c17e000 - 0x7fff8c1c0ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib + 0x7fff8c3ff000 - 0x7fff8c452fff libFontRegistry.dylib (??? - ???) <57FBD85F-41A6-3DB9-B5F4-FCC6B260F1AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib + 0x7fff8c461000 - 0x7fff8c4fbff7 com.apple.SearchKit (1.4.0 - 1.4.0) <4E70C394-773E-3A4B-A93C-59A88ABA9509> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit + 0x7fff8d20f000 - 0x7fff8d24aff7 libsystem_info.dylib (??? - ???) <9C8C2DCB-96DB-3471-9DCE-ADCC26BE2DD4> /usr/lib/system/libsystem_info.dylib + 0x7fff8d24b000 - 0x7fff8d250fff libGIF.dylib (??? - ???) <393E2DB5-9479-39A6-A75A-B5F20B852532> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib + 0x7fff8d251000 - 0x7fff8d268fff com.apple.CFOpenDirectory (10.7 - 144) <9709423E-8484-3B26-AAE8-EF58D1B8FB3F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory + 0x7fff8d269000 - 0x7fff8d26efff com.apple.OpenDirectory (10.7 - 146) <91A87249-6A2F-3F89-A8DE-0E95C0B54A3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory + 0x7fff8d26f000 - 0x7fff8d2c1ff7 libGLU.dylib (??? - ???) <3C9153A0-8499-3DC0-AAA4-9FA6E488BE13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib + 0x7fff8d2c2000 - 0x7fff8d789fff FaceCoreLight (1.4.7 - compatibility 1.0.0) <E9D2A69C-6E81-358C-A162-510969F91490> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight + 0x7fff8d78a000 - 0x7fff8d792fff libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib + 0x7fff8d793000 - 0x7fff8d7bcfff com.apple.CoreServicesInternal (113.8 - 113.8) <C1A3CF1B-BC45-3FC6-82B3-1511EBBA9D51> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal + 0x7fff8d823000 - 0x7fff8d838fff com.apple.speech.synthesis.framework (4.0.74 - 4.0.74) <C061ECBB-7061-3A43-8A18-90633F943295> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis + 0x7fff8e34d000 - 0x7fff8e371ff7 com.apple.RemoteViewServices (1.2 - 39) <862849C8-84C1-32A1-B87E-B29E74778C9F> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices + 0x7fff8e508000 - 0x7fff8e51bff7 libCRFSuite.dylib (??? - ???) <034D4DAA-63F0-35E4-BCEF-338DD7A453DD> /usr/lib/libCRFSuite.dylib + 0x7fff8e7a7000 - 0x7fff8e7a9ff7 com.apple.print.framework.Print (7.1 - 247.1) <8A4925A5-BAA3-373C-9B5D-03E0270C6B12> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print + 0x7fff8e7aa000 - 0x7fff8e7adff7 com.apple.securityhi (4.0 - 1) <B37B8946-BBD4-36C1-ABC6-18EDBC573F03> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI + 0x7fff8e7ae000 - 0x7fff8e7bcfff libdispatch.dylib (187.7.0 - compatibility 1.0.0) <712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib + 0x7fff8e7bd000 - 0x7fff8e7befff liblangid.dylib (??? - ???) <CACBE3C3-2F7B-3EED-B50E-EDB73F473B77> /usr/lib/liblangid.dylib + 0x7fff8e7cc000 - 0x7fff8e7e9fff libPng.dylib (??? - ???) <3C70A94C-9442-3E11-AF51-C1B0EF81680E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib + 0x7fff8e7ea000 - 0x7fff8e7eafff com.apple.Accelerate (1.7 - Accelerate 1.7) <82DDF6F5-FBC3-323D-B71D-CF7ABC5CF568> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate + 0x7fff8e7eb000 - 0x7fff8e801fff libGL.dylib (??? - ???) <6A473BF9-4D35-34C6-9F8B-86B68091A9AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib + 0x7fff8e810000 - 0x7fff8e81aff7 liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib + 0x7fff8e95f000 - 0x7fff8e9f5ff7 libvMisc.dylib (325.4.0 - compatibility 1.0.0) <642D8D54-F9F5-3FBB-A96C-EEFE94C6278B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib + 0x7fff8e9f6000 - 0x7fff8ec10fef com.apple.CoreData (104 - 358.12) <33B1FA75-7970-3751-9DCC-FF809D3E1FA2> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData + 0x7fff8ef91000 - 0x7fff8f2aaff7 com.apple.Foundation (6.7.1 - 833.20) <D922F590-FDA6-3D89-A271-FD35E2290624> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation + 0x7fff8f2ab000 - 0x7fff8f38cfff com.apple.CoreServices.OSServices (478.29 - 478.29) <B487110E-C942-33A8-A494-3BDEDB88B1CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices + 0x7fff8f3c8000 - 0x7fff8f3d5fff libCSync.A.dylib (600.0.0 - compatibility 64.0.0) <931F40EB-CA75-3A90-AC97-4DB8E210BC76> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib + 0x7fff8f44d000 - 0x7fff8f4c0fff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib + 0x7fff8f7e3000 - 0x7fff8f7e3fff com.apple.Carbon (153 - 153) <895C2BF2-1666-3A59-A669-311B1F4F368B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon + 0x7fff8fb82000 - 0x7fff8fc9aff7 com.apple.DesktopServices (1.6.1 - 1.6.1) <4418EAA6-7163-3A77-ABD3-F8289796C81A> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv + 0x7fff8fc9d000 - 0x7fff8fc9ffff com.apple.TrustEvaluationAgent (2.0 - 1) <1F31CAFF-C1C6-33D3-94E9-11B721761DDF> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent + 0x7fff8fca0000 - 0x7fff8fdf9fff com.apple.audio.toolbox.AudioToolbox (1.7.1 - 1.7.1) <4877267E-F736-3019-85D3-40A32A042A80> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox + 0x7fff8fef9000 - 0x7fff8ff39ff7 libcups.2.dylib (2.9.0 - compatibility 2.0.0) <B7173CA4-CE16-3BAB-8D83-185FCEFA15F5> /usr/lib/libcups.2.dylib + 0x7fff8ff9c000 - 0x7fff900a8fff libcrypto.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <3A8E1F89-5E26-3C8B-B538-81F5D61DBF8A> /usr/lib/libcrypto.0.9.8.dylib + 0x7fff900a9000 - 0x7fff900b7ff7 libkxld.dylib (??? - ???) <65BE345D-6618-3D1A-9E2B-255E629646AA> /usr/lib/system/libkxld.dylib + 0x7fff900b8000 - 0x7fff900beff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib + 0x7fff900cb000 - 0x7fff90204fef com.apple.vImage (5.1 - 5.1) <EB634387-CD15-3246-AC28-5FB368ACCEA2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage + 0x7fff9020d000 - 0x7fff9023dff7 com.apple.DictionaryServices (1.2.1 - 158.2) <3FC86118-7553-38F7-8916-B329D2E94476> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices + 0x7fff9024e000 - 0x7fff90343fff libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib + 0x7fff90344000 - 0x7fff9038aff7 libcurl.4.dylib (7.0.0 - compatibility 7.0.0) <EAF61ADC-DC00-34CE-B23E-7238ED54E31D> /usr/lib/libcurl.4.dylib + 0x7fff9038b000 - 0x7fff903a8ff7 libxpc.dylib (77.17.0 - compatibility 1.0.0) <72A16104-2F23-3C22-B474-1953F06F9376> /usr/lib/system/libxpc.dylib + 0x7fff90b3e000 - 0x7fff90b3ffff libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib + 0x7fff90b40000 - 0x7fff90e5cff7 com.apple.CoreServices.CarbonCore (960.18 - 960.18) <6020C3FB-6125-3EAE-A55D-1E77E38BEDEA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore + 0x7fff90e9b000 - 0x7fff90e9bfff com.apple.vecLib (3.7 - vecLib 3.7) <9A58105C-B36E-35B5-812C-4ED693F2618F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff90fe4000 - 0x7fff90feafff com.apple.DiskArbitration (2.4.1 - 2.4.1) <CEA34337-63DE-302E-81AA-10D717E1F699> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration + 0x7fff91024000 - 0x7fff91027fff libRadiance.dylib (??? - ???) <CD89D70D-F177-3BAE-8A26-644EA7D5E28E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib + 0x7fff91220000 - 0x7fff91222fff libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib + 0x7fff91223000 - 0x7fff9128bfff com.apple.CoreSymbolication (2.1 - 71) <0715BF39-D53C-3BFE-BBEA-B8EBF7274850> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication + 0x7fff9128c000 - 0x7fff912eefff com.apple.coreui (1.2.1 - 164.1) <F7972630-F696-3FC5-9FCF-A6E1C8771078> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI + 0x7fff912ef000 - 0x7fff9135ffff com.apple.datadetectorscore (3.0 - 179.4) <2A822A13-94B3-3A43-8724-98FDF698BB12> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore + 0x7fff91367000 - 0x7fff91394ff7 com.apple.opencl (1.50.63 - 1.50.63) <DB335C5C-3ABD-38C8-B6A5-8436EE1484D3> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL + 0x7fff91395000 - 0x7fff91f96ff7 com.apple.AppKit (6.7.2 - 1138.23) <5CD2C850-4F52-3BA2-BA11-3107DFD2D23C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x7fff91f97000 - 0x7fff91f99fff libCVMSPluginSupport.dylib (??? - ???) <61D89F3C-C64D-3733-819F-8AAAE4E2E993> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib + +External Modification Summary: + Calls made by other processes targeting this process: + task_for_pid: 2 + thread_create: 0 + thread_set_state: 0 + Calls made by this process: + task_for_pid: 0 + thread_create: 0 + thread_set_state: 0 + Calls made by all processes on this machine: + task_for_pid: 103153 + thread_create: 1 + thread_set_state: 0 + +VM Region Summary: +ReadOnly portion of Libraries: Total=144.3M resident=100.5M(70%) swapped_out_or_unallocated=43.8M(30%) +Writable regions: Total=185.9M written=3692K(2%) resident=23.0M(12%) swapped_out=0K(0%) unallocated=162.9M(88%) + +REGION TYPE VIRTUAL +=========== ======= +CG backing stores 1496K +CG image 4K +CG raster data 64K +CG shared images 3480K +CoreGraphics 16K +CoreServices 4112K +MALLOC 67.1M +MALLOC guard page 32K +MALLOC_LARGE (reserved) 25.3M reserved VM address space (unallocated) +Memory tag=242 12K +STACK GUARD 24K +Stack 66.5M +VM_ALLOCATE 16.1M +__CI_BITMAP 80K +__DATA 21.1M +__IMAGE 1256K +__LINKEDIT 48.1M +__TEXT 96.2M +__UNICODE 544K +mapped file 32.2M +shared memory 308K +=========== ======= +TOTAL 383.7M +TOTAL, minus reserved VM space 358.4M + +Model: MacBookPro8,3, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 1.70f3 +Graphics: AMD Radeon HD 6750M, AMD Radeon HD 6750M, PCIe, 1024 MB +Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB +Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 +Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 +AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18) +Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports +Network Service: Wi-Fi, AirPort, en1 +Serial ATA Device: APPLE SSD TS512C, 500.28 GB +Serial ATA Device: MATSHITADVD-R UJ-898 +USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3 +USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfa100000 / 2 +USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 5 +USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 7 +USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0253, 0xfa120000 / 4 +USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfd100000 / 2 +USB Device: Freecom Hard Drive XS, 0x07ab (Freecom Computer Peripherals), 0xfc8e, 0xfd120000 / 5 +USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3 + +Having exactly the same problem here... + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/887883 b/results/classifier/118/review/887883 new file mode 100644 index 000000000..b007b9c77 --- /dev/null +++ b/results/classifier/118/review/887883 @@ -0,0 +1,238 @@ +user-level: 0.904 +virtual: 0.832 +semantic: 0.829 +register: 0.824 +graphic: 0.823 +debug: 0.821 +permissions: 0.814 +assembly: 0.812 +architecture: 0.809 +socket: 0.806 +files: 0.802 +device: 0.801 +kernel: 0.799 +performance: 0.791 +arm: 0.787 +hypervisor: 0.782 +PID: 0.771 +mistranslation: 0.769 +network: 0.767 +peripherals: 0.751 +VMM: 0.741 +TCG: 0.734 +boot: 0.728 +vnc: 0.715 +i386: 0.696 +KVM: 0.688 +ppc: 0.675 +risc-v: 0.671 +x86: 0.655 +-------------------- +arm: 0.580 +debug: 0.096 +files: 0.063 +user-level: 0.045 +virtual: 0.034 +architecture: 0.022 +kernel: 0.020 +hypervisor: 0.019 +VMM: 0.018 +TCG: 0.014 +KVM: 0.010 +device: 0.010 +semantic: 0.009 +register: 0.009 +PID: 0.008 +performance: 0.007 +assembly: 0.006 +vnc: 0.005 +risc-v: 0.004 +peripherals: 0.004 +network: 0.004 +boot: 0.004 +socket: 0.003 +x86: 0.002 +graphic: 0.001 +mistranslation: 0.001 +i386: 0.001 +ppc: 0.001 +permissions: 0.001 + +Coverity scan revealed defects + +Coverity scan detected some issues such as RESOURCE_LEAK and REVERSE_INULL etc on qemu-1.0rc1: + +Analysis summary report: +------------------------ +Files analyzed : 830 +Total LoC input to cov-analyze : 576549 +Functions analyzed : 20721 +Paths analyzed : 858376 +New defects found : 428 Total + 2 ARRAY_VS_SINGLETON + 9 CHECKED_RETURN + 19 CONSTANT_EXPRESSION_RESULT + 60 DEADCODE + 43 FORWARD_NULL + 14 INFINITE_LOOP + 36 MISSING_BREAK + 3 MISSING_LOCK + 47 NEGATIVE_RETURNS + 1 NO_EFFECT + 11 NULL_RETURNS + 51 OVERRUN_STATIC + 1 RESOURCE_LEAK + 79 REVERSE_INULL + 20 SIGN_EXTENSION + 7 SIZEOF_MISMATCH + 15 UNINIT + 5 UNREACHABLE + 2 UNUSED_VALUE + 3 USE_AFTER_FREE + +For details, please see attachment. + + + +This is latest result on qemu-1.0-rc3, and I notice that 'RESOURCE_LEAK' is 10 now: + +Analysis summary report: +------------------------ +Files analyzed : 825 +Total LoC input to cov-analyze : 576887 +Functions analyzed : 20639 +Paths analyzed : 896645 +Defect occurrences found : 432 Total + 2 ARRAY_VS_SINGLETON + 4 ATOMICITY + 10 CHECKED_RETURN + 17 CONSTANT_EXPRESSION_RESULT + 62 DEADCODE + 42 FORWARD_NULL + 10 INFINITE_LOOP + 34 MISSING_BREAK + 1 MISSING_LOCK + 44 NEGATIVE_RETURNS + 10 NULL_RETURNS + 46 OVERRUN_STATIC + 10 RESOURCE_LEAK + 78 REVERSE_INULL + 1 REVERSE_NEGATIVE + 18 SIGN_EXTENSION + 7 SIZEOF_MISMATCH + 26 UNINIT + 5 UNREACHABLE + 2 UNUSED_VALUE + 3 USE_AFTER_FREE + +For details, please see attachment. + + + +I believe the ARM ones are bogus (although some could be clearer and simulataneously clear some of the warnings): + +Error: DEADCODE: *** IFDEF dependent +hw/arm_gic.c:409: +dead_error_condition: On this path, the condition "irq < 16" cannot be true. + *** ifdef'd - only true if NVIC defined +hw/arm_gic.c:407: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:406: +assignment: Assigning: "irq" = "(offset - 256U) * 8U + 32U". +hw/arm_gic.c:407: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:391: +new_values: Noticing condition "offset < 256U". +hw/arm_gic.c:410: +dead_error_line: Execution cannot reach this statement "value = 255U;". + +Error: DEADCODE: *** IFDEF dependent on NVIC +hw/arm_gic.c:434: +dead_error_condition: On this path, the condition "irq < 16" cannot be true. +hw/arm_gic.c:432: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:431: +assignment: Assigning: "irq" = "(offset - 384U) * 8U + 32U". +hw/arm_gic.c:432: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:391: +new_values: Noticing condition "offset < 256U". +hw/arm_gic.c:435: +dead_error_line: Execution cannot reach this statement "value = 0U;". + +Error: DEADCODE: *** IFDEF dependent on NVIC +hw/arm_gic.c:451: +dead_error_condition: On this path, the condition "irq < 16" cannot be true. +hw/arm_gic.c:449: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:448: +assignment: Assigning: "irq" = "(offset - 512U) * 8U + 32U". +hw/arm_gic.c:449: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:391: +new_values: Noticing condition "offset < 256U". +hw/arm_gic.c:452: +dead_error_line: Execution cannot reach this statement "irq = 0;". + +Error: DEADCODE: *** IFDEF depedent on NVIC +hw/arm_gic.c:480: +dead_error_condition: On this path, the condition "irq < 32" cannot be true. +hw/arm_gic.c:478: +between: After this line, the value of "irq" is between 32 and 95. +hw/arm_gic.c:477: +assignment: Assigning: "irq" = "offset - 1024U + 32U". +hw/arm_gic.c:478: +new_values: Noticing condition "irq >= 96". +hw/arm_gic.c:472: +new_values: Noticing condition "offset < 1024U". +hw/arm_gic.c:481: +dead_error_line: Execution cannot reach this statement "s->priority1[irq][cpu] = va...". + +Error: DEADCODE: *** Set in ifdef 0'd path +arm-dis.c:4012: +dead_error_condition: On this path, the condition "is_data" cannot be true. +arm-dis.c:3874: +const: After this line, the value of "is_data" is equal to 0. +arm-dis.c:3874: +assignment: Assigning: "is_data" = "0". +arm-dis.c:4014: +dead_error_begin: Execution cannot reach this statement "int i;". + +Error: NEGATIVE_RETURNS: *** I think the -1 value triggers the increment on line 9957 so it isn't -ve as an index +target-arm/translate.c:9873: +var_tested_neg: Assigning: "lj" = a negative value. +target-arm/translate.c:9961: +negative_returns: Using variable "lj" as an index to array "gen_opc_pc". + +Error: OVERRUN_STATIC: *** Safe because irq%8 always =0 and GIC_NIRQ divisible by 8 (but would be better to do irq+8 > GIC_NIRQ +hw/arm_gic.c:274: +assignment: Assigning: "irq" = "(offset - 256U) * 8U". +hw/arm_gic.c:277: +assignment: Assigning: "irq" = "irq += 0". +hw/arm_gic.c:282: +overrun-local: Overrunning static array "s->irq_state", with 96 elements, at position 96 with index variable "irq + i". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:235: *** Don't think so, at that point we know array value !=1023 and array value == irq, so irq can't be 1023 +overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:235:*** Don't think so, at that point we know array value !=1023 and array value == irq, so irq can't be 1023 +overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:461: *** Safe because irq%8=0, and GIC_NIRQ divisibly by 8 (again safer to do irq+8 > GIC_NIRQ) +assignment: Assigning: "irq" = "(offset - 640U) * 8U + 0U". +hw/arm_gic.c:469: +overrun-local: Overrunning static array "s->irq_state", with 96 elements, at position 96 with index variable "irq + i". + +Error: OVERRUN_STATIC: +hw/arm_gic.c:235: *** Same as case above??? +overrun-local: Overrunning static array "s->last_active", with 96 elements, at position 1023 with index variable "irq". + + + +AFAIK a lot of issues reported by coverity have been addressed in the recent versions of QEMU ... is there still anything left here that needs special attention? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/893367 b/results/classifier/118/review/893367 new file mode 100644 index 000000000..d85663479 --- /dev/null +++ b/results/classifier/118/review/893367 @@ -0,0 +1,84 @@ +mistranslation: 0.965 +graphic: 0.795 +device: 0.728 +performance: 0.710 +hypervisor: 0.652 +peripherals: 0.648 +ppc: 0.627 +network: 0.619 +semantic: 0.591 +socket: 0.590 +kernel: 0.583 +architecture: 0.511 +arm: 0.455 +vnc: 0.442 +PID: 0.438 +debug: 0.435 +register: 0.435 +risc-v: 0.371 +files: 0.338 +x86: 0.313 +TCG: 0.311 +boot: 0.307 +virtual: 0.307 +user-level: 0.301 +permissions: 0.273 +assembly: 0.269 +i386: 0.268 +VMM: 0.241 +KVM: 0.216 +-------------------- +x86: 0.967 +i386: 0.718 +kernel: 0.459 +virtual: 0.294 +performance: 0.270 +debug: 0.143 +hypervisor: 0.124 +files: 0.094 +device: 0.083 +ppc: 0.051 +TCG: 0.047 +architecture: 0.026 +arm: 0.024 +register: 0.018 +peripherals: 0.013 +risc-v: 0.009 +assembly: 0.007 +boot: 0.006 +KVM: 0.006 +VMM: 0.005 +semantic: 0.004 +PID: 0.004 +socket: 0.003 +user-level: 0.003 +graphic: 0.001 +network: 0.001 +vnc: 0.001 +permissions: 0.001 +mistranslation: 0.000 + +HPET supports only one IRQ + +The emulated HPET only supports triggering IRQ 2. Since MSIs are by default disabled, this severely limits the usefulness of the HPET as only one timer block can effectively be used (otherwise they would share IRQ 2). Ideally, the HPET should support as much timer blocks as CPUs and each timer block can be driven by a different IRQ. + +TIMER: HPET at fed00000 -> 0xbf500000. +TIMER: HPET vendor 8086 revision 01: LEGACY 64BIT +TIMER: HPET: cap 8086a201 config 0 period 10000000 +TIMER: HPET Timer[0]: config 30 int 4 +TIMER: HPET Timer[1]: config 30 int 4 +TIMER: HPET Timer[2]: config 30 int 4 + +The offending code seems to be: + + /* advertise availability of ioapic inti2 */ + timer->config |= 0x00000004ULL << 32; + +in hw/hpet.c hpet_reset(). + +I assume this has been fixed by this commit here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7a10ef51c2397ac4323b +Or is there still something left to do here? + +No. Looks good to me. + diff --git a/results/classifier/118/review/895 b/results/classifier/118/review/895 new file mode 100644 index 000000000..61b5c770d --- /dev/null +++ b/results/classifier/118/review/895 @@ -0,0 +1,98 @@ +mistranslation: 0.936 +virtual: 0.862 +vnc: 0.861 +debug: 0.784 +performance: 0.779 +graphic: 0.733 +device: 0.723 +peripherals: 0.665 +semantic: 0.587 +risc-v: 0.562 +VMM: 0.508 +PID: 0.491 +hypervisor: 0.437 +kernel: 0.409 +KVM: 0.391 +arm: 0.391 +i386: 0.382 +network: 0.364 +ppc: 0.364 +user-level: 0.326 +boot: 0.309 +x86: 0.308 +architecture: 0.294 +socket: 0.255 +register: 0.247 +permissions: 0.229 +TCG: 0.206 +files: 0.175 +assembly: 0.149 +-------------------- +debug: 0.967 +virtual: 0.943 +vnc: 0.924 +x86: 0.140 +hypervisor: 0.103 +TCG: 0.101 +device: 0.068 +peripherals: 0.065 +VMM: 0.043 +network: 0.040 +user-level: 0.038 +files: 0.028 +KVM: 0.024 +i386: 0.022 +performance: 0.021 +assembly: 0.014 +PID: 0.014 +risc-v: 0.013 +kernel: 0.013 +ppc: 0.012 +arm: 0.008 +semantic: 0.008 +socket: 0.006 +register: 0.004 +graphic: 0.003 +architecture: 0.003 +permissions: 0.002 +boot: 0.002 +mistranslation: 0.001 + +can't find table device while call qemu_input_is_absolute function +Description of problem: +vnc service can‘t run with mouse absolute mode +Steps to reproduce: +1.create a virtual machine with vnc service via virt-manager. + +2.delete mouse and table device if exists. + +3.add table devices first,next add mouse device. + +4.gdb attach corresponding qemu thread, run command +print "%d",qemu_input_is_absolute() +display function return false ,so I can't use mouse with absolute mode. +Additional information: +code in qemu_input_is_absolute() is +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_REL | INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +qemu_input_find_handler function find a handler INPUT_EVENT_MASK_REL or INPUT_EVENT_MASK_ABS,but just compare with INPUT_EVENT_MASK_ABS, +I think it should be +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +thanks for your help. diff --git a/results/classifier/118/review/905095 b/results/classifier/118/review/905095 new file mode 100644 index 000000000..0c0b967d9 --- /dev/null +++ b/results/classifier/118/review/905095 @@ -0,0 +1,438 @@ +user-level: 0.877 +peripherals: 0.793 +permissions: 0.783 +virtual: 0.780 +KVM: 0.766 +register: 0.754 +risc-v: 0.732 +ppc: 0.721 +graphic: 0.712 +device: 0.709 +mistranslation: 0.708 +architecture: 0.699 +PID: 0.688 +hypervisor: 0.685 +kernel: 0.685 +semantic: 0.683 +arm: 0.682 +assembly: 0.681 +debug: 0.677 +performance: 0.676 +boot: 0.675 +network: 0.669 +socket: 0.659 +VMM: 0.650 +vnc: 0.644 +x86: 0.619 +TCG: 0.617 +files: 0.583 +i386: 0.452 +-------------------- +virtual: 0.959 +KVM: 0.787 +user-level: 0.687 +files: 0.658 +hypervisor: 0.386 +permissions: 0.278 +x86: 0.133 +debug: 0.027 +ppc: 0.015 +i386: 0.012 +kernel: 0.011 +TCG: 0.008 +semantic: 0.007 +register: 0.005 +device: 0.003 +PID: 0.002 +VMM: 0.002 +arm: 0.002 +architecture: 0.001 +graphic: 0.001 +risc-v: 0.001 +mistranslation: 0.001 +socket: 0.001 +performance: 0.001 +network: 0.001 +assembly: 0.001 +boot: 0.000 +peripherals: 0.000 +vnc: 0.000 + +qemu-img can't convert vmdk file: Operation not permitted + +There is no reason why the vdmk image can't be converted. Even running it as root does not help. + +$ ls -lh +insgesamt 60G +-rw-rw-rw- 1 root root 479M 2011-09-10 17:47 freetz-linux-1.2.1-disk1.vmdk + +$ sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +I get a similar Error when I try to rum vmdk images directly. After adding a new machine and adding vmdk disks with virt-manager, it tells me when I start the virtual machine: +Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 +kvm: -drive file=/var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk,if=none,id=drive-virtio-disk0,boot=on,format=qcow2: could not open disk image /var/lib/libvirt/images/freetz-linux-1.2.1-disk1.vmdk: Invalid argument + +Runnung raw images works perfectly for me. + +Hint: i have a symlink set: +/var/lib/libvirt$ ls -lh +insgesamt 12K +drwxr-xr-x 2 root root 4,0K 2011-07-26 14:30 boot +lrwxrwxrwx 1 root root 9 2011-08-19 10:47 images -> /home/vms +drwxr-xr-x 2 root root 4,0K 2011-08-19 09:38 network +drwxr-xr-x 5 libvirt-qemu kvm 4,0K 2011-12-16 04:34 qemu + +but this should not be the reason hopefully + +ProblemType: Bug +DistroRelease: Ubuntu 11.04 +Package: qemu-kvm 0.14.0+noroms-0ubuntu4.4 +ProcVersionSignature: Ubuntu 2.6.38-13.52-generic 2.6.38.8 +Uname: Linux 2.6.38-13-generic x86_64 +Architecture: amd64 +CheckboxSubmission: 8f12e98536291f59719792d89958b124 +CheckboxSystem: d00f84de8a555815fa1c4660280da308 +Date: Fri Dec 16 04:24:10 2011 +InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1) +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: Dell Inc. Latitude E5510 +ProcEnviron: + LANGUAGE=de_DE:en + PATH=(custom, user) + LANG=de_DE.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=503213e4-5136-4e60-8a02-7cbd0123dca8 ro quiet splash vt.handoff=7 +SourcePackage: qemu-kvm +UpgradeStatus: Upgraded to natty on 2011-08-18 (119 days ago) +dmi.bios.date: 09/08/2011 +dmi.bios.vendor: Dell Inc. +dmi.bios.version: A11 +dmi.board.name: 023HKR +dmi.board.vendor: Dell Inc. +dmi.board.version: A00 +dmi.chassis.type: 9 +dmi.chassis.vendor: Dell Inc. +dmi.modalias: dmi:bvnDellInc.:bvrA11:bd09/08/2011:svnDellInc.:pnLatitudeE5510:pvr0001:rvnDellInc.:rn023HKR:rvrA00:cvnDellInc.:ct9:cvr: +dmi.product.name: Latitude E5510 +dmi.product.version: 0001 +dmi.sys.vendor: Dell Inc. + + + +I just saw that the image format in my last comment was not set right. After changing it from qcow2 to vmdk I get this error when starting the machine: + +Error starting domain: operation failed: failed to retrieve chardev info in qemu with 'info chardev' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/engine.py", line 956, in asyncfunc + vm.startup() + File "/usr/share/virt-manager/virtManager/domain.py", line 1048, in startup + self._backend.create() + File "/usr/lib/python2.7/dist-packages/libvirt.py", line 330, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirtError: operation failed: failed to retrieve chardev info in qemu with 'info chardev' + +To reproduce the problem feel free to download this image: +http://sourceforge.net/projects/freetz-linux/ + +here's the xml file of the virtual machine + +same on a fresh installed up to date ubuntu 11.10: +sudo qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw /tmp/freetz-linux-1.2.1-disk1.raw +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +up-to-date debian 6.0 says: +# qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img +qemu-img: error while reading + +debian testing says: +qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'freetz-linux-1.2.1-disk1.vmdk' + +debian sid says: +qemu-img convert freetz-linux-1.2.1-disk1.vmdk -O raw freetz1.img +*** glibc detected *** qemu-img: double free or corruption (top): 0x000000000755cd60 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x72656)[0x2b78929df656] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x2b78929e438c] +qemu-img[0x41c4a2] +qemu-img[0x41d1e6] +qemu-img[0x40e6d9] +qemu-img[0x40f247] +qemu-img[0x4055f1] +qemu-img[0x4068ad] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x2b789298bead] +qemu-img[0x404efd] +======= Memory map: ======== +00400000-0045a000 r-xp 00000000 91:e6 114343429 /usr/bin/qemu-img +0065a000-0065f000 rw-p 0005a000 91:e6 114343429 /usr/bin/qemu-img +0065f000-00a60000 rw-p 0065f000 00:00 0 +0755a000-0757b000 rw-p 0755a000 00:00 0 [heap] +2b7891471000-2b7891490000 r-xp 00000000 91:e6 254542713 /lib/x86_64-linux-gnu/ld-2.13.so +2b7891490000-2b7891492000 rw-p 2b7891490000 00:00 0 +2b7891690000-2b7891691000 r--p 0001f000 91:e6 254542713 /lib/x86_64-linux-gnu/ld-2.13.so +2b7891691000-2b7891692000 rw-p 00020000 91:e6 254542713 /lib/x86_64-linux-gnu/ld-2.13.so +2b7891692000-2b7891693000 rw-p 2b7891692000 00:00 0 +2b7891693000-2b789169a000 r-xp 00000000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b789169a000-2b7891899000 ---p 00007000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b7891899000-2b789189a000 r--p 00006000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b789189a000-2b789189b000 rw-p 00007000 91:e6 254542726 /lib/x86_64-linux-gnu/librt-2.13.so +2b789189b000-2b78918b2000 r-xp 00000000 91:e6 89718972 /usr/lib/libz.so.1.2.3.4 +2b78918b2000-2b7891ab1000 ---p 00017000 91:e6 89718972 /usr/lib/libz.so.1.2.3.4 +2b7891ab1000-2b7891ab2000 rw-p 00016000 91:e6 89718972 /usr/lib/libz.so.1.2.3.4 +2b7891ab2000-2b7891ab3000 rw-p 2b7891ab2000 00:00 0 +2b7891ab3000-2b7891ace000 r-xp 00000000 91:e6 115417965 /usr/lib/librbd.so.1.0.0 +2b7891ace000-2b7891ccd000 ---p 0001b000 91:e6 115417965 /usr/lib/librbd.so.1.0.0 +2b7891ccd000-2b7891cce000 rw-p 0001a000 91:e6 115417965 /usr/lib/librbd.so.1.0.0 +2b7891cce000-2b7891eca000 r-xp 00000000 91:e6 115417963 /usr/lib/librados.so.2.0.0 +2b7891eca000-2b78920ca000 ---p 001fc000 91:e6 115417963 /usr/lib/librados.so.2.0.0 +2b78920ca000-2b78920d9000 rw-p 001fc000 91:e6 115417963 /usr/lib/librados.so.2.0.0 +2b78920d9000-2b78920ed000 rw-p 2b78920d9000 00:00 0 +2b78920ed000-2b7892147000 r-xp 00000000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b7892147000-2b7892347000 ---p 0005a000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b7892347000-2b7892349000 r--p 0005a000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b7892349000-2b789234a000 rw-p 0005c000 91:e6 254542231 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.2.0 +2b789234a000-2b789234b000 rw-p 2b789234a000 00:00 0 +2b789234b000-2b789234f000 r-xp 00000000 91:e6 152502901 /lib/libuuid.so.1.3.0 +2b789234f000-2b789254e000 ---p 00004000 91:e6 152502901 /lib/libuuid.so.1.3.0 +2b789254e000-2b789254f000 rw-p 00003000 91:e6 152502901 /lib/libuuid.so.1.3.0 +2b789254f000-2b7892550000 r-xp 00000000 91:e6 254542270 /lib/x86_64-linux-gnu/libaio.so.1.0.1 +2b7892550000-2b789274f000 ---p 00001000 91:e6 254542270 /lib/x86_64-linux-gnu/libaio.so.1.0.1 +2b789274f000-2b7892750000 rw-p 00000000 91:e6 254542270 /lib/x86_64-linux-gnu/libaio.so.1.0.1 +2b7892750000-2b7892767000 r-xp 00000000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892767000-2b7892966000 ---p 00017000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892966000-2b7892967000 r--p 00016000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892967000-2b7892968000 rw-p 00017000 91:e6 254542714 /lib/x86_64-linux-gnu/libpthread-2.13.so +2b7892968000-2b789296d000 rw-p 2b7892968000 00:00 0 +2b789296d000-2b7892ae7000 r-xp 00000000 91:e6 254542727 /lib/x86_64-linux-gnu/libc-2.13.so +2b7892ae7000-2b7892ce7000 ---p 0017a000 91:e6 254542727 /lib/x86_64-linux-gnu/libc-2.13.so +2b7892ceAborted + + +seems to be an older problem: +https://bugzilla.redhat.com/show_bug.cgi?id=548723 + +still getting the error while trying to convert a vmdk + +how to proceed? + +I just generated OVA from vsphere client, then I untarred it and I got a ovf and a vmdk file, how do I convert the vmdk to a readable format by kvm? + +Angelo, a workaround for me was to run the freetz image (which in fact is an ubuntu image) with VirtalBox. Then I booted the Machine with a systemrescuecd CD. + +In systemrescuecd I extracted the disk image using the dd command (disk druid). You can netcat the raw image via network to your KVM machine. The raw image booted without any problems in KVM. + +Hope this works for you. + +Confirmed on ubuntu 11.10: +>> qemu-img convert ZendTo-Ubuntu-x64-disk1.vmdk -O raw zend.img +qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'ZendTo-Ubuntu-x64-disk1.vmdk' + + +Hello, +Could someone please comment on this? There are blogs and such all over the internet talking about how easy it is to use qemu-img convert to convert VMware vmdk's to KVM qcow2's (or other formats). However, every time I do this, no matter what version of Linux or qemu-img I am using, it either a) produces an image but that is only a few MBs and thus obviously unbootable; or b) has the error in comment #9 (Operation not permitted). I see thomas303's workaround but that obviously sounds pretty harsh to be doing on a regular basis as we are looking to support our product on both VMware and KVM. Will this inability to convert vmdk to qcow2 be addressed in qemu soon? + +@Neil, + +it looks like the 2011 google summer of code project did not succeed. I don't know of anyone else working on this problem right now. + +Actually support upstream has improved a lot in recent qemu (thanks to IBM), and Red Hat are planning on doing further work in this area. + +Right now / with old qemu, the best thing is to convert your proprietary vmdk files to a portable format, ie. raw or qcow2, and use that instead. + +I retried with ubuntu 16.04, qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.4). + +While the original file (freetz vmdk) is not available (they use .ova now), I got another .vmdk file from +http://www.osboxes.org/debian/#debian-8-5-vmware + +qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O raw test.raw +qemu-img convert Debian\ 8.5\ \(64bit\).vmdk -O qcow2 test.qcow2 + +Both worked, and I could boot the system I converted from .vmdk using qemu-kvm. + +Looks as if this issue got fixed, finally. + + +I did the same task on totally different images recently and it worked fine. +Thanks for bumping that old bug so we can close it. + +That "Debian 8.5 (64bit).vmdk" also works fine with the qemu-img from upstream master branch ==> I'm closing this ticket now for upstream, too. + +Description of problem: + +qemu-img convert cannot convert a VMDK4 format file to (eg) raw (or +anything else). It silently produces a large file that mostly +contains zero bytes, and is completely unusable. + +Version-Release number of selected component (if applicable): + +Tested with qemu-img 0.10.5, 0.11.0, and +git d9a50a366f2178 (2009-12-11). + +How reproducible: + +Always. + +Steps to Reproduce: +1. Export to OVF from VMWare vSphere / ESX 4.0.0. +2. Copy the resultant disk image to a Fedora machine. +3. Check the SHA1 sums (from *.mf file) to make sure image was not + corrupted during the copy. +4. Run: + qemu-img convert -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw +5. Try to mount / use the resulting raw file, eg. using guestfish. + +Actual results: + +The raw file contains mostly zeroes, see below. It contains zeroes +where there should be partition tables, superblocks etc. and so is +totally unusable. + +Expected results: + +A usable disk image. + +Additional info: + +Compare the entropy of the VMDK file with the resulting raw disk. +I would expect the entropy to be about the same, but you can see the +raw disk is mostly compressible (zeroes). + + $ ls -l TestLinux-disk1.vmdk + -rw-rw-r-- 1 rjones rjones 887312896 2009-12-18 10:35 TestLinux-disk1.vmdk + $ gzip -c TestLinux-disk1.vmdk | wc -c + 860846320 + $ gzip -c TestLinux-disk1.raw | wc -c + 8744715 + +VMWare's OVF metadata says the following about the disk format: + + <References> + <File ovf:href="TestLinux-disk1.vmdk" + ovf:id="file1" ovf:size="887312896" /> + </References> + <DiskSection> + <Info>Virtual disk information</Info> + <Disk ovf:capacity="8" + ovf:capacityAllocationUnits="byte * 2^30" + ovf:diskId="vmdisk1" ovf:fileRef="file1" + ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" /> + </DiskSection> + +qemu-img 0.10.5 fails in a different way. It gives the error +message: + + qemu-img: error while reading + +qemu-img >= 0.11.0 fail silently, no error message or error code. + +I've tried this with several disk images exported from vSphere 4 +and they have all failed to convert in the same way. + +Test files (at time of writing these are STILL UPLOADING, with ETA +of 2009-12-19). + +http://homes.merjis.com/~rich/TestLinux-disk1.vmdk + SHA1: 2C81BAE89210B075ACC51DA9D025935470149D55 +http://homes.merjis.com/~rich/TestLinux.ovf + SHA1: 30831689B8C6F1B1A1FCBB728769B5F71056A580 + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +You don't happen to know if this reproduces with qemu-img > 0.12.x or have a test image I can convert to reproduce handy? + +Nothing much has changed in the qemu vmdk block +driver since I looked at it before (I just checked upstream +git), so it's very likely to be still broken. + +I have some VMDK images, but I warn you that they +are very large! If you have somewhere I can upload +them to, I can send some your way ... + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +I just checked upstream git for the driver again, +and apart from code cleanups the code is still the +same as ever. Therefore moving the bug -> Rawhide. + +Updated links: +http://oirase.annexia.org/tmp/TestLinux-disk1.vmdk + SHA1: 2c81bae89210b075acc51da9d025935470149d55 +http://oirase.annexia.org/tmp/TestLinux.ovf + SHA1: 30831689b8c6f1b1a1fcbb728769b5f71056a580 + +Latest qemu-img no longer silently converts to zeroes. Instead +it gives a strange error: + +$ qemu-img convert -f vmdk -O raw TestLinux-disk1.vmdk TestLinux-disk1.raw +qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted +qemu-img: Could not open 'TestLinux-disk1.vmdk' + +> qemu-img: Could not open 'TestLinux-disk1.vmdk': Operation not permitted + +This is probably because qemu-img.c code expects brdv_open() to return an errno value + + ret = bdrv_open(bs, filename, flags, drv); + if (ret < 0) { + error_report("Could not open '%s': %s", filename, strerror(-ret)); + goto fail; + } + +while the vmdk_open function just returns -1 for everything: + + ... + return 0; + fail: + qemu_free(s->l1_backup_table); + qemu_free(s->l1_table); + qemu_free(s->l2_cache); + return -1; +} + +and by coincidence, '1 == EPERM'. There are ~4 codepaths in vmdk_open that could fail, the VMDK magic check and then a couple of reads of metadata + +There is hope: +http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg03130.html +http://lists.gnu.org/archive/html/qemu-devel/2011-06/threads.html#00033 + +The vmdk from "Export as OVF..." doesn't work. +# qemu-img convert -O raw esx4.1-rhel5.7-i386-disk1.vmdk test-vmdk.raw +qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk' +qemu-img: Could not open 'esx4.1-rhel5.7-i386-disk1.vmdk' + +I copied a vmdk file from ESX storage directly,and then use qemu-img to convert it to raw,it works. +# qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw +# ll test-vmdk.raw +-rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw + +(In reply to comment #11) +> I copied a vmdk file from ESX storage directly,and then use qemu-img to convert +> it to raw,it works. +> # qemu-img convert -O raw esx4.1-rhel5.7-i386-flat.vmdk test-vmdk.raw +> # ll test-vmdk.raw +> -rw-r--r--. 1 root root 8589934592 Feb 17 16:58 test-vmdk.raw + +*-flat.vmdk files are not VMDK. They are just raw files +which happen to have a .vmdk extension. So this doesn't +really prove anything. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This bug has lingered for forever, so I don't think tracking this in Fedora is going to solve much. + +Rich, if you can still reproduce this with qemu.git, I'd recommend filing an upstream bug and publishing a reproducer image like you did before. + diff --git a/results/classifier/118/review/906 b/results/classifier/118/review/906 new file mode 100644 index 000000000..fe8a3aebb --- /dev/null +++ b/results/classifier/118/review/906 @@ -0,0 +1,61 @@ +mistranslation: 0.829 +virtual: 0.565 +performance: 0.540 +device: 0.511 +graphic: 0.483 +permissions: 0.476 +user-level: 0.433 +semantic: 0.382 +network: 0.258 +debug: 0.235 +risc-v: 0.207 +register: 0.191 +ppc: 0.177 +arm: 0.169 +peripherals: 0.163 +hypervisor: 0.148 +assembly: 0.144 +vnc: 0.140 +architecture: 0.132 +socket: 0.125 +kernel: 0.101 +boot: 0.090 +i386: 0.076 +x86: 0.071 +PID: 0.069 +VMM: 0.062 +TCG: 0.049 +KVM: 0.041 +files: 0.038 +-------------------- +files: 0.767 +user-level: 0.224 +virtual: 0.071 +performance: 0.065 +graphic: 0.030 +semantic: 0.021 +peripherals: 0.018 +device: 0.014 +debug: 0.009 +permissions: 0.008 +network: 0.005 +kernel: 0.003 +i386: 0.003 +PID: 0.003 +boot: 0.003 +risc-v: 0.002 +VMM: 0.002 +mistranslation: 0.002 +socket: 0.001 +architecture: 0.001 +hypervisor: 0.001 +TCG: 0.001 +assembly: 0.001 +register: 0.001 +arm: 0.001 +vnc: 0.001 +KVM: 0.001 +x86: 0.001 +ppc: 0.001 + +Cannot IPL this ISO image diff --git a/results/classifier/118/review/910 b/results/classifier/118/review/910 new file mode 100644 index 000000000..7c6f091f7 --- /dev/null +++ b/results/classifier/118/review/910 @@ -0,0 +1,61 @@ +architecture: 0.829 +device: 0.674 +peripherals: 0.648 +performance: 0.647 +network: 0.358 +permissions: 0.338 +arm: 0.324 +virtual: 0.230 +files: 0.214 +semantic: 0.179 +PID: 0.172 +register: 0.166 +graphic: 0.163 +debug: 0.151 +user-level: 0.145 +hypervisor: 0.082 +ppc: 0.052 +mistranslation: 0.051 +socket: 0.046 +assembly: 0.045 +risc-v: 0.039 +boot: 0.037 +VMM: 0.034 +TCG: 0.026 +vnc: 0.019 +kernel: 0.008 +i386: 0.005 +x86: 0.003 +KVM: 0.002 +-------------------- +virtual: 0.986 +hypervisor: 0.951 +boot: 0.395 +user-level: 0.258 +arm: 0.095 +debug: 0.086 +architecture: 0.081 +performance: 0.080 +semantic: 0.039 +TCG: 0.025 +VMM: 0.021 +device: 0.019 +files: 0.012 +graphic: 0.008 +register: 0.007 +KVM: 0.004 +kernel: 0.003 +assembly: 0.003 +PID: 0.002 +risc-v: 0.002 +socket: 0.002 +peripherals: 0.001 +vnc: 0.001 +network: 0.001 +mistranslation: 0.000 +permissions: 0.000 +i386: 0.000 +ppc: 0.000 +x86: 0.000 + +Black screen in qemu 6.2 with wayland, weston, gtk, virgl, ivi shell, Aarch64 diff --git a/results/classifier/118/review/915 b/results/classifier/118/review/915 new file mode 100644 index 000000000..9f8f35a13 --- /dev/null +++ b/results/classifier/118/review/915 @@ -0,0 +1,439 @@ +register: 0.894 +permissions: 0.833 +architecture: 0.784 +virtual: 0.781 +performance: 0.770 +files: 0.759 +socket: 0.756 +device: 0.752 +user-level: 0.750 +PID: 0.738 +graphic: 0.729 +debug: 0.722 +arm: 0.711 +semantic: 0.699 +assembly: 0.687 +peripherals: 0.660 +boot: 0.654 +network: 0.637 +VMM: 0.627 +vnc: 0.622 +kernel: 0.618 +ppc: 0.576 +risc-v: 0.567 +TCG: 0.558 +KVM: 0.556 +hypervisor: 0.553 +mistranslation: 0.547 +x86: 0.430 +i386: 0.408 +-------------------- +ppc: 0.712 +hypervisor: 0.660 +kernel: 0.419 +files: 0.341 +PID: 0.307 +socket: 0.287 +TCG: 0.285 +debug: 0.237 +device: 0.200 +KVM: 0.110 +register: 0.089 +vnc: 0.088 +VMM: 0.083 +network: 0.081 +virtual: 0.069 +semantic: 0.068 +boot: 0.048 +peripherals: 0.038 +architecture: 0.031 +permissions: 0.024 +user-level: 0.017 +risc-v: 0.015 +assembly: 0.007 +performance: 0.007 +graphic: 0.006 +arm: 0.003 +mistranslation: 0.003 +x86: 0.003 +i386: 0.002 + +could not build qemu 6.2.0 in PPC64le +Description of problem: +Qemu 6.2.0 is not building in PPC64le +Additional information: +``` +Build Qemu +Using './build' as the directory for build output +Submodule 'dtc' (https://gitlab.com/qemu-project/dtc.git) registered for path 'dtc' +Submodule 'meson' (https://gitlab.com/qemu-project/meson.git) registered for path 'meson' +Submodule 'ui/keycodemapdb' (https://gitlab.com/qemu-project/keycodemapdb.git) registered for path 'ui/keycodemapdb' +Cloning into '/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/dtc'... +Cloning into '/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/meson'... +Cloning into '/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/ui/keycodemapdb'... +The Meson build system +Version: 0.59.3 +Source dir: /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu +Build dir: /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/build +Build type: native build +Project name: qemu +Project version: 6.2.0 +C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0") +C linker for the host machine: cc ld.bfd 2.34 +Host machine cpu family: ppc64 +Host machine cpu: ppc64le +Program sh found: YES (/usr/bin/sh) +Program python3 found: YES (/usr/bin/python3) +WARNING: Broken python installation detected. Python files installed by Meson might not be found by python interpreter. +C++ compiler for the host machine: c++ (gcc 9.4.0 "c++ (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0") +C++ linker for the host machine: c++ ld.bfd 2.34 +Program cgcc skipped: feature sparse disabled +Library m found: YES +Run-time dependency threads found: YES +Library util found: YES +Run-time dependency appleframeworks found: NO (tried framework) +Found pkg-config: /usr/bin/pkg-config (0.29.1) +Run-time dependency pixman-1 found: YES 0.38.4 +Run-time dependency zlib found: YES 1.2.11 +Library aio skipped: feature linux_aio disabled +Run-time dependency liburing found: NO (tried pkgconfig) +Dependency libxml-2.0 skipped: feature libxml2 disabled +Dependency libnfs skipped: feature libnfs disabled +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency libseccomp found: YES 2.5.1 +Has header "cap-ng.h" : YES +Library cap-ng found: YES +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Library vdeplug skipped: feature vde disabled +Run-time dependency libpulse found: NO (tried pkgconfig) +Run-time dependency alsa found: NO (tried pkgconfig) +Run-time dependency jack found: NO (tried pkgconfig) +Run-time dependency spice-protocol found: NO (tried pkgconfig) +Dependency spice-server skipped: feature spice disabled +Library rt found: YES +Dependency libiscsi skipped: feature libiscsi disabled +Run-time dependency libzstd found: NO (tried pkgconfig) +Dependency virglrenderer skipped: feature virglrenderer disabled +Dependency libcurl skipped: feature curl disabled +Dependency libudev skipped: feature libudev disabled +Library brlapi skipped: feature brlapi disabled +Dependency sdl2 skipped: feature sdl disabled +Library rados found: YES +Has header "rbd/librbd.h" : YES +Library rbd found: YES +Dependency glusterfs-api skipped: feature glusterfs disabled +Library bz2 skipped: feature bzip2 disabled +Has header "lzfse.h" : NO +Has header "sys/soundcard.h" : YES +Run-time dependency gnutls found: NO (tried pkgconfig) +Run-time dependency gnutls found: NO (tried pkgconfig) +libgcrypt-config found: NO need ['>=1.8'] +Run-time dependency libgcrypt found: NO (tried config-tool) +Dependency nettle skipped: feature nettle disabled +Dependency gtk+-3.0 skipped: feature gtk disabled +Library pam skipped: feature auth_pam disabled +Library snappy skipped: feature snappy disabled +Library lzo2 skipped: feature lzo disabled +Dependency libcacard skipped: feature smartcard disabled +Run-time dependency u2f-emu found: NO (tried pkgconfig) +Dependency libusbredirparser-0.5 skipped: feature usb_redir disabled +Dependency libusb-1.0 skipped: feature libusb disabled +Dependency libpmem skipped: feature libpmem disabled +Run-time dependency libdaxctl found: NO (tried pkgconfig) +Run-time dependency libkeyutils found: NO (tried pkgconfig) +Checking for function "gettid" : YES +Run-time dependency libselinux found: YES 3.0 +Run-time dependency fuse3 found: NO (tried pkgconfig) +Run-time dependency libbpf found: NO (tried pkgconfig) +Has header "sys/epoll.h" : YES +Has header "linux/magic.h" : YES +Has header "valgrind/valgrind.h" : NO +Has header "linux/btrfs.h" : YES +Has header "libdrm/drm.h" : NO +Has header "pty.h" : YES +Has header "sys/disk.h" : NO +Has header "sys/ioccom.h" : NO +Has header "sys/kcov.h" : NO +Checking for function "accept4" : YES +Checking for function "clock_adjtime" : YES +Checking for function "dup3" : YES +Checking for function "fallocate" : YES +Checking for function "posix_fallocate" : YES +Checking for function "posix_memalign" : YES +Checking for function "ppoll" : YES +Checking for function "preadv" : YES +Checking for function "sem_timedwait" with dependency threads: YES +Checking for function "sendfile" : YES +Checking for function "setns" : YES +Checking for function "unshare" : YES +Checking for function "syncfs" : YES +Checking for function "sync_file_range" : YES +Checking for function "timerfd_create" : YES +Checking for function "copy_file_range" : YES +Checking for function "openpty" with dependency -lutil: YES +Checking for function "strchrnul" : YES +Checking for function "system" : YES +Header <byteswap.h> has symbol "bswap_32" : YES +Header <sys/epoll.h> has symbol "epoll_create1" : YES +Header <unistd.h> has symbol "environ" : YES +Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : YES +Header <linux/falloc.h> has symbol "FALLOC_FL_KEEP_SIZE" : YES +Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : YES +Has header "linux/fiemap.h" : YES +Header <linux/fs.h> has symbol "FS_IOC_FIEMAP" : YES +Checking for function "getrandom" : YES +Header <sys/random.h> has symbol "GRND_NONBLOCK" : YES +Header <sys/inotify.h> has symbol "inotify_init" : YES +Header <sys/inotify.h> has symbol "inotify_init1" : YES +Header <machine/bswap.h> has symbol "bswap32" : NO +Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : YES +Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : YES +Header <sys/sysmacros.h> has symbol "makedev" : YES +Header <getopt.h> has symbol "optreset" : NO +Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : NO +Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO +Checking whether type "struct stat" has member "st_atim" : YES +Checking for type "struct iovec" : YES +Checking for type "struct utmpx" : YES +Checking for type "struct mmsghdr" : YES +Program scripts/minikconf.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/minikconf.py) +Configuring ppc64-softmmu-config-target.h using configuration +Configuring ppc64-softmmu-config-devices.mak with command +Reading depfile: /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/build/meson-private/ppc64-softmmu-config-devices.mak.d +Configuring ppc64-softmmu-config-devices.h using configuration +Library fdt found: NO +Configuring config-host.h using configuration +Program scripts/hxtool found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/hxtool) +Program scripts/shaderinclude.pl found: YES (/usr/bin/env perl /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/shaderinclude.pl) +Program scripts/qapi-gen.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/qapi-gen.py) +Program scripts/qemu-version.sh found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/qemu-version.sh) + +Executing subproject libvhost-user + +libvhost-user| Project name: libvhost-user +libvhost-user| Project version: undefined +libvhost-user| C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0") +libvhost-user| C linker for the host machine: cc ld.bfd 2.34 +libvhost-user| Dependency threads found: YES unknown (cached) +libvhost-user| Dependency glib-2.0 found: YES 6.2.0 (overridden) +libvhost-user| Build targets in project: 9 +libvhost-user| Subproject libvhost-user finished. + +Program cat found: YES (/usr/bin/cat) +Program scripts/decodetree.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/decodetree.py) +Program ../scripts/modules/module_block.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/block/../scripts/modules/module_block.py) +Program ../scripts/block-coroutine-wrapper.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/block/../scripts/block-coroutine-wrapper.py) +Program scripts/modinfo-collect.py found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/modinfo-collect.py) +Program scripts/modinfo-generate.py found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/modinfo-generate.py) +Program nm found: YES +Program scripts/undefsym.py found: YES (/usr/bin/python3 /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/undefsym.py) +Program scripts/feature_to_c.sh found: YES (/bin/sh /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/scripts/feature_to_c.sh) +Configuring 50-qemu-virtiofsd.json using configuration +Program qemu-keymap found: NO +Program cp found: YES (/usr/bin/cp) +Program sphinx-build-3 sphinx-build skipped: feature docs disabled +Program python3 found: YES (/usr/bin/python3) +Program diff found: YES (/usr/bin/diff) +Program dbus-daemon found: YES (/usr/bin/dbus-daemon) +Program /usr/bin/gdbus-codegen found: YES (/usr/bin/gdbus-codegen) +Program initrd-stress.sh found: YES (/home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/tests/migration/initrd-stress.sh) +Build targets in project: 395 + +qemu 6.2.0 + + Directories + Install prefix : /usr + BIOS directory : share/qemu/qemu + firmware path : /usr/share/qemu/qemu-firmware + binary directory : bin + library directory : lib/qemu + module directory : lib/qemu/qemu + libexec directory : libexec/qemu + include directory : include + config directory : /usr/etc + local state directory : /usr/var + Manual directory : share/man + Doc directory : /usr/share/doc + Build directory : /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/build + Source path : /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu + GIT submodules : ui/keycodemapdb meson dtc + + Host binaries + git : git + make : make + python : /usr/bin/python3 (version: 3.8) + sphinx-build : NO + gdb : /usr/bin/gdb + genisoimage : /usr/bin/genisoimage + + Configurable features + Documentation : NO + system-mode emulation : YES + user-mode emulation : NO + block layer : YES + Install blobs : YES + module support : NO + fuzzing support : NO + Audio drivers : oss + Trace backends : log + QOM debugging : NO + vhost-kernel support : YES + vhost-net support : YES + vhost-crypto support : YES + vhost-scsi support : YES + vhost-vsock support : YES + vhost-user support : YES + vhost-user-blk server support: YES + vhost-user-fs support : YES + vhost-vdpa support : YES + build guest agent : NO + + Compilation + host CPU : ppc64 + host endianness : little + C compiler : cc + Host C compiler : cc + C++ compiler : c++ + CFLAGS : -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -O2 -g + CXXFLAGS : -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -O2 -g + LDFLAGS : -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -z noexecstack -z relro -z now + QEMU_CFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_LDFLAGS : -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -fstack-protector-strong + profiler : NO + link-time optimization (LTO) : NO + PIE : YES + static build : NO + malloc trim support : YES + membarrier : NO + debug stack usage : NO + mutex debugging : NO + memory allocator : system + avx2 optimization : NO + avx512f optimization : NO + gprof enabled : NO + gcov : NO + thread sanitizer : NO + CFI support : NO + strip binaries : YES + sparse : NO + mingw32 support : NO + + Targets and accelerators + KVM support : YES + HAX support : NO + HVF support : NO + WHPX support : NO + NVMM support : NO + Xen support : NO + TCG support : NO + target list : ppc64-softmmu + default devices : YES + out of process emulation : YES + + Block layer support + coroutine backend : ucontext + coroutine pool : YES + Block whitelist (rw) : + Block whitelist (ro) : + Use block whitelist in tools : NO + VirtFS support : YES + build virtiofs daemon : YES + Live block migration : NO + replication support : NO + bochs support : NO + cloop support : NO + dmg support : NO + qcow v1 support : NO + vdi support : NO + vvfat support : NO + qed support : NO + parallels support : NO + FUSE exports : NO + + Crypto + TLS priority : "NORMAL" + GNUTLS support : NO + libgcrypt : NO + nettle : NO + crypto afalg : NO + rng-none : NO + Linux keyring : YES + + Dependencies + SDL support : NO + SDL image support : NO + GTK support : NO + pixman : YES 0.38.4 + VTE support : NO + slirp support : NO + libtasn1 : NO + PAM : NO + iconv support : NO + curses support : NO + virgl support : NO + curl support : NO + Multipath support : NO + VNC support : NO + OSS support : YES + ALSA support : NO + PulseAudio support : NO + JACK support : NO + brlapi support : NO + vde support : NO + netmap support : NO + l2tpv3 support : YES + Linux AIO support : NO + Linux io_uring support : NO + ATTR/XATTR support : YES + RDMA support : NO + PVRDMA support : NO + fdt support : internal + libcap-ng support : YES + bpf support : NO + spice protocol support : NO + rbd support : YES + xfsctl support : NO + smartcard support : NO + U2F support : NO + libusb : NO + usb net redir : NO + OpenGL support : NO + GBM : NO + libiscsi support : NO + libnfs support : NO + seccomp support : YES 2.5.1 + GlusterFS support : NO + TPM support : NO + libssh support : NO + lzo support : NO + snappy support : NO + bzip2 support : NO + lzfse support : NO + zstd support : NO + NUMA host support : NO + libxml2 : NO + capstone : NO + libpmem support : NO + libdaxctl support : NO + libudev : NO + FUSE lseek : NO + selinux : YES 3.0 + + Subprojects + libvhost-user : YES + +Found ninja-1.10.0 at /usr/bin/ninja +``` + +``` +[1330/1767] Compiling C object libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o +FAILED: libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o +cc -Ilibqemu-ppc64-softmmu.fa.p -I. -I.. -Itarget/ppc -I../target/ppc -I../dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/powerpc64le-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu -iquote /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/include -iquote /home/jenkins/workspace/kata-containers-2.0-ppc64le-containerd-k8s-ubuntu-20-04-PR/go/src/github.com/qemu/qemu/disas/libvixl -pthread -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -O2 -fno-semantic-interposition -falign-functions=32 -D_FORTIFY_SOURCE=2 -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="ppc64-softmmu-config-target.h"' '-DCONFIG_DEVICES="ppc64-softmmu-config-devices.h"' -MD -MQ libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o -MF libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o.d -o libqemu-ppc64-softmmu.fa.p/target_ppc_excp_helper.c.o -c ../target/ppc/excp_helper.c +../target/ppc/excp_helper.c: In function ‘powerpc_excp’: +../target/ppc/excp_helper.c:463:29: error: implicit declaration of function ‘cpu_ldl_code’ [-Werror=implicit-function-declaration] + 463 | uint32_t insn = cpu_ldl_code(env, env->nip); + | ^~~~~~~~~~~~ +../target/ppc/excp_helper.c:463:29: error: nested extern declaration of ‘cpu_ldl_code’ [-Werror=nested-externs] +cc1: all warnings being treated as errors +[1331/1767] Compiling C object libqemu-ppc64-softmmu.fa.p/hw_block_dataplane_virtio-blk.c.o +``` diff --git a/results/classifier/118/review/917 b/results/classifier/118/review/917 new file mode 100644 index 000000000..9b53c0e5c --- /dev/null +++ b/results/classifier/118/review/917 @@ -0,0 +1,61 @@ +mistranslation: 0.964 +device: 0.900 +semantic: 0.792 +performance: 0.784 +network: 0.662 +peripherals: 0.589 +assembly: 0.442 +permissions: 0.423 +architecture: 0.422 +graphic: 0.376 +ppc: 0.321 +boot: 0.275 +risc-v: 0.246 +virtual: 0.219 +debug: 0.206 +user-level: 0.190 +register: 0.182 +vnc: 0.173 +VMM: 0.169 +arm: 0.146 +i386: 0.122 +socket: 0.104 +TCG: 0.102 +PID: 0.083 +KVM: 0.079 +files: 0.050 +kernel: 0.049 +hypervisor: 0.021 +x86: 0.016 +-------------------- +peripherals: 0.938 +semantic: 0.784 +device: 0.779 +permissions: 0.215 +user-level: 0.188 +mistranslation: 0.031 +PID: 0.031 +virtual: 0.022 +performance: 0.017 +debug: 0.013 +network: 0.010 +files: 0.008 +VMM: 0.007 +risc-v: 0.003 +graphic: 0.003 +TCG: 0.002 +register: 0.002 +assembly: 0.002 +kernel: 0.001 +boot: 0.001 +architecture: 0.001 +socket: 0.001 +ppc: 0.001 +x86: 0.000 +KVM: 0.000 +arm: 0.000 +hypervisor: 0.000 +i386: 0.000 +vnc: 0.000 + +FireWire Device Passthrough? diff --git a/results/classifier/118/review/917645 b/results/classifier/118/review/917645 new file mode 100644 index 000000000..feeb48883 --- /dev/null +++ b/results/classifier/118/review/917645 @@ -0,0 +1,75 @@ +architecture: 0.843 +graphic: 0.757 +performance: 0.720 +user-level: 0.667 +device: 0.658 +semantic: 0.656 +permissions: 0.608 +mistranslation: 0.607 +register: 0.565 +virtual: 0.564 +network: 0.560 +arm: 0.552 +files: 0.537 +vnc: 0.535 +hypervisor: 0.531 +ppc: 0.523 +risc-v: 0.523 +VMM: 0.522 +PID: 0.508 +peripherals: 0.470 +TCG: 0.433 +socket: 0.427 +kernel: 0.395 +debug: 0.331 +boot: 0.301 +KVM: 0.256 +assembly: 0.219 +x86: 0.178 +i386: 0.057 +-------------------- +architecture: 0.842 +virtual: 0.135 +hypervisor: 0.056 +user-level: 0.025 +TCG: 0.017 +files: 0.016 +network: 0.016 +semantic: 0.012 +register: 0.010 +kernel: 0.010 +PID: 0.007 +boot: 0.004 +device: 0.004 +permissions: 0.003 +VMM: 0.003 +socket: 0.002 +assembly: 0.002 +debug: 0.002 +performance: 0.002 +x86: 0.002 +vnc: 0.001 +mistranslation: 0.001 +risc-v: 0.001 +graphic: 0.001 +ppc: 0.001 +KVM: 0.001 +i386: 0.000 +peripherals: 0.000 +arm: 0.000 + +[Feature request] ia64-softmmu wanted + +Qemu is missing support for full system emulation of the Itanium architecture, which is one of the main non-x86 server architectures today (despite the alleged decline in popularity). It would be really nice if someone had interest in adding full ia64 support to Qemu. Many OS projects could then use Qemu as the universal machine emulator for development and testing. + +Note that there is an open source Ski simulator which can emulate an ia64 CPU, memory and a couple of Ski-specific devices, but the project seems inactive and the simulated machine is too simplified (no real devices, no real firmware). Moreover, it'd be better to have one tool such as Qemu for all architectures of interest rather than one per each architecture. + +It may be actually easier to start with recreating the Ski machine inside QEMU. The result will be a faster Ski in a maintained codebase. Definitely not a bad start. + +Someone is working on it, see: https://github.com/XVilka/qemu-ia64 + +The QEMU project doesn't implement new target architectures or board models on demand based on wishlist requests; they're a lot of work to do. Instead we simply code-review and incorporate board models and architectures as and when people decide to write them and submit the patches. So there's really no point in having a 'wishlist' bug in the bug tracker saying "support for board X would be nice", because it will never happen, unless by the coincidence that somebody happened to implement and submit it to us anyway. + +So I'm going to close this bug as "Won't Fix"; if anybody happens to want to work with upstream on implementing this board model they are welcome to do so -- the mechanism for that is to email qemu-devel (with plans, requests for advice or patches). + + diff --git a/results/classifier/118/review/917824 b/results/classifier/118/review/917824 new file mode 100644 index 000000000..0fdd0d251 --- /dev/null +++ b/results/classifier/118/review/917824 @@ -0,0 +1,133 @@ +register: 0.889 +risc-v: 0.860 +debug: 0.857 +vnc: 0.843 +peripherals: 0.841 +permissions: 0.835 +user-level: 0.835 +ppc: 0.834 +hypervisor: 0.827 +socket: 0.820 +graphic: 0.816 +PID: 0.816 +semantic: 0.810 +architecture: 0.804 +assembly: 0.798 +device: 0.796 +performance: 0.794 +KVM: 0.794 +arm: 0.784 +virtual: 0.777 +TCG: 0.777 +boot: 0.764 +VMM: 0.764 +kernel: 0.763 +mistranslation: 0.740 +network: 0.733 +files: 0.724 +x86: 0.703 +i386: 0.572 +-------------------- +debug: 0.912 +virtual: 0.829 +hypervisor: 0.405 +KVM: 0.396 +x86: 0.101 +user-level: 0.098 +TCG: 0.032 +vnc: 0.014 +i386: 0.011 +register: 0.010 +PID: 0.009 +performance: 0.007 +files: 0.007 +kernel: 0.005 +semantic: 0.004 +assembly: 0.004 +ppc: 0.002 +VMM: 0.002 +network: 0.002 +device: 0.002 +socket: 0.002 +boot: 0.002 +graphic: 0.001 +architecture: 0.001 +arm: 0.001 +risc-v: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +permissions: 0.000 + +qemu loops/hangs on extending qcow2-diskspace + +system is ubuntu 11-10 with qemu-kvm 0.14.1 (standard dpkg) + +while trying to install a software in a winXP-guest on a nearly empty disk within a qcow2-file, qemu stops answering console and vnc. + +gdb on original binary shows, that it doesn't really hang, but seems to endless loop + +recompiling the binary with debugging-symbols shows following problem: + +in block/qcow2-cluster.c:777 there's a loop over an allocation-list, but instead of stopping somewhere, the "next" points to the current one. + QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) { ... } + +because I'm not firm with qemu-development, I don't know, which behaviour would be correct, but simply break this loop doesn't seem to work: a few moments later the process is again at this point (tried so by setting the register for comparison to 0) + +this situation is continuosly reproducible, but it always take at least 10-15min to get there, so please, if you have suggestion which I should try and report, try to give as much suggestions as possible in one action. + +Thanks for reporting this bug and doing the analysis. + +Despite your pinpointing, I'm afraid I don't quite understand where you are saying the problem is. I'm sorry, please bear with me. The QLIST_FOREACH variables are (var, head, field), so we start with &s->cluster_allocs as head, assign 'old_alloc' to s->cluster_allocs.lh_first to begin, use that in the loop, and then on each iteration we set old_allocs = old_allocs->next_in_flight.le_next. What are you saying we should be using instead? + +can you tell me exactly how to reproduce this, with a precise 'qemu-img create' command, precise kvm command, and how big the qcow2 image is when it hangs? Given how reproducible it is for you, I"m surprised I haven't run into it, so I imagine you must be using different options than I usually do. I'll try to reproduce with your exact options, so that I can try on the upstream qemu version to see if this has been fixed upstream. + +Thanks again. + +sorry, if it was not as clear as it should be... + +the assignment you describe is done until old_allocs is NULL (well the asm-test checks against zero, I've not looked at the macrodef of QLIST_FOREACH), but in this special case old_allocs points to address "foobar" *and* old_allocs->next_in_flight.le_next points to same address "foobar", too, so it will never become NULL and will endless loop... + +gdb shows this: +777 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) { +779 uint64_t end_offset = offset + nb_clusters * s->cluster_size; +780 uint64_t old_offset = old_alloc->offset; +779 uint64_t end_offset = offset + nb_clusters * s->cluster_size; +784 if (end_offset < old_offset || offset > old_end_offset) { +782 old_alloc->nb_clusters * s->cluster_size; +781 uint64_t old_end_offset = old_alloc->offset + +784 if (end_offset < old_offset || offset > old_end_offset) { +777 QLIST_FOREACH(old_alloc, &s->cluster_allocs, next_in_flight) { +(gdb) print old_alloc +$1 = (QCowL2Meta *) 0x34cb7a0 +(gdb) print old_alloc->next_in_flight.le_next +$2 = (struct QCowL2Meta *) 0x34cb7a0 + +I've not analyzed, what is done within the loop, but there should be a point of another break-possibility. +I've only understood, that there's something done to expand the allocation of the qcow2-file, because of some needs within the guest. + +because I don't know, how I created that certain disk, I've just started another VM with a newly created disk. this is done via the virt-manager-interface of libvirt. if this tool simply calls qemu-img or may make some api-calls by it's own - I don't know, but if it's as important I'll strace it. +the disk has a maximum of 32768MB with 0 pre-allocated. + +qemu-img info say at the current loop (tried to install the soft again): + +file format: qcow2 +virtual size: 32G (34359738368 bytes) +disk size: 76M +cluster_size: 65536 + +if you want more output out of gdb, tell me. the VM currently hangs and now gdb waits for commands... + + +sorry forgot the requested cmdline of kvm: +kvm -mem-path /VM/tmp -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name winxp -uuid 1c4f4992-9212-4b4c-a14d-25f2f3f28ed2 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/winxp.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=localtime -boot c -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=/VM/winxp/lw-c.img,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/VM/winxp/lw-t.img,if=none,id=drive-ide0-0-1,snapshot=on,format=qcow2 -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/VM/winxp/lw-d.img,if=none,id=drive-ide0-1-1,format=qcow2 -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive file=/VM/winxp/lw-p.img,if=none,id=drive-scsi0-0-0,format=qcow2 -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=13,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:00:c1:a3:f4:45,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:3 -vga std -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +the disk, on which the soft should be installed is that one on the emulated scsi-controller + + +Are you able to reproduce this either with an Ubuntu guest, or on a 12.04 (Precise) host? + +sorry, currently I'm busy and there's too much time gone, that I can check the things in a quick way. I'll try it, when I'm less busy, but this will probably take some weeks... + + +Marking this bug invalid. If you can still reproduce it, please reply to let us know. + diff --git a/results/classifier/118/review/920 b/results/classifier/118/review/920 new file mode 100644 index 000000000..27721d18f --- /dev/null +++ b/results/classifier/118/review/920 @@ -0,0 +1,72 @@ +architecture: 0.950 +graphic: 0.856 +device: 0.813 +vnc: 0.645 +semantic: 0.608 +performance: 0.493 +debug: 0.449 +KVM: 0.411 +register: 0.407 +user-level: 0.364 +virtual: 0.356 +hypervisor: 0.299 +files: 0.294 +mistranslation: 0.252 +permissions: 0.225 +VMM: 0.161 +boot: 0.153 +ppc: 0.144 +PID: 0.140 +risc-v: 0.116 +x86: 0.098 +socket: 0.074 +TCG: 0.069 +assembly: 0.066 +peripherals: 0.060 +kernel: 0.052 +i386: 0.052 +network: 0.048 +arm: 0.038 +-------------------- +debug: 0.863 +virtual: 0.782 +files: 0.477 +kernel: 0.087 +hypervisor: 0.052 +KVM: 0.048 +register: 0.020 +vnc: 0.019 +TCG: 0.018 +graphic: 0.015 +arm: 0.011 +device: 0.009 +semantic: 0.007 +assembly: 0.007 +performance: 0.007 +architecture: 0.005 +risc-v: 0.003 +user-level: 0.003 +boot: 0.003 +VMM: 0.002 +PID: 0.001 +network: 0.001 +peripherals: 0.001 +socket: 0.001 +ppc: 0.001 +permissions: 0.001 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +Aarch64 QEMU+KVM+OVMF RAM Bug +Description of problem: +OVMF EDK2 does not recognize any amount of RAM. It always detects as 0 MB and causes operating systems to crash. +Steps to reproduce: +1. +2. +3. +Additional information: +There was a problem with the Redmi Note 10S device via Termux. +  + + ovmf diff --git a/results/classifier/118/review/922 b/results/classifier/118/review/922 new file mode 100644 index 000000000..058542190 --- /dev/null +++ b/results/classifier/118/review/922 @@ -0,0 +1,80 @@ +architecture: 0.877 +graphic: 0.796 +device: 0.756 +arm: 0.697 +ppc: 0.678 +semantic: 0.572 +x86: 0.571 +performance: 0.543 +register: 0.529 +permissions: 0.506 +debug: 0.486 +vnc: 0.475 +TCG: 0.444 +risc-v: 0.387 +PID: 0.343 +virtual: 0.293 +files: 0.288 +VMM: 0.283 +boot: 0.282 +user-level: 0.260 +hypervisor: 0.195 +socket: 0.147 +network: 0.145 +mistranslation: 0.128 +assembly: 0.079 +kernel: 0.053 +peripherals: 0.051 +KVM: 0.016 +i386: 0.005 +-------------------- +arm: 0.898 +user-level: 0.753 +debug: 0.611 +hypervisor: 0.452 +virtual: 0.374 +register: 0.094 +TCG: 0.090 +PID: 0.058 +files: 0.052 +performance: 0.039 +x86: 0.010 +device: 0.008 +kernel: 0.007 +network: 0.006 +semantic: 0.005 +ppc: 0.004 +assembly: 0.004 +architecture: 0.003 +peripherals: 0.003 +graphic: 0.003 +socket: 0.002 +boot: 0.001 +vnc: 0.001 +risc-v: 0.001 +i386: 0.001 +permissions: 0.001 +VMM: 0.000 +mistranslation: 0.000 +KVM: 0.000 + +QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying. + +This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0 + +I wrote small test to demonstrate this bug. +Steps to reproduce: +1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2) +2. `$ make # To build the docker container` +3. `$ make shell # To run ARM bash` +4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault: +``` +[root@0d81b08f032b /]# /qemu --version +qemu-arm version 6.2.90 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done +Segmentation fault (core dumped) +[root@0d81b08f032b /]# +``` diff --git a/results/classifier/118/review/925 b/results/classifier/118/review/925 new file mode 100644 index 000000000..cb8cca974 --- /dev/null +++ b/results/classifier/118/review/925 @@ -0,0 +1,78 @@ +architecture: 0.901 +register: 0.833 +graphic: 0.770 +device: 0.746 +debug: 0.659 +PID: 0.582 +kernel: 0.575 +ppc: 0.521 +network: 0.517 +user-level: 0.493 +arm: 0.486 +performance: 0.469 +assembly: 0.416 +vnc: 0.416 +peripherals: 0.394 +socket: 0.394 +VMM: 0.346 +semantic: 0.338 +boot: 0.325 +permissions: 0.322 +KVM: 0.311 +risc-v: 0.290 +hypervisor: 0.288 +files: 0.276 +TCG: 0.259 +mistranslation: 0.233 +i386: 0.176 +virtual: 0.169 +x86: 0.122 +-------------------- +assembly: 0.499 +debug: 0.425 +architecture: 0.103 +TCG: 0.096 +register: 0.043 +device: 0.041 +files: 0.037 +kernel: 0.034 +arm: 0.029 +PID: 0.025 +hypervisor: 0.022 +risc-v: 0.016 +performance: 0.016 +virtual: 0.014 +semantic: 0.014 +VMM: 0.012 +peripherals: 0.012 +socket: 0.008 +vnc: 0.004 +network: 0.003 +ppc: 0.003 +boot: 0.003 +graphic: 0.003 +user-level: 0.003 +permissions: 0.002 +mistranslation: 0.002 +KVM: 0.001 +x86: 0.001 +i386: 0.000 + +AArch64 SVE2 LD/ST instructions segfault on MMIO addresses +Description of problem: +During execution of the following SVE2 instruction: `ld1b {z9.s}, p2/z, [x17, z26.s, sxtw]` with the following register state: +``` +(gdb) p $x17 +$1 = 0xffffffe2 +(gdb) p $z26.s.u +$2 = {0x0 <repeats 16 times>} +(gdb) p $p2 +$3 = {0xc4, 0x0, 0x9d, 0x0, 0xe5, 0x0, 0x83, 0x0, 0x80, 0xce, 0x3f, 0x3, 0x0, 0x0, 0x0, 0x0, 0x46, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x56, 0x1a, 0x6e, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x50, 0xce, 0x94, 0x1, 0x0, 0x0, 0x0, 0x0, 0xf0, 0xd8, 0x96, 0xee, 0xfc, 0x7f, 0x0, 0x0, 0x10, 0x38, 0x40, 0x3, 0x0, 0x0, 0x0, 0x0} +``` +QEMU segfaults due to a null pointer access. Note that after translation this address is an MMIO address that points to a UART device. +Additional information: +A quick look at the implementation of the SVE2 load/store host memory access functions I've noticed that the `TLB_MMIO` flag is ignored in `sve_probe_page`, which means that users use the (null) host address as if it was pointing to real memory. This function (or the ones above it) should (probably) throw the appropriate external data abort, otherwise this needs to be instrumented to support reading from MMIO mapped devices. + +<details><summary>Reproducer seed for my future self</summary> +S6008340160849309262|Q|cd4t|pq|w5|lK124 +</details> diff --git a/results/classifier/118/review/929 b/results/classifier/118/review/929 new file mode 100644 index 000000000..01cdd7657 --- /dev/null +++ b/results/classifier/118/review/929 @@ -0,0 +1,93 @@ +x86: 0.929 +architecture: 0.911 +user-level: 0.868 +PID: 0.850 +graphic: 0.770 +performance: 0.692 +device: 0.680 +semantic: 0.663 +ppc: 0.623 +network: 0.521 +arm: 0.519 +vnc: 0.482 +socket: 0.465 +mistranslation: 0.434 +files: 0.412 +permissions: 0.404 +debug: 0.390 +kernel: 0.376 +boot: 0.362 +TCG: 0.328 +risc-v: 0.309 +i386: 0.256 +VMM: 0.246 +peripherals: 0.233 +assembly: 0.210 +register: 0.192 +virtual: 0.178 +hypervisor: 0.159 +KVM: 0.077 +-------------------- +user-level: 0.831 +virtual: 0.680 +x86: 0.624 +debug: 0.170 +hypervisor: 0.127 +files: 0.108 +kernel: 0.044 +TCG: 0.042 +PID: 0.020 +performance: 0.012 +risc-v: 0.008 +architecture: 0.008 +register: 0.008 +semantic: 0.007 +ppc: 0.004 +network: 0.003 +assembly: 0.003 +VMM: 0.003 +device: 0.003 +i386: 0.002 +boot: 0.001 +peripherals: 0.001 +graphic: 0.001 +socket: 0.001 +permissions: 0.001 +arm: 0.001 +KVM: 0.000 +mistranslation: 0.000 +vnc: 0.000 + +qemu-user syscall clone fails +Description of problem: +This seems very similar to the issue reported here (https://bugs.launchpad.net/qemu/+bug/1926996). When attempting to perform the clone syscall, an error of -1 is returned where I would expect it to succeed. Running the same executable outside of qemu works as expected. +Steps to reproduce: +1. gcc clone.c +2. qemu-x86_64 a.out +Additional information: +I've tried building with gcc, zig cc, and clang and the output of each works fine when running natively, but running under qemu fails. I originally discovered it when cross compiling to riscv64 but it doesn't seem to be limited to that architecture. + +``` +// clone.c + +#include <linux/sched.h> +#include <sched.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <stdio.h> + +int main(void) { + + long pid = syscall( SYS_clone, 0, 0, 0, 0, 0 ); + + if (pid < 0) { + printf( "error %ld\n", pid ); + } else if (pid == 0) { + printf( "child %ld\n", pid ); + } else { + printf( "parent %ld\n", pid ); + } + + return 0; +} +``` diff --git a/results/classifier/118/review/939 b/results/classifier/118/review/939 new file mode 100644 index 000000000..be95ea404 --- /dev/null +++ b/results/classifier/118/review/939 @@ -0,0 +1,135 @@ +risc-v: 0.838 +permissions: 0.836 +performance: 0.813 +register: 0.813 +graphic: 0.793 +arm: 0.792 +ppc: 0.779 +user-level: 0.773 +device: 0.769 +semantic: 0.767 +KVM: 0.767 +assembly: 0.767 +debug: 0.764 +architecture: 0.763 +virtual: 0.756 +boot: 0.756 +kernel: 0.753 +peripherals: 0.749 +TCG: 0.741 +socket: 0.733 +hypervisor: 0.730 +files: 0.709 +PID: 0.705 +VMM: 0.693 +vnc: 0.693 +network: 0.668 +mistranslation: 0.599 +x86: 0.587 +i386: 0.572 +-------------------- +user-level: 0.545 +debug: 0.281 +files: 0.155 +performance: 0.107 +TCG: 0.061 +virtual: 0.052 +PID: 0.026 +semantic: 0.016 +hypervisor: 0.012 +device: 0.005 +architecture: 0.005 +VMM: 0.005 +assembly: 0.004 +register: 0.003 +boot: 0.003 +kernel: 0.002 +network: 0.002 +graphic: 0.002 +socket: 0.001 +risc-v: 0.001 +x86: 0.001 +permissions: 0.001 +KVM: 0.001 +peripherals: 0.001 +mistranslation: 0.001 +i386: 0.001 +vnc: 0.001 +ppc: 0.001 +arm: 0.000 + +qemu-mipsn32el user mode emulator allocates pointers beyond upper memory limit +Description of problem: +In qemu-based N32 mips chroots (both BE and LE), I became aware of memory-intensive programs segfaulting, apparently at random. tar, gcc, but only in specific situations. Watching the strace output of gcc, I got the impression that it happens when memory beyond 2Gbyte is allocated. (mips n32 and o32 uses only 31 bit of a pointer, I've been told, so this is somewhat expected, but a segfault is nevertheless wrong.) + +So, I used the following test program, statically linked: +``` +#include <stdlib.h> +#include <stdio.h> +#include <string.h> + +int main() { + + char *pointer; + int i; + + for (i=1; i<301; i++) { + + printf("Allocation %i : ", i); + pointer = malloc(20480000 * sizeof(char)); + + printf(" pointer is %p, ", pointer); + + if (! pointer) { + printf("malloc failed\n"); + exit(0); + }; + + memset(pointer, 0xDB, 20480000); + printf(" filled\n"); + } +}; +``` + +With mips3 n32 I get the following output: +``` +pinacolada ~ # file /var/lib/machines/mips64el-n32/root/memtest +/var/lib/machines/mips64el-n32/root/memtest: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mipsn32el /var/lib/machines/mips64el-n32/root/memtest +Allocation 1 : pointer is 0x40802010, filled +Allocation 2 : pointer is 0x41b8b010, filled +Allocation 3 : pointer is 0x42f14010, filled +[...] +Allocation 51 : pointer is 0x7d8c4010, filled +Allocation 52 : pointer is 0x7ec4d010, filled +qemu: unhandled CPU exception 0x15 - aborting +pc=0x0000000010021944 HI=0x0000000000000004 LO=0x00000000100218f0 ds 02ea 00000000100218f0 0 +GPR00: r0 0000000000000000 at 0000000000000001 v0 000000007ffd6010 v1 0000000026f77200 +GPR04: a0 000000007ffd6010 a1 dbdbdbdbdbdbdbdb a2 0000000001388000 a3 0000000001388000 +GPR08: t0 0000000025252525 t1 0000000025252525 t2 ffffffffffffffff t3 000000001006c369 +GPR12: t4 000000001006c368 t5 0000000000000000 t6 0000000000000000 t7 0000000000000010 +GPR16: s0 0000000000000001 s1 00000000407ffd54 s2 000000001009b270 s3 0000000000000000 +GPR20: s4 0000000010000760 s5 00000000407ffd5c s6 0000000000000000 s7 0000000000000000 +GPR24: t8 0000000000000000 t9 00000000100218f0 k0 0000000000000000 k1 0000000000000000 +GPR28: gp 00000000100a7320 sp 00000000407ffbf0 s8 00000000407ffbf0 ra 0000000010000854 +CP0 Status 0x24800010 Cause 0x00000000 EPC 0x0000000000000000 + Config0 0x80004482 Config1 0xbe61309b LLAddr 0x0000000000000000 + Config2 0x80000000 Config3 0x00000000 + Config4 0x00000000 Config5 0x00000000 +** +ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +``` + +For mips2 o32 I get the more correct looking output +``` +pinacolada ~ # file /var/lib/machines/mips-o32/root/memtest +/var/lib/machines/mips-o32/root/memtest: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mips /var/lib/machines/mips-o32/root/memtest +Allocation 1 : pointer is 0x3ec76008, filled +Allocation 2 : pointer is 0x3d8ed008, filled +Allocation 3 : pointer is 0x3c564008, filled +[...] +Allocation 104 : pointer is 0x4082c008, filled +Allocation 105 : pointer is (nil), malloc failed +``` diff --git a/results/classifier/118/review/939437 b/results/classifier/118/review/939437 new file mode 100644 index 000000000..14d91c4f5 --- /dev/null +++ b/results/classifier/118/review/939437 @@ -0,0 +1,73 @@ +mistranslation: 0.882 +device: 0.812 +network: 0.763 +KVM: 0.723 +semantic: 0.667 +PID: 0.641 +architecture: 0.622 +socket: 0.586 +hypervisor: 0.547 +performance: 0.531 +VMM: 0.512 +graphic: 0.494 +virtual: 0.470 +x86: 0.441 +peripherals: 0.440 +permissions: 0.429 +kernel: 0.426 +files: 0.421 +boot: 0.414 +ppc: 0.411 +user-level: 0.411 +risc-v: 0.390 +vnc: 0.387 +TCG: 0.381 +i386: 0.343 +arm: 0.307 +register: 0.305 +debug: 0.281 +assembly: 0.128 +-------------------- +KVM: 0.989 +virtual: 0.774 +hypervisor: 0.694 +user-level: 0.115 +x86: 0.079 +network: 0.046 +TCG: 0.041 +debug: 0.024 +files: 0.022 +register: 0.018 +PID: 0.017 +i386: 0.010 +ppc: 0.008 +socket: 0.007 +semantic: 0.007 +arm: 0.006 +device: 0.006 +boot: 0.003 +kernel: 0.003 +assembly: 0.002 +permissions: 0.002 +performance: 0.001 +architecture: 0.001 +graphic: 0.001 +peripherals: 0.001 +risc-v: 0.001 +VMM: 0.001 +mistranslation: 0.000 +vnc: 0.000 + +spice is not supported by this qemu build.(ubuntu 12.04) + +$ kvm -spice port=5900,addr=127.0.0.1,disable-ticketing +kvm: -spice port=5900,addr=127.0.0.1,disable-ticketing: there is no option group "spice" +spice is not supported by this qemu build. + +$ kvm -version +QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +Status changed to 'Confirmed' because the bug affects multiple users. + +On precise, use the qemu-kvm-spice package. + diff --git a/results/classifier/118/review/953 b/results/classifier/118/review/953 new file mode 100644 index 000000000..e13ad5ba0 --- /dev/null +++ b/results/classifier/118/review/953 @@ -0,0 +1,61 @@ +architecture: 0.915 +network: 0.815 +device: 0.813 +performance: 0.700 +arm: 0.606 +assembly: 0.460 +socket: 0.431 +register: 0.421 +debug: 0.412 +files: 0.411 +boot: 0.331 +semantic: 0.290 +hypervisor: 0.287 +vnc: 0.274 +permissions: 0.260 +graphic: 0.240 +ppc: 0.188 +virtual: 0.176 +PID: 0.146 +kernel: 0.142 +peripherals: 0.116 +mistranslation: 0.114 +TCG: 0.043 +user-level: 0.042 +VMM: 0.033 +KVM: 0.020 +x86: 0.012 +i386: 0.010 +risc-v: 0.007 +-------------------- +hypervisor: 0.966 +virtual: 0.927 +debug: 0.567 +arm: 0.253 +kernel: 0.152 +assembly: 0.100 +performance: 0.099 +KVM: 0.072 +architecture: 0.052 +semantic: 0.029 +permissions: 0.028 +user-level: 0.026 +files: 0.008 +VMM: 0.006 +device: 0.005 +register: 0.004 +PID: 0.003 +graphic: 0.003 +boot: 0.003 +socket: 0.002 +TCG: 0.001 +network: 0.001 +peripherals: 0.001 +risc-v: 0.001 +ppc: 0.001 +mistranslation: 0.000 +vnc: 0.000 +x86: 0.000 +i386: 0.000 + +qemu-system-aarch64 asserts trying to execute STXP on hosts without HAVE_CMPXCHG128 diff --git a/results/classifier/118/review/955 b/results/classifier/118/review/955 new file mode 100644 index 000000000..f2445f95f --- /dev/null +++ b/results/classifier/118/review/955 @@ -0,0 +1,61 @@ +architecture: 0.834 +device: 0.828 +network: 0.685 +arm: 0.676 +virtual: 0.660 +performance: 0.628 +risc-v: 0.568 +vnc: 0.562 +kernel: 0.544 +hypervisor: 0.505 +socket: 0.505 +peripherals: 0.468 +register: 0.408 +VMM: 0.377 +graphic: 0.352 +boot: 0.348 +debug: 0.303 +semantic: 0.207 +i386: 0.205 +PID: 0.196 +mistranslation: 0.187 +ppc: 0.183 +permissions: 0.178 +x86: 0.159 +TCG: 0.149 +assembly: 0.107 +user-level: 0.083 +files: 0.066 +KVM: 0.042 +-------------------- +peripherals: 0.965 +hypervisor: 0.956 +virtual: 0.882 +risc-v: 0.554 +device: 0.067 +register: 0.025 +arm: 0.024 +assembly: 0.018 +semantic: 0.016 +user-level: 0.013 +x86: 0.012 +TCG: 0.012 +VMM: 0.011 +debug: 0.010 +architecture: 0.009 +files: 0.008 +socket: 0.008 +KVM: 0.007 +kernel: 0.005 +i386: 0.004 +performance: 0.004 +graphic: 0.004 +ppc: 0.002 +boot: 0.002 +PID: 0.001 +permissions: 0.000 +vnc: 0.000 +network: 0.000 +mistranslation: 0.000 + +support multiple UARTs in qemu-riscv-virt by default diff --git a/results/classifier/118/review/956 b/results/classifier/118/review/956 new file mode 100644 index 000000000..ef102af7c --- /dev/null +++ b/results/classifier/118/review/956 @@ -0,0 +1,102 @@ +architecture: 0.912 +graphic: 0.897 +virtual: 0.863 +performance: 0.773 +device: 0.751 +arm: 0.737 +ppc: 0.719 +kernel: 0.707 +semantic: 0.686 +VMM: 0.675 +KVM: 0.669 +files: 0.655 +socket: 0.650 +debug: 0.645 +PID: 0.631 +hypervisor: 0.626 +vnc: 0.615 +network: 0.614 +x86: 0.610 +risc-v: 0.607 +i386: 0.574 +permissions: 0.548 +boot: 0.541 +TCG: 0.482 +peripherals: 0.462 +register: 0.460 +assembly: 0.458 +mistranslation: 0.430 +user-level: 0.392 +-------------------- +arm: 0.999 +debug: 0.682 +hypervisor: 0.329 +kernel: 0.246 +performance: 0.095 +architecture: 0.067 +files: 0.066 +virtual: 0.064 +TCG: 0.055 +device: 0.029 +assembly: 0.021 +PID: 0.019 +user-level: 0.019 +peripherals: 0.018 +register: 0.015 +risc-v: 0.014 +graphic: 0.012 +VMM: 0.012 +KVM: 0.011 +semantic: 0.007 +network: 0.006 +mistranslation: 0.005 +boot: 0.003 +socket: 0.003 +permissions: 0.003 +vnc: 0.002 +ppc: 0.001 +x86: 0.001 +i386: 0.000 + +ARM: When 'virsh dump' exports vmcore, specifies --format compression format, virtual machine assert hangs +Description of problem: +**ARM: virsh dump exports vmcore, specifies --format compression format, virtual machine assert hangs** + +**why 'virsh dump' page size configured as target page size (64KiB), but 'Implement kvm-steal-time' page size configured as host page size (4KB)?** +Steps to reproduce: +The vm image page size is configured as 64KiB, and the host page size is configured as 4KiB + +1.start vm + +2.Execute the virsh dump command to export vmcore + +Specify the compression format of vmcore, --format (kdump-zlib, kdump-snappy, kdump-lzo) + +/usr/bin/virsh dump avocado-vt-vm1 /var/tmp/vm.core --memory-only --format kdump-zlib + +/usr/bin/virsh dump avocado-vt-vm1 /var/tmp/vm.core --memory-only --format kdump-lzo + +/usr/bin/virsh dump avocado-vt-vm1 /var/tmp/vm.core --memory-only --format kdump-snappy + +**expected results**: The vmcore file is successfully exported and the virtual machine is running normally. + +**actual results**: The vmcore file is not exported normally, and the virtual machine is shut down abnormally. +Additional information: +qemu log: + + +host page size: + + +vm page size: + + +dump.c: get_next_page assert: + + +The code for the error assert exit is shown above. Here, it will check whether the memory to be dumped is actually aligned with the termination address. It needs to be aligned with the page size of the virtual machine. You can see through gdb that it is 64KiB. + + + +After binary search, it was found that a feature of kvm_steal_time was added to arm in version 5.2. Added the following code: + diff --git a/results/classifier/118/review/961 b/results/classifier/118/review/961 new file mode 100644 index 000000000..c8f511643 --- /dev/null +++ b/results/classifier/118/review/961 @@ -0,0 +1,61 @@ +architecture: 0.847 +KVM: 0.836 +virtual: 0.754 +permissions: 0.720 +debug: 0.648 +hypervisor: 0.632 +network: 0.618 +semantic: 0.525 +device: 0.444 +mistranslation: 0.420 +performance: 0.414 +arm: 0.393 +files: 0.331 +graphic: 0.318 +peripherals: 0.245 +register: 0.223 +boot: 0.145 +PID: 0.132 +VMM: 0.104 +TCG: 0.095 +user-level: 0.089 +vnc: 0.066 +ppc: 0.057 +risc-v: 0.055 +kernel: 0.046 +socket: 0.012 +assembly: 0.009 +i386: 0.006 +x86: 0.005 +-------------------- +hypervisor: 0.948 +KVM: 0.917 +virtual: 0.881 +kernel: 0.212 +architecture: 0.080 +semantic: 0.046 +debug: 0.045 +user-level: 0.011 +files: 0.011 +assembly: 0.009 +VMM: 0.008 +boot: 0.008 +register: 0.007 +TCG: 0.007 +device: 0.004 +permissions: 0.004 +risc-v: 0.003 +PID: 0.002 +performance: 0.002 +arm: 0.002 +socket: 0.001 +graphic: 0.001 +peripherals: 0.001 +network: 0.000 +mistranslation: 0.000 +vnc: 0.000 +ppc: 0.000 +i386: 0.000 +x86: 0.000 + +Property not found when using aarch64 `-machine=virt,secure=on` with KVM enabled diff --git a/results/classifier/118/review/961757 b/results/classifier/118/review/961757 new file mode 100644 index 000000000..5d2fc1f0c --- /dev/null +++ b/results/classifier/118/review/961757 @@ -0,0 +1,86 @@ +mistranslation: 0.921 +semantic: 0.777 +graphic: 0.752 +files: 0.707 +device: 0.591 +performance: 0.494 +socket: 0.378 +register: 0.373 +ppc: 0.359 +user-level: 0.345 +debug: 0.345 +PID: 0.339 +architecture: 0.338 +risc-v: 0.318 +assembly: 0.309 +peripherals: 0.301 +vnc: 0.274 +network: 0.265 +permissions: 0.243 +virtual: 0.234 +kernel: 0.234 +arm: 0.233 +boot: 0.190 +x86: 0.183 +hypervisor: 0.179 +i386: 0.111 +TCG: 0.095 +VMM: 0.080 +KVM: 0.064 +-------------------- +debug: 0.534 +semantic: 0.110 +user-level: 0.065 +x86: 0.057 +files: 0.028 +virtual: 0.026 +TCG: 0.025 +hypervisor: 0.023 +kernel: 0.018 +device: 0.018 +PID: 0.014 +arm: 0.012 +performance: 0.009 +register: 0.008 +i386: 0.007 +assembly: 0.006 +peripherals: 0.004 +ppc: 0.004 +boot: 0.004 +network: 0.004 +risc-v: 0.004 +architecture: 0.003 +VMM: 0.002 +socket: 0.002 +vnc: 0.001 +mistranslation: 0.001 +graphic: 0.001 +permissions: 0.001 +KVM: 0.000 + +wrong error for blockdev-snapshot-sync + +From Laszlo Ersek: + +>> + proto_drv = bdrv_find_protocol(snapshot_file); +>> if (!proto_drv) { +>> - qerror_report(QERR_INVALID_BLOCK_FORMAT, format); +>> - ret = -1; +>> - goto out; +>> + error_set(errp, QERR_INVALID_BLOCK_FORMAT, format); +>> + return; +>> } +> +> I don't understand the logic here (based on the error message). We +> specified "format" for the case when a completely new snapshot file has +> to be created. If the file exists already, then bdrv_find_protocol() +> tries to find the driver for it. If that fails, then we must report an +> error indeed, but instead of referring to "format", we'd have to report +> the "scheme" from the beginning of "snapshot_file". + +Which version of QEMU was this? Is this still a problem with the latest version of QEMU? + +I can't find anything in the blockdev-snapshot-sync path that has this code in it still. Think it's a non-issue in 2017. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/review/963 b/results/classifier/118/review/963 new file mode 100644 index 000000000..e2599f4f9 --- /dev/null +++ b/results/classifier/118/review/963 @@ -0,0 +1,61 @@ +mistranslation: 0.857 +network: 0.652 +device: 0.642 +architecture: 0.574 +vnc: 0.528 +performance: 0.493 +socket: 0.453 +register: 0.453 +graphic: 0.448 +VMM: 0.427 +arm: 0.414 +kernel: 0.386 +debug: 0.366 +ppc: 0.346 +assembly: 0.331 +hypervisor: 0.315 +permissions: 0.305 +TCG: 0.305 +peripherals: 0.260 +risc-v: 0.249 +boot: 0.226 +files: 0.222 +semantic: 0.215 +PID: 0.186 +i386: 0.172 +virtual: 0.139 +x86: 0.123 +KVM: 0.120 +user-level: 0.058 +-------------------- +virtual: 0.920 +hypervisor: 0.892 +debug: 0.356 +files: 0.258 +x86: 0.063 +KVM: 0.030 +semantic: 0.025 +TCG: 0.021 +kernel: 0.020 +i386: 0.014 +register: 0.012 +user-level: 0.011 +assembly: 0.007 +arm: 0.007 +ppc: 0.006 +VMM: 0.005 +performance: 0.004 +PID: 0.004 +device: 0.004 +boot: 0.003 +architecture: 0.003 +graphic: 0.003 +mistranslation: 0.002 +risc-v: 0.001 +permissions: 0.001 +socket: 0.001 +peripherals: 0.001 +network: 0.001 +vnc: 0.000 + +qemu-7.0.0-rc2/migration/ram.c:1292: possible wrong operator ? diff --git a/results/classifier/118/review/966 b/results/classifier/118/review/966 new file mode 100644 index 000000000..4c4cc290b --- /dev/null +++ b/results/classifier/118/review/966 @@ -0,0 +1,118 @@ +user-level: 0.807 +graphic: 0.797 +semantic: 0.796 +permissions: 0.791 +performance: 0.744 +virtual: 0.733 +device: 0.722 +risc-v: 0.719 +mistranslation: 0.704 +debug: 0.696 +PID: 0.694 +register: 0.694 +vnc: 0.686 +arm: 0.669 +architecture: 0.656 +files: 0.655 +TCG: 0.643 +assembly: 0.641 +peripherals: 0.628 +ppc: 0.623 +kernel: 0.607 +boot: 0.591 +socket: 0.587 +VMM: 0.578 +network: 0.566 +KVM: 0.542 +x86: 0.538 +hypervisor: 0.515 +i386: 0.391 +-------------------- +kernel: 0.975 +performance: 0.971 +arm: 0.961 +virtual: 0.941 +hypervisor: 0.723 +PID: 0.362 +debug: 0.175 +KVM: 0.142 +TCG: 0.092 +files: 0.046 +register: 0.024 +socket: 0.008 +device: 0.008 +risc-v: 0.007 +VMM: 0.004 +semantic: 0.003 +user-level: 0.003 +architecture: 0.003 +vnc: 0.002 +assembly: 0.001 +network: 0.001 +boot: 0.001 +permissions: 0.001 +graphic: 0.001 +peripherals: 0.001 +ppc: 0.000 +mistranslation: 0.000 +x86: 0.000 +i386: 0.000 + +simple code line is so slow on rv6(rust os) than ubuntu +Description of problem: +[Simple code line for getppid](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L470) takes so long time(About 0.08 microsec, which is about 70% time of ubuntu getppid() syscall) on kernel. So we wonder if there is a problem with the qemu or kvm side settings. +Steps to reproduce: +``` +git clone https://github.com/kaist-cp/rv6 +cd rv6 +make clean +RUST_MODE=release TARGET=arm GIC_VERSION=3 KVM=yes make qemu +``` +Additional information: +We are currently working on the [rv6 project](https://github.com/kaist-cp/rv6) which is porting MIT's educational operating system [xv6](https://github.com/mit-pdos/xv6-public) to Rust.<br> Our code is located [here](https://github.com/kaist-cp/rv6/tree/main/kernel-rs). +We use qemu and [qemu's virt platform](https://qemu.readthedocs.io/en/latest/system/arm/virt.html) to execute rv6, and it works well with using qemu. +Executing command on arm machine is this: +``` +RUST_MODE=release TARGET=arm KVM=yes GIC_VERSION=3; # compile +qemu-system-aarch64 -machine virt -kernel kernel/kernel -m 128M -smp 1 -nographic -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 -cpu host -enable-kvm -machine gic-version=3 +``` +Now, we are comparing the speed(exactly, elapsed wall clock time) of system call of qemu+rv6+kvm and qemu+ubuntu 18.04+kvm with [lmbench](http://lmbench.sourceforge.net/). +For ubuntu, qemu command is this: +``` +qemu-system-aarch64 -cpu host -enable-kvm -device rtl8139,netdev=net0 -device virtio-scsi-device -device scsi-cd,drive=cdrom -device virtio-blk-device,drive=hd0 -drive "file=${iso},id=cdrom,if=none,media=cdrom" -drive "if=none,file=${img_snapshot},id=hd0" -m 2G -machine "virt,gic-version=3,its=off" -netdev user,id=net0 -nographic -pflash "$flash0" -pflash "$flash1" -smp 1 +``` +Now, our goal is to make rv6 perform similar or faster than ubuntu for relatively simple system call like getppid(). <br> +Relatively simple system call means, for example, in the case of getppid(), the actual system call execution part is so simple. So it mainly measures the time for user space -> kernel space -> user space. <br> +And we thought that on getppid() syscall, rv6 could show similar performance or more faster than ubuntu cause it's simple system.<br> +**The most important problem** is that, although it will be described later, a [simple code line for getppid](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L470) takes so long time(About 0.08 microsec, which is about 70% time of ubuntu getppid() syscall) on kernel. So we wonder if there is a problem with the qemu or kvm side settings. + +First, the measured performance result for lmbench's "lat_syscall null" which executes internally getppid() is: + - rv6, Rust opt-level: 1, smp 3(qemu), gcc optimization level: -O -> average 1.662 microsec + - ubuntu, smp 3, gcc optimization level: -O -> average 0.126 microsec +So we see that rv6 is so slower than ubuntu over 10x. + +To find the bottleneck of rv6, we use [linux perf](https://perf.wiki.kernel.org/index.php/Main_Page) and divided execution path into 4 stages. <br> +Stage 1: Call getppid in the user space to until just before the trap handler is called<br> +Stage 2: From after stage 1 to until just before the start of code specific to sys_getppid.<br> +Stage 3: From after stage 2 to [end of actual sys_getppid function](https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L468-L473)<br> +Stage 4: From after stage 3 to the point which getppid syscall returns on user space<br> +The result with perf was: + - ubuntu: 0.042 microsec/ 0.0744 microsec / 0.00985 microsec / 0 -> total 0.126 microsec + - rv6: ? / ? / 0.3687 microsec / ? -> 1.662 microsec + - we made assumption for ubuntu stage 4 time is zero. + - The question mark is, on rv6 we couldn't use perf so only stage 3 time is measured for right now, but checked stage 3 part manually. + +So from the result, it can be confirmed that the rv6's stage 3 already consumes more than 3 times of ubuntu's syscall total time, and at least 30 times more than ubuntu's stage 3. +This is so bad, so we tried several things to inspect the problem: + - Check whether rv6's timer interrupt affects execution time: The interval is 100ms which is so big, so it seems not related. + - To check user space's execution speed, we made simple quick sort program and check rv6's user space speed is significantly slower than ubuntu. + - When running 100,000 times, rv6(smp 1, opt-level 1)'s execution time: 3.2s vs ubuntu(smp 1)'s execution time: 2.7s. + - Although it is 20% slower, it is judged that there is almost no difference compared to the lmbench result. So we thought it is no big problem. + + - Next we checked rv6's stage 3's code. https://github.com/kaist-cp/rv6/blob/main/kernel-rs/src/proc/procs.rs#L468 + - The lock is held twice at line 469 and line 472, whereas ubuntu's same code part, lock is held only once. So first if we change the structure to hold lock only once, there will be improvement in speed. we noticed that. + - **Also there's a big problem on 470 line.** We measured time for 470 line with CNTPCT_EL0 register, and it was found that at least 0.08 microsec was consumed in the corresponding line. + - So ubuntu's stage 3 consumes about 0.01 microsec, but only line 470 of rv6, which does not have complicated logic(it also doesn't hold lock) consumes about 8 times that ubuntu's stage 3. + - So we concluded that there may be a problem with the kvm setting on the kernel side or other settings. + +So do you have any idea for this problem? Thank you for your help. diff --git a/results/classifier/118/review/990 b/results/classifier/118/review/990 new file mode 100644 index 000000000..a319f3da2 --- /dev/null +++ b/results/classifier/118/review/990 @@ -0,0 +1,61 @@ +architecture: 0.942 +virtual: 0.915 +device: 0.850 +network: 0.822 +hypervisor: 0.737 +VMM: 0.735 +arm: 0.621 +vnc: 0.554 +semantic: 0.430 +graphic: 0.398 +boot: 0.386 +risc-v: 0.377 +performance: 0.372 +ppc: 0.359 +peripherals: 0.340 +register: 0.323 +x86: 0.288 +assembly: 0.288 +socket: 0.284 +i386: 0.282 +files: 0.237 +KVM: 0.215 +debug: 0.207 +TCG: 0.183 +kernel: 0.160 +mistranslation: 0.145 +PID: 0.120 +permissions: 0.107 +user-level: 0.072 +-------------------- +virtual: 0.987 +hypervisor: 0.964 +VMM: 0.143 +architecture: 0.122 +kernel: 0.122 +KVM: 0.052 +semantic: 0.030 +files: 0.029 +register: 0.019 +risc-v: 0.017 +device: 0.009 +x86: 0.009 +TCG: 0.008 +assembly: 0.007 +boot: 0.005 +network: 0.005 +user-level: 0.004 +arm: 0.004 +graphic: 0.003 +peripherals: 0.002 +i386: 0.002 +permissions: 0.002 +ppc: 0.002 +PID: 0.002 +performance: 0.001 +socket: 0.001 +debug: 0.001 +mistranslation: 0.000 +vnc: 0.000 + +support for vIOMMU and vSR-IOV together in L1 as virtual machine diff --git a/results/classifier/118/review/995758 b/results/classifier/118/review/995758 new file mode 100644 index 000000000..058abe1bc --- /dev/null +++ b/results/classifier/118/review/995758 @@ -0,0 +1,77 @@ +mistranslation: 0.969 +ppc: 0.898 +architecture: 0.840 +graphic: 0.838 +device: 0.835 +semantic: 0.817 +performance: 0.809 +permissions: 0.709 +i386: 0.697 +kernel: 0.686 +socket: 0.651 +boot: 0.648 +files: 0.634 +network: 0.632 +register: 0.632 +vnc: 0.619 +user-level: 0.611 +x86: 0.609 +arm: 0.592 +PID: 0.575 +peripherals: 0.571 +risc-v: 0.545 +debug: 0.541 +assembly: 0.503 +VMM: 0.490 +TCG: 0.484 +hypervisor: 0.464 +KVM: 0.448 +virtual: 0.384 +-------------------- +x86: 0.522 +semantic: 0.287 +i386: 0.118 +VMM: 0.058 +TCG: 0.053 +virtual: 0.035 +register: 0.030 +network: 0.025 +files: 0.025 +debug: 0.018 +PID: 0.017 +boot: 0.013 +kernel: 0.012 +device: 0.010 +socket: 0.009 +architecture: 0.007 +user-level: 0.007 +performance: 0.006 +hypervisor: 0.006 +KVM: 0.004 +assembly: 0.004 +vnc: 0.003 +graphic: 0.001 +mistranslation: 0.001 +permissions: 0.001 +ppc: 0.001 +peripherals: 0.001 +risc-v: 0.001 +arm: 0.000 + +Possibly inaccurate statement in PC Platform Docs + +The documentation at: + +http://wiki.qemu.org/Documentation/Platforms/PC + +Contains the statement that the processor, after reset, executes code starting from address 0xFFFFF, corresponding to the last byte of the single megabyte of memory in the old 8086 address range. + +From my recollection of working in the microcomputer industry in the late 1980's, execution actually starts in real mode at the start of the last 16 bytes of addressable memory, at 0xFFFF0. Think about it - if it's the last byte there's no room for an address operand to accompany a 1-byte opcode. + +Oh, and if I recall correctly, on the 80286 and 80386 and 80486, on reset the amount of addressable memory was 16MiB, 4GiB and 4GiB respectively, and IBM made the choice to map the BIOS ROMs to both the top of addressable memory and at the top of the first MiB. The CPU's themselves always reset to near the top of their address range, and the BIOS writers promptly jumped back down to somewhere near the top of the first MiB. + + +As far as I can see, the wording on the page only says that the BIOS ends at address 0xFFFFF, not that it starts execution at exactly that address. So I think that page is ok. + +OK, I just read the text again, and the sentences before the one with the 0xfffff indeed sounded like the the start address was at the last byte. I've reworded the text now a little bit so that it should be more accurate. + |