diff options
Diffstat (limited to 'results/classifier/105/instruction')
509 files changed, 27863 insertions, 0 deletions
diff --git a/results/classifier/105/instruction/1006655 b/results/classifier/105/instruction/1006655 new file mode 100644 index 00000000..4094b3c3 --- /dev/null +++ b/results/classifier/105/instruction/1006655 @@ -0,0 +1,153 @@ +instruction: 0.799 +graphic: 0.799 +semantic: 0.752 +mistranslation: 0.724 +vnc: 0.714 +device: 0.713 +other: 0.713 +network: 0.623 +boot: 0.616 +assembly: 0.582 +KVM: 0.579 +socket: 0.571 + +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/105/instruction/1006702 b/results/classifier/105/instruction/1006702 new file mode 100644 index 00000000..376129c5 --- /dev/null +++ b/results/classifier/105/instruction/1006702 @@ -0,0 +1,26 @@ +instruction: 0.780 +graphic: 0.688 +semantic: 0.677 +mistranslation: 0.673 +device: 0.635 +network: 0.574 +other: 0.547 +vnc: 0.520 +socket: 0.439 +boot: 0.372 +KVM: 0.354 +assembly: 0.190 + +something wrong in function type_initialize() in object.c in the source code of qemu-1.1.0 + +In the function type_initialize() in file object.c, about line 237, the sentence : + memset((void *)ti->class + class_size, 0, ti->class_size - class_size); +after the + if (type_has_parent(ti)){} +will clean the information copied from the parent in the if block. +I'm wondering whether this will lead to a bug. Thanks. + +That code has been remove with this commit: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=745549c8d0273d3a3d9c3701 +... so I think we can close this ticket nowadays. + diff --git a/results/classifier/105/instruction/1007 b/results/classifier/105/instruction/1007 new file mode 100644 index 00000000..00f1b846 --- /dev/null +++ b/results/classifier/105/instruction/1007 @@ -0,0 +1,14 @@ +instruction: 0.896 +device: 0.712 +network: 0.541 +socket: 0.394 +semantic: 0.267 +graphic: 0.256 +assembly: 0.198 +vnc: 0.188 +boot: 0.166 +mistranslation: 0.115 +other: 0.041 +KVM: 0.018 + +qemu-user: add execveat syscall support diff --git a/results/classifier/105/instruction/1011 b/results/classifier/105/instruction/1011 new file mode 100644 index 00000000..6c8d51fa --- /dev/null +++ b/results/classifier/105/instruction/1011 @@ -0,0 +1,34 @@ +instruction: 0.828 +device: 0.789 +graphic: 0.772 +vnc: 0.706 +semantic: 0.601 +network: 0.400 +socket: 0.356 +mistranslation: 0.227 +boot: 0.201 +other: 0.125 +assembly: 0.094 +KVM: 0.061 + +hvf: RDTSCP capability not passed to guests +Description of problem: + +Steps to reproduce: +1. Run: +wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso +./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso + +2. login as "root" +3. type + +cat /etc/cpuinfo | grep rdtscp + +Expected result: cpu flag lines including rdtscp +Actual result: empty, with: + +warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27] +Additional information: +This patch apparently resolves the issue according to my tests: + +https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/ diff --git a/results/classifier/105/instruction/1027 b/results/classifier/105/instruction/1027 new file mode 100644 index 00000000..3e35e9d9 --- /dev/null +++ b/results/classifier/105/instruction/1027 @@ -0,0 +1,28 @@ +instruction: 0.701 +device: 0.700 +other: 0.667 +graphic: 0.636 +network: 0.613 +semantic: 0.507 +mistranslation: 0.502 +vnc: 0.499 +socket: 0.453 +KVM: 0.293 +boot: 0.288 +assembly: 0.127 + +Executables should have embedded plist on macOS +Description of problem: +QEMU binaries on macOS should have an embedded property list (`plist`). + +The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). + +When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier). + +All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary: + +``` +-sectcreate __TEXT __info_plist YourPlistFile.plist +``` + +This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code. diff --git a/results/classifier/105/instruction/1030104 b/results/classifier/105/instruction/1030104 new file mode 100644 index 00000000..0a42dc7b --- /dev/null +++ b/results/classifier/105/instruction/1030104 @@ -0,0 +1,45 @@ +instruction: 0.744 +device: 0.622 +network: 0.558 +other: 0.526 +socket: 0.524 +mistranslation: 0.493 +semantic: 0.473 +graphic: 0.427 +vnc: 0.314 +boot: 0.287 +assembly: 0.164 +KVM: 0.060 + +Parallel build doesn't work after "make clean" + +After running "make clean" qemu won't build with -j option. +When I run "./configure && make clean" and then make -j5, following errors occur: + GEN config-host.h + GEN trace.h + GEN qemu-options.def + GEN qmp-commands.h + GEN qapi-types.h + GEN qapi-visit.h + GEN tests/test-qapi-types.h + GEN tests/test-qapi-visit.h + GEN tests/test-qmp-commands.h + GEN qapi-generated/qga-qapi-types.h + GEN qapi-generated/qga-qapi-visit.h + GEN qapi-generated/qga-qmp-commands.h + CC osdep.o + CC qemu-thread-posix.o +cc1: error: qapi-generated: No such file or directory [-Werror] +cc1: all warnings being treated as errors + +make: *** [qemu-thread-posix.o] Error 1 +make: *** Waiting for unfinished jobs.... +cc1: error: qapi-generated: No such file or directory [-Werror] +cc1: all warnings being treated as errors + +make: *** [osdep.o] Error 1 + +If you run "make -j5" once again after this, build continues succesfully because "qapi-generated" directory already exists. + +I think this should have been fixed at one point in time - at least it seems to work for me, so I'm closing this ticket now. If you still have problems, feel free to open this ticket again, but then please specify the exact version of QEMU which causes the trouble for you. + diff --git a/results/classifier/105/instruction/1037 b/results/classifier/105/instruction/1037 new file mode 100644 index 00000000..d49dc107 --- /dev/null +++ b/results/classifier/105/instruction/1037 @@ -0,0 +1,14 @@ +instruction: 0.686 +device: 0.426 +mistranslation: 0.253 +semantic: 0.215 +graphic: 0.183 +network: 0.113 +vnc: 0.050 +other: 0.029 +socket: 0.029 +boot: 0.016 +KVM: 0.013 +assembly: 0.011 + +Let's encrypt certificate for *.qemu.org has expired diff --git a/results/classifier/105/instruction/105 b/results/classifier/105/instruction/105 new file mode 100644 index 00000000..99c92188 --- /dev/null +++ b/results/classifier/105/instruction/105 @@ -0,0 +1,14 @@ +instruction: 0.880 +device: 0.874 +graphic: 0.483 +network: 0.454 +assembly: 0.389 +other: 0.361 +socket: 0.312 +mistranslation: 0.305 +vnc: 0.234 +semantic: 0.209 +boot: 0.186 +KVM: 0.011 + +Gdb hangs when trying to single-step after an invalid instruction diff --git a/results/classifier/105/instruction/1052857 b/results/classifier/105/instruction/1052857 new file mode 100644 index 00000000..03b4ef79 --- /dev/null +++ b/results/classifier/105/instruction/1052857 @@ -0,0 +1,61 @@ +instruction: 0.810 +device: 0.801 +other: 0.794 +socket: 0.765 +graphic: 0.735 +mistranslation: 0.696 +semantic: 0.695 +network: 0.690 +boot: 0.679 +vnc: 0.650 +assembly: 0.649 +KVM: 0.432 + +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/105/instruction/1053 b/results/classifier/105/instruction/1053 new file mode 100644 index 00000000..cd632d88 --- /dev/null +++ b/results/classifier/105/instruction/1053 @@ -0,0 +1,22 @@ +instruction: 0.915 +device: 0.726 +other: 0.620 +graphic: 0.463 +semantic: 0.437 +socket: 0.389 +vnc: 0.319 +boot: 0.315 +network: 0.297 +KVM: 0.276 +mistranslation: 0.242 +assembly: 0.212 + +Executable PMP regions of size less than 4K always trigger an instruction access fault +Description of problem: +When configuring a PMP region that is less than 4K in size (Page size), and then trying to execute instructions inside said region, TCG always throws a PMP exception, even though the area allows code execution. +Additional information: +I've debugged the issue already, and it's happening because of the following optimization in TCG: + +TCG uses `get_page_addr_code_hostp` in order to try and get the translation cached for a whole page of instructions; if this function is unable to translate a whole page, it's supposed to simply return `-1`, and then the caller is supposed to translate and execute on a per-instruction basis. In this case `get_page_addr_code_hostp` calls `tlb_fill`, which then calls `riscv_cpu_tlb_fill`, which then calls `get_physical_address_pmp` to perform the PMP access checks. When said instructions are covered by a PMP region which is smaller than a page, this check then fails, since PMP regions must cover the whole access in order to allow it. At this point `riscv_cpu_tlb_fill` will see that a PMP fault happened, and since `probe` is set to false by `get_page_addr_code_hostp`, it will throw a RISC-V access fault exception instead of just returning a failure that `get_page_addr_code_hostp` can handle (by only accessing the memory of the specific instruction instead, which will be fully covered by the PMP region). + +I haven't tried to fix it myself (my first idea is to simply make `get_page_addr_code_hostp` set the probe flag), since I'm not sure if changing that part of TCG will affect other architectures that I'm not aware of. diff --git a/results/classifier/105/instruction/1057 b/results/classifier/105/instruction/1057 new file mode 100644 index 00000000..5815e3de --- /dev/null +++ b/results/classifier/105/instruction/1057 @@ -0,0 +1,36 @@ +instruction: 0.938 +semantic: 0.521 +device: 0.491 +other: 0.379 +assembly: 0.282 +graphic: 0.233 +network: 0.207 +mistranslation: 0.133 +socket: 0.065 +KVM: 0.060 +vnc: 0.056 +boot: 0.050 + +AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions +Description of problem: +I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction: +`0x0000000000000000: C3 44 00 B8 str w3, [x6], #4` + +notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting. + +Here is the relevant part of the manual: + +``` +For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts: +• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback). +``` + +However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions. + +Another example of instruction: `0x00000000000002f8: 01 1C 40 38 ldrb w1, [x0, #1]!` +Steps to reproduce: +1. Run some hypervisor in EL2 +2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP) +3. Observe the value of ESR_EL2 on data abort + +Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch. diff --git a/results/classifier/105/instruction/1060 b/results/classifier/105/instruction/1060 new file mode 100644 index 00000000..8fd9d546 --- /dev/null +++ b/results/classifier/105/instruction/1060 @@ -0,0 +1,46 @@ +instruction: 0.859 +mistranslation: 0.718 +other: 0.662 +device: 0.604 +graphic: 0.540 +semantic: 0.443 +assembly: 0.442 +vnc: 0.323 +socket: 0.226 +boot: 0.186 +network: 0.177 +KVM: 0.052 + +RISC-V: mtval/stval is not correctly set to the instruction itself on illegal instructions +Description of problem: +QEMU 7.0 claims to support `stval`/`mtval` for illegal instructions, but `mtval`/`stval` is actually set to `0` +Steps to reproduce: +1. Assemble and link `mtval-illegal.elf`. The code simply sets up a trap handler and generates an illegal instruction exception + +2. Start QEMU with: + + ``` + qemu-system-riscv64 -cpu rv64,h=off -bios mtval-illegal.elf -nographic -icount shift=0 -s -S + ``` + +3. Attach with GDB: + + ``` + gdb mtval-illegal.elf + + # Within GDB + target extended-remote :1234 + break trap + disp $mtval + + # Keep single stepping until breakpoint + stepi + ``` + +4. When control flow reaches `trap`, `mtval` is written with `0` instead of the encoding of `csrw time, x0` (`0xc0101073`) +Additional information: +Writing `0` to `mtval` on a illegal instruction trap is allowed by the specs, but since the [changelog of QEMU 7.0][changelog] says it should be supported, I would consider it a bug. + +[changelog]: https://wiki.qemu.org/ChangeLog/7.0#RISC-V + +I encountered this when trying to figure out why my program worked with QEMU 6 but breaks with QEMU 7. It's more complicated, but in that case I managed to get `mtval` written with neither `0` nor the actual illegal instruction, but a different illegal instruction. I will try gathering up all the dependencies and write down the steps to reproduce if needed and if I find the time. diff --git a/results/classifier/105/instruction/1061778 b/results/classifier/105/instruction/1061778 new file mode 100644 index 00000000..f1861c20 --- /dev/null +++ b/results/classifier/105/instruction/1061778 @@ -0,0 +1,27 @@ +instruction: 0.757 +network: 0.738 +socket: 0.655 +device: 0.564 +semantic: 0.535 +graphic: 0.481 +vnc: 0.374 +mistranslation: 0.268 +boot: 0.168 +other: 0.128 +assembly: 0.117 +KVM: 0.043 + +signal mask not reset on exec + +Seen in qemu-1.0 under 12.04, but AFAICT from current git it hasn't changed. + +./main-loop.c:qemu_signal_init blocks SIGALRM so it can be handled via signalfd. + +./net/tap.c:launch_script does not reset the signal mask before the execv() call, and signal masks are inherited. So the script is run with SIGALRM blocked (as can be seen in /proc/$$/status, "SigBlk: 0000000000002000"). One reasonable example of where this bites is an interface up script that calls ping with a timeout to give things a chance to settle down before continuing, but abort if this doesn't happen within a reasonable time). Since ping uses SIGALRM for the timeout, this now never terminates. + +qemu-0.14 didn't block SIGALRM, so such scripts worked fine there. + +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/105/instruction/1062 b/results/classifier/105/instruction/1062 new file mode 100644 index 00000000..67d2da1c --- /dev/null +++ b/results/classifier/105/instruction/1062 @@ -0,0 +1,29 @@ +instruction: 0.925 +graphic: 0.906 +assembly: 0.851 +device: 0.826 +mistranslation: 0.798 +socket: 0.727 +network: 0.651 +semantic: 0.646 +vnc: 0.606 +other: 0.562 +boot: 0.478 +KVM: 0.082 + +AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32 +Description of problem: +In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support. + +This would break this EL3 code, which should run on cpu reset to attempt to return to EL1: +```asm +mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked +mov SPSR_EL3, x1 +adr x1, 1f +msr ELR_EL3, x1 +eret +1: +; something something +``` +Additional information: + diff --git a/results/classifier/105/instruction/1065 b/results/classifier/105/instruction/1065 new file mode 100644 index 00000000..c7ae0c81 --- /dev/null +++ b/results/classifier/105/instruction/1065 @@ -0,0 +1,18 @@ +instruction: 0.921 +device: 0.886 +graphic: 0.829 +network: 0.720 +other: 0.534 +vnc: 0.511 +socket: 0.422 +mistranslation: 0.369 +boot: 0.329 +semantic: 0.313 +assembly: 0.156 +KVM: 0.059 + +cputlb: uninitialized local variable in tlb_set_page_with_attrs cause SIGSEGV when a CPU access an unmapped IOMMU page +Description of problem: +When a TCG cpu accesses an unmapped page within an IOMMU region that causes a translation fault, QEMU SIGSEGVs in `io_readx`. +The reason was that in `address_space_translate_for_iotlb`, `xlat` is not set on a permission fault. +As a result, `xlat` in `tlb_set_page_with_attr` is uninitialized. This in turn causes various mis-calculation and eventually crashes in `io_readx`. diff --git a/results/classifier/105/instruction/1076445 b/results/classifier/105/instruction/1076445 new file mode 100644 index 00000000..b4f044b5 --- /dev/null +++ b/results/classifier/105/instruction/1076445 @@ -0,0 +1,65 @@ +instruction: 0.953 +device: 0.818 +graphic: 0.779 +other: 0.717 +mistranslation: 0.700 +boot: 0.698 +semantic: 0.696 +socket: 0.690 +network: 0.556 +vnc: 0.487 +assembly: 0.471 +KVM: 0.371 + +qemu-i386 fails on system(3) with a cross-toolchain from Buildroot + +qemu-i386 fails with small C program containing a system(). +The C program is cross-compiled with a toolchain created by buildroot (http://buildroot.net/), gcc version 4.6.3, uClibc version 0.9.33.2 . +qemu version 1.2.0 (built with http://git.buildroot.net/buildroot/tree/package/qemu/qemu.mk) +host machine : Ubuntu 12.04 LTS on x86_64. + + $ cat sys.c + #include <stdio.h> + #include <stdlib.h> + + int main() + { + int ret = system("echo hello"); + printf("%d\n", ret); + } + + $ ../../host/usr/bin/i686-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-i386 ./sys + -1 + +same problem with x86_64 : + $ ../../host/usr/bin/x86_64-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-x86_64 sys + -1 + +works fine with arm : + $ ../../host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-arm ./sys + hello + 0 + +works fine with mips : + $ ../../host/usr/bin/mips-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped + $ ../../host/usr/bin/qemu-mips sys + hello + 0 + +Looks like the long-standing "clone/fork for i386 user mode targets doesn't work" issue. See also discussion in bug 739785... + + +Fixed in 2013 some time. + + diff --git a/results/classifier/105/instruction/1078892 b/results/classifier/105/instruction/1078892 new file mode 100644 index 00000000..b971721c --- /dev/null +++ b/results/classifier/105/instruction/1078892 @@ -0,0 +1,24 @@ +instruction: 0.861 +device: 0.781 +boot: 0.714 +graphic: 0.701 +vnc: 0.544 +semantic: 0.510 +other: 0.462 +mistranslation: 0.376 +network: 0.376 +socket: 0.350 +KVM: 0.114 +assembly: 0.107 + +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/105/instruction/1079080 b/results/classifier/105/instruction/1079080 new file mode 100644 index 00000000..c3723248 --- /dev/null +++ b/results/classifier/105/instruction/1079080 @@ -0,0 +1,43 @@ +instruction: 0.967 +graphic: 0.903 +device: 0.901 +semantic: 0.833 +network: 0.755 +socket: 0.707 +vnc: 0.648 +boot: 0.648 +other: 0.637 +mistranslation: 0.619 +assembly: 0.187 +KVM: 0.100 + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic + +It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009. + +Can you make the test case dtb and image available? That would help in testing... + + + + + + +Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/ + +If you'd like to give me a name/email [format "Full Name <email address hidden>"] I can credit you in a Reported-by: tag in the commit message... + + +You are welcome. +Credit info you need: Cesson Vincent <email address hidden> +Thank you for fixing it! + diff --git a/results/classifier/105/instruction/1085 b/results/classifier/105/instruction/1085 new file mode 100644 index 00000000..2e838b3d --- /dev/null +++ b/results/classifier/105/instruction/1085 @@ -0,0 +1,53 @@ +instruction: 0.989 +graphic: 0.898 +socket: 0.760 +device: 0.687 +network: 0.677 +other: 0.565 +vnc: 0.525 +semantic: 0.515 +boot: 0.437 +mistranslation: 0.288 +KVM: 0.277 +assembly: 0.217 + +QEMU 7.0.0 - NSIS installer issue +Description of problem: +Misisng info in QEMU.nsi file +Steps to reproduce: +The exe installer exe file properties has a lot of porpeties missing + + + +This is casued by mssing instruction like + +VIAddVersionKey "ProductName" "" +VIAddVersionKey "ProductVersion" "" +VIAddVersionKey "Comments" "" +VIAddVersionKey "CompanyName" "" +VIAddVersionKey "LegalTrademarks" "" +VIAddVersionKey "LegalCopyright" "" +VIAddVersionKey "FileVersion" "" +VIAddVersionKey "FileDescription" "" + +VIAddVersionKey "InternalName" "" +VIAddVersionKey "OriginalFilename" "" + +In Windows program òlist about uninstalle + +the QEMU icon is not right (generic icon) +The Is missing teh publisg + + + +This si due error on + +!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico" + +that probably point to an icon file not available + +and an misisng line that set Publisher info for uninstalelr + +WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "" + +Thanks. KR. diff --git a/results/classifier/105/instruction/109 b/results/classifier/105/instruction/109 new file mode 100644 index 00000000..592b1b76 --- /dev/null +++ b/results/classifier/105/instruction/109 @@ -0,0 +1,14 @@ +instruction: 0.758 +device: 0.687 +network: 0.509 +semantic: 0.372 +KVM: 0.369 +mistranslation: 0.311 +boot: 0.307 +vnc: 0.270 +socket: 0.211 +other: 0.201 +assembly: 0.171 +graphic: 0.153 + +Make Uninstall Rule Requested diff --git a/results/classifier/105/instruction/1090837 b/results/classifier/105/instruction/1090837 new file mode 100644 index 00000000..6d542b5d --- /dev/null +++ b/results/classifier/105/instruction/1090837 @@ -0,0 +1,51 @@ +instruction: 0.785 +other: 0.714 +device: 0.683 +semantic: 0.642 +mistranslation: 0.580 +socket: 0.502 +graphic: 0.499 +vnc: 0.493 +network: 0.474 +boot: 0.388 +KVM: 0.283 +assembly: 0.280 + +Error in building Qemu-1.3.0 on Solaris 10 + +While trying to build Qemu on Oracle Solaris 10 (SPARC processor), I encountered the following error in the configure step: + +./configure --prefix=/usr/local/ --install=/usr/ucb/install +./configure: bad substitution +./configure: !: not found +./configure: !: not found +./configure: !: not found +./configure: !: not found +./configure: !: not found +./configure: curl-config: not found +./configure: curl-config: not found + +As the following bug report says: https://bugs.launchpad.net/qemu/+bug/636315, "sh" is hard-coded in the script. Can't the script be modified to accept a $SHELL argument to make use of bash or other shell during configure and make step? + +Are you using /bin/sh (broken) or /usr/xpg4/bin/sh (should work)? + +If I invoke /usr/xpg4/bin/sh from bash and then start the build process, will it be OK/ Or do I need to add /usr/xpg4/bin/sh to PATH? Does the patch mentioned in the referred bug need to be applied? + +Just using $SHELL inside configure would be insufficient if run via Solaris' sh. +Using `bash ./configure ...` should've worked for v1.2 without patches, didn't test v1.3 on Sol10 yet. + +Whether the DTrace support scripts fully work on Solaris 10 is another issue. + +Until tomorrow, I can't report back as the Solaris 10 system is in my workplace. What I tried was to trigger ./configure from bash shell which produced the log above and aborted. As the title already says, I tried to build Qemu 1.3.0. + +P.S. If I already use bash shell to invoke the script, do I need to `bash ./configure ...` any more? + +Yes, if you execute `./configure ...` the shell will execute the shebang line inside the script, which says /bin/sh and happens to be a really ancient version for backwards compatibility on Solaris. + +I did the following and it was a success: + +1. Added sh to path to override default /usr/bin/sh: PATH=/usr/xpg4/bin/sh:$PATH +2. From bash: sh ./configure + +Closing, as there is a work-around according to comment #6 + diff --git a/results/classifier/105/instruction/1092 b/results/classifier/105/instruction/1092 new file mode 100644 index 00000000..544940be --- /dev/null +++ b/results/classifier/105/instruction/1092 @@ -0,0 +1,27 @@ +instruction: 0.963 +mistranslation: 0.914 +device: 0.801 +graphic: 0.636 +semantic: 0.492 +network: 0.383 +other: 0.340 +vnc: 0.339 +boot: 0.313 +socket: 0.296 +assembly: 0.171 +KVM: 0.030 + +PPC: `sraw` instructions does not set `ca` and `ca32` flags. +Description of problem: +The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to +[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should. +Additional information: +This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`). + +**sraw** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914 + +**srawi** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924 diff --git a/results/classifier/105/instruction/1095857 b/results/classifier/105/instruction/1095857 new file mode 100644 index 00000000..a74648b9 --- /dev/null +++ b/results/classifier/105/instruction/1095857 @@ -0,0 +1,29 @@ +instruction: 0.914 +mistranslation: 0.764 +graphic: 0.736 +device: 0.679 +other: 0.555 +semantic: 0.442 +network: 0.323 +assembly: 0.286 +socket: 0.242 +boot: 0.214 +vnc: 0.198 +KVM: 0.114 + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +end up executing as + +mov eax,[r15] + +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. + +You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1103868 b/results/classifier/105/instruction/1103868 new file mode 100644 index 00000000..72de233d --- /dev/null +++ b/results/classifier/105/instruction/1103868 @@ -0,0 +1,76 @@ +instruction: 0.892 +device: 0.877 +socket: 0.820 +mistranslation: 0.762 +vnc: 0.736 +semantic: 0.721 +network: 0.713 +boot: 0.698 +graphic: 0.684 +other: 0.649 +assembly: 0.637 +KVM: 0.326 + +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/105/instruction/1103903 b/results/classifier/105/instruction/1103903 new file mode 100644 index 00000000..d320df43 --- /dev/null +++ b/results/classifier/105/instruction/1103903 @@ -0,0 +1,56 @@ +instruction: 0.853 +device: 0.842 +mistranslation: 0.832 +vnc: 0.742 +socket: 0.701 +network: 0.662 +other: 0.609 +semantic: 0.575 +graphic: 0.572 +boot: 0.485 +KVM: 0.378 +assembly: 0.340 + +drive_mirror on a resized image creates file with wrong size + +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 vda test +Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off + +the file is 32M instead of 64M: + +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 + +Workaround is to precreate the new file of the proper size and pass -n + +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 create -f qcow2 -o backing_file=base test 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 vda test -n + + + +reformatted patch and submitted upstream: + +http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg04584.html + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8689907266b649b757c220 +... so I think it should be OK to close this bug ticket now. + diff --git a/results/classifier/105/instruction/111 b/results/classifier/105/instruction/111 new file mode 100644 index 00000000..fe8646cb --- /dev/null +++ b/results/classifier/105/instruction/111 @@ -0,0 +1,14 @@ +instruction: 0.891 +network: 0.845 +mistranslation: 0.835 +device: 0.719 +socket: 0.481 +graphic: 0.412 +boot: 0.304 +semantic: 0.294 +other: 0.237 +vnc: 0.223 +assembly: 0.144 +KVM: 0.037 + +[OSS-Fuzz] Assertion Failure: !in6_zero(&ip_addr) diff --git a/results/classifier/105/instruction/1111 b/results/classifier/105/instruction/1111 new file mode 100644 index 00000000..35e76d27 --- /dev/null +++ b/results/classifier/105/instruction/1111 @@ -0,0 +1,31 @@ +instruction: 0.926 +graphic: 0.901 +device: 0.845 +semantic: 0.744 +network: 0.672 +vnc: 0.525 +socket: 0.403 +mistranslation: 0.372 +boot: 0.353 +KVM: 0.174 +other: 0.166 +assembly: 0.125 + +Calling FUTEX_LOCK_PI with qemu-x86_64-static caused ENOSYS error. +Description of problem: +When I executed the command "perf bench futex lock-pi" in amd64 docker image on s390x, I got the following error. +``` +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +``` + +I searched for this error message in the source code of perf-bench. I think that the following system call caused ENOSYS error. +` syscall(SYS_futex, uaddr, FUTEX_LOCK_PI | opflags, val, timeout, uaddr2, val3)` +Steps to reproduce: +1. Execute the command "perf bench futex lock-pi" in amd64 docker image on s390x +2. +3. +Additional information: + diff --git a/results/classifier/105/instruction/1116 b/results/classifier/105/instruction/1116 new file mode 100644 index 00000000..ba4baf70 --- /dev/null +++ b/results/classifier/105/instruction/1116 @@ -0,0 +1,31 @@ +instruction: 0.916 +device: 0.916 +graphic: 0.851 +network: 0.800 +semantic: 0.784 +KVM: 0.712 +vnc: 0.683 +mistranslation: 0.596 +socket: 0.573 +boot: 0.563 +assembly: 0.427 +other: 0.381 + +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/105/instruction/1119686 b/results/classifier/105/instruction/1119686 new file mode 100644 index 00000000..d3dce8ec --- /dev/null +++ b/results/classifier/105/instruction/1119686 @@ -0,0 +1,59 @@ +instruction: 0.842 +semantic: 0.745 +graphic: 0.740 +device: 0.726 +network: 0.696 +other: 0.667 +socket: 0.664 +vnc: 0.624 +KVM: 0.589 +boot: 0.508 +assembly: 0.381 +mistranslation: 0.327 + +Incorrect handling of icebp + +Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. + +To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: + + exception.c:202: exception 0: 80000004 flags:0 addr:003F0000 + exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001 + exception.c:214: this is the last test seen before the exception + exception: unhandled exception 80000004 at 003F0000 + exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9 + exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004 + exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 + +Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). + + + +This bug is still present in QEMU 1.6.0 (as per Debian's qemu-system-x86 1.6.0+dfsg-1 package). + + +This bug is still present in QEMU 1.7.0 (as per Debian's qemu-system-x86 1.7.0+dfsg-3 package). + +The patch submitted upstream was for the kernel. Is this also a bug in QEMU when TCG is disabled? + +s/TCG/KVM/ - Is this also a bug when KVM is disabled? + +[Expired for QEMU because there has been no activity for 60 days.] + +Actually this got fixed by the following Linux kernel commit: + +https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd2a445a94d2ab6b39fb623dc02fee48d01a565a + +commit fd2a445a94d2ab6b39fb623dc02fee48d01a565a (patch) + +KVM: VMX: Advance rip to after an ICEBP instruction +When entering an exception after an ICEBP, the saved instruction +pointer should point to after the instruction. + +This fixes the bug here: https://bugs.launchpad.net/qemu/+bug/1119686 + +Signed-off-by: Huw Davies <email address hidden> +Reviewed-by: Jan Kiszka <email address hidden> +Signed-off-by: Marcelo Tosatti <email address hidden> + + diff --git a/results/classifier/105/instruction/1142 b/results/classifier/105/instruction/1142 new file mode 100644 index 00000000..933768f7 --- /dev/null +++ b/results/classifier/105/instruction/1142 @@ -0,0 +1,59 @@ +instruction: 0.903 +device: 0.885 +boot: 0.849 +socket: 0.793 +graphic: 0.745 +vnc: 0.704 +network: 0.618 +semantic: 0.577 +KVM: 0.504 +other: 0.481 +mistranslation: 0.441 +assembly: 0.398 + +Measurements fail with direct kernel boot for AMD SEV confidential virtualization with 7.1 machine type +Description of problem: +When booting the QEMU with the 'kernel-hashes:true' property set for 'sev-guest' confidential virtualization, the contents of the `-kernel` file are measured by the firmware. + +A remote tenant can then validate the measurement against its expected contents to see if the boot was trustworthy. + +With the pc-q35-7.1 machine type the measurement always fails to validate against expected state. + +Making the following code change + +``` +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +index 7280c02ce3..3a4bf5cba3 100644 +--- a/hw/i386/pc.c ++++ b/hw/i386/pc.c +@@ -1899,6 +1899,8 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) + pcmc->rsdp_in_ram = true; + pcmc->smbios_defaults = true; + pcmc->smbios_uuid_encoded = true; ++ pcmc->legacy_no_rng_seed = true; ++ + pcmc->gigabyte_align = true; + pcmc->has_reserved_memory = true; + pcmc->kvmclock_enabled = true; +``` + +results in successfully validating the measurement. + +THis is not surprising, the RNG seed patch introduced in + +``` +commit 67f7e426e53833a5db75b0d813e8d537b8a75bd2 +Author: Jason A. Donenfeld <Jason@zx2c4.com> +Date: Thu Jul 21 14:56:36 2022 +0200 + + hw/i386: pass RNG seed via setup_data entry +``` + +intentionally modifies the contents of the kernel image before passing it to the firmware, to inject a random seed. This will ensure the boot measuremnts are different every time. + +This RNG seed functionality must NOT be used when AMD SEV is active. +Steps to reproduce: +1. Create an AMD SEV guest with kernel-hashes=true and pc-q35-7.1 machine type +2. Attempt to validate the boot measurement +Additional information: + diff --git a/results/classifier/105/instruction/1156 b/results/classifier/105/instruction/1156 new file mode 100644 index 00000000..83908c6d --- /dev/null +++ b/results/classifier/105/instruction/1156 @@ -0,0 +1,14 @@ +instruction: 0.874 +mistranslation: 0.834 +device: 0.815 +assembly: 0.455 +graphic: 0.452 +semantic: 0.202 +boot: 0.139 +network: 0.079 +other: 0.068 +socket: 0.017 +KVM: 0.017 +vnc: 0.007 + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/105/instruction/1157 b/results/classifier/105/instruction/1157 new file mode 100644 index 00000000..9cb7e839 --- /dev/null +++ b/results/classifier/105/instruction/1157 @@ -0,0 +1,26 @@ +instruction: 0.943 +graphic: 0.879 +device: 0.812 +semantic: 0.725 +vnc: 0.492 +network: 0.465 +socket: 0.434 +boot: 0.432 +assembly: 0.334 +KVM: 0.133 +other: 0.103 +mistranslation: 0.045 + +aarch64: enabling MMU causes instruction abort +Description of problem: +The title describes the problem pretty accurately, we get an instruction abort when enabling the MMU with a pretty simple set of page tables. This has been regressed from qemu 6.x. +Steps to reproduce: +1. Run the provided Kernel binary with the command line specified above. +2. Notice the hang after 'Initialize MMU'. I traced it down to being an instructions abort after the write to the SCTLR_EL1 register. +3. Try to run with qemu 6.x, and notice that it works. +Additional information: +This does work on actual hardware, so it has to be a qemu bug. + +A binary of the Serenity Kernel has been attached to the issue. The source of that binary can be found at commit ca0e32e59fcf67a662e5d3a994d44cd7c941624a of [SerenityOS](https://github.com/SerenityOS/serenity). + +[Kernel](/uploads/f731edbf81d8e575035e9693b0a51dbf/Kernel) diff --git a/results/classifier/105/instruction/1163034 b/results/classifier/105/instruction/1163034 new file mode 100644 index 00000000..2dddbbc7 --- /dev/null +++ b/results/classifier/105/instruction/1163034 @@ -0,0 +1,59 @@ +instruction: 0.424 +device: 0.340 +socket: 0.280 +boot: 0.262 +network: 0.236 +other: 0.219 +semantic: 0.147 +graphic: 0.133 +vnc: 0.102 +mistranslation: 0.100 +assembly: 0.041 +KVM: 0.031 + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) + +Please look at +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+packages +and +https://code.launchpad.net/~costamagnagianfranco/+archive/costamagnagianfranco-ppa/+build/4457434 + +I cannot make gnutls28 build on armhf, I suspect a builder problem + +configure tries to check how printf behaves when it runs out of memory. I've attached a cut-down version of the code that reproduces the hang in qemu-arm-static, but works on real hardware. It uses a SIGSEGV handler, which is probably relevant. + +I've tested with qemu-arm-static 1.4.0-2013.02+git63+20130225+79aa792-0linaro1 and 1.4.0+dfsg-1expubuntu4. + +Anyway even if you disable this check you will find another unsupported syscall bug... :( + +Actually, assuming the guest ARM glibc doesn't have the printf() bug the code is testing for, we shouldn't take the SIGSEGV anyway, so that's a red herring. The actual problem here is the setrlimit(). + +The conftest.c test case works by using rlimit to limit the address space. This generally doesn't work on QEMU because we just pass the rlimit syscall through to the host, and end up limiting not just the guest program but also QEMU itself. QEMU doesn't expect its own allocations to fail and typically dies in confusing ways as a result. (Sometimes we do check allocations and call abort(), which then under linux-user doesn't work properly because we treat the resulting signal as if it were caused by the guest and not by QEMU's own code; IIRC we end up hanging in that situation.) In this particular instance we segfault in tb_alloc_page() because it doesn't check that page_find_alloc() didn't return NULL. + +[Confirmed by running qemu-arm under gdb.] + +Fixing this would require us to implement the address space rlimits entirely in QEMU by keeping track of how much memory we've handed the guest so we can fail mmap() etc. That is probably relatively speaking fairly tractable, though it's not a five minute job. + +Unsupported syscall bugs are usually easy fixes, incidentally (though occasionally they are nasty); also often QEMU will warn but things will continue OK because the guest libc/userspace supports fallback code for when a native kernel hasn't yet implemented the new syscall. + + +I'm referring to bug 1042388, I din't know about the fallback on this, but I have to say it doesn't work since apt exits and fails when encounters this call, maybe the fallback has some problems? + +Regarding bug 1042388, those are the posix timer syscalls, and I guess they've just been around long enough that apt expects them to exist. Anyway, we should just implement them in QEMU. + + +This will come in when implemented upstream. + +It's been a while since the last change to this ticket ... Has this ever been implemented? + +This bug is still valid, 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/95 + + diff --git a/results/classifier/105/instruction/1163065 b/results/classifier/105/instruction/1163065 new file mode 100644 index 00000000..26169960 --- /dev/null +++ b/results/classifier/105/instruction/1163065 @@ -0,0 +1,38 @@ +instruction: 0.759 +boot: 0.722 +device: 0.683 +other: 0.650 +graphic: 0.648 +mistranslation: 0.598 +semantic: 0.560 +socket: 0.455 +network: 0.422 +vnc: 0.392 +assembly: 0.343 +KVM: 0.086 + +target-i386 cpu_get_phys_page_debug checks bits in wrong order + +In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked before CR0_PG. This means that if paging is disabled but the PAE bit has been set in CR4, cpu_get_phys_page_debug will return the wrong result (it will try to translate the address as virtual rather than using it as a physical address). + +Although this might seem like an unusual case, it in fact happens consistently when booting Linux on amd64 (from linux-2.6.32.60/arch/x86/boot/compressed/head_64.S): + + /* Enable PAE mode */ + xorl %eax, %eax + orl $(X86_CR4_PAE), %eax + movl %eax, %cr4 +[... code to set up page tables omitted ...] + /* Enter paged protected Mode, activating Long Mode */ + movl $(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected mode */ + movl %eax, %cr0 + +The most noticeable effect of this bug is that using the disassembler during this time will fetch the wrong data by trying to read from page tables that aren't there. One symptom is that booting Linux amd64 with -d in_asm will result in several "Disassembler disagrees with translator over instruction decoding" messages. + +Attached is a patch that moves the CR0_PG check to the beginning. I'm still not 100% certain that the logic of cpu_get_phys_page_debug matches cpu_x86_handle_mmu_fault, but it's a start. + + + +Can you still reproduce this problem with the latest version of QEMU? If so, could you please send a refreshed patch to the qemu-devel mailing list? We do not pick up patches from the bug tracker. Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/11933524 b/results/classifier/105/instruction/11933524 new file mode 100644 index 00000000..371333c6 --- /dev/null +++ b/results/classifier/105/instruction/11933524 @@ -0,0 +1,1133 @@ +instruction: 0.775 +other: 0.771 +device: 0.762 +assembly: 0.754 +socket: 0.751 +boot: 0.743 +graphic: 0.737 +mistranslation: 0.719 +vnc: 0.695 +KVM: 0.689 +semantic: 0.673 +network: 0.662 + +[BUG] hw/i386/pc.c: CXL Fixed Memory Window should not reserve e820 in bios + +Early-boot e820 records will be inserted by the bios/efi/early boot +software and be reported to the kernel via insert_resource. Later, when +CXL drivers iterate through the regions again, they will insert another +resource and make the RESERVED memory area a child. + +This RESERVED memory area causes the memory region to become unusable, +and as a result attempting to create memory regions with + + `cxl create-region ...` + +Will fail due to the RESERVED area intersecting with the CXL window. + + +During boot the following traceback is observed: + +0xffffffff81101650 in insert_resource_expand_to_fit () +0xffffffff83d964c5 in e820__reserve_resources_late () +0xffffffff83e03210 in pcibios_resource_survey () +0xffffffff83e04f4a in pcibios_init () + +Which produces a call to reserve the CFMWS area: + +(gdb) p *new +$54 = {start = 0x290000000, end = 0x2cfffffff, name = "Reserved", + flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0, + child = 0x0} + +Later the Kernel parses ACPI tables and reserves the exact same area as +the CXL Fixed Memory Window. The use of `insert_resource_conflict` +retains the RESERVED region and makes it a child of the new region. + +0xffffffff811016a4 in insert_resource_conflict () + insert_resource () +0xffffffff81a81389 in cxl_parse_cfmws () +0xffffffff818c4a81 in call_handler () + acpi_parse_entries_array () + +(gdb) p/x *new +$59 = {start = 0x290000000, end = 0x2cfffffff, name = "CXL Window 0", + flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0, + child = 0x0} + +This produces the following output in /proc/iomem: + +590000000-68fffffff : CXL Window 0 + 590000000-68fffffff : Reserved + +This reserved area causes `get_free_mem_region()` to fail due to a check +against `__region_intersects()`. Due to this reserved area, the +intersect check will only ever return REGION_INTERSECTS, which causes +`cxl create-region` to always fail. + +Signed-off-by: Gregory Price <gregory.price@memverge.com> +--- + hw/i386/pc.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +index 566accf7e6..5bf5465a21 100644 +--- a/hw/i386/pc.c ++++ b/hw/i386/pc.c +@@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, + hwaddr cxl_size = MiB; + + cxl_base = pc_get_cxl_range_start(pcms); +- e820_add_entry(cxl_base, cxl_size, E820_RESERVED); + memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size); + memory_region_add_subregion(system_memory, cxl_base, mr); + cxl_resv_end = cxl_base + cxl_size; +@@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms, + memory_region_init_io(&fw->mr, OBJECT(machine), &cfmws_ops, fw, + "cxl-fixed-memory-region", fw->size); + memory_region_add_subregion(system_memory, fw->base, &fw->mr); +- e820_add_entry(fw->base, fw->size, E820_RESERVED); + cxl_fmw_base += fw->size; + cxl_resv_end = cxl_fmw_base; + } +-- +2.37.3 + +Early-boot e820 records will be inserted by the bios/efi/early boot +software and be reported to the kernel via insert_resource. Later, when +CXL drivers iterate through the regions again, they will insert another +resource and make the RESERVED memory area a child. + +This RESERVED memory area causes the memory region to become unusable, +and as a result attempting to create memory regions with + + `cxl create-region ...` + +Will fail due to the RESERVED area intersecting with the CXL window. + + +During boot the following traceback is observed: + +0xffffffff81101650 in insert_resource_expand_to_fit () +0xffffffff83d964c5 in e820__reserve_resources_late () +0xffffffff83e03210 in pcibios_resource_survey () +0xffffffff83e04f4a in pcibios_init () + +Which produces a call to reserve the CFMWS area: + +(gdb) p *new +$54 = {start = 0x290000000, end = 0x2cfffffff, name = "Reserved", + flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0, + child = 0x0} + +Later the Kernel parses ACPI tables and reserves the exact same area as +the CXL Fixed Memory Window. The use of `insert_resource_conflict` +retains the RESERVED region and makes it a child of the new region. + +0xffffffff811016a4 in insert_resource_conflict () + insert_resource () +0xffffffff81a81389 in cxl_parse_cfmws () +0xffffffff818c4a81 in call_handler () + acpi_parse_entries_array () + +(gdb) p/x *new +$59 = {start = 0x290000000, end = 0x2cfffffff, name = "CXL Window 0", + flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0, + child = 0x0} + +This produces the following output in /proc/iomem: + +590000000-68fffffff : CXL Window 0 + 590000000-68fffffff : Reserved + +This reserved area causes `get_free_mem_region()` to fail due to a check +against `__region_intersects()`. Due to this reserved area, the +intersect check will only ever return REGION_INTERSECTS, which causes +`cxl create-region` to always fail. + +Signed-off-by: Gregory Price <gregory.price@memverge.com> +--- + hw/i386/pc.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +index 566accf7e6..5bf5465a21 100644 +--- a/hw/i386/pc.c ++++ b/hw/i386/pc.c +@@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, + hwaddr cxl_size = MiB; +cxl_base = pc_get_cxl_range_start(pcms); +- e820_add_entry(cxl_base, cxl_size, E820_RESERVED); + memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size); + memory_region_add_subregion(system_memory, cxl_base, mr); + cxl_resv_end = cxl_base + cxl_size; +@@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms, + memory_region_init_io(&fw->mr, OBJECT(machine), &cfmws_ops, +fw, + "cxl-fixed-memory-region", fw->size); + memory_region_add_subregion(system_memory, fw->base, &fw->mr); +Or will this be subregion of cxl_base? + +Thanks, +Pankaj +- e820_add_entry(fw->base, fw->size, E820_RESERVED); + cxl_fmw_base += fw->size; + cxl_resv_end = cxl_fmw_base; + } + +> +> - e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +> +> memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size); +> +> memory_region_add_subregion(system_memory, cxl_base, mr); +> +> cxl_resv_end = cxl_base + cxl_size; +> +> @@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms, +> +> memory_region_init_io(&fw->mr, OBJECT(machine), +> +> &cfmws_ops, fw, +> +> "cxl-fixed-memory-region", +> +> fw->size); +> +> memory_region_add_subregion(system_memory, fw->base, +> +> &fw->mr); +> +> +Or will this be subregion of cxl_base? +> +> +Thanks, +> +Pankaj +The memory region backing this memory area still has to be initialized +and added in the QEMU system, but it will now be initialized for use by +linux after PCI/ACPI setup occurs and the CXL driver discovers it via +CDAT. + +It's also still possible to assign this area a static memory region at +bool by setting up the SRATs in the ACPI tables, but that patch is not +upstream yet. + +On Tue, Oct 18, 2022 at 5:14 AM Gregory Price <gourry.memverge@gmail.com> wrote: +> +> +Early-boot e820 records will be inserted by the bios/efi/early boot +> +software and be reported to the kernel via insert_resource. Later, when +> +CXL drivers iterate through the regions again, they will insert another +> +resource and make the RESERVED memory area a child. +I have already sent a patch +https://www.mail-archive.com/qemu-devel@nongnu.org/msg882012.html +. +When the patch is applied, there would not be any reserved entries +even with passing E820_RESERVED . +So this patch needs to be evaluated in the light of the above patch I +sent. Once you apply my patch, does the issue still exist? + +> +> +This RESERVED memory area causes the memory region to become unusable, +> +and as a result attempting to create memory regions with +> +> +`cxl create-region ...` +> +> +Will fail due to the RESERVED area intersecting with the CXL window. +> +> +> +During boot the following traceback is observed: +> +> +0xffffffff81101650 in insert_resource_expand_to_fit () +> +0xffffffff83d964c5 in e820__reserve_resources_late () +> +0xffffffff83e03210 in pcibios_resource_survey () +> +0xffffffff83e04f4a in pcibios_init () +> +> +Which produces a call to reserve the CFMWS area: +> +> +(gdb) p *new +> +$54 = {start = 0x290000000, end = 0x2cfffffff, name = "Reserved", +> +flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0, +> +child = 0x0} +> +> +Later the Kernel parses ACPI tables and reserves the exact same area as +> +the CXL Fixed Memory Window. The use of `insert_resource_conflict` +> +retains the RESERVED region and makes it a child of the new region. +> +> +0xffffffff811016a4 in insert_resource_conflict () +> +insert_resource () +> +0xffffffff81a81389 in cxl_parse_cfmws () +> +0xffffffff818c4a81 in call_handler () +> +acpi_parse_entries_array () +> +> +(gdb) p/x *new +> +$59 = {start = 0x290000000, end = 0x2cfffffff, name = "CXL Window 0", +> +flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0, +> +child = 0x0} +> +> +This produces the following output in /proc/iomem: +> +> +590000000-68fffffff : CXL Window 0 +> +590000000-68fffffff : Reserved +> +> +This reserved area causes `get_free_mem_region()` to fail due to a check +> +against `__region_intersects()`. Due to this reserved area, the +> +intersect check will only ever return REGION_INTERSECTS, which causes +> +`cxl create-region` to always fail. +> +> +Signed-off-by: Gregory Price <gregory.price@memverge.com> +> +--- +> +hw/i386/pc.c | 2 -- +> +1 file changed, 2 deletions(-) +> +> +diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> +index 566accf7e6..5bf5465a21 100644 +> +--- a/hw/i386/pc.c +> ++++ b/hw/i386/pc.c +> +@@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +> +hwaddr cxl_size = MiB; +> +> +cxl_base = pc_get_cxl_range_start(pcms); +> +- e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +> +memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size); +> +memory_region_add_subregion(system_memory, cxl_base, mr); +> +cxl_resv_end = cxl_base + cxl_size; +> +@@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms, +> +memory_region_init_io(&fw->mr, OBJECT(machine), &cfmws_ops, +> +fw, +> +"cxl-fixed-memory-region", fw->size); +> +memory_region_add_subregion(system_memory, fw->base, +> +&fw->mr); +> +- e820_add_entry(fw->base, fw->size, E820_RESERVED); +> +cxl_fmw_base += fw->size; +> +cxl_resv_end = cxl_fmw_base; +> +} +> +-- +> +2.37.3 +> + +This patch does not resolve the issue, reserved entries are still created. +[  0.000000] BIOS-e820: [mem 0x0000000280000000-0x00000002800fffff] reserved +[  0.000000] BIOS-e820: [mem 0x0000000290000000-0x000000029fffffff] reserved +# cat /proc/iomem +290000000-29fffffff : CXL Window 0 + 290000000-29fffffff : Reserved +# cxl create-region -m -d decoder0.0 -w 1 -g 256 mem0 +cxl region: create_region: region0: set_size failed: Numerical result out of range +cxl region: cmd_create_region: created 0 regions +On Tue, Oct 18, 2022 at 2:05 AM Ani Sinha < +ani@anisinha.ca +> wrote: +On Tue, Oct 18, 2022 at 5:14 AM Gregory Price < +gourry.memverge@gmail.com +> wrote: +> +> Early-boot e820 records will be inserted by the bios/efi/early boot +> software and be reported to the kernel via insert_resource. Later, when +> CXL drivers iterate through the regions again, they will insert another +> resource and make the RESERVED memory area a child. +I have already sent a patch +https://www.mail-archive.com/qemu-devel@nongnu.org/msg882012.html +. +When the patch is applied, there would not be any reserved entries +even with passing E820_RESERVED . +So this patch needs to be evaluated in the light of the above patch I +sent. Once you apply my patch, does the issue still exist? +> +> This RESERVED memory area causes the memory region to become unusable, +> and as a result attempting to create memory regions with +> +>   `cxl create-region ...` +> +> Will fail due to the RESERVED area intersecting with the CXL window. +> +> +> During boot the following traceback is observed: +> +> 0xffffffff81101650 in insert_resource_expand_to_fit () +> 0xffffffff83d964c5 in e820__reserve_resources_late () +> 0xffffffff83e03210 in pcibios_resource_survey () +> 0xffffffff83e04f4a in pcibios_init () +> +> Which produces a call to reserve the CFMWS area: +> +> (gdb) p *new +> $54 = {start = 0x290000000, end = 0x2cfffffff, name = "Reserved", +>    flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0, +>    child = 0x0} +> +> Later the Kernel parses ACPI tables and reserves the exact same area as +> the CXL Fixed Memory Window. The use of `insert_resource_conflict` +> retains the RESERVED region and makes it a child of the new region. +> +> 0xffffffff811016a4 in insert_resource_conflict () +>            insert_resource () +> 0xffffffff81a81389 in cxl_parse_cfmws () +> 0xffffffff818c4a81 in call_handler () +>            acpi_parse_entries_array () +> +> (gdb) p/x *new +> $59 = {start = 0x290000000, end = 0x2cfffffff, name = "CXL Window 0", +>    flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0, +>    child = 0x0} +> +> This produces the following output in /proc/iomem: +> +> 590000000-68fffffff : CXL Window 0 +>  590000000-68fffffff : Reserved +> +> This reserved area causes `get_free_mem_region()` to fail due to a check +> against `__region_intersects()`. Due to this reserved area, the +> intersect check will only ever return REGION_INTERSECTS, which causes +> `cxl create-region` to always fail. +> +> Signed-off-by: Gregory Price < +gregory.price@memverge.com +> +> --- +> hw/i386/pc.c | 2 -- +> 1 file changed, 2 deletions(-) +> +> diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> index 566accf7e6..5bf5465a21 100644 +> --- a/hw/i386/pc.c +> +++ b/hw/i386/pc.c +> @@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +>     hwaddr cxl_size = MiB; +> +>     cxl_base = pc_get_cxl_range_start(pcms); +> -    e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +>     memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size); +>     memory_region_add_subregion(system_memory, cxl_base, mr); +>     cxl_resv_end = cxl_base + cxl_size; +> @@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms, +>         memory_region_init_io(&fw->mr, OBJECT(machine), &cfmws_ops, fw, +>                    "cxl-fixed-memory-region", fw->size); +>         memory_region_add_subregion(system_memory, fw->base, &fw->mr); +> -        e820_add_entry(fw->base, fw->size, E820_RESERVED); +>         cxl_fmw_base += fw->size; +>         cxl_resv_end = cxl_fmw_base; +>       } +> -- +> 2.37.3 +> + ++Gerd Hoffmann + +On Tue, Oct 18, 2022 at 8:16 PM Gregory Price <gourry.memverge@gmail.com> wrote: +> +> +This patch does not resolve the issue, reserved entries are still created. +> +> +[ 0.000000] BIOS-e820: [mem 0x0000000280000000-0x00000002800fffff] reserved +> +[ 0.000000] BIOS-e820: [mem 0x0000000290000000-0x000000029fffffff] reserved +> +> +# cat /proc/iomem +> +290000000-29fffffff : CXL Window 0 +> +290000000-29fffffff : Reserved +> +> +# cxl create-region -m -d decoder0.0 -w 1 -g 256 mem0 +> +cxl region: create_region: region0: set_size failed: Numerical result out of +> +range +> +cxl region: cmd_create_region: created 0 regions +> +> +On Tue, Oct 18, 2022 at 2:05 AM Ani Sinha <ani@anisinha.ca> wrote: +> +> +> +> On Tue, Oct 18, 2022 at 5:14 AM Gregory Price <gourry.memverge@gmail.com> +> +> wrote: +> +> > +> +> > Early-boot e820 records will be inserted by the bios/efi/early boot +> +> > software and be reported to the kernel via insert_resource. Later, when +> +> > CXL drivers iterate through the regions again, they will insert another +> +> > resource and make the RESERVED memory area a child. +> +> +> +> I have already sent a patch +> +> +https://www.mail-archive.com/qemu-devel@nongnu.org/msg882012.html +. +> +> When the patch is applied, there would not be any reserved entries +> +> even with passing E820_RESERVED . +> +> So this patch needs to be evaluated in the light of the above patch I +> +> sent. Once you apply my patch, does the issue still exist? +> +> +> +> > +> +> > This RESERVED memory area causes the memory region to become unusable, +> +> > and as a result attempting to create memory regions with +> +> > +> +> > `cxl create-region ...` +> +> > +> +> > Will fail due to the RESERVED area intersecting with the CXL window. +> +> > +> +> > +> +> > During boot the following traceback is observed: +> +> > +> +> > 0xffffffff81101650 in insert_resource_expand_to_fit () +> +> > 0xffffffff83d964c5 in e820__reserve_resources_late () +> +> > 0xffffffff83e03210 in pcibios_resource_survey () +> +> > 0xffffffff83e04f4a in pcibios_init () +> +> > +> +> > Which produces a call to reserve the CFMWS area: +> +> > +> +> > (gdb) p *new +> +> > $54 = {start = 0x290000000, end = 0x2cfffffff, name = "Reserved", +> +> > flags = 0x200, desc = 0x7, parent = 0x0, sibling = 0x0, +> +> > child = 0x0} +> +> > +> +> > Later the Kernel parses ACPI tables and reserves the exact same area as +> +> > the CXL Fixed Memory Window. The use of `insert_resource_conflict` +> +> > retains the RESERVED region and makes it a child of the new region. +> +> > +> +> > 0xffffffff811016a4 in insert_resource_conflict () +> +> > insert_resource () +> +> > 0xffffffff81a81389 in cxl_parse_cfmws () +> +> > 0xffffffff818c4a81 in call_handler () +> +> > acpi_parse_entries_array () +> +> > +> +> > (gdb) p/x *new +> +> > $59 = {start = 0x290000000, end = 0x2cfffffff, name = "CXL Window 0", +> +> > flags = 0x200, desc = 0x0, parent = 0x0, sibling = 0x0, +> +> > child = 0x0} +> +> > +> +> > This produces the following output in /proc/iomem: +> +> > +> +> > 590000000-68fffffff : CXL Window 0 +> +> > 590000000-68fffffff : Reserved +> +> > +> +> > This reserved area causes `get_free_mem_region()` to fail due to a check +> +> > against `__region_intersects()`. Due to this reserved area, the +> +> > intersect check will only ever return REGION_INTERSECTS, which causes +> +> > `cxl create-region` to always fail. +> +> > +> +> > Signed-off-by: Gregory Price <gregory.price@memverge.com> +> +> > --- +> +> > hw/i386/pc.c | 2 -- +> +> > 1 file changed, 2 deletions(-) +> +> > +> +> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> +> > index 566accf7e6..5bf5465a21 100644 +> +> > --- a/hw/i386/pc.c +> +> > +++ b/hw/i386/pc.c +> +> > @@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +> +> > hwaddr cxl_size = MiB; +> +> > +> +> > cxl_base = pc_get_cxl_range_start(pcms); +> +> > - e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +> +> > memory_region_init(mr, OBJECT(machine), "cxl_host_reg", cxl_size); +> +> > memory_region_add_subregion(system_memory, cxl_base, mr); +> +> > cxl_resv_end = cxl_base + cxl_size; +> +> > @@ -1077,7 +1076,6 @@ void pc_memory_init(PCMachineState *pcms, +> +> > memory_region_init_io(&fw->mr, OBJECT(machine), +> +> > &cfmws_ops, fw, +> +> > "cxl-fixed-memory-region", +> +> > fw->size); +> +> > memory_region_add_subregion(system_memory, fw->base, +> +> > &fw->mr); +> +> > - e820_add_entry(fw->base, fw->size, E820_RESERVED); +> +> > cxl_fmw_base += fw->size; +> +> > cxl_resv_end = cxl_fmw_base; +> +> > } +> +> > -- +> +> > 2.37.3 +> +> > + +> +>> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> +>> > index 566accf7e6..5bf5465a21 100644 +> +>> > --- a/hw/i386/pc.c +> +>> > +++ b/hw/i386/pc.c +> +>> > @@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +> +>> > hwaddr cxl_size = MiB; +> +>> > +> +>> > cxl_base = pc_get_cxl_range_start(pcms); +> +>> > - e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +Just dropping it doesn't look like a good plan to me. + +You can try set etc/reserved-memory-end fw_cfg file instead. Firmware +(both seabios and ovmf) read it and will make sure the 64bit pci mmio +window is placed above that address, i.e. this effectively reserves +address space. Right now used by memory hotplug code, but should work +for cxl too I think (disclaimer: don't know much about cxl ...). + +take care & HTH, + Gerd + +On Tue, 8 Nov 2022 12:21:11 +0100 +Gerd Hoffmann <kraxel@redhat.com> wrote: + +> +> >> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> +> >> > index 566accf7e6..5bf5465a21 100644 +> +> >> > --- a/hw/i386/pc.c +> +> >> > +++ b/hw/i386/pc.c +> +> >> > @@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +> +> >> > hwaddr cxl_size = MiB; +> +> >> > +> +> >> > cxl_base = pc_get_cxl_range_start(pcms); +> +> >> > - e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +> +> +Just dropping it doesn't look like a good plan to me. +> +> +You can try set etc/reserved-memory-end fw_cfg file instead. Firmware +> +(both seabios and ovmf) read it and will make sure the 64bit pci mmio +> +window is placed above that address, i.e. this effectively reserves +> +address space. Right now used by memory hotplug code, but should work +> +for cxl too I think (disclaimer: don't know much about cxl ...). +As far as I know CXL impl. in QEMU isn't using etc/reserved-memory-end +at all, it' has its own mapping. + +Regardless of that, reserved E820 entries look wrong, and looking at +commit message OS is right to bailout on them (expected according +to ACPI spec). +Also spec says + +" +E820 Assumptions and Limitations + [...] + The platform boot firmware does not return a range description for the memory +mapping of + PCI devices, ISA Option ROMs, and ISA Plug and Play cards because the OS has +mechanisms + available to detect them. +" + +so dropping reserved entries looks reasonable from ACPI spec point of view. +(disclaimer: don't know much about cxl ... either) +> +> +take care & HTH, +> +Gerd +> + +On Fri, Nov 11, 2022 at 11:51:23AM +0100, Igor Mammedov wrote: +> +On Tue, 8 Nov 2022 12:21:11 +0100 +> +Gerd Hoffmann <kraxel@redhat.com> wrote: +> +> +> > >> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> +> > >> > index 566accf7e6..5bf5465a21 100644 +> +> > >> > --- a/hw/i386/pc.c +> +> > >> > +++ b/hw/i386/pc.c +> +> > >> > @@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +> +> > >> > hwaddr cxl_size = MiB; +> +> > >> > +> +> > >> > cxl_base = pc_get_cxl_range_start(pcms); +> +> > >> > - e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +> +> +> +> Just dropping it doesn't look like a good plan to me. +> +> +> +> You can try set etc/reserved-memory-end fw_cfg file instead. Firmware +> +> (both seabios and ovmf) read it and will make sure the 64bit pci mmio +> +> window is placed above that address, i.e. this effectively reserves +> +> address space. Right now used by memory hotplug code, but should work +> +> for cxl too I think (disclaimer: don't know much about cxl ...). +> +> +As far as I know CXL impl. in QEMU isn't using etc/reserved-memory-end +> +at all, it' has its own mapping. +This should be changed. cxl should make sure the highest address used +is stored in etc/reserved-memory-end to avoid the firmware mapping pci +resources there. + +> +so dropping reserved entries looks reasonable from ACPI spec point of view. +Yep, I don't want dispute that. + +I suspect the reason for these entries to exist in the first place is to +inform the firmware that it should not place stuff there, and if we +remove that to conform with the spec we need some alternative way for +that ... + +take care, + Gerd + +On Fri, 11 Nov 2022 12:40:59 +0100 +Gerd Hoffmann <kraxel@redhat.com> wrote: + +> +On Fri, Nov 11, 2022 at 11:51:23AM +0100, Igor Mammedov wrote: +> +> On Tue, 8 Nov 2022 12:21:11 +0100 +> +> Gerd Hoffmann <kraxel@redhat.com> wrote: +> +> +> +> > > >> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c +> +> > > >> > index 566accf7e6..5bf5465a21 100644 +> +> > > >> > --- a/hw/i386/pc.c +> +> > > >> > +++ b/hw/i386/pc.c +> +> > > >> > @@ -1061,7 +1061,6 @@ void pc_memory_init(PCMachineState *pcms, +> +> > > >> > hwaddr cxl_size = MiB; +> +> > > >> > +> +> > > >> > cxl_base = pc_get_cxl_range_start(pcms); +> +> > > >> > - e820_add_entry(cxl_base, cxl_size, E820_RESERVED); +> +> > +> +> > Just dropping it doesn't look like a good plan to me. +> +> > +> +> > You can try set etc/reserved-memory-end fw_cfg file instead. Firmware +> +> > (both seabios and ovmf) read it and will make sure the 64bit pci mmio +> +> > window is placed above that address, i.e. this effectively reserves +> +> > address space. Right now used by memory hotplug code, but should work +> +> > for cxl too I think (disclaimer: don't know much about cxl ...). +> +> +> +> As far as I know CXL impl. in QEMU isn't using etc/reserved-memory-end +> +> at all, it' has its own mapping. +> +> +This should be changed. cxl should make sure the highest address used +> +is stored in etc/reserved-memory-end to avoid the firmware mapping pci +> +resources there. +if (pcmc->has_reserved_memory && machine->device_memory->base) { + +[...] + + if (pcms->cxl_devices_state.is_enabled) { + + res_mem_end = cxl_resv_end; + +that should be handled by this line + + } + + *val = cpu_to_le64(ROUND_UP(res_mem_end, 1 * GiB)); + + fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, sizeof(*val)); + + } + +so SeaBIOS shouldn't intrude into CXL address space +(I assume EDK2 behave similarly here) + +> +> so dropping reserved entries looks reasonable from ACPI spec point of view. +> +> +> +> +Yep, I don't want dispute that. +> +> +I suspect the reason for these entries to exist in the first place is to +> +inform the firmware that it should not place stuff there, and if we +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +just to educate me, can you point out what SeaBIOS code does with reservations. + +> +remove that to conform with the spec we need some alternative way for +> +that ... +with etc/reserved-memory-end set as above, +is E820_RESERVED really needed here? + +(my understanding was that E820_RESERVED weren't accounted for when +initializing PCI devices) + +> +> +take care, +> +Gerd +> + +> +if (pcmc->has_reserved_memory && machine->device_memory->base) { +> +> +[...] +> +> +if (pcms->cxl_devices_state.is_enabled) { +> +> +res_mem_end = cxl_resv_end; +> +> +that should be handled by this line +> +> +} +> +> +*val = cpu_to_le64(ROUND_UP(res_mem_end, 1 * GiB)); +> +> +fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, +> +sizeof(*val)); +> +} +> +> +so SeaBIOS shouldn't intrude into CXL address space +Yes, looks good, so with this in place already everyting should be fine. + +> +(I assume EDK2 behave similarly here) +Correct, ovmf reads that fw_cfg file too. + +> +> I suspect the reason for these entries to exist in the first place is to +> +> inform the firmware that it should not place stuff there, and if we +> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +> +just to educate me, can you point out what SeaBIOS code does with +> +reservations. +They are added to the e820 map which gets passed on to the OS. seabios +uses (and updateas) the e820 map too, when allocating memory for +example. While thinking about it I'm not fully sure it actually looks +at reservations, maybe it only uses (and updates) ram entries when +allocating memory. + +> +> remove that to conform with the spec we need some alternative way for +> +> that ... +> +> +with etc/reserved-memory-end set as above, +> +is E820_RESERVED really needed here? +No. Setting etc/reserved-memory-end is enough. + +So for the original patch: +Acked-by: Gerd Hoffmann <kraxel@redhat.com> + +take care, + Gerd + +On Fri, Nov 11, 2022 at 02:36:02PM +0100, Gerd Hoffmann wrote: +> +> if (pcmc->has_reserved_memory && machine->device_memory->base) { +> +> +> +> [...] +> +> +> +> if (pcms->cxl_devices_state.is_enabled) { +> +> +> +> res_mem_end = cxl_resv_end; +> +> +> +> that should be handled by this line +> +> +> +> } +> +> +> +> *val = cpu_to_le64(ROUND_UP(res_mem_end, 1 * GiB)); +> +> +> +> fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, +> +> sizeof(*val)); +> +> } +> +> +> +> so SeaBIOS shouldn't intrude into CXL address space +> +> +Yes, looks good, so with this in place already everyting should be fine. +> +> +> (I assume EDK2 behave similarly here) +> +> +Correct, ovmf reads that fw_cfg file too. +> +> +> > I suspect the reason for these entries to exist in the first place is to +> +> > inform the firmware that it should not place stuff there, and if we +> +> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +> +> just to educate me, can you point out what SeaBIOS code does with +> +> reservations. +> +> +They are added to the e820 map which gets passed on to the OS. seabios +> +uses (and updateas) the e820 map too, when allocating memory for +> +example. While thinking about it I'm not fully sure it actually looks +> +at reservations, maybe it only uses (and updates) ram entries when +> +allocating memory. +> +> +> > remove that to conform with the spec we need some alternative way for +> +> > that ... +> +> +> +> with etc/reserved-memory-end set as above, +> +> is E820_RESERVED really needed here? +> +> +No. Setting etc/reserved-memory-end is enough. +> +> +So for the original patch: +> +Acked-by: Gerd Hoffmann <kraxel@redhat.com> +> +> +take care, +> +Gerd +It's upstream already, sorry I can't add your tag. + +-- +MST + diff --git a/results/classifier/105/instruction/1195 b/results/classifier/105/instruction/1195 new file mode 100644 index 00000000..ee7d3772 --- /dev/null +++ b/results/classifier/105/instruction/1195 @@ -0,0 +1,31 @@ +instruction: 0.789 +graphic: 0.706 +device: 0.695 +other: 0.509 +semantic: 0.459 +mistranslation: 0.340 +network: 0.270 +assembly: 0.232 +boot: 0.197 +socket: 0.193 +vnc: 0.148 +KVM: 0.137 + +Race condition during QEMU exit cleanup can lead to deadlock +Description of problem: +During the cleanup phase of QEMU exiting, there is a small race condition window that can lead QEMU to lock up completely: +In the main QEMU thread, during the exit, the thread will execute the 'qemu_cleanup' function, which calls 'do_vm_stop', which calls 'pause_all_vcpus'. This method tries to (as the name suggests) stop/pause all the vcpu threads. At the same time, the vcpu thread might have just existed it's main mttcg exec loop, which means it will enter 'qemu_wait_io_event'. At this point, the following race condition can occur: +- vcpu_thread - cpus.c:416 <= enters qemu_wait_io_event +- shutdown_thread - cpus.c:555 <= enters pause_all_vcpus +- vcpu_thread - cpus.c:418 <= cpu_thread_is_idle returns true, cpu->stop not set yet +- shutdown_thread - cpus.c:560/561 <= sets cpu->stop and kicks the vcpu, but it's not waiting on cpu->halt_cond yet, so nothing happens +- vcpu_thread - cpus.c:423 <= starts waiting on cpu->halt_cond +- shutdown_thread - cpus.c:570 <= not all vcpus paused, so enters while loop +- shutdown_thread - cpus.c:571 <= starts waiting on qemu_pause_cond +- **deadlock** + +In my case, my plugin registers qemu_plugin_vcpu_idle_cb, so the race window is extended significantly in the vcpu thread (cpus.c:421) but I believe it can happen with the smaller race window as well. + +Note that this explanation is just based on my understanding of the code, and the final state of QEMU during the deadlock after I attached: The main thread (thread 1) was waiting on qemu_pause_cond in pause_all_vcpus, and the vcpu was waiting on cpu->halt_cond in qemu_wait_io_event, with no one else to wake either of them up. (This was following an exit that was triggered by a timeout signal) +Steps to reproduce: +This is a race condition, so I don't have a reliable reproducer. diff --git a/results/classifier/105/instruction/1195012 b/results/classifier/105/instruction/1195012 new file mode 100644 index 00000000..e17c4aba --- /dev/null +++ b/results/classifier/105/instruction/1195012 @@ -0,0 +1,53 @@ +instruction: 0.805 +graphic: 0.772 +other: 0.762 +semantic: 0.752 +network: 0.716 +device: 0.688 +mistranslation: 0.655 +socket: 0.582 +boot: 0.527 +vnc: 0.518 +KVM: 0.382 +assembly: 0.284 + +x86_64 and i386 return 0 when reading MSR_TSC + +Running NetBSD 6.1 (i386 and amd64) under QEMU (from git - 1.5.50 is the version it shows) results in an incorrectly set +TSC frequency (set to 0), because NetBSD uses rdmsr(TSC_MSR) for its serializing CPU counter. + +To reproduce the problem, you can run an install ISO of NetBSD 6.1 (either i386 or amd64, depending on which qemu). Quit out of the installer, and you're left at a root prompt: + +# sysctl machdep.tsc_freq +machdep.tsc_freq = 0 + +...on real hardware, it will return the TSC frequency: + +# sysctl machdep.tsc_freq +machdep.tsc_freq = 3292685070 + +...this causes problems with a number of applications. + +The NetBSD code which reads the MSR is here: + +http://nxr.netbsd.org/xref/src/sys/arch/x86/x86/tsc.c#262 + +... the "rdmsr(MSR_TSC)" call in cpu_counter_serializing() always returns 0 when run under QEMU. + +I should mention, the NetBSD 6.1 ISO I used for testing is here: + +http://iso.netbsd.org/pub/NetBSD/iso/6.1/NetBSD-6.1-amd64.iso + + + +The NetBSD problem report where this issue was raised: + +http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=47967 + +a workaround has been put in place for now, but it would be good to fix this in QEMU. + +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/105/instruction/1196498 b/results/classifier/105/instruction/1196498 new file mode 100644 index 00000000..b82522ec --- /dev/null +++ b/results/classifier/105/instruction/1196498 @@ -0,0 +1,42 @@ +instruction: 0.895 +boot: 0.837 +KVM: 0.820 +semantic: 0.806 +device: 0.801 +graphic: 0.790 +network: 0.748 +other: 0.661 +socket: 0.593 +mistranslation: 0.545 +vnc: 0.540 +assembly: 0.527 + +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/105/instruction/1199 b/results/classifier/105/instruction/1199 new file mode 100644 index 00000000..ccf94cff --- /dev/null +++ b/results/classifier/105/instruction/1199 @@ -0,0 +1,23 @@ +instruction: 0.858 +device: 0.846 +vnc: 0.601 +graphic: 0.506 +boot: 0.492 +KVM: 0.366 +network: 0.359 +semantic: 0.265 +socket: 0.249 +mistranslation: 0.189 +assembly: 0.115 +other: 0.080 + +Prevent virtual machine memory leakage +Description of problem: +The data written in the virtual machine does not clear the memory after the virtual machine is shut down. When the virtual machine with large memory is started, it may access the data of the previous virtual machine +Steps to reproduce: +1. create a virtual machine with large size memory( 80% of the host's Physical memory) +2. Request all free memory and write the characteristic string in vm +3. restart the vm +4. Request all free memory and query the last character string written +Additional information: + diff --git a/results/classifier/105/instruction/1204 b/results/classifier/105/instruction/1204 new file mode 100644 index 00000000..e47ce874 --- /dev/null +++ b/results/classifier/105/instruction/1204 @@ -0,0 +1,42 @@ +instruction: 0.457 +device: 0.406 +graphic: 0.397 +semantic: 0.357 +network: 0.356 +socket: 0.345 +assembly: 0.330 +vnc: 0.306 +mistranslation: 0.284 +other: 0.165 +boot: 0.147 +KVM: 0.125 + +AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0 +Description of problem: +As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119). +Memory regions marked as Device do not support unaligned access. +Steps to reproduce: +Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault) +``` +.balign 8 +.global first_variable +first_variable: + .word 0x1 +.balign 4 +.global second_variable +second_variable: + .word 0x2 + +no_mmu_sctlr: .dword 0x0000000030C51834 + +.globl reproducer +reproducer: + ldr x1, no_mmu_sctlr // A=0,M=0 + msr sctlr_el3, x1 + dsb sy + isb + + ldr x0, =first_variable + ldr x1, [x0, #0] // Aligned - Success + ldr x1, [x0, #4] // Unaligned - Success??? (Should be failure) +``` diff --git a/results/classifier/105/instruction/1211943 b/results/classifier/105/instruction/1211943 new file mode 100644 index 00000000..9da6d6fc --- /dev/null +++ b/results/classifier/105/instruction/1211943 @@ -0,0 +1,21 @@ +instruction: 0.935 +device: 0.751 +network: 0.548 +graphic: 0.544 +assembly: 0.538 +socket: 0.489 +boot: 0.311 +semantic: 0.300 +vnc: 0.292 +KVM: 0.278 +other: 0.199 +mistranslation: 0.128 + +#GP and aligned move instruction + +When the operand of movaps, movapd or movdqa instruction isn't aligned, general-protection exception should be generated. + +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/105/instruction/1216845 b/results/classifier/105/instruction/1216845 new file mode 100644 index 00000000..3bbd6775 --- /dev/null +++ b/results/classifier/105/instruction/1216845 @@ -0,0 +1,103 @@ +instruction: 0.771 +other: 0.760 +semantic: 0.753 +graphic: 0.750 +assembly: 0.745 +mistranslation: 0.742 +device: 0.736 +vnc: 0.699 +KVM: 0.650 +network: 0.627 +socket: 0.622 +boot: 0.549 + +qemu-system-arm semihosting always calls exit(0) + +In my embedded ARM project I have a bunch of unit tests that I run in a POSIX synthetic environment, and, as usual for POSIX processes, these tests return 0 for success and !=0 for error. + +Now I expanded the testing environment to run some of these tests compiled for ARM, under QEMU, with the tracing messages forwarded via the semihosting API. + +Up to now everything is fine with the emulation. + +However I have a problem with passing the failure code back to the operating system, to drive the continuous integration framework. + +I checked the arm-semi.c code and for SYS_EXIT and I discovered that the parameter passed is ignored and it always calls exit(0): + + case SYS_EXIT: + gdb_exit(env, 0); + exit(0); + +To solve my problem I temporarily made a patch, and for cases that should return non zero codes, I call an unsupported BKPT instruction, which makes QEMU abort, and pass an non zero code (1) back to the operating system. + + qemu: Unsupported SemiHosting SWI 0xf1 + +This kludge is more or less functional, but is quite inconvenient. + +After checking the ARM manuals, I discovered that SYS_EXIT is not standard, and the 0x18 code used for it originally was used for angel_SWIreason_ReportException, which has a slightly different purpose. + +Now the question: + +Would it be possible to no longer ignore the code passed to 0x18, and if it is non zero, to call exit() with a different value? + +The suggested rule would be: + +if (code ==0 || code == 0x20026) + exit(0); +elif (code < 256) + exit(code); +else + exit(1); + +The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I understood it right, it means that the program terminated successfully. If this is not true, it can be removed from the first conditional statement. + +What do you think? Can this be added to arm-semi.c? + + +Regards, + +Liviu + +Had a similar problem with my emulation environment. However, I did some inspection of the assembly code generated by newlib for ARM semi-hosting. While it initially appears that exit() and _exit() discard the status code, upon careful inspection one finds that it is pushed on the stack, with the SP pointing right to it at the point at which the SWI is executed. + +Thus, if the code passed to 0x18 is 0x20026, you can fetch the status code passed to exit() from the stack. + +thank you for your suggestion. + +as semihosting servers I use the j-link gdb server, openocd and qemu. if I got it right, you suggest to modify all these servers to retrieve the exit code from a specific location. as long as this is not documented in the ARM manuals, I cannot recommend such a solution. + +in the GNU ARM Eclipse project templates I fixed the problem by using my own semihosting routines, where exit returns different values for 0 and non zero, so I no longer depend on the newlib support for semihosting. + + + +On 4 February 2015 at 15:56, Karl Zimmerman +<email address hidden> wrote: +> Had a similar problem with my emulation environment. However, I did +> some inspection of the assembly code generated by newlib for ARM semi- +> hosting. While it initially appears that exit() and _exit() discard the +> status code, upon careful inspection one finds that it is pushed on the +> stack, with the SP pointing right to it at the point at which the SWI is +> executed. +> +> Thus, if the code passed to 0x18 is 0x20026, you can fetch the status +> code passed to exit() from the stack. + +Yes, but this is an internal implementation detail of newlib, +not a part of the semihosting ABI. It might well change +in different versions of newlib and we can't rely on it. + +-- PMM + + +With the new 2.0 ARM semihosting ABI, there is an optional extension SYS_EXIT_EXTENDED which can be used to implement returning a non-zero exit code for 32-bit ARM programs: + +https://developer.arm.com/docs/100863/latest/semihosting-operations/sys_exit_extended-0x20#sh-ext-exit-extended + +QEMU should implement this. + + +https://<email address hidden>/ is a patchset which adds semihosting v2 support to QEMU. With those patches and a guest binary which understands semihosting v2 and knows how to probe for the existence of the EXIT_EXTENDED extension, arm guest binaries will be able to pass a non-zero exit status. + + +The semihosting v2 support went into QEMU in the 4.2 release, but I forgot to close this bug... + + diff --git a/results/classifier/105/instruction/1223477 b/results/classifier/105/instruction/1223477 new file mode 100644 index 00000000..8999ab3d --- /dev/null +++ b/results/classifier/105/instruction/1223477 @@ -0,0 +1,48 @@ +instruction: 0.770 +semantic: 0.769 +device: 0.692 +graphic: 0.607 +socket: 0.605 +other: 0.603 +assembly: 0.553 +mistranslation: 0.431 +vnc: 0.379 +boot: 0.374 +network: 0.372 +KVM: 0.252 + +Unable to read USB filesystems with EFI Bios + +Preamble and version: +With respect to my fix for using USB devices as -hda mentioned in bug 1223467 +Using Qemu 1.6.0 with OVMF r11337-alpha (Qemu is built from Source, OVMF is pre built) + +Command: +qemu-system-i386.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 + +Fault: +The EFI Shell is able to detect the hda block device, report its capacity and usage; +but it sees no files or directories on the device. + +Similar commands: +I have also seen the same with +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-ia32 +and +qemu-system-x86_64.exe -m 1024 -hda \\.\PhysicalDrive1 -L ovmf-x64 + +Investigations: +I tried very small (500MB) and very large (32 GB) USB devices with no difference. +I re-built several versions of Qemu in an identical build environment, and found that: +Qemu 1.2.2 and before, all the above commands work and the EFI boot loader is called. +Qemu 1.3.0-rc0 and after do not work and the USB device appears blank. +I'm reporting the bug here and not with OVMF because older versions of Qemu with the same OVMF bios work perfectly. + +In all cases using '-L pc-bios' works perfectly. +In all cases using an image of the USB device works. + +Thanks + +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/105/instruction/1224 b/results/classifier/105/instruction/1224 new file mode 100644 index 00000000..7b8330e8 --- /dev/null +++ b/results/classifier/105/instruction/1224 @@ -0,0 +1,23 @@ +instruction: 0.864 +graphic: 0.810 +device: 0.749 +network: 0.632 +semantic: 0.518 +socket: 0.456 +vnc: 0.374 +other: 0.295 +boot: 0.209 +mistranslation: 0.186 +assembly: 0.074 +KVM: 0.003 + +QEMU crashes with failed assertion when executing compressed instructions with C extension support disabled +Description of problem: +When executing compressed instructions with compressed instruction support disabled (c=off), the tcg riscv translations fails an assertion. +``` +qemu-system-riscv64: qemu/accel/tcg/translate-all.c:1449: tb_gen_code: Assertion `tb->size != 0' failed. +``` + +I believe that the issue is caused due to the fact that the compressed instruction without RVC support branch of the `decode_opc` function does not update `ctx->pc_succ_insn`, which causes `ctx->base.pc_next` to not be updated in `riscv_tr_translate_insn`, which then finally triggers the assertion once the tcg generation returns to `tb_gen_code`. + +Side note, it also seems like the `gen_exception_illegal` call in the same if case is not needed, since we also call it again at the end of the function. diff --git a/results/classifier/105/instruction/1239008 b/results/classifier/105/instruction/1239008 new file mode 100644 index 00000000..0a02adda --- /dev/null +++ b/results/classifier/105/instruction/1239008 @@ -0,0 +1,90 @@ +instruction: 0.758 +graphic: 0.685 +other: 0.584 +device: 0.558 +KVM: 0.484 +semantic: 0.477 +vnc: 0.386 +socket: 0.375 +mistranslation: 0.358 +assembly: 0.353 +network: 0.334 +boot: 0.275 + +qemu fails to scroll screen on ^Vidmem output + +Pascal uses ^Vidmem for B800 console output. The terminal does not oblige the Pascal OS code to scroll the output. Virtualbox emulation works, so this must be a qemu bug. Using QEMU in KVM mode as Ubuntu LTS. + +Source line to trip bug(in theory pushes VideoMem up one line): + +procedure Scroll; +//this is whats causing crashes. FIXME:Virtualbox not affected.QEMU BUG? +begin + if scrolldisabled then exit; + if (CursorPosY >= 24) then begin //in case called before end of screen + blank:= $20 or (TextAttr shl 8); + Move((VidMem+(2*80))^,VidMem^,24*(2*80)); + // Empty last line + FillWord((VidMem+(24*2*80))^,80,Blank); + CursorPosX:=1; + CursorPosY:=23; + update_cursor; + end; +end; + +Thanks for reporting this bug. Is there any other reproducer you can give us? + +I dont know how to write it myself, but the original kernel scrolling +code is in C. +Might try OSDev forums. Not that I know of. + +On 11/27/2013 09:24 PM, Serge Hallyn wrote: +> Thanks for reporting this bug. Is there any other reproducer you can +> give us? +> +> ** No longer affects: kvm (Ubuntu) +> +> ** Also affects: qemu (Ubuntu) +> Importance: Undecided +> Status: New +> +> ** Changed in: qemu (Ubuntu) +> Status: New => Incomplete +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +Can you test with the latest version to see if this still affects you? +If this still is a problem, any information on how to obtain the Guest OS in question that would also be helpful. + +It is hosted on google code, a dying service. FreePascal(coffee) OS.A +more basic version is posted there.I assume it works as the version that +I last built did not for some reason. Sources should be there via +subversion checkout.Thats what I tested with. +https://code.google.com/p/coffee-os/ + + It uses a basic VRAM scroll buffer and writes to it. + +Examples are found elsewhere in C. (OS Dev pages) +Im in the middle of a fedup upgrade at the moment, but will see what I +can do. + +On 06/17/2015 12:11 PM, Chris J Arges wrote: +> Can you test with the latest version to see if this still affects you? +> If this still is a problem, any information on how to obtain the Guest OS in question that would also be helpful. +> +> ** Changed in: qemu (Ubuntu) +> Status: New => Incomplete +> + + + +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.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1240669 b/results/classifier/105/instruction/1240669 new file mode 100644 index 00000000..e6c683be --- /dev/null +++ b/results/classifier/105/instruction/1240669 @@ -0,0 +1,55 @@ +instruction: 0.745 +graphic: 0.698 +semantic: 0.656 +device: 0.651 +socket: 0.512 +boot: 0.506 +mistranslation: 0.453 +network: 0.389 +assembly: 0.253 +vnc: 0.240 +other: 0.178 +KVM: 0.173 + +sd_init() generates SIGSEGV when passed NULL + +Ran into a bug following the following tutorial: +http://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/ + +I built QEMU from a clone of master and became stuck at the beginning part of the tutorial where only u-boot.bin is exectuted. + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4f8a066b5fc254eeaabbbde56ba4f5b29cc68fdf +See the modifications to sd.c specifically. + +When sd_init (sd.c) is called from pl181_init(), bs is potentially null: +s->card = sd_init(dinfo ? dinfo->bdrv : NULL, false); + +sd_init() : +SDState *sd_init(BlockDriverState *bs, bool is_spi) +{ + SDState *sd; + + sd = (SDState *) g_malloc0(sizeof(SDState)); + sd->buf = qemu_blockalign(bs, 512); + sd->spi = is_spi; + sd->enable = true; + sd_reset(sd, bs); + if (sd->bdrv) { + bdrv_attach_dev_nofail(sd->bdrv, sd); + bdrv_set_dev_ops(sd->bdrv, &sd_block_ops, sd); + } + vmstate_register(NULL, -1, &sd_vmstate, sd); + return sd; +} + +Line 497 calls bdrv_is_read_only(bs) (from block.c)and this generates a SEGSIGV. + +int bdrv_is_read_only(BlockDriverState *bs) +{ + return bs->read_only; +} + +Checking out tag v1.6.1 reverted the problem. Thanks! + +Fixed with commit 794cbc26eb94ce13c75d105eea9ff0afff56e2c2. + diff --git a/results/classifier/105/instruction/1244 b/results/classifier/105/instruction/1244 new file mode 100644 index 00000000..f13056e6 --- /dev/null +++ b/results/classifier/105/instruction/1244 @@ -0,0 +1,58 @@ +instruction: 0.954 +device: 0.910 +graphic: 0.907 +other: 0.906 +vnc: 0.877 +socket: 0.826 +network: 0.813 +assembly: 0.737 +semantic: 0.646 +boot: 0.467 +mistranslation: 0.317 +KVM: 0.062 + +macOS 12.x ld: warning: -undefined dynamic_lookup may not work with chained fixups +Description of problem: +Not sure if this is a serious or negligible problem and if it has any significant runtime implications but reporting it anyway: + +``` +$ ld -v +@(#)PROGRAM:ld PROJECT:ld64-819.6 +BUILD 14:58:44 Aug 5 2022 +configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em +LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29) +TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) + +$ ninja -C build +ninja: Entering directory `build' +[314/2946] Linking static target libevent-loop-base.a +warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libevent-loop-base.a the table of contents is empty (no object file members in the library define global symbols) +[2044/2946] Generating qemu-system-aarch64 with a custom command +qemu-system-aarch64.tmp: replacing existing signature +[2584/2946] Linking target tests/plugin/libempty.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2585/2946] Linking target tests/plugin/libbb.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2588/2946] Linking target tests/plugin/libinsn.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2589/2946] Linking target tests/plugin/libmem.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2592/2946] Linking target tests/plugin/libsyscall.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2946/2946] Linking target tests/qtest/test-arm-mptimer +``` + +I saw a similar discussions in Bazel building system, CPython, and Ruby: +- https://github.com/bazelbuild/bazel/issues/16413 +- https://github.com/python/cpython/issues/97524 +- https://github.com/ruby/ruby/pull/6193 +- https://issues.guix.gnu.org/issue/57849 +Steps to reproduce: +1. ` ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-cocoa --enable-plugins` (note that target list is not that important in this case though) +2. `ninja -C build` +3. Observe the warnings +Additional information: +See "New Features" subsection under "Linking" section for chained fixup +https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes for more information: + +> All programs and dylibs built with a deployment target of macOS 12 or iOS 15 or later now use the chained fixups format. This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. (49851380) diff --git a/results/classifier/105/instruction/1245543 b/results/classifier/105/instruction/1245543 new file mode 100644 index 00000000..99966ab8 --- /dev/null +++ b/results/classifier/105/instruction/1245543 @@ -0,0 +1,43 @@ +instruction: 0.966 +other: 0.798 +device: 0.770 +semantic: 0.629 +socket: 0.619 +network: 0.548 +vnc: 0.529 +graphic: 0.455 +boot: 0.437 +mistranslation: 0.417 +assembly: 0.269 +KVM: 0.262 + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" + + + +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/105/instruction/1248168 b/results/classifier/105/instruction/1248168 new file mode 100644 index 00000000..22e04de3 --- /dev/null +++ b/results/classifier/105/instruction/1248168 @@ -0,0 +1,42 @@ +instruction: 0.820 +graphic: 0.800 +assembly: 0.749 +device: 0.731 +mistranslation: 0.533 +socket: 0.270 +boot: 0.257 +other: 0.250 +semantic: 0.231 +vnc: 0.131 +network: 0.118 +KVM: 0.030 + +MIPS, self-modifying code and uncached memory + +Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region. + +For example, when running this code I get unexpected behavior: + + 0: e3000010 b 0x390 + 4: 00000000 nop + ... + 380: 00701f40 mfc0 ra,c0_epc + 384: 0400e0bb swr zero,4(ra) + 388: 18000042 eret + 38c: 00000000 nop + 390: 25500000 move t2,zero + 394: 02000b34 li t3,0x2 + 398: 23504b01 subu t2,t2,t3 + 39c: e9003c0b j 0xcf003a4 + 3a0: 0a004a21 addi t2,t2,10 + 3a4: ffff0010 b 0x3a4 + 3a8: 00000000 nop + 3ac: 00000000 nop + + I expect that swr instruction in line 384 would change `addi t2,t2,1`0 to `nop` +This should work because no cache is used for this memory region. + +Can you please provide full reproduction steps rather than just an assembly snippet? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1251 b/results/classifier/105/instruction/1251 new file mode 100644 index 00000000..705c9b8f --- /dev/null +++ b/results/classifier/105/instruction/1251 @@ -0,0 +1,28 @@ +instruction: 0.897 +device: 0.728 +graphic: 0.575 +other: 0.533 +semantic: 0.489 +socket: 0.478 +network: 0.473 +vnc: 0.435 +boot: 0.384 +mistranslation: 0.203 +assembly: 0.066 +KVM: 0.016 + +Octeon Instruction BBIT Bug +Steps to reproduce: +1. Compile 64bit binary for Octeon with Octeon instructions +`mips64-octeon-linux-gnu-gcc -o hello hello.c` +2. Run with `qemu-mips64` +`qemu-mips64 -cpu Octeon68XX hello` +3. Get the output below: +``` +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Additional information: +I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. + +[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/results/classifier/105/instruction/1253465 b/results/classifier/105/instruction/1253465 new file mode 100644 index 00000000..c11e6ac5 --- /dev/null +++ b/results/classifier/105/instruction/1253465 @@ -0,0 +1,74 @@ +instruction: 0.812 +other: 0.741 +semantic: 0.736 +mistranslation: 0.715 +device: 0.691 +network: 0.578 +socket: 0.536 +assembly: 0.502 +graphic: 0.479 +boot: 0.475 +KVM: 0.459 +vnc: 0.383 + +qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 + +qemu-img convert in.vmdk -O RAW out.img + +Fails with: +qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 + +qemu-img version 1.6.1 + +On Wed, Nov 20, 2013 at 11:00:14PM -0000, adrelanos wrote: +> qemu-img convert in.vmdk -O RAW out.img +> +> Fails with: +> qemu-img: 'image' uses a vmdk feature which is not supported by this qemu version: VMDK version 3 +> +> qemu-img version 1.6.1 + +This is a known issue. VMware has not released the file format +specification for VMDK version 3. At this point the information needed +to implement version 3 support is not publicly available. + +If you are aware of open source software which already supports version +3, please let us know! + +Fam: Do you have instructions for exporting version 2 images from +VMware? + +Stefan + + +> If you are aware of open source software which already supports version 3, please let us know! + +VirtualBox can. + +- VirtualBox uses VMDK version 3 disks. +- When you export a VM with VirtualBox (creating an .ova), it will include VMDK version 3 disks. +- VirtualBox can convert from vmkd to vdi. ('VBoxManage clonehd --format VDI "vmdk_file" "vdi_file"') + +Does that help? + + +On Sat, 01/07 21:36, Patrick Schleizer wrote: +> > If you are aware of open source software which already supports +> version 3, please let us know! +> +> VirtualBox can. +> +> - VirtualBox uses VMDK version 3 disks. +> - When you export a VM with VirtualBox (creating an .ova), it will include VMDK version 3 disks. +> - VirtualBox can convert from vmkd to vdi. ('VBoxManage clonehd --format VDI "vmdk_file" "vdi_file"') +> +> Does that help? + +Can you try again with QEMU 2.8? Recent versions of QEMU should be able to +handle version 3 VMDK disks. + +Fam + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1256826 b/results/classifier/105/instruction/1256826 new file mode 100644 index 00000000..bc7e909a --- /dev/null +++ b/results/classifier/105/instruction/1256826 @@ -0,0 +1,29 @@ +instruction: 0.987 +device: 0.836 +graphic: 0.816 +semantic: 0.669 +network: 0.548 +mistranslation: 0.505 +other: 0.468 +vnc: 0.439 +boot: 0.415 +socket: 0.385 +KVM: 0.235 +assembly: 0.135 + +INT instruction bug in WindowsXP + +This bug is in -no-kvm mode. + +In windowsXP at IDT entry 2&8 is Task gate + +when application use INT 2 or INT 8 it will cause blue screen in XP. + +I found it should cause #GP not generate hw interrupt. + +also I check this bug with -enable-kvm and works correctly. + +Which QEMU version did you use here? Can you still reproduce this problem with the latest version of QEMU (currently 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1260555 b/results/classifier/105/instruction/1260555 new file mode 100644 index 00000000..e4b44dd4 --- /dev/null +++ b/results/classifier/105/instruction/1260555 @@ -0,0 +1,237 @@ +instruction: 0.853 +mistranslation: 0.843 +other: 0.822 +assembly: 0.821 +graphic: 0.818 +semantic: 0.818 +device: 0.810 +boot: 0.794 +KVM: 0.790 +socket: 0.786 +vnc: 0.772 +network: 0.772 + +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/105/instruction/1266 b/results/classifier/105/instruction/1266 new file mode 100644 index 00000000..cf678e57 --- /dev/null +++ b/results/classifier/105/instruction/1266 @@ -0,0 +1,14 @@ +instruction: 0.933 +device: 0.890 +graphic: 0.398 +network: 0.362 +boot: 0.318 +semantic: 0.301 +vnc: 0.219 +mistranslation: 0.079 +assembly: 0.076 +socket: 0.042 +other: 0.025 +KVM: 0.024 + +Assert in resettable_phase_enter through virtio-scsi diff --git a/results/classifier/105/instruction/1268671 b/results/classifier/105/instruction/1268671 new file mode 100644 index 00000000..335beb92 --- /dev/null +++ b/results/classifier/105/instruction/1268671 @@ -0,0 +1,66 @@ +instruction: 0.735 +device: 0.722 +graphic: 0.666 +semantic: 0.615 +other: 0.585 +vnc: 0.568 +network: 0.555 +KVM: 0.492 +socket: 0.488 +boot: 0.397 +mistranslation: 0.319 +assembly: 0.164 + +CentOS guest crashing due to assertion failure in qemu-char.c + +Here is the log in /var/log/libvirt/qemu/centos_heavy.log + +qemu-kvm: /builddir/build/BUILD/qemu-kvm-0.12.1.2/qemu-char.c:630: io_watch_poll_finalize: Assertion `iwp->src == ((void *)0)' failed. +2014-01-13 16:50:31.576+0000: shutting down + +The code it's failing the assertion on has an interesting comment: + + static void io_watch_poll_finalize(GSource *source) + { + /* Due to a glib bug, removing the last reference to a source + * inside a finalize callback causes recursive locking (and a + * deadlock). This is not a problem inside other callbacks, + * including dispatch callbacks, so we call io_remove_watch_poll + * to remove this source. A t this point, iwp->src must + * be NULL, or we would leak it. + * + * This would be solved much more elegantly by child sources, + * but we support older glib versions that do not have them. + */ + IOWatchPoll *iwp = io_watch_poll_from_source(source); + assert(iwp->src == NULL); + } + +------ +CPU Info: + +http://pastebin.com/U7MrzFxK + +-------- + +Relevant RPM versions: + +qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64 +libvirt-0.10.2-29.el6_5.2.x86_64 + +-------- + +Domain config: + +http://pastebin.com/Nf2VsER8 + +(Note the use of the vmchannels; I believe this is playing a part in this crash) + + + +QEMU 0.12 is completely outdated nowadays ... can you still reproduce this problem with the latest version of QEMU? + +It's a glib bug. It's fixed in RHEL 6.9 beta and in due time the fix will get to CentOS. + +https://bugzilla.redhat.com/show_bug.cgi?id=1212722 + diff --git a/results/classifier/105/instruction/1269 b/results/classifier/105/instruction/1269 new file mode 100644 index 00000000..68311609 --- /dev/null +++ b/results/classifier/105/instruction/1269 @@ -0,0 +1,39 @@ +instruction: 0.882 +device: 0.808 +network: 0.786 +boot: 0.785 +graphic: 0.770 +vnc: 0.666 +socket: 0.529 +semantic: 0.525 +other: 0.461 +mistranslation: 0.411 +KVM: 0.070 +assembly: 0.065 + +qemu-system-i386 no longer boots NetBSD +Description of problem: +Since qemu commit e3a79e0e87831602e41819591a8e6dcc70a2a231, NetBSD +no longer boots under qemu-system-i386. +Steps to reproduce: +1. `wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/i386/installation/cdrom/boot-com.iso` +2. `qemu-system-i386 -nographic -cdrom boot-com.iso` + +Expected behavior: the system boots and prompts you for a terminal type with + + Terminal type (just hit ENTER for 'vt220'): + +Observed incorrect behavior: the guest kernel either hangs during boot at + + Loading /stand/i386/9.2/modules/cd9660/cd9660.kmod + WARNING: 1 module failed to load + +or panics during boot with + + kernel: supervisor trap page fault, code=0 + Stopped in pid 0.1 (system) at netbsd:idt_vec_reserve+0xa: cmpb $0,netbs + d:idt_allocmap(%ebx) + db{0}> +Additional information: +This regression is a critical issue to the NetBSD project as its automated +testing infrastructure is heavily dependent on qemu-system-i386. diff --git a/results/classifier/105/instruction/1272796 b/results/classifier/105/instruction/1272796 new file mode 100644 index 00000000..c6f4273e --- /dev/null +++ b/results/classifier/105/instruction/1272796 @@ -0,0 +1,39 @@ +instruction: 0.877 +graphic: 0.810 +boot: 0.802 +device: 0.787 +semantic: 0.726 +other: 0.690 +socket: 0.631 +mistranslation: 0.613 +vnc: 0.533 +assembly: 0.498 +KVM: 0.449 +network: 0.421 + +Windows 98 First Edition emulation problems + +System: Debian SID x86 with latest updates + +1) QEMU compiled from latest main GIT branch (and 1.7 stable version) +./configure options: ./configure --enable-sdl --target-list=i386-softmmu --cpu=i686 --audio-drv-list=alsa + +When you try to boot Windows 98 First Edition (Italian), it does not simply boot. It stays on booting screen. +If you try to install, the installation goes flawless, but when it boots it freeze. + +I am launching VM with this: qemu-system-i386 -hda main.img -cpu pentium -m 256 -fda floppy1.img -boot c -soundhw gus -vga cirrus + +I have tried with -M option "pc-i440fx-1.6" since 1.6 have no problems with the booting of Win98, but nothing. No fix found. + +2) QEMU 1.6.2 (same compile and launching options) +gus soundboard seems not recognized even with real dos drivers (tried to install theme into real dos mode). +with SoundBlaster 16 i have following error: WARNING: I/O thread spun for 1000 iterations, making the emulation impossible (too slow, and sound is stuttering) . Tried to compile with oss and sdl option on audio-drv-list but no fix found. + +Any ideas? thank you + +Even with Windows 98 SE (English and Italian) still not working. Got some ideas? + +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/105/instruction/1277 b/results/classifier/105/instruction/1277 new file mode 100644 index 00000000..ae4c7a90 --- /dev/null +++ b/results/classifier/105/instruction/1277 @@ -0,0 +1,14 @@ +instruction: 0.910 +graphic: 0.792 +device: 0.782 +other: 0.634 +assembly: 0.546 +KVM: 0.541 +vnc: 0.529 +socket: 0.454 +network: 0.440 +boot: 0.424 +semantic: 0.371 +mistranslation: 0.257 + +two instructions has executed twice diff --git a/results/classifier/105/instruction/1278166 b/results/classifier/105/instruction/1278166 new file mode 100644 index 00000000..209513db --- /dev/null +++ b/results/classifier/105/instruction/1278166 @@ -0,0 +1,21 @@ +instruction: 0.713 +graphic: 0.632 +device: 0.532 +mistranslation: 0.517 +other: 0.426 +semantic: 0.352 +vnc: 0.207 +socket: 0.205 +network: 0.188 +boot: 0.163 +assembly: 0.091 +KVM: 0.007 + +Last commit to exec.c causes BSOD installing WinXP on i386-softmmu + +The last commit to exec.c (360e607b88a23d378f6efaa769c76d26f538234d), causes a BSOD when trying to install a 32bit Windows XP SP-3 image using the pure emulation version of i386-softmmu. A checkout of the previous version of the file (commited in 0169c511554cb0014a00290b0d3d26c31a49818f) solves the problem. Nevertheless, this last commit was intented to solve a BSOD when Xen was used as a hypervisor. + +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/105/instruction/1283519 b/results/classifier/105/instruction/1283519 new file mode 100644 index 00000000..5dee496d --- /dev/null +++ b/results/classifier/105/instruction/1283519 @@ -0,0 +1,28 @@ +instruction: 0.918 +device: 0.844 +graphic: 0.800 +network: 0.626 +mistranslation: 0.585 +semantic: 0.478 +socket: 0.448 +boot: 0.419 +other: 0.407 +vnc: 0.387 +KVM: 0.186 +assembly: 0.065 + +PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped + +When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions: + +If the binary contains vrfim QEMU sees vrfiz +If the binary contains vrfin QEMU sees vrfim +If the binary contains vrfiz QEMU sees vrfin +The vrfip instruction is correctly recognized. + +Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n). + +This problem should have been fixed by the following commit: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=abe60a439b760c749201 +... so closing this ticket now. + diff --git a/results/classifier/105/instruction/129 b/results/classifier/105/instruction/129 new file mode 100644 index 00000000..4f78f621 --- /dev/null +++ b/results/classifier/105/instruction/129 @@ -0,0 +1,25 @@ +instruction: 0.762 +device: 0.738 +semantic: 0.632 +graphic: 0.595 +mistranslation: 0.462 +vnc: 0.262 +network: 0.258 +boot: 0.251 +socket: 0.164 +KVM: 0.083 +other: 0.042 +assembly: 0.009 + +Build failure due to conflicts with the C++20 version header +Steps to reproduce: +qemu 5.2.0: +``` +brew install -s qemu +``` + +qemu 6.0.0: +``` +wget https://raw.githubusercontent.com/Homebrew/homebrew-core/02107501a48cc9d08480913ee1c79866dc60c23a/Formula/qemu.rb +brew install -s qemu.rb +``` diff --git a/results/classifier/105/instruction/1306818 b/results/classifier/105/instruction/1306818 new file mode 100644 index 00000000..673a970b --- /dev/null +++ b/results/classifier/105/instruction/1306818 @@ -0,0 +1,61 @@ +instruction: 0.803 +semantic: 0.640 +network: 0.611 +device: 0.610 +other: 0.503 +socket: 0.432 +graphic: 0.354 +mistranslation: 0.280 +boot: 0.257 +vnc: 0.250 +assembly: 0.167 +KVM: 0.064 + +resetting moder register in opencores_eth.c code (ethernet IP core specification code) + +Hi, I would like to report a possible error in the code qemu/hw/net/opencores_eth.c + +The corresponding data sheet : http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf + + +In the code, there is a function open_eth_moder_host_write. + +static void open_eth_moder_host_write(OpenEthState *s, uint32_t val) +{ + uint32_t set = val & ~s->regs[MODER]; + + if (set & MODER_RST) { + open_eth_reset(s); + } + + s->regs[MODER] = val; + + if (set & MODER_RXEN) { + s->rx_desc = s->regs[TX_BD_NUM]; + open_eth_notify_can_receive(s); + } + if (set & MODER_TXEN) { + s->tx_desc = 0; + open_eth_check_start_xmit(s); + } +} + +This piece of code is executed when MODER (Mode Register) resister is command to updated to ‘val’. + +In case of reset, as you can see, if the MODER_RST bit (0x800) bit is set && the old MODER_RST bit (0x800) of MODER register is clear, the code falls into the if(set & MODER_RST) branch. Then, it calls open_eth_reset(s), which does “s->regs[MODER] = 0xa000;”. Now, the MODER register is reset to 0xa000. Page 9 of the data sheet (http://www.cprover.org/firmware/doc/ethoc/eth_speci.pdf) specifies the reset value of the moder is 0000A000h. So far, the code works fine. +Then, the open_eth_moder_host_write function does not end but executes but executes “s->regs[MODER] = val;” line. Now, the MODER register is not 0xa000 any more. +In fact, since the MODER_RST bit of ‘val’ is 1, now the MODER_RST bit of the MODER register becomes 1 as well. Suppose one somehow calls this open_eth_moder_host_write again with val = MODER_RST with purpose of resetting again. Since the MODER_RST bit is 1, (set = val & ~s->regs[MODER]) & MODER_RST is zero. So after this, resetting again is not possible. + +Hence, I doubt the function’s correctness here. I think it could be better if the function changes to : + + if (set & MODER_RST) { + open_eth_reset(s); + return; + } + +Please let me know if I am correct. + +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/105/instruction/1308381 b/results/classifier/105/instruction/1308381 new file mode 100644 index 00000000..b6f24b24 --- /dev/null +++ b/results/classifier/105/instruction/1308381 @@ -0,0 +1,99 @@ +instruction: 0.904 +assembly: 0.817 +graphic: 0.807 +device: 0.793 +other: 0.778 +vnc: 0.762 +boot: 0.749 +mistranslation: 0.744 +socket: 0.709 +network: 0.693 +KVM: 0.628 +semantic: 0.520 + +illegal instructions for AArch64 ARMv8 + +The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): +$aarch64-linux-gnu-gcc qemu.c -o test +$./test +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + +There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: +SQXTUN Bd, Hn +SQXTUN Hd, Sn +SQXTUN Sd, Dn. + +It seems that these instructions are not supported in QEMU. Is this a bug? + + + +Can you attach a statically linked test case binary, please? + + + +Peter Maydell <email address hidden> writes: + +> Can you attach a statically linked test case binary, please? + +I can reproduce with the source file. It looks like: + +@@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn) + } + break; + case 0x12: /* SQXTUN */ +- if (u) { +- unallocated_encoding(s); +- return; +- } + /* fall through */ + +Fixes it. Let me check why this slipped through the risu tests and +re-validate. I'll submit a patch once I've double checked. + +-- +Alex Bennée + + + +On 16 April 2014 11:55, Alex Bennée <email address hidden> wrote: +> +> Peter Maydell <email address hidden> writes: +> +>> Can you attach a statically linked test case binary, please? +> +> I can reproduce with the source file. It looks like: +> +> @@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn) +> } +> break; +> case 0x12: /* SQXTUN */ +> - if (u) { +> - unallocated_encoding(s); +> - return; +> - } +> /* fall through */ +> +> Fixes it. + +However the ARM ARM, unless I'm misreading it, requires scalar-2-misc +SQXTUN to have U==1, so the correct fix should be to turn that "if (u)" +into "if (!u)" I think. (Opcode 0x12 u==0 isn't in the table so should undef.) + +Better check we didn't make the same mistake in the vector-2-misc +decode as well. + +thanks +-- PMM + + +Fix identified + +I've sent this patch to the mailing list but it fixes the attached test case and has been tested with risu patterns. + +@pmaydell: yeah vector is unaffected as U is used to select another opcode. + +Patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e44a90c59697cf98 +==> Fix released + diff --git a/results/classifier/105/instruction/1309034 b/results/classifier/105/instruction/1309034 new file mode 100644 index 00000000..773fcdd4 --- /dev/null +++ b/results/classifier/105/instruction/1309034 @@ -0,0 +1,48 @@ +instruction: 0.821 +KVM: 0.812 +graphic: 0.788 +device: 0.757 +semantic: 0.722 +boot: 0.677 +mistranslation: 0.662 +other: 0.660 +socket: 0.617 +network: 0.548 +assembly: 0.527 +vnc: 0.487 + +A way not to grab keyboards or mice + +I set up the window manager to move windows with Alt-Btn1, and to +iconify windows with Shift-Btn1. But since qemu grabs keyboards and +mice, I can't move or iconify the qemu window. + +I tried not to grab anything, by inserting return, just beginnig of +ui/sdl.c:sdl_grab_start() as follows: + +static void sdl_grab_start(void) +{ + return; + /* + +It is comfortable. I'm glad if you make a way not to grab. +Environment variables, options, etc are welcome. + +Current command line is: +QEMU_AUDIO_DRV=pa /usr/local/bin/qemu-system-x86_64 -enable-kvm -hda /dosc/win8_x64.img -soundhw hda -boot c -m 2G -cpu Nehalem,+sep -usb -usbdevice tablet -display sdl -rtc base=localtime + +qemu version is: +luna:linux % qemu-system-x86_64 --version +QEMU emulator version 1.7.93, Copyright (c) 2003-2008 Fabrice Bellard +luna:linux % + +Host: slackware64 14.1 +Host Environment: xfce4 / sawfish +Guest: Windows 8.1 x64 + +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/105/instruction/1314 b/results/classifier/105/instruction/1314 new file mode 100644 index 00000000..c7fe18f7 --- /dev/null +++ b/results/classifier/105/instruction/1314 @@ -0,0 +1,53 @@ +instruction: 0.747 +graphic: 0.746 +other: 0.715 +device: 0.668 +semantic: 0.636 +mistranslation: 0.609 +network: 0.597 +vnc: 0.593 +KVM: 0.558 +socket: 0.528 +boot: 0.505 +assembly: 0.379 + +68k: issues with fremx and fmodx +Description of problem: +Some of the mac68k folks have been testing my MacOS branch at https://github.com/mcayland/qemu/tree/q800.upstream2-vm and noticed problems with the values of some of the MacOS _Pack5 transcendental functions. This is easily visible when calling the `sin()` and `cos()` functions whereby some angle ranges use the values from the wrong section of the waveform and/or return values with the incorrect sign. + +SolraBizna was kind enough to write a 68K MacOS test program to generate a sine table (including dumping the hex values of the FP registers) that could be run on real hardware for comparison with QEMU. Using this it was discovered that the issue is related to the implementation of the `fremx` and `fmodx` instructions which can be found in [`floatx80_modrem()`](https://gitlab.com/qemu-project/qemu/-/blob/master/fpu/softfloat.c#L2601). + +I have taken the output of the test program run on a real 68040 Mac and used it to create a test harness at https://github.com/mcayland/qemu/commits/68k-fmodrem-bug [(diff from git master)](https://github.com/mcayland/qemu/commit/4afd6b7c3cad89df943ec43395f95dad7f368338.diff) which iterates over 100 points of the sine table and uses the registers to indicate any failures according to the following comment: + +``` + /* + * The test program below hangs when it completes and the exit + * condition can be determined using the monitor via "info + * registers" command as follows: + * + * D7 is the test number (0-99) + * D6 is the error code + * 0 = no error + * 1 = frem result incorrect + * 2 = frem fpsr result incorrect + * 3 = fmod result incorrect + * 4 = fmod fpsr result incorrect + * D2 is the actual result of the long comparison + * D1 is the expected result of the long comparison + * + * A successful termination of the test program is when D7 == 100 + * and D6 == 0. + */ +``` + +This enables the majority of debugging to be done directly using `info registers` in the monitor rather than manually stepping through the example code using the gdbstub. + +Based upon my local testing on `qemu-system-m68k` there are 2 main differences between QEMU and the output from a real 68040: + +- Differences in precision + +The very first `fremx` result comparison fails here returning `0x3ffe0000 0xc90fdaa2 0x2168c23c 0x........` instead of `0x3ffe0000 0xc90fdaa2 0x2168c238 0x........`. Fortunately the difference in precision is small, and while it may not be possible to fix this, at least it gives a measure of how QEMU's emulation compares to a real 68040. + +- Incorrect setting of the quotient byte + +Bits 16-23 of the FPSR are supposed to contain the sign and 7 LSBs of the quotient for `fremx` and `fmodx` instructions, which is used in _Pack5 to generate an offset into a lookup table for the transcendental functions. It appears that the main cause of the incorrect `sin()` and `cos()` functions is due to the quotient byte being set incorrectly by `fremx`, causing MacOS to jump to the wrong segment of the lookup table for certain angle ranges. diff --git a/results/classifier/105/instruction/1328996 b/results/classifier/105/instruction/1328996 new file mode 100644 index 00000000..b48ededc --- /dev/null +++ b/results/classifier/105/instruction/1328996 @@ -0,0 +1,25 @@ +instruction: 0.932 +device: 0.871 +mistranslation: 0.798 +graphic: 0.713 +semantic: 0.618 +network: 0.577 +socket: 0.504 +other: 0.463 +vnc: 0.395 +boot: 0.376 +assembly: 0.134 +KVM: 0.107 + +[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/105/instruction/1338563 b/results/classifier/105/instruction/1338563 new file mode 100644 index 00000000..0170bcea --- /dev/null +++ b/results/classifier/105/instruction/1338563 @@ -0,0 +1,55 @@ +instruction: 0.804 +other: 0.750 +network: 0.680 +semantic: 0.652 +mistranslation: 0.643 +device: 0.513 +socket: 0.426 +graphic: 0.361 +KVM: 0.344 +vnc: 0.340 +boot: 0.272 +assembly: 0.230 + +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/105/instruction/1354529 b/results/classifier/105/instruction/1354529 new file mode 100644 index 00000000..e5719bac --- /dev/null +++ b/results/classifier/105/instruction/1354529 @@ -0,0 +1,62 @@ +instruction: 0.849 +graphic: 0.780 +device: 0.740 +socket: 0.738 +semantic: 0.705 +network: 0.681 +vnc: 0.644 +boot: 0.560 +mistranslation: 0.414 +KVM: 0.393 +assembly: 0.306 +other: 0.243 + +qemu-io: Assert failure on the fuzzed qcow2 image + +'qemu-io -c write' failed on the fuzzed image with missed refcount tables: + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.cow in the same directory + 3. Execute + qemu-io copy.img -c 'write 2856960 208896' + +Result: qemu-io was killed by SIGIOT with the reason: + +qemu-io: block/qcow2-cluster.c:910: handle_copied: Assertion `*host_offset == 0 +|| offset_into_cluster(s, guest_offset) == offset_into_cluster(s, *host_offset)' + failed. + +qemu.git HEAD 2d591ce2aeebf + + + +Hi, + +The problem here is that an L2 table contains an offset which is not aligned on cluster boundaries. To turn the failed assertion into an EIO (and probably we also want to mark the image corrupt), we'd have to verify every single L2 entry when it is read. + +We can (and should) most certainly do that, but as it doesn't seem too urgent, it may take some time. + +Max + +Hi, + +This issue has been fixed in master (5f77ef69a195098baddfdc6d189f1b4a94587378): + +$ ./qemu-io copy.img -c 'write 2856960 208896' +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: Invalid argument +qcow2_free_clusters failed: File too large +qcow2_free_clusters failed: Invalid argument +qcow2: Image is corrupt: Cannot free unaligned cluster 0xfffffffffffe00; further non-fatal corruption events will be suppressed +qcow2_free_clusters failed: Invalid argument +qcow2: Marking image as corrupt: Data cluster offset 0xfffffe00 unaligned (guest offset: 0x2e1000); further corruption events will be suppressed +write failed: Input/output error + +Thanks for your report (and your fuzzer), + +Max + diff --git a/results/classifier/105/instruction/1354727 b/results/classifier/105/instruction/1354727 new file mode 100644 index 00000000..9ad054ff --- /dev/null +++ b/results/classifier/105/instruction/1354727 @@ -0,0 +1,28 @@ +instruction: 0.886 +graphic: 0.644 +device: 0.592 +network: 0.490 +mistranslation: 0.470 +semantic: 0.440 +socket: 0.387 +vnc: 0.384 +assembly: 0.315 +other: 0.230 +boot: 0.137 +KVM: 0.079 + +build error with GCC 4.9 + +% gcc --version +gcc (GCC) 4.9.1 + +latest development version on git + +xen-hvm.c: In function ‘xen_hvm_init’: +xen-hvm.c:1008:41: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn); + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1355 b/results/classifier/105/instruction/1355 new file mode 100644 index 00000000..d3f074be --- /dev/null +++ b/results/classifier/105/instruction/1355 @@ -0,0 +1,14 @@ +instruction: 0.835 +device: 0.795 +network: 0.549 +graphic: 0.520 +semantic: 0.350 +mistranslation: 0.308 +socket: 0.293 +boot: 0.255 +assembly: 0.193 +vnc: 0.147 +other: 0.120 +KVM: 0.016 + +qemu-system-x86_64: Issue while setting TUNSETSTEERINGEBPF: Invalid argument with fd: 13, prog_fd: -1 diff --git a/results/classifier/105/instruction/1355738 b/results/classifier/105/instruction/1355738 new file mode 100644 index 00000000..05e701fe --- /dev/null +++ b/results/classifier/105/instruction/1355738 @@ -0,0 +1,58 @@ +instruction: 0.589 +semantic: 0.504 +graphic: 0.446 +device: 0.389 +network: 0.267 +vnc: 0.248 +KVM: 0.247 +socket: 0.234 +mistranslation: 0.215 +boot: 0.184 +assembly: 0.156 +other: 0.119 + +qemu-img: Killed by SIGTRAP on check of the fuzzed image + +'qemu-img check -r all' was killed by SIGTRAP. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.qed in the same directory + 3. Execute + +qemu-img check -f qcow2 -r all copy.img + +Result: qemu-img was killed by SIGTRAP with the reason: + +(process:2210): GLib-ERROR **: gmem.c:140: failed to allocate 18446744069633940288 bytes + +The qemu-img execution log can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf + + + +Hi, + +This issue has at least been partially fixed in master (5f77ef69a195098baddfdc6d189f1b4a94587378): + +$ ./qemu-img check -f qcow2 -r all copy.img +# ... +The following inconsistencies were found and repaired: + + 0 leaked clusters + 1 corruptions + +Double checking the fixed image now... + +469 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +4766 internal errors have occurred during the check. +2459/4434 = 55.46% allocated, 99.31% fragmented, 10.41% compressed clusters +Image end offset: 2048 + +As with bug 1355697, I'm still working on the repair function. But this image is broken in a way that there's no real way to fix it. The best we could do is ask the user to use qemu-img convert and then hope for the best. I'll just mark this as fixed. + +Max + diff --git a/results/classifier/105/instruction/1356916 b/results/classifier/105/instruction/1356916 new file mode 100644 index 00000000..086022c2 --- /dev/null +++ b/results/classifier/105/instruction/1356916 @@ -0,0 +1,23 @@ +instruction: 0.368 +device: 0.353 +mistranslation: 0.321 +semantic: 0.153 +graphic: 0.142 +network: 0.090 +socket: 0.079 +boot: 0.040 +other: 0.035 +vnc: 0.033 +KVM: 0.011 +assembly: 0.007 + +Too small argv limit + +Current kernels don't have a fixed argv/environ limit any more, but the user-space emulation of qemu is still using a fixed limit. This can cause execve to fail when it wouldn't on a real system. For example, the follwing command should not fail in the emulated environment: + +$ /bin/true $(yes | head -n 100000) +-bash: /bin/true: Argument list too long + +This was fixed in QEMU 2.5. + + diff --git a/results/classifier/105/instruction/1357226 b/results/classifier/105/instruction/1357226 new file mode 100644 index 00000000..659afb0e --- /dev/null +++ b/results/classifier/105/instruction/1357226 @@ -0,0 +1,80 @@ +instruction: 0.858 +other: 0.849 +graphic: 0.819 +boot: 0.807 +mistranslation: 0.785 +device: 0.772 +semantic: 0.766 +vnc: 0.726 +socket: 0.684 +KVM: 0.677 +assembly: 0.661 +network: 0.538 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +steps to reproduce: +pbuilder-dist utopic armhf create +pbuilder-dist utopic armhf login +apt-get install imagemagick +convert foo.xpm foo.png +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +(doesn't matter if images are actually there or not) + +I'm running into this same problem, and it's making automation of Raspberry Pi builds of my application difficult. + +I'm running in a chroot environment: +3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 armv7l GNU/Linux + +Package: qemu +Version: 1.1.2+dfsg-6a+deb7u11 + +This may or may not be relevant here, but the mysterious "uncaught target signal 11" error was fixed for maas images (lp:maas-images) build process by increasing the memory to the VMs that were doing the build. We had been doing the cross/qemu-static building in ~512M vms and that was resulting in somewhat transient failures during 'apt-get update'. Upping the memory of the vm to 2G made those go away. + + +Status changed to 'Confirmed' because the bug affects multiple users. + +Thanks Thomas for assigning to Ubuntu's Qemu which is correct in this case. +I know there are still issues reported by Locutus to look into, but this one seems expired. + +I don't want to appear randomly closing bugs, so I verified with something "old" which today would be Trusty. So there I ran. + +$ pbuilder-dist trusty armhf create +$ pbuilder-dist trusty armhf login +$ apt-get install imagemagick +$ convert foo.xpm foo.png (file not there) +$ convert ./share/pixmaps/display.im6.xpm ./share/pixmaps/display.im6.png (Trusty) +$ convert ./share/pixmaps/display-im6.q16.xpm ./share/pixmaps/display-im6.q16.png (Artful) + +All working, so closing this old bug as invalid now. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Hi, I am getting the error: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +When I try to execute a Hello World binary on my amd64 machine, with Hello World built by mips-linux-gnu-g++, using either mips binfmt extensions (./hello) or qemu-mips-static hello. I have libstdc++6:mips installed as well. My source code is as follows: + +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +Worth noting that this problem only happens with mips cross runs. mips64el and mipsel work just fine. + +I happen to be doing this in Debian 10.0.0 Buster stable amd64 on VirtualBox on Ubuntu 19.04 Disco Dingo amd64, but it looks like the same behavior on native Ubuntu hosts as well. I tried increasing guest RAM to 1GiB and 2GiB, with no affect on the runtime error message. Is there a glitch in one of the mips packages? + +@mcandre, I think your issue, even though it's also a segfault, is a different one than this bug from 2014, which was about armhf and was verified in comment #4 as no longer happening. + +Could you please open a separate bug about what you experienced, including detailed steps to reproduce it? Attaching the core file would also help. + +Thanks! + + diff --git a/results/classifier/105/instruction/1358 b/results/classifier/105/instruction/1358 new file mode 100644 index 00000000..729e9d55 --- /dev/null +++ b/results/classifier/105/instruction/1358 @@ -0,0 +1,14 @@ +instruction: 0.681 +mistranslation: 0.602 +semantic: 0.536 +graphic: 0.368 +device: 0.248 +assembly: 0.169 +vnc: 0.136 +KVM: 0.094 +boot: 0.089 +other: 0.042 +network: 0.019 +socket: 0.019 + +Remove CPUState::trace_dstate diff --git a/results/classifier/105/instruction/1361912 b/results/classifier/105/instruction/1361912 new file mode 100644 index 00000000..059c8634 --- /dev/null +++ b/results/classifier/105/instruction/1361912 @@ -0,0 +1,80 @@ +instruction: 0.768 +device: 0.750 +assembly: 0.717 +other: 0.596 +socket: 0.538 +network: 0.523 +vnc: 0.465 +boot: 0.387 +mistranslation: 0.330 +graphic: 0.328 +semantic: 0.286 +KVM: 0.087 + +qemu-mips64 Segmentation fault + +When I ran qemu-mips64 for any mips 64 executable , I got this error: + +$ ./qemu-mips64 ../lang +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Is this a known issue? + +Could you please provide backtrace and give more details to reproduce the issue? + +This is a error in user mode, I think it should be very easy to reproduce. + +On Thu, Sep 11, 2014 at 4:55 AM, Leon Alrae <email address hidden> wrote: + +> Could you please provide backtrace and give more details to reproduce +> the issue? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1361912 +> +> Title: +> qemu-mips64 Segmentation fault +> +> Status in QEMU: +> New +> +> Bug description: +> When I ran qemu-mips64 for any mips 64 executable , I got this error: +> +> $ ./qemu-mips64 ../lang +> qemu: uncaught target signal 11 (Segmentation fault) - core dumped +> Segmentation fault (core dumped) +> +> Is this a known issue? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1361912/+subscriptions +> + + +I forgot to add that qemu-mips64 works for me, that's why I asked for the details to reproduce the issue (i.e. what is "lang", what tools you used to build it, command line etc.) + +I can see the problem with any simple program: +1. cat t.c +#include <stdio.h> +int main() +{ + printf("Hello QEMU.\n"); +} + +2. mips64-gcc -static t.c -o t +3. qemu-mips64 t +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +I built QEMU on Ubuntu 12.04 with the system GCC compiler, and the commands are: +./configure --enable-linux-user +make + + +I've just checked with current head-of-git QEMU and we can execute the attached mips executable OK, so we've clearly fixed this bug at some point in the last three years. Closing as fix-committed, since the fix will definitely be in 2.11, though it's quite likely that 2.10 would also work. + + diff --git a/results/classifier/105/instruction/1376 b/results/classifier/105/instruction/1376 new file mode 100644 index 00000000..3f75ca7c --- /dev/null +++ b/results/classifier/105/instruction/1376 @@ -0,0 +1,28 @@ +instruction: 0.954 +assembly: 0.897 +device: 0.854 +graphic: 0.701 +vnc: 0.674 +socket: 0.609 +network: 0.505 +boot: 0.489 +semantic: 0.444 +KVM: 0.243 +other: 0.223 +mistranslation: 0.191 + +x86 LSL and LAR fault +Description of problem: +From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xa02e698e741f5a6a"); + asm("mov rbx, 0x20959ddd7a0aef"); + asm("lsl ax, bx"); +} +``` +2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/105/instruction/1377 b/results/classifier/105/instruction/1377 new file mode 100644 index 00000000..f3d87d4f --- /dev/null +++ b/results/classifier/105/instruction/1377 @@ -0,0 +1,27 @@ +instruction: 0.973 +assembly: 0.847 +device: 0.773 +vnc: 0.768 +graphic: 0.742 +boot: 0.462 +socket: 0.412 +KVM: 0.326 +semantic: 0.321 +network: 0.279 +other: 0.095 +mistranslation: 0.073 + +x86 CVT* series instructions fault +Description of problem: +For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + mmap(0x555555559000, 0x1000, flag, ~~, 0); + asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); +} +``` +2. Execute. QEMU crashes but CPU does not. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/105/instruction/1381642 b/results/classifier/105/instruction/1381642 new file mode 100644 index 00000000..f88c89f7 --- /dev/null +++ b/results/classifier/105/instruction/1381642 @@ -0,0 +1,46 @@ +instruction: 0.814 +boot: 0.756 +device: 0.723 +socket: 0.654 +graphic: 0.593 +vnc: 0.584 +network: 0.562 +semantic: 0.496 +mistranslation: 0.433 +other: 0.390 +KVM: 0.274 +assembly: 0.233 + +ecovec.c:66: buffer too small by one. + +[qemu-2.1.2/roms/u-boot/board/renesas/ecovec/ecovec.c:66]: (error) Buffer is accessed out of bounds. + + sprintf(env_mac, "%02X:%02X:%02X:%02X:%02X:%02X", + mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); + +but + + char env_mac[17]; + +and 18 into 17 won't go. Suggest increase size of env_mac. + +On 15 October 2014 19:00, dcb <email address hidden> wrote: +> Public bug reported: +> +> [qemu-2.1.2/roms/u-boot/board/renesas/ecovec/ecovec.c:66]: (error) +> Buffer is accessed out of bounds. + +This is in the u-boot code which we just carry a copy of +to produce certain boot ROMs. You should report these +issues directly to u-boot upstream. + +Thanks +-- PMM + + +FWIW, u-boot was apparently fixed here: +http://git.denx.de/?p=u-boot.git;a=commitdiff;h=44442c13ba2f63a67664ab5 + +...and we don't build u-boot for the renesas ecovec, so we don't need to worry about updating our copy of u-boot to something with the fix in it. + + diff --git a/results/classifier/105/instruction/1394 b/results/classifier/105/instruction/1394 new file mode 100644 index 00000000..e5f6aaf7 --- /dev/null +++ b/results/classifier/105/instruction/1394 @@ -0,0 +1,74 @@ +instruction: 0.822 +graphic: 0.782 +device: 0.776 +other: 0.755 +network: 0.632 +semantic: 0.631 +socket: 0.555 +mistranslation: 0.522 +vnc: 0.518 +boot: 0.465 +assembly: 0.452 +KVM: 0.118 + +Byte-swapping issue in getresuid on qemu-user-sparc64 +Description of problem: +When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed. + +For example, the UID 0x000003e8 (1000) becomes 0x03e80000. +Steps to reproduce: +A minimal test case looks like this: +```c +#define _GNU_SOURCE +#include <stdio.h> +#include <sys/types.h> +#include <pwd.h> +#include <unistd.h> + +int main(int argc, char **argv) { + struct passwd *pw = getpwuid(geteuid()); + if (pw == NULL) { + perror("getpwuid failure"); + return 1; + } + printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid); + + uid_t ruid = 0, euid = 0, suid = 0; + if (getresuid(&ruid, &euid, &suid) != 0) { + perror("getresuid failure"); + return 1; + } + printf("getresuid()->suid=0x%08x\n", suid); + + return 0; +} +``` + +Compile and run with: +``` +$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c +$ sudo chroot sid-sparc64 +[chroot] $ qemu-sparc64-static ./test +``` + +Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`): +``` +$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c +$ qemu-sparc64-static ./test +``` + +Expected output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x000003e8 +``` + +Actual output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x03e80000 +``` +Additional information: +I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu. diff --git a/results/classifier/105/instruction/1409 b/results/classifier/105/instruction/1409 new file mode 100644 index 00000000..328275dc --- /dev/null +++ b/results/classifier/105/instruction/1409 @@ -0,0 +1,14 @@ +instruction: 0.720 +device: 0.698 +mistranslation: 0.626 +graphic: 0.486 +assembly: 0.257 +semantic: 0.228 +network: 0.194 +vnc: 0.188 +boot: 0.076 +socket: 0.075 +other: 0.063 +KVM: 0.017 + +make check failed about qemu@7.2.0on suse15_aarch64 diff --git a/results/classifier/105/instruction/141 b/results/classifier/105/instruction/141 new file mode 100644 index 00000000..237ef464 --- /dev/null +++ b/results/classifier/105/instruction/141 @@ -0,0 +1,14 @@ +instruction: 0.886 +device: 0.688 +network: 0.535 +socket: 0.384 +mistranslation: 0.380 +semantic: 0.333 +graphic: 0.317 +boot: 0.260 +vnc: 0.161 +assembly: 0.083 +other: 0.040 +KVM: 0.005 + +qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options diff --git a/results/classifier/105/instruction/1412 b/results/classifier/105/instruction/1412 new file mode 100644 index 00000000..19cbb736 --- /dev/null +++ b/results/classifier/105/instruction/1412 @@ -0,0 +1,18 @@ +instruction: 0.943 +device: 0.794 +graphic: 0.745 +network: 0.666 +vnc: 0.606 +socket: 0.527 +semantic: 0.404 +assembly: 0.397 +other: 0.306 +boot: 0.260 +mistranslation: 0.190 +KVM: 0.057 + +QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364 + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given. diff --git a/results/classifier/105/instruction/1414 b/results/classifier/105/instruction/1414 new file mode 100644 index 00000000..9f0ea54f --- /dev/null +++ b/results/classifier/105/instruction/1414 @@ -0,0 +1,33 @@ +instruction: 0.800 +device: 0.716 +graphic: 0.703 +semantic: 0.637 +vnc: 0.575 +network: 0.562 +other: 0.555 +assembly: 0.517 +socket: 0.493 +boot: 0.429 +mistranslation: 0.346 +KVM: 0.327 + +Configure script fix for glib version +Description of problem: +Script "configure" uses "pkg-config" directly, at line 2420: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420 + +Because of it, GLIB_VERSION in "config-host.mak" can be taken from host system, under some circumstances (if PKG_CONFIG_PATH is not defined). + +In case of cross-compilation, "**$pkg_config**" should be used instead of "pkg-config", to use pkg-config from cross-compilation toolchain and to take GLIB_VERSION of cross-compiled glib (as it is **correctly used at line 1476**: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L1476 ). +Steps to reproduce: +1. Do not define PKG_CONFIG_PATH environment variable, use PKG_CONFIG variable instead. +2. Try to ./configure with cross-compiled glib. +3. GLIB_VERSION in config-host.mak will be from host glib. +Additional information: +Change lihe 2420:<br> +https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420 +<br> +echo "GLIB_VERSION=$(**pkg-config** --modversion glib-2.0)" >> $config_host_mak +<br>to:<br> +echo "GLIB_VERSION=$(**\$pkg_config** --modversion glib-2.0)" >> $config_host_mak + +P.s. Sorry for posting the patch here, GitLab requires signing with a key to push the commit, it's too complicated to post 2-bytes fix. diff --git a/results/classifier/105/instruction/1416 b/results/classifier/105/instruction/1416 new file mode 100644 index 00000000..4426c8f2 --- /dev/null +++ b/results/classifier/105/instruction/1416 @@ -0,0 +1,18 @@ +instruction: 0.926 +device: 0.851 +network: 0.824 +graphic: 0.801 +mistranslation: 0.735 +socket: 0.649 +other: 0.641 +vnc: 0.553 +semantic: 0.439 +boot: 0.362 +assembly: 0.233 +KVM: 0.049 + +MTE tags are applied at page granularity (4K) instead of tag granularity (16) +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing stg/ldg instructions on any address, QEMU behaves as if the instruction was executed on the page base of said address. + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `ptr_paddr` is changed to be calculated based on `CPUTLBEntryFull::phys_addr`, which contains the page base address, while beforehand it was calculated based on `host` which does have the page offset applied. diff --git a/results/classifier/105/instruction/1416246 b/results/classifier/105/instruction/1416246 new file mode 100644 index 00000000..37fe3a3c --- /dev/null +++ b/results/classifier/105/instruction/1416246 @@ -0,0 +1,68 @@ +instruction: 0.823 +graphic: 0.790 +device: 0.703 +semantic: 0.654 +assembly: 0.621 +mistranslation: 0.593 +network: 0.556 +KVM: 0.429 +socket: 0.377 +other: 0.350 +vnc: 0.306 +boot: 0.222 + +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/105/instruction/1423 b/results/classifier/105/instruction/1423 new file mode 100644 index 00000000..afaa933a --- /dev/null +++ b/results/classifier/105/instruction/1423 @@ -0,0 +1,26 @@ +instruction: 0.940 +graphic: 0.913 +device: 0.907 +semantic: 0.726 +boot: 0.621 +vnc: 0.549 +other: 0.522 +mistranslation: 0.509 +socket: 0.475 +assembly: 0.469 +network: 0.423 +KVM: 0.103 + +QEMU 6.2.0 fullscreen problem +Description of problem: +After running the command above, clicking on "Try Ubuntu" and adjusting the guest display resolution in GNOME to the native resolution, pressing ctrl+alt+f yields a "fullscreen" that only covers the QEMU window but not the entire host screen. This is not the case when switching to fullscreen while the boot screen is active or running `qemu-system-x86_64 -display gtk,full-screen=on`. + +The problem also occurs when replacing `-device qxl-vga` by `-device VGA,vgamem_mb=64`. The problem however does not occur when using `-device virtio-vga` instead of `-device qxl-vga` or `-display sdl` instead of `-display gtk`. +Steps to reproduce: +1. Run the command above +2. Click "Try Ubuntu" +3. Set guest resolution to native resolution (1920x1200 in my case) +4. Move the window a bit off the corners to observe the effect +5. Press ctrl+alt+f +Additional information: +The bug has also been [reported here](https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2000739). diff --git a/results/classifier/105/instruction/1426092 b/results/classifier/105/instruction/1426092 new file mode 100644 index 00000000..06d6f2a5 --- /dev/null +++ b/results/classifier/105/instruction/1426092 @@ -0,0 +1,53 @@ +instruction: 0.839 +device: 0.807 +boot: 0.780 +graphic: 0.750 +other: 0.645 +socket: 0.619 +vnc: 0.567 +network: 0.527 +semantic: 0.492 +mistranslation: 0.329 +assembly: 0.248 +KVM: 0.230 + +virtio-balloon-device locks up Guest + +Setting arbitrary balloon target values locks up the guest in some cases crashes it, if the target memory is < used +~5% free. +Found while testing aggressive memory over-commit, scenarios. +You get messages like: + +[ 155.827448] [<c002060c>] (show_stack) from [<c041c518>] (dump_stack+0x6c/0x88) +[ 155.837076] [<c041c518>] (dump_stack) from [<c0091994>] (warn_alloc_failed+0xe0/0x120) +[ 155.847075] [<c0091994>] (warn_alloc_failed) from [<c0094480>] (__alloc_pages_nodemask+0x600/0x91c) +[ 155.859039] [<c0094480>] (__alloc_pages_nodemask) from [<c00da414>] (balloon_page_enqueue+0x20/0xbc) +[ 155.870556] [<c00da414>] (balloon_page_enqueue) from [<c025d794>] (balloon+0x140/0x2cc) +[ 155.881377] [<c025d794>] (balloon) from [<c0043b38>] (kthread+0xd8/0xf4) + +page dumped bacause: nonzero _count +BUG: BAad page state in process Xorg pfn:396e5 + +Test Environment: +x86_64 +Ubuntu 13.10, Guest Linux Kernel 3.19, qemu 2.2.0 with following patches applied - balloon OOM enhancement +commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5 +Author: Raushaniya Maksudova <email address hidden> + +Boot guest with '-balloon virtio', -qmp .... -hmp access +1. sudo info balloon | socat - tcp4-connect:127.0.0.1:4444 + - or over qmp interface +{"execute":"qom-get", "arguments": { "path": "/machine/peripheral-anon/device[1]","property": "guest-stats" }} +{"return": {"stats": {"stat-swap-out": 0, "stat-free-memory": 513454080, "stat-minor-faults": 1261, "stat-major-faults": 0, "stat-total-memory": 526073856, "stat-swap-in": 0}, "last-update": 11109}} + +2. Take memory down check free memory using (1) +3. Issue "sudo echo balloon XXX | socat - tcp4-connect:127.0.0.1:4444" - XXX is value in threshold mentioned above + and you get Guest lockup + +ARM - samething except '-device virtio-balloon-device' used + +Libvirt - virsh setmem causes same issue. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? ... anyway, this rather sounds like a bug with the guest kernel to me, so in case this problem persists, you likely should report this in the kernel bug tracker instead. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1432 b/results/classifier/105/instruction/1432 new file mode 100644 index 00000000..31bc0271 --- /dev/null +++ b/results/classifier/105/instruction/1432 @@ -0,0 +1,37 @@ +instruction: 0.928 +device: 0.911 +graphic: 0.872 +semantic: 0.841 +vnc: 0.803 +network: 0.751 +socket: 0.728 +assembly: 0.686 +KVM: 0.602 +boot: 0.563 +mistranslation: 0.355 +other: 0.136 + +meson prints "Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12." for every test +Description of problem: +Run 'make check V=1' and observe that every test causes an warning message about an unknown TAP version + +``` +>>> G_TEST_SRCDIR=/home/berrange/src/virt/qemu/tests/unit MALLOC_PERTURB_=61 G_TEST_BUILDDIR=/home/berrange/src/virt/qemu/build/tests/unit /home/berrange/src/virt/qemu/build/tests/unit/test-shift128 --tap -k +▶ 22/44 /host-utils/test_lshift OK +▶ 22/44 /host-utils/test_rshift OK +22/44 qemu:unit / test-shift128 OK 0.01s 2 subtests passed + +Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12. + +``` + +This message comes from inside meson + +``` +$ rpm -ql meson | xargs grep 'Unknown TAP version' 2>/dev/null +/usr/lib/python3.11/site-packages/mesonbuild/mtest.py: self.warnings.append('Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12.') +``` + +This is with meson-1.0.0-1.fc38.noarch +Steps to reproduce: +1. make check V=1 diff --git a/results/classifier/105/instruction/1432103 b/results/classifier/105/instruction/1432103 new file mode 100644 index 00000000..aa6d78a4 --- /dev/null +++ b/results/classifier/105/instruction/1432103 @@ -0,0 +1,21 @@ +instruction: 0.713 +device: 0.653 +network: 0.468 +socket: 0.399 +graphic: 0.364 +vnc: 0.301 +other: 0.301 +boot: 0.272 +semantic: 0.211 +assembly: 0.152 +KVM: 0.143 +mistranslation: 0.143 + +error in x86 executable segment permission check + +When the code segment register (%cs) selects an executable segment with no read permission, mov instructions that read from the segment via %cs prefix can still succeed without causing a general protection error. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Can you provide a binary to reproduce this issue? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1437367 b/results/classifier/105/instruction/1437367 new file mode 100644 index 00000000..570a69f3 --- /dev/null +++ b/results/classifier/105/instruction/1437367 @@ -0,0 +1,50 @@ +instruction: 0.708 +device: 0.703 +other: 0.686 +semantic: 0.676 +graphic: 0.656 +mistranslation: 0.520 +vnc: 0.508 +assembly: 0.446 +socket: 0.405 +network: 0.399 +boot: 0.378 +KVM: 0.273 + +Qemu guest fails to write files with raw disk (like \\.\PhysicalDrive1) on Windows host. + +Qemu guest fails to write files with specifing raw disk like \\.\PhysicalDrive1 +full command line is below. +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi + +I found the reason is below aio_worker returns -EIO when flush operation. + +https://github.com/qemu/qemu/blob/master/block/raw-win32.c#L95 + +static int aio_worker(void *arg) +... + case QEMU_AIO_FLUSH: + if (!FlushFileBuffers(aiocb->hfile)) { + return -EIO; + } + +FlushFileBuffers always fails with GetLastError() == ERROR_INVALID_FUNCTION +I think this function doesn't support raw device. +For flushing, you might have to issue scsi/ata command or use another way. +Trying to just ignoring this error, writing function seems to be fine for me. + +Thanks +hiroaki + +The documentation of FlushFileBuffers() only mentions that consoles cannot be flushed. It doesn't specifically mention physical drives, but it does explicitly mention that whole volumes can be flushed this way: + +https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439%28v=vs.85%29.aspx + +Of course, I'm not really a Windows expert, so my reading of this may be wrong. If anyone knows how physical drives are supposed to be flushed other than with FlushFileBuffers(), we can certainly implement that in qemu. + +In any case, just disabling the flush is not advisable as it may harm data integrity in case of crashes/power failure. If you really want to disable it, the cache=unsafe option should avoid the calls. + +Is there still anything left to do here, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1438572 b/results/classifier/105/instruction/1438572 new file mode 100644 index 00000000..cbf0c4b5 --- /dev/null +++ b/results/classifier/105/instruction/1438572 @@ -0,0 +1,34 @@ +instruction: 0.616 +device: 0.511 +graphic: 0.445 +semantic: 0.431 +other: 0.354 +network: 0.306 +mistranslation: 0.256 +boot: 0.200 +socket: 0.181 +KVM: 0.165 +vnc: 0.147 +assembly: 0.074 + +kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm) + +We have a machine which is having QEMU+KVM on below configuration of linux +uname -a +Linux cairotrior 2.6.18-308.13.1.el5 #1 SMP Thu Jul 26 05:45:09 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux +cat /etc/issue +Red Hat Enterprise Linux Server release 5.8 (Tikanga) +Kernel \r on an \m + + +But in another setup, we are trying on a different machine having RHEL 5.9 having higher kernel version but it still gives below error +kvm does not support KVM_CAP_USER_MEMORY Please upgrade to at least kernel 2.6.29 or recent kvm-kmod (see http://sourceforge.net/projects/kvm). +failed to initialize KVM: Invalid argument No accelerator found! + + +I don’t know if the qemu version have compatibility issues with redhat 5.9 version – need someone to check if the qemu can run on redhat 5.9 64 bit or not ? + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +This error has never existed in QEMU, only in the old qemu-kvm fork which has been obsolete for about 5 years. I'm closing this ticket. + diff --git a/results/classifier/105/instruction/1441 b/results/classifier/105/instruction/1441 new file mode 100644 index 00000000..c4171377 --- /dev/null +++ b/results/classifier/105/instruction/1441 @@ -0,0 +1,47 @@ +instruction: 0.967 +vnc: 0.812 +graphic: 0.732 +device: 0.715 +network: 0.594 +socket: 0.471 +semantic: 0.412 +boot: 0.340 +assembly: 0.166 +mistranslation: 0.152 +other: 0.142 +KVM: 0.074 + +Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction +Description of problem: +When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.``` + +It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848 +Steps to reproduce: +The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6): +``` +/* test.c */ +#include <riscv_vector.h> + +#define LEN 4 + +int main(int argc, char *argv[]) { + double in[LEN]; + int out[LEN]; + + vfloat64m1_t vf = vle64_v_f64m1(in, LEN); + vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN); + vse32_v_i32mf2(out, vi, LEN); + + return 0; +} +``` + +The above `test.c` can be compiled and run as follows: +``` +clang -O3 -march=rv64gcv -static test.c +qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out +qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed. +Segmentation fault (core dumped) +``` +Additional information: + diff --git a/results/classifier/105/instruction/1442 b/results/classifier/105/instruction/1442 new file mode 100644 index 00000000..0a7d21e4 --- /dev/null +++ b/results/classifier/105/instruction/1442 @@ -0,0 +1,14 @@ +instruction: 0.934 +mistranslation: 0.879 +device: 0.848 +graphic: 0.470 +semantic: 0.365 +assembly: 0.161 +boot: 0.097 +vnc: 0.080 +other: 0.033 +socket: 0.025 +network: 0.025 +KVM: 0.018 + +RISC-V qemu, get cpu tick diff --git a/results/classifier/105/instruction/1452 b/results/classifier/105/instruction/1452 new file mode 100644 index 00000000..6abcb5dd --- /dev/null +++ b/results/classifier/105/instruction/1452 @@ -0,0 +1,14 @@ +instruction: 0.785 +device: 0.718 +mistranslation: 0.410 +graphic: 0.361 +network: 0.315 +boot: 0.279 +semantic: 0.260 +vnc: 0.220 +socket: 0.173 +assembly: 0.167 +other: 0.098 +KVM: 0.043 + +Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/105/instruction/1458 b/results/classifier/105/instruction/1458 new file mode 100644 index 00000000..6e4d1996 --- /dev/null +++ b/results/classifier/105/instruction/1458 @@ -0,0 +1,40 @@ +instruction: 0.780 +device: 0.779 +graphic: 0.761 +other: 0.731 +network: 0.487 +vnc: 0.469 +socket: 0.446 +semantic: 0.366 +boot: 0.318 +mistranslation: 0.304 +assembly: 0.210 +KVM: 0.187 + +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/105/instruction/1460 b/results/classifier/105/instruction/1460 new file mode 100644 index 00000000..938bbd65 --- /dev/null +++ b/results/classifier/105/instruction/1460 @@ -0,0 +1,18 @@ +instruction: 0.836 +graphic: 0.762 +device: 0.725 +network: 0.655 +other: 0.628 +semantic: 0.604 +socket: 0.524 +vnc: 0.462 +KVM: 0.398 +mistranslation: 0.333 +boot: 0.244 +assembly: 0.222 + +block_load fails if last block is included in snapshot and block device isn't multiple of BLK_MIG_BLOCK_SIZE +Description of problem: +The `block_load` function in `migration/block.c` has a bug where `blk_pwrite` or `blk_pwrite_zeroes` always write `cluster_size` bytes. If the underlying device is not a multiple of `BLK_MIG_BLOCK_SIZE`, the write will fail with -EIO when trying to write past the end of the device, as `blk_check_byte_request` checks the length of the device. + +This can be fixed by ensuring that `cur_addr` + write length passed to `blk_pwrite`/`blk_pwrite_zeroes` never exceeds the total length of the block device. diff --git a/results/classifier/105/instruction/1460523 b/results/classifier/105/instruction/1460523 new file mode 100644 index 00000000..7cae52a1 --- /dev/null +++ b/results/classifier/105/instruction/1460523 @@ -0,0 +1,26 @@ +instruction: 0.844 +device: 0.795 +mistranslation: 0.745 +vnc: 0.629 +graphic: 0.603 +socket: 0.602 +network: 0.589 +semantic: 0.555 +other: 0.403 +KVM: 0.318 +boot: 0.276 +assembly: 0.242 + +target-arm/op_helper.c:424: bad assert + +/home/dcb/qemu/trunk/qemu/target-arm/op_helper.c: In function ‘helper_access_check_cp_reg’: +/home/dcb/qemu/trunk/qemu/target-arm/op_helper.c:424:52: error: comparison of constant ‘3’ with boolean expression is always false [-Werror=bool-compare] + assert(!arm_is_secure(env) && !arm_current_el(env) == 3); + ^ + +Maybe + + assert(!arm_is_secure(env) && arm_current_el(env) != 3); + +Fixed by commit 3fc827d591679f3e262b9d1f8b34528eabfca8c0 + diff --git a/results/classifier/105/instruction/1463338 b/results/classifier/105/instruction/1463338 new file mode 100644 index 00000000..4a46291d --- /dev/null +++ b/results/classifier/105/instruction/1463338 @@ -0,0 +1,37 @@ +instruction: 0.726 +mistranslation: 0.709 +device: 0.586 +other: 0.564 +graphic: 0.534 +network: 0.454 +semantic: 0.432 +socket: 0.386 +assembly: 0.284 +vnc: 0.280 +boot: 0.258 +KVM: 0.153 + +qemu-system-arm injects #UND exception with wrong PC + +Usually all accesses to coprocessor registers are only possible in PL1 or higher. When accessing a coprocessor register in user mode, QEMU generates a trap and the PC of the trapping instruction is passed to the OS with an offset of+ 4. Some coprocessor registers can be configured to allow access to them in usermode (PL0). The latest qemu-git (ee09f84e6bf5383a23c9624115c26b72aa1e076c) seems to add an offest of 8 instead of four if such a register is accessed from user mode. This happens only if the coprocessors register that is accessed might also be accessed from PL0. In case all accesses to the coprocessor register from PL0 cause a trap, qemu injects the #UND trap with the correct PC value. + +Attached is a small test program that installs a signal handler for "SIGILL". On a pandaboard the progam prints "Val=0x2 Val2=0x2" whereas on the latest "qemu-system-arm" the output is : "Val=0x1 Val2=0x2" + +Qemu was configured with: "./configure --python=`which python2.7` --target-list=arm-softmmu" +The test can be compiled with: "gcc -g -static test2.c -o test2" + +If further information is needed, feel free to ask. + +Regards, + +Robert + + + +Thanks for the clear bug report and the test case. I've submitted a patch which fixes this: +http://patchwork.ozlabs.org/patch/482273/ + + +Should be in 2.6. + + diff --git a/results/classifier/105/instruction/1469342 b/results/classifier/105/instruction/1469342 new file mode 100644 index 00000000..2bcdaf98 --- /dev/null +++ b/results/classifier/105/instruction/1469342 @@ -0,0 +1,49 @@ +instruction: 0.738 +semantic: 0.665 +other: 0.660 +mistranslation: 0.647 +graphic: 0.553 +device: 0.484 +vnc: 0.273 +network: 0.233 +boot: 0.226 +socket: 0.202 +assembly: 0.141 +KVM: 0.130 + +qemu-i386 pentium3/athlon incorrect instruction set + +Running a binary containing a movsd instruction (SSE2) in 32-bit qemu-i386 -cpu pentium3 from 20150609 results in flawless execution whereas it should crash with SIGILL as P3 only had SSE. + +Still there in the latest master. + +To clarify, running the binary with the -cpu athlon switch (same instruction set as P3) also exhibits the problem whereas a real athlon SIGILL's correctly. + +QEMU doesn't try to mimic the exact set of instructions for a processor, unfortunately. Virtualization solutions like KVM also do not allow you to do that, so the case for this feature is relatively minor. + +However, patches are welcome. + +I'm pretty sure you're right regarding entire instruction sets - but surely simply disabling SSE2 is possible even now? (after all pentium2 and below doesn't have it) + +That could solve this problem with a simple hack like, eg. : + +pentium3 = $pentium3 - SSE2 + + + +In the case it's really unfixable and both pentium3 and athlon are nothing more than aliases for 'QEMU Virtual CPU version 2.4.50' they should be removed from the list the user gets after: + +qemu-i386 -cpu help + +so as not to mislead. Thanks! + +After looking at target-i386/cpu.c, it's clear to me CPUID_SSE and CPUID_SSE2 are defined seperately and neither pentium3 nor athlon have those defines set. + +This could mean it's a bug not in the instruction set but possibly in the build process somewhere. + +This option is useful for testing, nothing more. + +I think I may have found the culprit - athlon is defined as 'PPRO_FEATURES + some additional features'. + +If PPRO_FEATURES is what I think it is (pentium pro) why does it have SSE and SSE2 defined? It should end with MMX. + diff --git a/results/classifier/105/instruction/1470 b/results/classifier/105/instruction/1470 new file mode 100644 index 00000000..6cdccee0 --- /dev/null +++ b/results/classifier/105/instruction/1470 @@ -0,0 +1,22 @@ +instruction: 0.847 +graphic: 0.826 +boot: 0.802 +device: 0.688 +semantic: 0.564 +vnc: 0.393 +socket: 0.247 +network: 0.193 +mistranslation: 0.112 +other: 0.090 +assembly: 0.031 +KVM: 0.016 + +Mouse cursor disappeared for WfW 3.11 +Description of problem: +I've been using the "GD5434 v1.25f, 1280x1024x64K Smlfnt" driver (from sp2904.exe, https://archive.org/download/Windows-3.1-WING-doom inside cirrus.zip) with Fedora's qemu build for years, which is the best version of that driver that I could find, and which works quite nicely apart from a font problem right after startup, and is a lot faster than the standard (patched) SVGA driver. Opening and closing File Manager will get rid of the font corruption. After an upgrade to Fedora 37, I noticed that the mouse cursor was not displayed anymore, which I bisected to this git commit: cb8962c146 +Steps to reproduce: +1. Run the image (boots right into Windows) +2. Note the missing cursor +3. +Additional information: +Image for easy testing (IBM DOS 5, 1024x768) is here: https://drive.google.com/file/d/1_5-gGXEahPOPvgG436WbKM9dnOr7Z8zo/view?usp=sharing (4.4 MB) diff --git a/results/classifier/105/instruction/1473 b/results/classifier/105/instruction/1473 new file mode 100644 index 00000000..117d4706 --- /dev/null +++ b/results/classifier/105/instruction/1473 @@ -0,0 +1,14 @@ +instruction: 0.796 +device: 0.789 +graphic: 0.303 +semantic: 0.299 +network: 0.195 +mistranslation: 0.106 +boot: 0.080 +socket: 0.034 +assembly: 0.015 +other: 0.015 +vnc: 0.006 +KVM: 0.001 + +how to run qemu with sgx feature enabled diff --git a/results/classifier/105/instruction/1479717 b/results/classifier/105/instruction/1479717 new file mode 100644 index 00000000..e533ac0b --- /dev/null +++ b/results/classifier/105/instruction/1479717 @@ -0,0 +1,56 @@ +instruction: 0.904 +graphic: 0.866 +other: 0.849 +mistranslation: 0.847 +device: 0.832 +semantic: 0.812 +KVM: 0.797 +network: 0.793 +assembly: 0.786 +socket: 0.767 +boot: 0.698 +vnc: 0.619 + +Auto resize VM doesn't work with windows 10 guest + +I,m using a Ubuntu 15.04 host and a windows 10 guest (both 64 bit) on a intel i7 proc. My ubuntu system is up-to-date and I'm using QEMU emulator version 2.2.0. I use virt-manager 1.0.1 and SPICE guest tools 0.100 are installed on the guest. + +With the exactly same setup and a windows 7 guest I can set "Auto resize VM with window" and it perfectly works. After installing SPICE in windows 10 I can still select this box, but it doesn't work any longer. + +I've observed the same issue (in Ubuntu Gnome 15.04). In addition, when I select '' from the Virtual Machine Manager, View, Scale Display, Auto Resize VM with Window, the guest's screen starts flickering. + +On Windows 10 64bit, virtio drivers and QXL installed from ISO extracted out the RPM here: https://fedorapeople.org/groups/virt/virtio-win/repo/latest/virtio-win-0.1.110-2.noarch.rpm. In all cases, I installed the Windows 8.1 x64 option, given w10 drivers are not yet included in the ISO. The windows QXL drivers haven't been updated since July 28th (v22.33.46.473) . + +There is a commit on github about windows 10 signatures here which suggests more formal support for Windows 10 is getting closer for some of the virtio driver set: https://github.com/crobinso/virtio-win-pkg-scripts/commit/342a5aaf632fa11cfd2e69acf589dd00c15f72ca + +Note, qxl-dod comes from http://cgit.freedesktop.org/spice/win32/qxl. I don't see any recent commits related to Windows 10 support. + +Red Hat bugzilla doesn't seem to have the auto resize VM bug noted anywhere? Perhaps this should be propagated upstream? + +Should someone else stumble upon this, the way to resolve issues for now is to not use gnome boxes, but rather remote-viewer and perhaps there's an issue with BIOS/EFI graphics setup with Windows 10 guests? + +After a lucky coincidence, flickering seems to have be resolved for me while tweaking something else (OVMF NVRAM for EFI). It might have simply been manually updating OVMF or adding the NVRAM / VARS piece to my VM Win 10 guest config. I'm not sure. + +What I can report: +* virt-viewer / remote-viewer, virt-manager and gnome boxes have have stopped flickering +* virt-viewer / remote-viewer are now auto-adjusting windows 10 properly to the windows size +* gnome boxes is scaling (zooming in and out) the Windows 10 display instead of auto-adjusting the guest resolution +** Unlike the Windows 10 guest, When I test a Linux VM with the spice agent installed, it auto-adjusts the guest resolution +* virt-manager is not, it's simply cropping the output + +So I think something about how Gnome Boxes handles the Windows 10 guest is inferior to the way in which remote viewer does (when EFI is used, which does affect graphics setup). But perhaps wait till spice-agent officially supports Windows 10 with proper drivers, given you may not care for people like me who try their luck with the Windows 8.1 drivers in Windows 10. + +More detail on the EFI NVRAM issue? + +See: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071 + +Hacking around a debian/ubuntu distro specific libvirt apparmor bug allowed me to use a proper OVMF nvram template to the virtual machine config, and after reconfiguring the VM to use this, the display flickering stopped, so this may be something to do with UEFI simulation and windows 10 on KVM (but given my day job as just a virtualisation user, debugging that or understanding that low level interaction is beyond me). + +I shared similar info on a related bug where gnome boxes removed the ability to control scale and auto-adjust options for the spice display behaviour +https://bugzilla.gnome.org/show_bug.cgi?id=729700 + +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/105/instruction/1481272 b/results/classifier/105/instruction/1481272 new file mode 100644 index 00000000..7cab15c9 --- /dev/null +++ b/results/classifier/105/instruction/1481272 @@ -0,0 +1,257 @@ +instruction: 0.817 +other: 0.751 +KVM: 0.750 +vnc: 0.735 +graphic: 0.719 +semantic: 0.718 +device: 0.692 +mistranslation: 0.692 +network: 0.691 +boot: 0.648 +socket: 0.640 +assembly: 0.631 + +main-loop: WARNING: I/O thread spun for 1000 iterations + +I compile the latest qemu to launch a VM but the monitor output the "main-loop: WARNING: I/O thread spun for 1000 iterations". + +# /usr/local/bin/qemu-system-x86_64 -name rhel6 -S -no-kvm -m 1024M -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid c9dd2a5c-40f2-fd3d-3c54-9cd84f8b9174 -rtc base=utc -drive file=/home/samba-share/ubuntu.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=disk,serial=425618d4-871f-4021-bc5d-bcd7f1b5ca9c,bootindex=0 -vnc :1 -boot menu=on -monitor stdio +QEMU 2.3.93 monitor - type 'help' for more information +(qemu) c +(qemu) main-loop: WARNING: I/O thread spun for 1000 iterations <----------------------- + +qemu]# git branch -v +* master e95edef Merge remote-tracking branch 'remotes/sstabellini/tags/xen-migration-2.4-tag' into staging + +host kernel version: 2.6.32-504.23.4.el6.x86_64 + + +(qemu) info version +2.3.93 + + +On Tue, Aug 4, 2015 at 10:56 AM, Sibiao Luo <email address hidden> wrote: +> I compile the latest qemu to launch a VM but the monitor output the +> "main-loop: WARNING: I/O thread spun for 1000 iterations". + +This this warning message is new, please use git-bisect(1) to +determine which commit caused it to appear: + +https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search +https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html + +Once you've found the commit that caused the warning to appear, please +post the details. + +Stefan + + +Good catch, thanks stefanha for your kindly reminds with such good tools (git-bisect) to determine which commit caused this problem. I'm very sorry that i did not try it as your instruction timely, mainly that i focus on the openstack(nova&cinder) currently in the new company and have to adapt to the new work flow & role as quickly as possible. According to me trying that 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3 is the first bad commit pushed by pbonzini. + +My trying results as following: +master 074a992 Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into staging <---> latest version fail +qemu-2.3-stable dfa83a6 Update version for 2.3.1 release <---> qemu-2.3-stable good + +[root@PEK1000012301 qemu]# git bisect start +[root@PEK1000012301 qemu]# git bisect bad 074a992 +[root@PEK1000012301 qemu]# git bisect good dfa83a6 +Bisecting: a merge base must be tested +[e5b3a24181ea0cebf1c5b20f44d016311b7048f0] Update version for v2.3.0 release +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 1105 revisions left to test after this (roughly 10 steps) +[afa25c4bb5bd0732dca4aa0691fd4682d242925f] Merge remote-tracking branch 'remotes/kraxel/tags/pull-sdl-20150611-1' into staging +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 552 revisions left to test after this (roughly 9 steps) +[922f893e57da24bc80db3e79bea56485d1c111fa] ahci: assert is_ncq for process_ncq +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 274 revisions left to test after this (roughly 8 steps) +[711dc6f36b74fe65a6e5a1847f1152717d887f8a] Merge remote-tracking branch 'remotes/cody/tags/jtc-for-upstream-pull-request' into staging +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 138 revisions left to test after this (roughly 7 steps) +[226d007dbd75ec8d0f12d0f9e1ce66caf55d49e4] gdbstub: Set current CPU on interruptions +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect bad +Bisecting: 67 revisions left to test after this (roughly 6 steps) +[b9c46307996856d03ddc1527468ff5401ac03a79] Merge remote-tracking branch 'remotes/mdroth/tags/qga-pull-2015-07-21-tag' into staging +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 32 revisions left to test after this (roughly 5 steps) +[f793d97e454a56d17e404004867985622ca1a63b] Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect bad +Bisecting: 17 revisions left to test after this (roughly 4 steps) +[80adb8fcad4778376a11d394a9e01516819e2327] tcg/aarch64: use 32-bit offset for 32-bit softmmu emulation +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect bad +Bisecting: 8 revisions left to test after this (roughly 3 steps) +[dc94bd9166af5236a56bd5bb06845911915a925c] Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect bad +Bisecting: 3 revisions left to test after this (roughly 2 steps) +[6493c975af75be5b8d9ade954239bdf5492b7911] aio-win32: reorganize polling loop +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 1 revision left to test after this (roughly 1 step) +[21a03d17f2edb1e63f7137d97ba355cc6f19d79f] AioContext: fix broken placement of event_notifier_test_and_clear +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect good +Bisecting: 0 revisions left to test after this (roughly 0 steps) +[05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3] AioContext: optimize clearing the EventNotifier +<<<compile QEMU with this branch and try to launch VM to test as comment#0>>> + +[root@PEK1000012301 qemu]# git bisect bad +05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3 is the first bad commit +commit 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3 +Author: Paolo Bonzini <email address hidden> +Date: Tue Jul 21 16:07:53 2015 +0200 + + AioContext: optimize clearing the EventNotifier + + It is pretty rare for aio_notify to actually set the EventNotifier. It + can happen with worker threads such as thread-pool.c's, but otherwise it + should never be set thanks to the ctx->notify_me optimization. The + previous patch, unfortunately, added an unconditional call to + event_notifier_test_and_clear; now add a userspace fast path that + avoids the call. + + Note that it is not possible to do the same with event_notifier_set; + it would break, as proved (again) by the included formal model. + + This patch survived over 3000 reboots on aarch64 KVM. + + Signed-off-by: Paolo Bonzini <email address hidden> + Reviewed-by: Fam Zheng <email address hidden> + Tested-by: Richard W.M. Jones <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Stefan Hajnoczi <email address hidden> + +:100644 100644 5c8b266c72b79e07f881a563da189e0267937766 d4770336c5d5355758c3da207b8be5160f66fc5f M aio-posix.c +:100644 100644 7afc9992d682d335b4fce58182b580f7f678f503 50a68674589aa3c6418604bfb9320e915f624796 M aio-win32.c +:100644 100644 d625e8a8035656711f156078bbc7784b4f4754b0 9a98a74acb99bbf74c004ab2de0d09ca78eac84c M async.c +:040000 040000 6f98147da6fdc258f6b7b967ee90d02686311951 11705f58169772ff280c44f4f7d7e7c367600f1a M docs +:040000 040000 97f8f766a2ad81d2a262f0379643c3ebaa9d32bc 49b13585c2fad748b6f7c7cb49944dc6c2a149f8 M include + +Best Regards & Thx, +Sibiao Luo + +[root@PEK1000012301 qemu]# git bisect log +git bisect start +# bad: [074a9925e1cfd659d5376dcaccd1436d3840e611] Merge remote-tracking branch 'remotes/cody/tags/block-pull-request' into staging +git bisect bad 074a9925e1cfd659d5376dcaccd1436d3840e611 +# good: [dfa83a6bae960e3e3a3186264d75790cfd727bce] Update version for 2.3.1 release +git bisect good dfa83a6bae960e3e3a3186264d75790cfd727bce +# good: [e5b3a24181ea0cebf1c5b20f44d016311b7048f0] Update version for v2.3.0 release +git bisect good e5b3a24181ea0cebf1c5b20f44d016311b7048f0 +# good: [afa25c4bb5bd0732dca4aa0691fd4682d242925f] Merge remote-tracking branch 'remotes/kraxel/tags/pull-sdl-20150611-1' into staging +git bisect good afa25c4bb5bd0732dca4aa0691fd4682d242925f +# good: [922f893e57da24bc80db3e79bea56485d1c111fa] ahci: assert is_ncq for process_ncq +git bisect good 922f893e57da24bc80db3e79bea56485d1c111fa +# good: [711dc6f36b74fe65a6e5a1847f1152717d887f8a] Merge remote-tracking branch 'remotes/cody/tags/jtc-for-upstream-pull-request' into staging +git bisect good 711dc6f36b74fe65a6e5a1847f1152717d887f8a +# bad: [226d007dbd75ec8d0f12d0f9e1ce66caf55d49e4] gdbstub: Set current CPU on interruptions +git bisect bad 226d007dbd75ec8d0f12d0f9e1ce66caf55d49e4 +# good: [b9c46307996856d03ddc1527468ff5401ac03a79] Merge remote-tracking branch 'remotes/mdroth/tags/qga-pull-2015-07-21-tag' into staging +git bisect good b9c46307996856d03ddc1527468ff5401ac03a79 +# bad: [f793d97e454a56d17e404004867985622ca1a63b] Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging +git bisect bad f793d97e454a56d17e404004867985622ca1a63b +# bad: [80adb8fcad4778376a11d394a9e01516819e2327] tcg/aarch64: use 32-bit offset for 32-bit softmmu emulation +git bisect bad 80adb8fcad4778376a11d394a9e01516819e2327 +# bad: [dc94bd9166af5236a56bd5bb06845911915a925c] Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging +git bisect bad dc94bd9166af5236a56bd5bb06845911915a925c +# good: [6493c975af75be5b8d9ade954239bdf5492b7911] aio-win32: reorganize polling loop +git bisect good 6493c975af75be5b8d9ade954239bdf5492b7911 +# good: [21a03d17f2edb1e63f7137d97ba355cc6f19d79f] AioContext: fix broken placement of event_notifier_test_and_clear +git bisect good 21a03d17f2edb1e63f7137d97ba355cc6f19d79f +# bad: [05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3] AioContext: optimize clearing the EventNotifier +git bisect bad 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3 + +We are hitting this bug as well. With Ceph storage back end running in OpenStack environment. + +Ubuntu 14.04 +Kernel - 3.13.0-52-generic +Qemu: QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.11) + +Please provide a workaround or solution or if a patch is being worked on. + +Thank you, + +Arghya + +Please try removing the "notified = true;" line from main-loop.c's os_host_main_loop_wait, and see if the warning comes out forever or just a few times. + +I have experienced this behavior (main-loop: WARNING: I/O thread spun for 1000 iterations) and the resulting degraded performance. The VM becomes very unresponsive but eventually recovers. My setup: + +Ubuntu 15.10 | qemu-system-x86_64 --version QEMU emulator version 2.3.0 (Debian 1:2.3+dfsg-5ubuntu9) +HW = Dell Precision M6600 with Intel(R) Core(TM) i7-2760QM CPU + +I agree with other comments that it seems related to high disk I/O as the problem seems to occur during VM install or other VM operations which read/write large amounts of data. + +Count me in: Windows 10 Pro 64 November 2015 update is totally unusable because of this bug. + +Some people say their VM recovers over time but mine doesn't apparently - I've been waiting for 15 minutes and the QEmu window is just dead. + +I see the same with a Windows 10 guest on a Gentoo host. I tried setting nonblocking = 0; in vl.c as https://rafalcieslak.wordpress.com/2015/11/20/qemu-main-loop-warning-io-thread-spun-for-1000-iterations/ suggests, but that didn't solve the problem for me: the message is still there. + +I experience the same while running Minix guest under an Arch Linux host. Sometimes during heavy I/O the whole machine freezes with this error message. + +The command used is: qemu-system-x86_64 -drive file=../minix-img/minix_work.img -net user,hostfwd=tcp::22222-:22 -net nic,model=virtio -m 1024M +qemu 1.8.0 in this case, I'll test against 1.8.1 when it gets into the repos. + +Apparently, the solution is: https://rafalcieslak.wordpress.com/2015/11/20/qemu-main-loop-warning-io-thread-spun-for-1000-iterations/ + +I haven't experienced the hang within a couple of days, it's fairly irregular for me to reproduce it. + +I think that's a workaround, not a fix for whatever the underlying bug is. + + +http://gnats.netbsd.org/52184 looks like it may be related. + + +I no longer see the "WARNING: I/O thread spun for 1000 iterations" message. A bisection showed that it disappeared with the following commit: + +commit e330c118f2a5a5365409b123cd0dd2c7d575bf05 +Author: Paolo Bonzini <email address hidden> +Date: Fri Mar 3 11:51:07 2017 +0100 + + main-loop: remove now unnecessary optimization + + This optimization is not necessary anymore, because the vCPU now drops + the I/O thread lock even with TCG. Drop it to simplify the code and + avoid the "I/O thread spun for 1000 iterations" warning. + + Reviewed-by: Alex Bennée <email address hidden> + Reviewed-by: Edgar E. Iglesias <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +The amount of system time consumed by the qemu process, which had incrased 300-fold with commit 05e514b1d4d5bd4209e2c8bbc76ff05c85a235f3, is also back to normal. + + + +Nice, thanks for the update. +I checked a few recent logs and agree that the message is gone since 2.9 + +Some might still encounter slow guests (for other reasons) and trigger the message, but the most common TCG emulation case is solved by this since Artful and later. + +I think we don't want to backport all the prereqs (I/O thread locking changes) to Xenial that allow to add this change here. + +Updated the Ubuntu tasks on this bug, leaving the qemu state to a triager of the project. + +Ok, closing this for upstream, too, according to the previous comments. + +I see the same issue with qemu version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31). + diff --git a/results/classifier/105/instruction/1490886 b/results/classifier/105/instruction/1490886 new file mode 100644 index 00000000..dd5e8561 --- /dev/null +++ b/results/classifier/105/instruction/1490886 @@ -0,0 +1,64 @@ +instruction: 0.871 +network: 0.772 +device: 0.688 +graphic: 0.682 +socket: 0.679 +boot: 0.568 +vnc: 0.548 +KVM: 0.539 +semantic: 0.435 +other: 0.423 +mistranslation: 0.340 +assembly: 0.247 + +spice-qemu-char.c Assert + +spice-qemu-char.c:173: spice_chr_add_watch: Assertion `cond == G_IO_OUT' failed. +I trace the code virtio-console.c: +ret = qemu_chr_fe_write(vcon->chr, buf, len); + trace_virtio_console_flush_buf(port->id, len, ret); + + if (ret < len) { + VirtIOSerialPortClass *k = VIRTIO_SERIAL_PORT_GET_CLASS(port); + + /* + * Ideally we'd get a better error code than just -1, but + * that's what the chardev interface gives us right now. If + * we had a finer-grained message, like -EPIPE, we could close + * this connection. + */ + if (ret < 0) + ret = 0; + if (!k->is_console) { + virtio_serial_throttle_port(port, true); + if (!vcon->watch) { + vcon->watch = qemu_chr_fe_add_watch(vcon->chr, + G_IO_OUT|G_IO_HUP, + chr_write_unblocked, vcon); + } + } + } +and spice-qemu-char.c in function:spice_chr_add_watch +assert(cond == G_IO_OUT); +so run in this code,will trigger this assert. + +My qemu version is 2.3.0 and spice-server version is 0.12.5 + +called param is G_IO_OUT|G_IO_HUP,but assert (cond == G_IO_OUT) + +I think this is fixed by: + +commit f7a8beb5e6a13dc924895244777d9ef08b23b367 +Author: Marc-André Lureau <email address hidden> +Date: Thu May 28 15:04:58 2015 +0200 + + spice: fix spice_chr_add_watch() pre-condition + + Since e02bc6de30c44fd668dc0d6e1cd1804f2eed3ed3, add_watch() is called + with G_IO_HUP. Even if spice-qemu-char ignores this flag, the + precondition must be changed. + + https://bugzilla.redhat.com/show_bug.cgi?id=1128992 + +Which is in 2.4.0 + diff --git a/results/classifier/105/instruction/1498 b/results/classifier/105/instruction/1498 new file mode 100644 index 00000000..2ac4b50f --- /dev/null +++ b/results/classifier/105/instruction/1498 @@ -0,0 +1,18 @@ +instruction: 0.978 +graphic: 0.914 +other: 0.851 +device: 0.849 +semantic: 0.841 +mistranslation: 0.800 +network: 0.564 +boot: 0.371 +vnc: 0.362 +socket: 0.166 +assembly: 0.098 +KVM: 0.027 + +LDC, STC unimplemented in qemu-system-arm +Description of problem: +I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected. + +The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU. diff --git a/results/classifier/105/instruction/1500 b/results/classifier/105/instruction/1500 new file mode 100644 index 00000000..149feba1 --- /dev/null +++ b/results/classifier/105/instruction/1500 @@ -0,0 +1,51 @@ +instruction: 0.866 +graphic: 0.789 +device: 0.769 +assembly: 0.664 +socket: 0.597 +vnc: 0.589 +semantic: 0.515 +network: 0.514 +boot: 0.441 +KVM: 0.414 +mistranslation: 0.257 +other: 0.241 + +Some system/debug regisiters are inconsistent with real device in qemu-system-arm +Description of problem: +We used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in system regisiter was detected. + +1. CCSIDR--Cache Size ID Registers + + **Inconsistency** + + - CCSIDR in QEMU: 0x701fe00a--Associativity: 2, Number of sets:256 + + - CCSIDR in Raspi2B: 0x700fe01a--Associativity: 4, Number of sets:128 + + **Tested Instruction sample** + + - MRC_T1A1_A 11101110001100000000111100010000 0xee300f10 + + According to ARMv7 Manual B4.1.19 encoding, the NumSets and Associativity are set different bewteen QEMU when emulating raspi2b and raspi2b. + + The CCSIDR is set in the function`cortex_a7_initfn(Object *obj)` in target/arm/cpu_tcg.c for cortex_a7. + +2. DBGDRAR--Debug ROM Address Register + + **Inconsistency** + + - DBGDRAR in QEMU: 0x0 --Invalid + + - DBGDRAR in Raspi2B: 0x40020003--Valid + + According to ARMv7 Manual C11.11.16 encoding, the DBGDRAR in qemu is invalid. + + **Tested Instruction sample** + + - MRC_T1A1_A 11101110000100010001111000010000 0xee111e10 +Steps to reproduce: +1. Compile a kernel module to run the test instruction in PL1. +2. Use kgdb to get the register info +Additional information: + diff --git a/results/classifier/105/instruction/1503031 b/results/classifier/105/instruction/1503031 new file mode 100644 index 00000000..e690190c --- /dev/null +++ b/results/classifier/105/instruction/1503031 @@ -0,0 +1,34 @@ +instruction: 0.750 +semantic: 0.698 +device: 0.682 +socket: 0.665 +graphic: 0.655 +other: 0.651 +network: 0.599 +assembly: 0.551 +vnc: 0.525 +mistranslation: 0.512 +boot: 0.431 +KVM: 0.303 + +32-to-64-bit call gate unsupported in IA32e mode + +In particular, the lcall implementation doesn't support the 64-bit TSS. + +helper_lcall_protected (target-i386/seg_helper.c:1884) calls get_ss_esp_from_tss() on a call gate to a lower privilege level, which tries to extract a 32-bit ESP and 16-bit SS from the TSS. In IA32e mode (64-bit or compatibility mode), this instead grabs the lower 32-bits of the target RSP, and 16 of the upper bits as the SS. Additionally, several of the subsequent checks are incorrect (even if the correct stack pointer were extracted). + +This isn't a problem for interrupts since the interrupts are given their own implementation entirely, that uses get_rsp_from_tss() rather than get_ss_esp_from_tss(). + +I believe the missing logic is from the branch starting "ELSE (* current TSS is 64-bit *)" in the CALL pseudocode in the Intel manual (page 3-124 of the PDF I have). + +Reproduced at master (c0b520dfb8890294a9f8879f4759172900585995), and also as of a qemu built a year ago. + +I also suspect that qemu will incorrectly allow calls through 32-bit call gates in compatibility mode (rather than raising a GP fault --- see Intel manuals volume 3A 5-21). And I doubt 64-to-64-bit call gates work either. I haven't actually tested either of those scenarios, though, this is just from reading the code. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Looking at the commit log it looks like Andrew fixed this in commit 0aca060526d3ff9632aaed in 2018 ? + + +That looks like the corresponding fix, indeed. Let's close this ticket. + diff --git a/results/classifier/105/instruction/1504 b/results/classifier/105/instruction/1504 new file mode 100644 index 00000000..f01484a0 --- /dev/null +++ b/results/classifier/105/instruction/1504 @@ -0,0 +1,14 @@ +instruction: 0.962 +device: 0.892 +network: 0.865 +boot: 0.536 +assembly: 0.518 +graphic: 0.412 +vnc: 0.339 +semantic: 0.257 +socket: 0.173 +mistranslation: 0.165 +other: 0.055 +KVM: 0.012 + +Implement Synopsys DesignWare PCI-I2C adapter model diff --git a/results/classifier/105/instruction/1511 b/results/classifier/105/instruction/1511 new file mode 100644 index 00000000..6cf5ab2a --- /dev/null +++ b/results/classifier/105/instruction/1511 @@ -0,0 +1,14 @@ +instruction: 0.437 +boot: 0.278 +graphic: 0.241 +semantic: 0.167 +mistranslation: 0.085 +vnc: 0.056 +other: 0.051 +device: 0.049 +KVM: 0.042 +socket: 0.031 +assembly: 0.008 +network: 0.003 + +Please a CPU model for ABI version for x86_64 i386 according to x86-64 psABI diff --git a/results/classifier/105/instruction/1511710 b/results/classifier/105/instruction/1511710 new file mode 100644 index 00000000..50ef87b6 --- /dev/null +++ b/results/classifier/105/instruction/1511710 @@ -0,0 +1,38 @@ +instruction: 0.734 +KVM: 0.720 +graphic: 0.703 +device: 0.688 +vnc: 0.679 +semantic: 0.672 +other: 0.627 +network: 0.624 +boot: 0.611 +socket: 0.607 +assembly: 0.582 +mistranslation: 0.426 + +unknown option --disable-modules + +MSYS64, Windows 7 x64 + +$ ./configure --target-list=i386-softmmu --static --prefix=/d/qemu/ --disable-system --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-docs --disable-guest-agent --disable-guest-agent-msi --disable-pie --disable-modules --disable-debug-tcg --disable-debug-info --disable-sparse --disable-seccomp --disable-gnutls --disable-sdl--disable-gtk --disable-vte --disable-curses --disable-vnc --disable-vnc-tls --disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa --disable-virtfs --disable-xen --disable-xen-pci-passthro --disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm --disable-rdma --disable-uuid --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard-nss --disable-libusb --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-coroutine-pool --disable-glusterfs --disable-archipelago --disable-tpm --disable-libssh2 --disable-vhdx --disable-numa --disable-tcmalloc +ERROR: unknown option --disable-modules +Try './configure --help' for more information + +On Fri, Oct 30, 2015 at 12:03:44PM -0000, Guy wrote: +> MSYS64, Windows 7 x64 +> +> $ ./configure --target-list=i386-softmmu --static --prefix=/d/qemu/ --disable-system --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-docs --disable-guest-agent --disable-guest-agent-msi --disable-pie --disable-modules --disable-debug-tcg --disable-debug-info --disable-sparse --disable-seccomp --disable-gnutls --disable-sdl--disable-gtk --disable-vte --disable-curses --disable-vnc --disable-vnc-tls --disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa --disable-virtfs --disable-xen --disable-xen-pci-passthro --disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm --disable-rdma --disable-uuid --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard-nss --disable-libusb --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-coroutine-pool --disable-glusterfs --disable-archipelago --disable-tpm --disable-libssh2 --disable-vhdx --disable-numa --disable-tcmalloc +> ERROR: unknown option --disable-modules +> Try './configure --help' for more information + +Modules are disabled by default. You can omit --disable-modules for +now. + +I will send a patch to add the explicit option in the next QEMU release. + + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3aa88b31290c7cbbbae34 +... so closing this ticket now. + diff --git a/results/classifier/105/instruction/1524637 b/results/classifier/105/instruction/1524637 new file mode 100644 index 00000000..f2e861f6 --- /dev/null +++ b/results/classifier/105/instruction/1524637 @@ -0,0 +1,31 @@ +instruction: 0.826 +device: 0.805 +graphic: 0.727 +semantic: 0.679 +mistranslation: 0.648 +socket: 0.449 +other: 0.411 +network: 0.411 +vnc: 0.352 +KVM: 0.302 +boot: 0.179 +assembly: 0.178 + +system_powerdown/system_reset not working when exec stop on hmp + +system_powerdown/system_reset stops working in qemu for centos kernels if KVM is enabled. + +qemu versioin: 2.4 +linux kernel versioin: 4.2.5 + +How to reproduce: + +1. qemu-system-x86_64 -enable-kvm -drive if=none,id=drive0,file=/media/sda5/image/fc21/fc21.raw -device virtio-blk-pci,drive=drive0,iothread=iothread0 -machine smm=off -object iothread,id=iothread0 -monitor stdio +2. Enter stop in the qemu console, we can see the vm is stopped. +3. Enter system_powerdown in the qemu console +4. Nothing happens. + +Can you please give a prompt or something else when the vm isn't allowed to powerdown or reset? + +Looking through old bug tickets ... I don't think this was really a bug. If you stop your guest, of course the guest operating system can not powerdown anymore. It should powerdown once you resume your guest with "cont". + diff --git a/results/classifier/105/instruction/1529764 b/results/classifier/105/instruction/1529764 new file mode 100644 index 00000000..f8ecb7ce --- /dev/null +++ b/results/classifier/105/instruction/1529764 @@ -0,0 +1,28 @@ +instruction: 0.827 +graphic: 0.784 +device: 0.781 +network: 0.525 +mistranslation: 0.509 +semantic: 0.476 +other: 0.471 +socket: 0.430 +vnc: 0.429 +boot: 0.410 +KVM: 0.274 +assembly: 0.198 + +No video output with the official Windows XP VMWare VGA driver + +Steps to reproduce: + +1) Set -vga to vmware +2) Install Windows XP SP3 +3) Install VGA drivers from http://packages.vmware.com/tools/releases/latest/windows/x86/VMware-tools-windows-10.0.5-3227872.iso + +Result: completely black screen (even after F8 -> use VGA mode). + +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/105/instruction/1541 b/results/classifier/105/instruction/1541 new file mode 100644 index 00000000..2c892660 --- /dev/null +++ b/results/classifier/105/instruction/1541 @@ -0,0 +1,45 @@ +instruction: 0.830 +graphic: 0.817 +device: 0.752 +mistranslation: 0.626 +semantic: 0.599 +network: 0.553 +vnc: 0.539 +other: 0.482 +assembly: 0.475 +socket: 0.467 +KVM: 0.312 +boot: 0.230 + +Invalid position of G_NORETURN in clang v15 +Description of problem: +Order of `G_NORETURN` used in https://gitlab.com/qemu-project/qemu/-/blob/0f3de970febd2c9b29dccecb63ca928c6802a101/include/qemu/osdep.h#L240-242 is not valid in clang++ 15.0.7. + +Switching `extern` with `G_NORETURN` seems to fix the issue. +Steps to reproduce: +1. Build qemu system for MIPSEL or use minimal reproducer: + +`example.cpp`: +``` +#include "/path/to/qemu/include/glib-compat.h" + +extern G_NORETURN +void // QEMU_ERROR("code path is reachable") + qemu_build_not_reached_always(void); +``` + +``` +$ clang++ --version +clang version 15.0.7 +Target: x86_64-pc-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +$ clang++ -m64 -mcx16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu++11 -O0 -g example.cpp +example.cpp:3:8: error: an attribute list cannot appear here +extern G_NORETURN + ^~~~~~~~~~ +/usr/include/glib-2.0/glib/gmacros.h:1075:21: note: expanded from macro 'G_NORETURN' +# define G_NORETURN [[noreturn]] + ^~~~~~~~~~~~ +1 error generated. +``` diff --git a/results/classifier/105/instruction/1541643 b/results/classifier/105/instruction/1541643 new file mode 100644 index 00000000..d01d8320 --- /dev/null +++ b/results/classifier/105/instruction/1541643 @@ -0,0 +1,26 @@ +instruction: 0.811 +device: 0.765 +mistranslation: 0.756 +graphic: 0.586 +semantic: 0.577 +network: 0.569 +other: 0.559 +vnc: 0.533 +KVM: 0.499 +socket: 0.470 +boot: 0.441 +assembly: 0.102 + +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/105/instruction/1542 b/results/classifier/105/instruction/1542 new file mode 100644 index 00000000..a250c027 --- /dev/null +++ b/results/classifier/105/instruction/1542 @@ -0,0 +1,26 @@ +instruction: 0.853 +device: 0.810 +graphic: 0.737 +network: 0.702 +other: 0.637 +socket: 0.633 +mistranslation: 0.620 +semantic: 0.594 +vnc: 0.513 +assembly: 0.342 +KVM: 0.330 +boot: 0.301 + +Non-Executable PMP regions of size less than 4K trigger instruction access faults non-deterministically +Description of problem: +When a non-executable PMP region of size less than 4K (page size) with a start address that is not 4K-aligned is created, QEMU will non-deterministically dispatch instruction access faults when instructions are executed from the PMP-covered region (will in some cases, won't in others, based on the current TLB state) +Steps to reproduce: +1. Create a PMP region of size less than 4K, that is not aligned to the start of the page, make it non-executable +2. Flush TLB with `sfence.vma x0, x0` +3. Jump to the start of the pmp-protected page and start executing instructions +4. Notice that no instruction access fault is reported once we reach the protected region inside the page +Additional information: +@rth7680 I believe this is at least partially an unintentional result of this commit that you authored: 7e0d9973ea665bf459b2dbd173d0e51bc6ca5216, which modified the behavior of `get_page_addr_code_hostp` probes to probe a single byte, instead of a full page size (signaled by passing 0). +This means that we initially probe the first byte of the page, see that no PMP faults are raised, and then assume that no other bytes in the page can cause a PMP fault. + +Note that I believe that simply changing this back to 0 from 1 is not enough, as this will likely simply reintroduce the issue I originally reported in #1053. diff --git a/results/classifier/105/instruction/1544 b/results/classifier/105/instruction/1544 new file mode 100644 index 00000000..75db1e56 --- /dev/null +++ b/results/classifier/105/instruction/1544 @@ -0,0 +1,14 @@ +instruction: 0.825 +mistranslation: 0.798 +device: 0.688 +network: 0.654 +graphic: 0.500 +semantic: 0.226 +boot: 0.099 +socket: 0.061 +other: 0.048 +vnc: 0.037 +assembly: 0.020 +KVM: 0.010 + +Abort in net_tx_pkt_do_sw_fragmentation diff --git a/results/classifier/105/instruction/1547526 b/results/classifier/105/instruction/1547526 new file mode 100644 index 00000000..ae3ec973 --- /dev/null +++ b/results/classifier/105/instruction/1547526 @@ -0,0 +1,430 @@ +instruction: 0.786 +device: 0.782 +graphic: 0.768 +mistranslation: 0.729 +other: 0.721 +semantic: 0.696 +boot: 0.669 +vnc: 0.645 +network: 0.499 +assembly: 0.481 +socket: 0.463 +KVM: 0.461 + +Java program does not execute on SPARC Solaris 8 + +Hello, + +I am trying to run a java program that never execute. The program uses jre1.1.5 which came with the java program. I don't know what to do to run this application. There are some random messages in command line that can be related to my problem (or not). They are: + + #1. Webstart launcher crashing. + Also found here: http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html + + #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, line 766 + Which was already reported here: https://bugs.launchpad.net/qemu/+bug/1450881 + + #3. Some problems with libthread in Solaris. + I have tried a workaround setting LM_LIBRARY_PATH to use another version of libthread that Solaris 8 has. + +I don't know if this is a qemu problem or Solaris problem. +My java application can be executed in command line or in GUI but I've tried both with no luck. I also have tryed other versions of JRE from 1.1.8 to 1.5 but no luck either. + +I appreciate **any information** that can help me to execute the java program!! +Thank you. + +I am using qemu-system-sparc (v2.5.50) with Solaris 8 (solaris-8-hw4-2.04-sparc). +The host is an Ubuntu 15.10 and I am using the openbios-sparc from Ubuntus ppa as shown bellow: + + openbios-sparc | 1.1+svn1334-1 | http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages + +The command line used to launch qemu is: + + qemu-system-sparc \ + -M SS-5 \ + -m 256 \ + -boot c \ + -cdrom $(DATA_ISO) \ + -drive file=root-disk.img,index=0,media=disk,format=raw \ + -serial stdio \ + -monitor tcp::4444,server,nowait \ + -localtime \ + -net user \ + -net nic \ + $(ui) + +DATA_ISO is the way I found to send my data to the guest. + +The root-disk.img is: + + Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors + Geometry: 27 heads, 107 sectors/track, 24620 cylinders + Units: sectors of 1 * 512 = 512 bytes + Sector size (logical/physical): 512 bytes / 512 bytes + I/O size (minimum/optimal): 512 bytes / 512 bytes + Disklabel type: sun + + Device Start End Sectors Size Id Type Flags + root-disk.img1 0 2744549 2744550 1.3G 2 SunOS root + root-disk.img2 2744550 3047894 303345 148.1M 3 SunOS swap u + root-disk.img3 0 71127179 71127180 33.9G 5 Whole disk + root-disk.img8 3047895 71127179 68079285 32.5G 8 SunOS home + + image: root-disk.img + file format: raw + virtual size: 36G (38654705664 bytes) + disk size: 1.2G + +I've been looking at this as I have time, and IMO it's a qemu bug. Fortunately I have a easy local reproducer here, and from what I can see in this one particular case it seems the QEMU doesn't honour the annul bit in the branch (or apparently corrupts it according to the guest?!). So yes, it's a known issue and I am working hard to try and isolate the bug and come up with a fix. + +Hi Mark, it is very good to hear that it isn't only with me. + +Let me know if you need a help to test and/or collect any information to help you to discover/fix this problem. + +Proposed patch posted to mailing list: https://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg01645.html - please test and report back. + + +Great Mark! This patch solves my problem. Thank you very much. + +Patch that solves the problem. + +Leandro, thanks for testing on your setup. If it passes my local tests, I'll send it in for the QEMU 2.6 release. + +Good! I tested with QEMU from git that I did the clone now. It shows +version 2.5.91. + +On Mon, Apr 11, 2016, 11:36 Mark Cave-Ayland <email address hidden> +wrote: + +> Leandro, thanks for testing on your setup. If it passes my local tests, +> I'll send it in for the QEMU 2.6 release. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1547526 +> +> Title: +> Java program does not execute on SPARC Solaris 8 +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> I am trying to run a java program that never execute. The program uses +> jre1.1.5 which came with the java program. I don't know what to do to +> run this application. There are some random messages in command line +> that can be related to my problem (or not). They are: +> +> #1. Webstart launcher crashing. +> Also found here: +> http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html +> +> #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, +> line 766 +> Which was already reported here: +> https://bugs.launchpad.net/qemu/+bug/1450881 +> +> #3. Some problems with libthread in Solaris. +> I have tried a workaround setting LM_LIBRARY_PATH to use another +> version of libthread that Solaris 8 has. +> +> I don't know if this is a qemu problem or Solaris problem. +> My java application can be executed in command line or in GUI but I've +> tried both with no luck. I also have tryed other versions of JRE from 1.1.8 +> to 1.5 but no luck either. +> +> I appreciate **any information** that can help me to execute the java +> program!! +> Thank you. +> +> I am using qemu-system-sparc (v2.5.50) with Solaris 8 +> (solaris-8-hw4-2.04-sparc). +> The host is an Ubuntu 15.10 and I am using the openbios-sparc from +> Ubuntus ppa as shown bellow: +> +> openbios-sparc | 1.1+svn1334-1 | +> http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages +> +> The command line used to launch qemu is: +> +> qemu-system-sparc \ +> -M SS-5 \ +> -m 256 \ +> -boot c \ +> -cdrom $(DATA_ISO) \ +> -drive file=root-disk.img,index=0,media=disk,format=raw \ +> -serial stdio \ +> -monitor tcp::4444,server,nowait \ +> -localtime \ +> -net user \ +> -net nic \ +> $(ui) +> +> DATA_ISO is the way I found to send my data to the guest. +> +> The root-disk.img is: +> +> Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors +> Geometry: 27 heads, 107 sectors/track, 24620 cylinders +> Units: sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disklabel type: sun +> +> Device Start End Sectors Size Id Type Flags +> root-disk.img1 0 2744549 2744550 1.3G 2 SunOS root +> root-disk.img2 2744550 3047894 303345 148.1M 3 SunOS swap u +> root-disk.img3 0 71127179 71127180 33.9G 5 Whole disk +> root-disk.img8 3047895 71127179 68079285 32.5G 8 SunOS home +> +> image: root-disk.img +> file format: raw +> virtual size: 36G (38654705664 bytes) +> disk size: 1.2G +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1547526/+subscriptions +> +-- +Leandro S. Heck + + +Hi Mark, do you know when qemu 2.6 will be released? + +-- +Leandro Sehnem Heck + +On Fri, Apr 15, 2016 at 4:49 AM, Mark Cave-Ayland < +<email address hidden>> wrote: + +> *** This bug is a duplicate of bug 1450881 *** +> https://bugs.launchpad.net/bugs/1450881 +> +> ** This bug has been marked a duplicate of bug 1450881 +> qemu-system-sparc MUTEX_HELD assert and libC lock errors +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1547526 +> +> Title: +> Java program does not execute on SPARC Solaris 8 +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> I am trying to run a java program that never execute. The program uses +> jre1.1.5 which came with the java program. I don't know what to do to +> run this application. There are some random messages in command line +> that can be related to my problem (or not). They are: +> +> #1. Webstart launcher crashing. +> Also found here: +> http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html +> +> #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, +> line 766 +> Which was already reported here: +> https://bugs.launchpad.net/qemu/+bug/1450881 +> +> #3. Some problems with libthread in Solaris. +> I have tried a workaround setting LM_LIBRARY_PATH to use another +> version of libthread that Solaris 8 has. +> +> I don't know if this is a qemu problem or Solaris problem. +> My java application can be executed in command line or in GUI but I've +> tried both with no luck. I also have tryed other versions of JRE from 1.1.8 +> to 1.5 but no luck either. +> +> I appreciate **any information** that can help me to execute the java +> program!! +> Thank you. +> +> I am using qemu-system-sparc (v2.5.50) with Solaris 8 +> (solaris-8-hw4-2.04-sparc). +> The host is an Ubuntu 15.10 and I am using the openbios-sparc from +> Ubuntus ppa as shown bellow: +> +> openbios-sparc | 1.1+svn1334-1 | +> http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages +> +> The command line used to launch qemu is: +> +> qemu-system-sparc \ +> -M SS-5 \ +> -m 256 \ +> -boot c \ +> -cdrom $(DATA_ISO) \ +> -drive file=root-disk.img,index=0,media=disk,format=raw \ +> -serial stdio \ +> -monitor tcp::4444,server,nowait \ +> -localtime \ +> -net user \ +> -net nic \ +> $(ui) +> +> DATA_ISO is the way I found to send my data to the guest. +> +> The root-disk.img is: +> +> Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors +> Geometry: 27 heads, 107 sectors/track, 24620 cylinders +> Units: sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disklabel type: sun +> +> Device Start End Sectors Size Id Type Flags +> root-disk.img1 0 2744549 2744550 1.3G 2 SunOS root +> root-disk.img2 2744550 3047894 303345 148.1M 3 SunOS swap u +> root-disk.img3 0 71127179 71127180 33.9G 5 Whole disk +> root-disk.img8 3047895 71127179 68079285 32.5G 8 SunOS home +> +> image: root-disk.img +> file format: raw +> virtual size: 36G (38654705664 bytes) +> disk size: 1.2G +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1547526/+subscriptions +> + + +On 05/02/2016 09:50 PM, Leandro Heck wrote: +> *** This bug is a duplicate of bug 1450881 *** +> https://bugs.launchpad.net/bugs/1450881 +> +> Hi Mark, do you know when qemu 2.6 will be released? +> + +Hi Leandro, + +please take a look here: http://wiki.qemu.org/Planning/2.6 + +Cheers, +Bastian + + + +Oh nice! Thank you. + +-- +Leandro Sehnem Heck + +On Mon, May 2, 2016 at 6:17 PM, Bastian Koppelmann < +<email address hidden>> wrote: + +> *** This bug is a duplicate of bug 1450881 *** +> https://bugs.launchpad.net/bugs/1450881 +> +> On 05/02/2016 09:50 PM, Leandro Heck wrote: +> > *** This bug is a duplicate of bug 1450881 *** +> > https://bugs.launchpad.net/bugs/1450881 +> > +> > Hi Mark, do you know when qemu 2.6 will be released? +> > +> +> Hi Leandro, +> +> please take a look here: http://wiki.qemu.org/Planning/2.6 +> +> Cheers, +> Bastian +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1547526 +> +> Title: +> Java program does not execute on SPARC Solaris 8 +> +> Status in QEMU: +> New +> +> Bug description: +> Hello, +> +> I am trying to run a java program that never execute. The program uses +> jre1.1.5 which came with the java program. I don't know what to do to +> run this application. There are some random messages in command line +> that can be related to my problem (or not). They are: +> +> #1. Webstart launcher crashing. +> Also found here: +> http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html +> +> #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, +> line 766 +> Which was already reported here: +> https://bugs.launchpad.net/qemu/+bug/1450881 +> +> #3. Some problems with libthread in Solaris. +> I have tried a workaround setting LM_LIBRARY_PATH to use another +> version of libthread that Solaris 8 has. +> +> I don't know if this is a qemu problem or Solaris problem. +> My java application can be executed in command line or in GUI but I've +> tried both with no luck. I also have tryed other versions of JRE from 1.1.8 +> to 1.5 but no luck either. +> +> I appreciate **any information** that can help me to execute the java +> program!! +> Thank you. +> +> I am using qemu-system-sparc (v2.5.50) with Solaris 8 +> (solaris-8-hw4-2.04-sparc). +> The host is an Ubuntu 15.10 and I am using the openbios-sparc from +> Ubuntus ppa as shown bellow: +> +> openbios-sparc | 1.1+svn1334-1 | +> http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages +> +> The command line used to launch qemu is: +> +> qemu-system-sparc \ +> -M SS-5 \ +> -m 256 \ +> -boot c \ +> -cdrom $(DATA_ISO) \ +> -drive file=root-disk.img,index=0,media=disk,format=raw \ +> -serial stdio \ +> -monitor tcp::4444,server,nowait \ +> -localtime \ +> -net user \ +> -net nic \ +> $(ui) +> +> DATA_ISO is the way I found to send my data to the guest. +> +> The root-disk.img is: +> +> Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors +> Geometry: 27 heads, 107 sectors/track, 24620 cylinders +> Units: sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disklabel type: sun +> +> Device Start End Sectors Size Id Type Flags +> root-disk.img1 0 2744549 2744550 1.3G 2 SunOS root +> root-disk.img2 2744550 3047894 303345 148.1M 3 SunOS swap u +> root-disk.img3 0 71127179 71127180 33.9G 5 Whole disk +> root-disk.img8 3047895 71127179 68079285 32.5G 8 SunOS home +> +> image: root-disk.img +> file format: raw +> virtual size: 36G (38654705664 bytes) +> disk size: 1.2G +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1547526/+subscriptions +> + + diff --git a/results/classifier/105/instruction/1549298 b/results/classifier/105/instruction/1549298 new file mode 100644 index 00000000..a2309cd5 --- /dev/null +++ b/results/classifier/105/instruction/1549298 @@ -0,0 +1,32 @@ +instruction: 0.874 +graphic: 0.860 +device: 0.834 +semantic: 0.656 +other: 0.649 +socket: 0.614 +vnc: 0.571 +network: 0.563 +mistranslation: 0.555 +assembly: 0.496 +boot: 0.474 +KVM: 0.165 + +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/105/instruction/1551 b/results/classifier/105/instruction/1551 new file mode 100644 index 00000000..f5750b33 --- /dev/null +++ b/results/classifier/105/instruction/1551 @@ -0,0 +1,53 @@ +instruction: 0.773 +boot: 0.753 +graphic: 0.731 +device: 0.614 +semantic: 0.611 +vnc: 0.498 +assembly: 0.451 +socket: 0.449 +KVM: 0.379 +network: 0.372 +other: 0.334 +mistranslation: 0.238 + +qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed. +Description of problem: +When starting the guest, the mentioned assertion is triggered very soon: +``` +qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed. +``` +I'm able to successfully boot the same image with QEMU 7.2.0. + +The last output from the qemu logging with `-d guest_errors,in_asm,int,pcall,cpu` is +``` +---------------- +IN: +0x40209100: e92d4ff0 push {r4, r5, r6, r7, r8, sb, sl, fp, lr} +0x40209104: e28db020 add fp, sp, #0x20 +0x40209108: e24b3f49 sub r3, fp, #0x124 +0x4020910c: e24ddf43 sub sp, sp, #0x10c +0x40209110: e1a0e00f mov lr, pc +0x40209114: e3e0f0ff mvn pc, #0xff + +R00=4021000c R01=4020a5f8 R02=0000000f R03=40209100 +R04=40210018 R05=40210018 R06=4020c000 R07=40002000 +R08=00000000 R09=00000000 R10=00000000 R11=4020d7fc +R12=00000000 R13=4020d7f0 R14=4020074c R15=40209100 +PSR=2000011f --C- A sys32 +---------------- +IN: +0xffffff00: ee1d0f50 mrc p15, #0, r0, c13, c0, #2 + +R00=4021000c R01=4020a5f8 R02=0000000f R03=4020d6c8 +R04=40210018 R05=40210018 R06=4020c000 R07=40002000 +R08=00000000 R09=00000000 R10=00000000 R11=4020d7ec +R12=00000000 R13=4020d6c0 R14=40209118 R15=ffffff00 +PSR=2000011f --C- A sys32 +``` + +Please note that the L4Re OS uses `mvn pc, #0xff` to switch from EL1 to EL2 (system call). +Steps to reproduce: +1. Boot the attached image with the provided command line to trigger the assertion +Additional information: +I will attach the bootstrap image to this ticket. diff --git a/results/classifier/105/instruction/1552549 b/results/classifier/105/instruction/1552549 new file mode 100644 index 00000000..776af160 --- /dev/null +++ b/results/classifier/105/instruction/1552549 @@ -0,0 +1,24 @@ +instruction: 0.757 +device: 0.486 +graphic: 0.358 +network: 0.333 +boot: 0.313 +other: 0.244 +semantic: 0.229 +socket: 0.217 +vnc: 0.184 +mistranslation: 0.097 +assembly: 0.087 +KVM: 0.060 + +qemu-system-i386 verison 2.5.50 fails at lmsw instruction + +I cloned qemu source code from github.com, and compiled it on my Kubuntu 15.10 laptop to run my little OS. When booting my little OS, the virtual machine's screen keep blinking, I guess it's the virtual machine rebooting on and on automatically for some unknown reason, but there is no further information shown on Kubuntu's terminal. I'm pretty sure this problem is not caused by my little OS, because it works just fine in qemu-system-i386 version 2.5.0. + +I debugged my OS and find this problem happens when executing instruction "lmsw ax". Is this a bug, can anyone help me out? + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? If not, can you provide an example for testing? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1560 b/results/classifier/105/instruction/1560 new file mode 100644 index 00000000..fec7994d --- /dev/null +++ b/results/classifier/105/instruction/1560 @@ -0,0 +1,14 @@ +instruction: 0.895 +network: 0.858 +device: 0.822 +boot: 0.459 +semantic: 0.437 +other: 0.396 +mistranslation: 0.298 +vnc: 0.282 +graphic: 0.218 +socket: 0.167 +assembly: 0.101 +KVM: 0.055 + +SLIRP hostfwd_add ignores bind address and uses `INADDR_ANY` diff --git a/results/classifier/105/instruction/1565395 b/results/classifier/105/instruction/1565395 new file mode 100644 index 00000000..ab30f723 --- /dev/null +++ b/results/classifier/105/instruction/1565395 @@ -0,0 +1,42 @@ +instruction: 0.788 +graphic: 0.769 +device: 0.705 +semantic: 0.651 +vnc: 0.595 +other: 0.563 +mistranslation: 0.554 +assembly: 0.551 +socket: 0.546 +network: 0.508 +boot: 0.469 +KVM: 0.218 + +qemu-2.4.1 fails when compiled against pulseaudio + +If I compile qemu-2.4.1 like this: + +CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe +-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local +--localstatedir=/var --libexecdir=/usr/local/lib/qemu +--interp-prefix=/usr/local/share/qemu --disable-smartcard-nss +--disable-curses --disable-brlapi --audio-drv-list="oss alsa sdl" +--target-list="i386-softmmu i386-linux-user x86_64-softmmu +x86_64-linux-user" --smbd=/usr/local/sbin/smbd + +find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \; + +make + +..it works fine. + +If I add pulseaudio dev files and use --audio-drv-list="oss alsa sdl pa", +then "qemu-system-x86_64 -blah-blah" opens a window, displays the bios +message and stops. Strace shows qemu is not hung, but loops continually. + +The same happens with qemu-2.2.1 and qemu-2.5.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 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/105/instruction/1567254 b/results/classifier/105/instruction/1567254 new file mode 100644 index 00000000..68d08324 --- /dev/null +++ b/results/classifier/105/instruction/1567254 @@ -0,0 +1,53 @@ +instruction: 0.568 +device: 0.401 +graphic: 0.355 +semantic: 0.349 +other: 0.303 +mistranslation: 0.192 +socket: 0.183 +boot: 0.157 +assembly: 0.147 +network: 0.136 +vnc: 0.066 +KVM: 0.032 + +qemu-2.5.1 will not run with gtk3/vte + +Using qemu-2.5.1 and compiling without gtk3 and vte-2.90. + +This works: + +CC="gcc -mtune=generic -Os -pipe" CXX="g++ -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local --localstatedir=/var --libexecdir=/usr/local/lib/qemu --interp-prefix=/usr/local/share/qemu --audio-drv-list="oss alsa sdl" --target-list="i386-softmmu i386-linux-user x86_64-softmmu x86_64-linux-user" --smbd=/usr/local/sbin/smbd --disable-curses + +find . -name config-host.mak -type f -exec sed -i 's/-O2//g' {} \; + +make +sudo make install + +If I then add gtk3 and vte-2.90 development files and compile again, this fails with or without --disable-docs: + + sudo make install +... +make -C po install +make[1]: Entering directory '/usr/src/qemu-2.5.1/po' + GEN tr.mo +/bin/sh: msgfmt: not found +Makefile:13: recipe for target 'tr.mo' failed +make[1]: *** [tr.mo] Error 127 +make[1]: Leaving directory '/usr/src/qemu-2.5.1/po' +Makefile:443: recipe for target 'install' failed +make: *** [install] Error 2 + +If I then add gettext and re-compile, "qemu-system-x86_64 -blah-blah" opens a window, displays the bios message and stops. + +* configure script should check for gettext +* if "--disable-docs" is passed, "make install" should not try to install docs +* qemu should work when compiled with gtk3 and vte +* why does qemu insist on vte-2.90, when vte-2.91 has been out +/- 2 years? + +Looking through old bug tickets... can you still reproduce these issues with the latest version of QEMU? + +Things seem to work with gtk3 and qemu-3.1.0 - I didn't try vte though... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1574346 b/results/classifier/105/instruction/1574346 new file mode 100644 index 00000000..410bb5ba --- /dev/null +++ b/results/classifier/105/instruction/1574346 @@ -0,0 +1,41 @@ +instruction: 0.779 +other: 0.750 +graphic: 0.731 +device: 0.728 +mistranslation: 0.635 +semantic: 0.551 +network: 0.544 +socket: 0.467 +vnc: 0.421 +boot: 0.390 +assembly: 0.341 +KVM: 0.339 + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. + +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/105/instruction/1582 b/results/classifier/105/instruction/1582 new file mode 100644 index 00000000..dc38e01e --- /dev/null +++ b/results/classifier/105/instruction/1582 @@ -0,0 +1,14 @@ +instruction: 0.831 +device: 0.818 +graphic: 0.813 +network: 0.718 +assembly: 0.459 +mistranslation: 0.360 +boot: 0.208 +semantic: 0.206 +socket: 0.118 +other: 0.089 +vnc: 0.052 +KVM: 0.012 + +Floating-point-exception in rtl8139_cplus_transmit_one diff --git a/results/classifier/105/instruction/1586611 b/results/classifier/105/instruction/1586611 new file mode 100644 index 00000000..75d887bf --- /dev/null +++ b/results/classifier/105/instruction/1586611 @@ -0,0 +1,38 @@ +instruction: 0.853 +graphic: 0.843 +device: 0.778 +KVM: 0.762 +other: 0.760 +semantic: 0.688 +network: 0.679 +vnc: 0.632 +mistranslation: 0.608 +socket: 0.559 +boot: 0.511 +assembly: 0.271 + +usb-hub can not be detached when detach usb device from VM + +I give a host usb device to guest in the way of passthrough,use "virsh attach-device" cmd. In guest os,use "lsusb" cmd I can see two devices have been added,one is usb device and the other is usb-hub（0409:55aa NEC Corp. Hub）. +when I use "virsh detach-device" detach the usb device,in guest os the usb-hub was still exists. +It can create a bad impression when operating the VM,for example,suspend and resume the VM,qemu would report that: + +2016-05-24T12:03:54.434369Z qemu-kvm: Unknown savevm section or instance '0000:00:01.2/2/usb-hub' 0 + +2016-05-24T12:03:54.434742Z qemu-kvm: load of migration failed: Invalid argument + +From qemu's code,it can be sure that the usb-hub is generated by qemu,and the process of detaching usb-hub has already been executed,but failed.With adding print information,error as follows: +libusbx: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know +libusbx: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle + +I found that when I attached an usb device to the VM, the VM would add an usb-hub automatically if there was no usb-hub. +After adding an usb-hub,the VM assigned a port to the actual usb device. When detaching the usb device,the qemu only detach the port,without detaching the usb-hub.So when doing action like migrating or suspending/resumming,the VM will fail. + +Try detach the usb-hub device by the virsh detach-device usb-hub.xml? + +Of course using virtual usb controller is normal,The situation of the problems is to use the passthrough usb devices + +The usb-hub device should be deleted when the usb device was detached. When do you fix this bug? + +Use a newer libvirt version which manages usb addressing and assigns usb devices to usb ports. This is required to make sure the physical device tree is the same after vmsave/vmload or live migration. + diff --git a/results/classifier/105/instruction/1587 b/results/classifier/105/instruction/1587 new file mode 100644 index 00000000..04ed2209 --- /dev/null +++ b/results/classifier/105/instruction/1587 @@ -0,0 +1,38 @@ +instruction: 0.949 +graphic: 0.888 +semantic: 0.794 +device: 0.759 +socket: 0.556 +network: 0.547 +vnc: 0.528 +mistranslation: 0.483 +boot: 0.357 +assembly: 0.348 +other: 0.345 +KVM: 0.207 + +Invalid memory access allowed (possibly due to TLB bypassing PMP after mret) +Description of problem: +A load instruction that should be blocked by PMP due to MPRV changing the effective privilege mode to U is allowed. The sequence that I observed was: + + +1. Be in machine mode. +2. Set MPP to U (0). +3. Set MPRV to 1. +4. Enter an ISR, setting MPP to M (3). +5. Load from address xxxx (populating the QEMU TLB). +6. Execute mret, setting MPP back to U (0). +7. Load from address xxxx, which should fail but succeeds without any TLB fill. +Steps to reproduce: +``` +git clone https://github.com/dreiss/qemu_pmp_repro +cd qemu_pmp_repro +./build_and_run.sh +``` +The `build_and_run.sh` script expects `riscv-none-elf-gcc` and `qemu-system-riscv64` on PATH. It will also attempt to run the reproducer with `spike`, the reference RISC-V emulator, which succeeds. +Additional information: +Adding a call to `tlb_flush` to `helper_mret` causes this test to pass in QEMU, but I don't know if that's a valid fix. + +Output from `build_and_run.sh`: + +[output.txt](/uploads/108547bcb160a8f0bfffe72ea77b215f/output.txt) diff --git a/results/classifier/105/instruction/1589923 b/results/classifier/105/instruction/1589923 new file mode 100644 index 00000000..71fa4e3d --- /dev/null +++ b/results/classifier/105/instruction/1589923 @@ -0,0 +1,178 @@ +instruction: 0.928 +graphic: 0.917 +KVM: 0.908 +device: 0.904 +other: 0.904 +vnc: 0.890 +mistranslation: 0.863 +network: 0.842 +assembly: 0.836 +semantic: 0.829 +socket: 0.818 +boot: 0.768 + +https websockets not working in 2.5 or 2.6 + +% gdb --args ./x86_64-softmmu/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 + +GNU gdb (GDB) 7.11 +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 ./x86_64-softmmu/qemu-system-x86_64...done. +(gdb) run +Starting program: /home/ben/qemu/qemu-2.6.0/x86_64-softmmu/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib/libthread_db.so.1". +[New Thread 0x7fffe16f6700 (LWP 12767)] +[New Thread 0x7fffde2d4700 (LWP 12768)] +[New Thread 0x7fffd3fff700 (LWP 12769)] +Initializing VNC server with x509 no auth +Client sioc=0x55555874d6b0 ws=1 auth=1 subauth=0 +New client on socket 0x55555874d6b0 +vnc_set_share_mode/0x55555874d6b0: undefined -> connecting +TLS Websocket connection required +Start TLS WS handshake process +Handshake failed TLS handshake failed: The TLS connection was non-properly terminated. +Closing down client sock: protocol error +vnc_set_share_mode/0x55555779f510: connecting -> disconnected +Client sioc=0x55555873c6a0 ws=1 auth=1 subauth=0 +New client on socket 0x55555873c6a0 +vnc_set_share_mode/0x55555873c6a0: undefined -> connecting +TLS Websocket connection required +Start TLS WS handshake process +TLS handshake complete, starting websocket handshake +Websocket negotiate starting +Websock handshake complete, starting VNC protocol +Write Plain: Pending output 0x555557b91c60 size 4096 offset 12. Wait SSF 0 +Wrote wire 0x555557b91c60 12 -> 12 + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +0x0000000000000001 in ?? () +(gdb) thread apply all bt + +Thread 4 (Thread 0x7fffd3fff700 (LWP 12769)): +#0 0x00007fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a20bd9 in qemu_cond_wait (cond=cond@entry=0x5555587267e0, + mutex=mutex@entry=0x555558726810) at util/qemu-thread-posix.c:123 +#2 0x00005555559770ab in vnc_worker_thread_loop (queue=queue@entry=0x5555587267e0) + at ui/vnc-jobs.c:228 +#3 0x00005555559775e8 in vnc_worker_thread (arg=0x5555587267e0) at ui/vnc-jobs.c:335 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 3 (Thread 0x7fffde2d4700 (LWP 12768)): +#0 0x00007fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a20bd9 in qemu_cond_wait (cond=<optimized out>, +---Type <return> to continue, or q <return> to quit--- + emu_global_mutex>) at util/qemu-thread-posix.c:123 +#2 0x0000555555715edf in qemu_tcg_wait_io_event (cpu=0x5555564ee840) at /home/ben/qemu/qemu-2.6.0/cpus.c:1015 +#3 qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/ben/qemu/qemu-2.6.0/cpus.c:1161 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7fffe16f6700 (LWP 12767)): +#0 0x00007fffea438229 in syscall () from /usr/lib/libc.so.6 +#1 0x0000555555a20ee8 in futex_wait (val=<optimized out>, ev=<optimized out>) at util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=ev@entry=0x55555641ece4 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399 +#3 0x0000555555a2f2ae in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:250 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7ffff7f5bb00 (LWP 12763)): +#0 0x0000000000000001 in ?? () +#1 0x00005555559efb53 in qio_task_free (task=0x555558212140) at io/task.c:58 +#2 0x00005555559efd89 in qio_task_complete (task=task@entry=0x555558212140) at io/task.c:145 +#3 0x00005555559ef5aa in qio_channel_websock_handshake_send (ioc=0x55555873c6a0, condition=<optimized out>, + user_data=0x555558212140) at io/channel-websock.c:289 +#4 0x00007fffecf59c8a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#5 0x000055555598a6b3 in glib_pollfds_poll () at main-loop.c:213 +#6 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258 +#7 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506 +#8 0x00005555556e1fbd in main_loop () at vl.c:1934 +#9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4656 + +The crash in 2.6 is fixed by + + https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01885.html + +The dropped connection in 2.5 is fixed by + + https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01884.html + +Fix has been included in QEMU v2.7.0: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=bc35d51077b33e68a0 + + +Fixed in stable-2.6 branch in + +commit 510531ea442a02048b1837fcf574d03559b38c9e +Author: Daniel P. Berrange <email address hidden> +Date: Tue Jun 7 12:27:51 2016 +0100 + + io: remove mistaken call to object_ref on QTask + + The QTask struct is just a standalone struct, not a QOM Object, + so calling object_ref() on it is not appropriate. This results + in mangling the 'destroy' field in the QTask struct, causing + the later call to qtask_free() to try to call the function + at address 0x1, with predictably segfault happy results. + + There is in fact no need for ref counting with QTask, as the + call to qtask_abort() or qtask_complete() will automatically + free associated memory. + + This fixes the crash shown in + + https://bugs.launchpad.net/qemu/+bug/1589923 + + Reviewed-by: Eric Blake <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + (cherry picked from commit bc35d51077b33e68a0ab10a057f352747214223f) + Signed-off-by: Michael Roth <email address hidden> + + + +Fixed in >=2.7 and thereby >=Zesty. +Needs to be considered for SRUs now. + +I added this to my list a while ago but now closed out the immediate tasks for artful, so I'm coming back here. +Writing repro steps which will be needed for the SRU. + +# Brute force create dummy keys for this +openssl req -out ca.pem -new -x509 +openssl genrsa -out server.key 1024 +openssl req -key server.key -new -out server.req +echo 00 > file.srl +openssl x509 -req -in server.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out server-cert.pem +openssl genrsa -out client.key 1024 +openssl req -key client.key -new -out client.req +openssl x509 -req -in client.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out client-cert.pem +ln -s ca.pem ca-cert.pem +ln -s server.key server-key.pem + +# run qemu with x509 websocket +/usr/bin/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=$(pwd),websocket=5707 + +It is not crashing and I can even connect with krdc (likely also other clients) against it without breaking. + +But then I'd think your command above for the crash was the one for the crash in 2.6 which was yakkety. + +But what is left to fix is the dropped connection [1] in 2.5 (Xenial). + +I tried to read a better testcase out of that mail thread but failed, if you'd have a better setup description to still trigger this blocked handshake that eventually fails once the signal sets data - that would be great. +The actual report I found [2] is actually this bug bridges onto the ML so no more info there for me. + +[1]: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01884.html +[2]: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01917.html + diff --git a/results/classifier/105/instruction/1590336 b/results/classifier/105/instruction/1590336 new file mode 100644 index 00000000..ea1186bb --- /dev/null +++ b/results/classifier/105/instruction/1590336 @@ -0,0 +1,52 @@ +instruction: 0.935 +graphic: 0.916 +other: 0.912 +assembly: 0.846 +device: 0.834 +semantic: 0.752 +socket: 0.742 +mistranslation: 0.642 +network: 0.640 +vnc: 0.597 +boot: 0.460 +KVM: 0.385 + +qemu-arm does not reject vrintz on non-v8 cpu + +Hello, + +It seems that qemu-arm does not reject some v8-only instructions as it should, but executes them "correctly". + +For instance, while compiling/running some of the GCC ARM instrinsics tests, we noticed that +vrintz should be rejected on cortex-a9 for instance, while it is executed as if the instruction was supported. + +objdump says: + 1074c: f3fa05a0 vrintz.f32 d16, d16 +and qemu -d in_asm says: +0x0001074c: f3fa05a0 vabal.u<illegal width 64> q8, d26, d16 + +The problem is still present in qemu-2.6.0 + +Should be fixed by http://patchwork.ozlabs.org/patch/633105/ + + +I confirm your patch does fix the problem. + +You may still want to fix the disassembler such that it dumps the right instruction, but that would be a separate fix. + +Thanks for your quick support. + + +On 9 June 2016 at 20:14, Christophe Lyon <email address hidden> wrote: +> You may still want to fix the disassembler such that it dumps the right +> instruction, but that would be a separate fix. + +Unfortunately the disassembler is the pre-GPLv3 binutils one, +so we can't just update it (and I'm not particularly inclined +to independently re-implement all the 32-bit instruction set +changes post that change). + +thanks +-- PMM + + diff --git a/results/classifier/105/instruction/1594069 b/results/classifier/105/instruction/1594069 new file mode 100644 index 00000000..bd2574b9 --- /dev/null +++ b/results/classifier/105/instruction/1594069 @@ -0,0 +1,87 @@ +instruction: 0.927 +mistranslation: 0.916 +graphic: 0.897 +other: 0.895 +device: 0.892 +boot: 0.847 +socket: 0.846 +semantic: 0.821 +assembly: 0.814 +network: 0.782 +vnc: 0.665 +KVM: 0.641 + +SIMD instructions translated to scalar host instructions + +SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions. It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2]. + +I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM). + +[1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103 +[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html + +On 19 June 2016 at 06:33, Timothy Pearson <email address hidden> wrote: +> Public bug reported: +> +> SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are +> translated to scalar instructions on the host instead of SIMD +> instructions. It appears that there have been a few efforts to rectify +> this [1], and even a submitted patch series, but all discussion has +> effectively died out [2]. +> +> I would like to see better SIMD performance on qemu, especially as +> non-x86 architectures are becoming widely used (e.g. ARM). + +I agree it would be nice, but I'm not sure there's much benefit +from filing a bug about it. Bug reports don't magically become +code changes, and doing SIMD-to-SIMD is very difficult when +you need to support multiple host and guest architectures and +get all the details and corner cases correct. QEMU as it stands +isn't behaving wrongly. + +thanks +-- PMM + + +I mostly filed the bug report since I was seeing multiple different attempts to implement this, and even a proper patch series on the mailing list, but no movement at all toward integrating this feature into mainline qemu. + +What would be needed to e.g. make the patch series on the mailing list acceptable for merge? + +On 20 June 2016 at 15:05, Timothy Pearson <email address hidden> wrote: +> I mostly filed the bug report since I was seeing multiple different +> attempts to implement this, and even a proper patch series on the +> mailing list, but no movement at all toward integrating this feature +> into mainline qemu. +> +> What would be needed to e.g. make the patch series on the mailing list +> acceptable for merge? + +The bare minimum is that things need to not break for any +guest x host combination. The RFC patchset from Kirill says +that it doesn't work for all ARM guest code, for instance. +It also needs to fall back cleanly if the backend doesn't support +vector ops, and I'm not sure if the RFC does that. It needs +to implement more than a single test "vector add". It needs +to be reasonably demonstrated that it's actually a win on +real-life code rather than a trivial microbenchmark. The +various concerns listed in the RFC cover letter need to be +discussed and addressed. + +This is all certainly doable, but the missing thing is "nobody +is actually doing it", not "we didn't know about this". +An RFC patchset is a sketch of a design, and there's a long +way between that and committable code. + +The ACM paper looks like a classic example of a bit of academic +work: maybe they did something interesting, but their intended +end output was a paper, not code, and they never submitted any +patches to us that I'm aware of. (And again, "academic prototype" +and "production code" are often far apart.) + +thanks +-- PMM + + +Closing this because it isn't a bug. (It looks like some of the vector TCG improvements are now in progress and might hit master for 2.12; but in any case having an open bug in the system about this serves no useful purpose.) + + diff --git a/results/classifier/105/instruction/1598029 b/results/classifier/105/instruction/1598029 new file mode 100644 index 00000000..93adde6d --- /dev/null +++ b/results/classifier/105/instruction/1598029 @@ -0,0 +1,41 @@ +instruction: 0.875 +device: 0.837 +graphic: 0.828 +assembly: 0.698 +boot: 0.659 +other: 0.642 +semantic: 0.617 +mistranslation: 0.610 +network: 0.580 +vnc: 0.566 +socket: 0.564 +KVM: 0.413 + +failed to boot a customized kernel if emulating Broadwell/Skylake + +Hardware: X86-64, Intel(R) Core(TM) i7-6500U( Skylake) +OS: Linux Mint 18 +Host Kernel: 4.5.7 + PaX/Grsecurity +Qemu: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.2) + +[Reproduction Steps] +1, Install a Debian 8 in the guest +2, Install a customized kernel( using same config to Debian 8) +3, Reboot: +qemu-system-x86_64 -hda debian8-test.img -boot d -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Broadwell -smp 2 + +or + +qemu-system-x86_64 -hda debian8-test.img -boot d -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu host -smp 2 + +[Actual Result] +kernel panic or can't login in the system + +[Workaround] +qemu-system-x86_64 -hda debian8-test.img -boot d -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Haswell -smp 2 + +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 be + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1605123 b/results/classifier/105/instruction/1605123 new file mode 100644 index 00000000..8a32f315 --- /dev/null +++ b/results/classifier/105/instruction/1605123 @@ -0,0 +1,50 @@ +instruction: 0.945 +graphic: 0.887 +semantic: 0.794 +device: 0.717 +other: 0.692 +mistranslation: 0.618 +network: 0.597 +vnc: 0.552 +boot: 0.485 +socket: 0.475 +KVM: 0.329 +assembly: 0.215 + +PEXT returns wrong values, seemingly switches arguments + +Hi, + +I fiddled with BMI2 instructions and discovered that pext instructions +emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It +seemingly switches up its arguments. I suspect that the error is around the +gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext +in target-i386/int_helper.c and it works fine. + +I ran my program on a CPU with BMI2 instruction set too, and it indeed +returns different values. + +I didn't check pdep, it could have the same problem. + +$ qemu-x86_64 --version +qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux + +I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". + +$ gcc --version +gcc (Debian 5.4.0-6) 5.4.0 20160609 + +Best regards, +Lénárd Szolnoki + + + +Paolo sent a patch here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05700.html + +Fix has been committed: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=75b208c28316095c4685 + diff --git a/results/classifier/105/instruction/1611 b/results/classifier/105/instruction/1611 new file mode 100644 index 00000000..72d635a2 --- /dev/null +++ b/results/classifier/105/instruction/1611 @@ -0,0 +1,14 @@ +instruction: 0.720 +device: 0.689 +graphic: 0.610 +semantic: 0.230 +mistranslation: 0.157 +boot: 0.097 +network: 0.069 +assembly: 0.017 +other: 0.009 +vnc: 0.006 +socket: 0.004 +KVM: 0.002 + +How to test rutabaga_gfx/gfxstream patches diff --git a/results/classifier/105/instruction/1611394 b/results/classifier/105/instruction/1611394 new file mode 100644 index 00000000..8e998f75 --- /dev/null +++ b/results/classifier/105/instruction/1611394 @@ -0,0 +1,54 @@ +instruction: 0.684 +device: 0.664 +socket: 0.635 +semantic: 0.634 +network: 0.607 +vnc: 0.572 +other: 0.559 +mistranslation: 0.476 +graphic: 0.473 +assembly: 0.460 +boot: 0.448 +KVM: 0.444 + +qemu-ppc: Scalar Single-Precision Floating-Point instructions should not test MSR[SPV] + +According to "Signal Processing Engine (SPE) Programming Environments Manual" at +http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf?fsrch=1&sr=1&pageNum=1 + +c.f section 4.2.3 and also Figure 2-2. + +When MSR[SPV] is _NOT_ set, then the embedded scalar single-precision floating-point instructions +should _NOT_ generate an Embedded Floating-Point Unavailable Interrupt. + + +Hence, some tests for MSR[SPV] in file target-ppc/translate.c need to be removed. +Namely, in the definitions of +1. GEN_SPEFPUOP_ARITH2_32_32 +2. gen_efsabs +3. gen_efsnabs +4. gen_efsneg +5. GEN_SPEFPUOP_COMP_32 + +Note, the macro GEN_SPEFPUOP_CONV_32_32 is already correct. + +One more thing, afaict the macro GEN_SPEFPUOP_CONV_32_64 is used by both +efs- and efd- instructions, and will need to be split in two versions. +The efs-use (i.e for efscfd) should be as it is today, but the use by efd-instructions +(e.g efdctui) will need to add a test for MSR[SPV]. + + + +(I've looked at today's HEAD-revision of target-ppc/translate.c). + +I have filed a broader ticket, Bug #1888918, reporting a very similar issue that leads to corruption/bad arithmetic when using double-precision & vector instructions. + +I will be submitting a patch in the next few days that will also address this ticket. + +Assuming that this commit: +https://gitlab.com/qemu-project/qemu/-/commit/8dcdb535d7cc4ba6270bb756e12e1d323254ed4e + +is sufficient to mark this bug as Fix Committed. Please re-open if I am mistaken. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/instruction/1614 b/results/classifier/105/instruction/1614 new file mode 100644 index 00000000..f31632cc --- /dev/null +++ b/results/classifier/105/instruction/1614 @@ -0,0 +1,14 @@ +instruction: 0.785 +device: 0.775 +network: 0.688 +semantic: 0.522 +graphic: 0.419 +boot: 0.321 +assembly: 0.313 +vnc: 0.297 +KVM: 0.202 +socket: 0.132 +mistranslation: 0.113 +other: 0.102 + +Add option to chardev pty for setting a named link to the allocated pty diff --git a/results/classifier/105/instruction/1615823 b/results/classifier/105/instruction/1615823 new file mode 100644 index 00000000..46314465 --- /dev/null +++ b/results/classifier/105/instruction/1615823 @@ -0,0 +1,81 @@ +instruction: 0.887 +mistranslation: 0.881 +assembly: 0.871 +semantic: 0.870 +vnc: 0.852 +other: 0.849 +device: 0.845 +boot: 0.845 +socket: 0.828 +graphic: 0.828 +network: 0.811 +KVM: 0.811 + +Windows 10 reports no compatible TPM found yet device manager shows it? + +Ubuntu 16.04 with stock kvm, libvirt, ovmf +Qemu 2.5 installed from stock ubuntu ppa +Qemu 2.6.1 built from tarball. +Qemu 2.7.0-rc4 built from tarball. + +Windows 10 guest reports a TPM device is installed and the driver functional under Device Manager-->Security Devices. TPM Administrator however advises no compatible TPM chip can be found. + +Qemu 2.5 is buggy and prevents the guest loading the TPM driver, this was addressed by http://git.qemu.org/?p=qemu.git;a=commit;h=2b1c2e8e5f1990f0a201a8cbf9d366fca60f4aa8 + +Have tested the below cmd out on both qemu-2.6.1 and qemu-2.7.0-rc4, both suffer the same problem. My TPM is most certainly compatible as installing Win10Pro onto the same host as bare metal provides me the desired and expected functionality aka Bitlocker and TPM Administrator work. + +sudo ./qemu-system-x86_64 \ +-enable-kvm \ +-machine q35 \ +-cpu host \ +-m 4096 \ +-smp 4,sockets=1,cores=2,threads=2 \ +-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 qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x2 \ +-drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on \ +-drive file=/mnt/120GB_SSD/wintpm_VARS.fd,if=pflash,format=raw,unit=1 \ +-drive file=/mnt/120GB_SSD/wintpm.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \ +-drive file="/mnt/share/Filestorage/Images/Microsoft Windows 10 Pro x64.iso",format=raw,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 \ +-drive file=/mnt/share/Filestorage/Images/virtio-win-0.1.117.iso,format=raw,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 \ +-tpmdev passthrough,id=tpm-tpm0,path=/dev/tpm0,cancel-path=/sys/class/tpm/tpm0/device/cancel \ +-device tpm-tis,tpmdev=tpm-tpm0,id=tpm0 + +Hi, any chance of this bug getting triaged anytime soon? I've posted to the qemu-devel mailing list twice but no response. Am keen to resolve this soon if its user error or not so if its a bonafide bug? + +Thanks, + +Kelvin + +I have the same problem with Windows 10 Enterprise running under qemu-2.5.0-9.fc23.1.tpmfix (which is the qemu version containing the fix you mentioned above.) on fedora 23. The same qemu version runs windows 7 enterprise with TPM just fine. So there seems to be some change in the way Windows uses TPM between 7 and 10. + +Hey, I bug out my own Win7 Ultimate iso and have the same results as Markus i.e. TPM Admin correctly see's the TPM chip installed and allows me to Initialise and generally manage it which is as per expectations but obviously different to what Windows 10 shows. + +I'm using Ubuntu 16.04 but building qemu 2.7.0 to test the guests with. + +So I used the Windows Media Creation tool to generate a more recent ISO which resulted in a date stamp of July-16. Using this Win10Pro image my TPM is now recognised by the TPM Administrator, I re-tested my older ISO in the same guest and this still had the problem so conclusive enough for me. + +Still using 2.7.0 git tag built from source tree + +I can get the TPM device working in Windows 10 after I upgrade Windows to version 1607. My qemu is still 2.6.1 from ubuntu 16.10. + +@Nelson, please can you provide a little more info as I'm still having problems with TPM preparation in Windows. What make and version is your TPM device. How was your guest configured i.e. SeaBios vs. OVMF, Q35 or i440FX? Are you using kvm/qemu with libvirt or just qemu on the command line? Any info/pointers would be appreciated. + +Thanks, + +K + +My laptop has a TPM 1.2 chip made by IFX (dmesg: tpm_tis 00:07: 1.2 TPM (device-id 0x1B, rev-id 16)) + +I couldn't get it to work in libvirt (I am running ubuntu 17.04) until I upgraded my Windows 10 to version 1607. I needed to change the CPU to "core2duo" first before I could apply the version 1607 patch (if you don't do that, you can never apply the patch). After applying this Windows patch, Windows can detect and use the TPM device assigned to it successfully. + + +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/105/instruction/1619 b/results/classifier/105/instruction/1619 new file mode 100644 index 00000000..4399fb1b --- /dev/null +++ b/results/classifier/105/instruction/1619 @@ -0,0 +1,14 @@ +instruction: 0.872 +device: 0.845 +semantic: 0.568 +assembly: 0.461 +network: 0.436 +graphic: 0.423 +boot: 0.363 +mistranslation: 0.216 +socket: 0.112 +vnc: 0.063 +other: 0.054 +KVM: 0.007 + +Emulate x86_64 on ARM machine diff --git a/results/classifier/105/instruction/1637 b/results/classifier/105/instruction/1637 new file mode 100644 index 00000000..9656c06f --- /dev/null +++ b/results/classifier/105/instruction/1637 @@ -0,0 +1,14 @@ +instruction: 0.919 +device: 0.840 +graphic: 0.655 +boot: 0.219 +other: 0.214 +vnc: 0.201 +semantic: 0.196 +network: 0.164 +assembly: 0.162 +socket: 0.081 +mistranslation: 0.070 +KVM: 0.044 + +Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/105/instruction/1641 b/results/classifier/105/instruction/1641 new file mode 100644 index 00000000..eb1a07d0 --- /dev/null +++ b/results/classifier/105/instruction/1641 @@ -0,0 +1,37 @@ +instruction: 0.889 +KVM: 0.831 +device: 0.773 +graphic: 0.766 +vnc: 0.570 +semantic: 0.555 +mistranslation: 0.465 +network: 0.383 +socket: 0.348 +other: 0.292 +boot: 0.241 +assembly: 0.185 + +[abrt] qemu-system-x86-core: do_patch_instruction(): qemu-system-x86_64 killed by SIGABRT +Description of problem: +Copied from downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2195952 + +Description of problem: +Virtualizing a Windows XP system which tried to reboot. + +Version-Release number of selected component: +qemu-system-x86-core-2:7.2.1-1.fc38 + +Additional info: +reason: qemu-system-x86_64 killed by SIGABRT +backtrace_rating: 4 +crash_function: do_patch_instruction +comment: Virtualizing a Windows XP system which tried to reboot. + +Truncated backtrace: +Thread no. 1 (6 frames) + #4 do_patch_instruction at ../hw/i386/kvmvapic.c:439 + #5 process_queued_cpu_work at ../cpus-common.c:347 + #6 qemu_wait_io_event at ../softmmu/cpus.c:435 + #7 kvm_vcpu_thread_fn at ../accel/kvm/kvm-accel-ops.c:56 + #8 qemu_thread_start at ../util/qemu-thread-posix.c:505 + #10 clone3 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 diff --git a/results/classifier/105/instruction/1642 b/results/classifier/105/instruction/1642 new file mode 100644 index 00000000..3d6bd4e1 --- /dev/null +++ b/results/classifier/105/instruction/1642 @@ -0,0 +1,35 @@ +instruction: 0.810 +graphic: 0.800 +device: 0.511 +semantic: 0.470 +vnc: 0.384 +mistranslation: 0.382 +socket: 0.376 +other: 0.373 +network: 0.339 +assembly: 0.257 +boot: 0.239 +KVM: 0.077 + +Qemu aarch64 tcg crashes when emulating an STXP instruction but only on a Windows host +Description of problem: +Qemu segfaults when trying to emulate an STXP instruction, but only when running natively on a windows host (msys2 build). This is not the same as https://gitlab.com/qemu-project/qemu/-/issues/1581. + +I've managed to git-bisect it to this change: https://github.com/qemu/qemu/commit/546789c7df8866c55cae8d3195e8e58328a35d51 +Sadly i cannot investigate it further and contribute a fix, but it seems like a problem with one of the I128 arguments to `helper_atomic_cmpxchgo_le ` + +UPD: Issue is also in master (as of `caa9cbd566877b34e9abcc04d936116fc5e0ab28`) +Steps to reproduce: +N/A +Additional information: +``` +Thread 9 received signal SIGSEGV, Segmentation fault. +0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, addr=18446684150325987376, oldv=46236672343829145701101521005152, newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +60 CMPXCHG_HELPER(cmpxchgo_le, Int128) +(gdb) bt +#0 0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, + addr=18446684150325987376, oldv=46236672343829145701101521005152, + newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +#1 0x00000247a124f73d in ?? () + +``` diff --git a/results/classifier/105/instruction/1643537 b/results/classifier/105/instruction/1643537 new file mode 100644 index 00000000..74904230 --- /dev/null +++ b/results/classifier/105/instruction/1643537 @@ -0,0 +1,45 @@ +instruction: 0.826 +semantic: 0.714 +graphic: 0.699 +device: 0.693 +network: 0.640 +socket: 0.622 +assembly: 0.604 +vnc: 0.547 +other: 0.522 +mistranslation: 0.506 +boot: 0.473 +KVM: 0.363 + +target-ppc/int_helper.c: 2 * bad array index + +1. + +[qemu/target-ppc/int_helper.c:2575]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Source code is + + return reg->u16[8 - n]; + +and + +qemu/target-ppc/cpu.h: uint16_t u16[8]; + +but at least once, n is zero, for example line 2725 in the int_helper.c file: + + uint16_t sgnb = get_national_digit(b, 0); + +2. + +[qemu/target-ppc/int_helper.c:2584]: (error) Array 'reg.u16[8]' accessed at index 8, which is out of bounds. + +Duplicate + +Thanks for the bug report! Jose posted a patch: +marc.info/?<email address hidden> + +Fix has been committed: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a813fe73621e1221a09 + +Released with version 2.8 + diff --git a/results/classifier/105/instruction/1645355 b/results/classifier/105/instruction/1645355 new file mode 100644 index 00000000..8dd04431 --- /dev/null +++ b/results/classifier/105/instruction/1645355 @@ -0,0 +1,72 @@ +instruction: 0.852 +other: 0.827 +device: 0.746 +mistranslation: 0.740 +graphic: 0.738 +semantic: 0.721 +vnc: 0.658 +socket: 0.636 +boot: 0.572 +assembly: 0.571 +KVM: 0.487 +network: 0.484 + +x86: singlestepping through SYSCALL instruction causes exception in kernelspace + +Hi, + +The bug was originally reported [1] and [2] here. There is a problem inside QEMU with singlestepping from userspace until SYSCALL instruction is reached. The OS has in FMASK TF bit set, therefore there should be no singlestepping exception when transitioning to kernelmode. But, inside QEMU there is (TF is clear seems FMASK is applied). See below for further details. + +The reproducer is available at [2]. + +Here is the original text with some minor clarifications: + +It seems that there is something wrong with QEMU with respect to handle the singlestepping and AMD64 syscall instruction. + +The AMD "syscall" instruction will clear defined flag in the FMASK MSR. Normally the TF flag is set there, so the first instruction when kernel is entered after syscall won't cause single step exception in the kernel. + +The observed scenario is a unhandled singlestep fault in the kernel or host reboot or QEMU crash. + +The possible way how to reproduce it is to single step through any function (in userspace) which does "syscall" instruction. After syscall is entered QEMU will trigger singlestepping exception in the kernel despite that the TF is set in FMASK MSR. Real HW behaves correctly and does not trigger this exception. + + +What is interesting is that I was not able to trigger it if I just enabled TF and did the syscall instruction, perhaps for this bug is somewhat important to have TF set for previous few instruction. + + +I have stumbled to this problem while working with our custom OS. However after some googling I found out that the NetBSD guys (CCed) are having very similar problem and I asked them to prepare a ISO image where the problem ends with QEMU SIGSEGV or host reboot. + +Thanks +Rudolf + +[1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html +[2] http://gnats.netbsd.org/49603 + +I believe this is fixed in the qemu git mainline (but not yet in any release) +by the following commits: + + commit c52ab08aee6f7d4717fc6b517174043126bd302f + Author: Doug Evans <email address hidden> + Date: Tue Dec 6 23:06:30 2016 +0000 + + target-i386: Fix eflags.TF/#DB handling of syscall/sysret insns + + The syscall and sysret instructions behave a bit differently: + TF is checked after the instruction completes. + This allows the o/s to disable #DB at a syscall by adding TF to FMASK. + And then when the sysret is executed the #DB is taken "as if" the + syscall insn just completed. + + commit 410e98146ffde201ab4c778823ac8beaa74c4c3f + Author: Doug Evans <email address hidden> + Date: Sat Dec 24 20:29:33 2016 +0000 + + target/i386: Fix bad patch application to translate.c + + In commit c52ab08aee6f7d4717fc6b517174043126bd302f, + the patch snippet for the "syscall" insn got applied to "iret". + + +Hi Andreas, man thanks for your reply. I can confirm that applying the two patches fixes my problem in the older version of the QEMU. + +The two patches mentioned in comment #1 have been released with v2.9.0, so setting status to "Fix released" now. + diff --git a/results/classifier/105/instruction/1648 b/results/classifier/105/instruction/1648 new file mode 100644 index 00000000..93f26692 --- /dev/null +++ b/results/classifier/105/instruction/1648 @@ -0,0 +1,71 @@ +instruction: 0.905 +device: 0.723 +assembly: 0.603 +socket: 0.563 +vnc: 0.505 +network: 0.482 +graphic: 0.460 +boot: 0.428 +semantic: 0.379 +KVM: 0.352 +other: 0.215 +mistranslation: 0.206 + +linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash +Description of problem: +Corrent Print Result: + +sp: cdd3b4e8 + +SUCCEEDED! + +qemu-x86_64 Print Result: + +sp: 2804170 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Segmentation fault + +Reason of Bug: + +sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*) + +For example on x86_64: + +reference to "qemu/linux-user/i386/signal.c" + +``` +# define TARGET_FPSTATE_FXSAVE_OFFSET 0 + +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + struct target_fpstate fpstate QEMU_ALIGNED(16); +}; +#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET ( \ + offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET) +``` + +offsetof(struct rt_sigframe, fpstate) align of 16 + +TARGET_FPSTATE_FXSAVE_OFFSET is 0 + +TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64 + +so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect! + +Fix the bug: + +``` +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + abi_ulong unused QEMU_ALIGNED(16); + struct target_fpstate fpstate; +}; +``` + +offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64. diff --git a/results/classifier/105/instruction/1650 b/results/classifier/105/instruction/1650 new file mode 100644 index 00000000..a0b36319 --- /dev/null +++ b/results/classifier/105/instruction/1650 @@ -0,0 +1,27 @@ +instruction: 0.934 +device: 0.836 +graphic: 0.772 +network: 0.750 +semantic: 0.731 +other: 0.692 +vnc: 0.487 +mistranslation: 0.424 +boot: 0.348 +socket: 0.283 +KVM: 0.226 +assembly: 0.120 + +Consider doing runtime detection of MAP_FIXED_NOREPLACE +Description of problem: +``` +qemu-i386-static: Unable to reserve 0xfffff000 bytes of virtual address space at 0x1000 (Operation not supported) for use as guest address space (check your virtual memory ulimit setting, min_mmap_addr or reserve less using -R option) +``` +strace says +``` + mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_FIXED_NOREPLACE, -1, 0) = -1 EOPNOTSUPP (Operation not supported) +``` +Steps to reproduce: +1. `apt install qemu-i386-static 32subsystem` +2. `strace qemu-i386-static /opt/32/bin/as` +Additional information: +Repeating the strace call in a minimal C program gives the same errno as expected -- the kernel is only 4.4. The problem here is that qemu only does `MAP_FIXED_NOREPLACE` feature detection at build-time via a `#ifndef` and even that behavior is poorly documented. Maybe do something at runtime? diff --git a/results/classifier/105/instruction/1656676 b/results/classifier/105/instruction/1656676 new file mode 100644 index 00000000..e2fb6366 --- /dev/null +++ b/results/classifier/105/instruction/1656676 @@ -0,0 +1,38 @@ +instruction: 0.812 +graphic: 0.804 +vnc: 0.758 +device: 0.691 +semantic: 0.676 +other: 0.565 +mistranslation: 0.518 +network: 0.466 +assembly: 0.356 +socket: 0.312 +boot: 0.159 +KVM: 0.136 + +nvram/fw_cfg.c ‘read’ may be used uninitialized + +Commit Number: b6af8ea60282df514f87d32e36afd1c9aeee28c8 + +The gcc version version 6.3.1 catches a new uninitialized variable in the master branch of QEMU on the Github. After looking through the function, it is really not properly assigned to a value in a certain path (the else condition of assigning read value in the code). +Here is the snippet of the condition assigning value: + if (dma.control & FW_CFG_DMA_CTL_READ) { + read = 1; + } else if (dma.control & FW_CFG_DMA_CTL_SKIP) { + read = 0; + } else { + dma.length = 0; + } + +Error (Warning) message is as following: +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’: +hw/nvram/fw_cfg.c:372:16: error: ‘read’ may be used uninitialized in this function [-Werror=maybe-uninitialized] + +Solution: +You can fix this by either assign a proper initial value when defining it, or give a proper value in the else condition. +Sorry that I don't have a patch for this. I'm not sure whether to assign 1 or 0 in the else condition. + +This has been fixed here already: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=baf2d5bfbac#patch6 + diff --git a/results/classifier/105/instruction/1672383 b/results/classifier/105/instruction/1672383 new file mode 100644 index 00000000..e116effc --- /dev/null +++ b/results/classifier/105/instruction/1672383 @@ -0,0 +1,36 @@ +instruction: 0.571 +device: 0.519 +boot: 0.462 +vnc: 0.421 +graphic: 0.395 +socket: 0.387 +network: 0.375 +semantic: 0.281 +other: 0.241 +mistranslation: 0.141 +assembly: 0.102 +KVM: 0.009 + +Slow Windows XP load after commit a9353fe897ca2687e5b3385ed39e3db3927a90e0 + +I've recently discovered, that in QEMU 2.8+ my Windows XP loading time has significantly worsened. In 2.7 it took 30-40 second to boot, but in 2.8 it became 2-2,5 minutes. + +I've used Git bisect, and found out that the change happened after commit a9353fe897ca2687e5b3385ed39e3db3927a90e0, which, as far as I can tell from the commit message, handled race condition when invalidating breakpoint. + +I've set a breakpoint in static void breakpoint_invalidate(CPUState *cpu, target_ulong pc), and here's a backtrace: +#0 cpu_breakpoint_insert (cpu=cpu@entry=0x555556a73be0, pc=144, + flags=flags@entry=32, breakpoint=breakpoint@entry=0x555556a7c670) + at /media/sdd2/qemu-work/exec.c:830 +#1 0x00005555558746ac in hw_breakpoint_insert (env=env@entry=0x555556a7be60, + index=index@entry=0) at /media/sdd2/qemu-work/target-i386/bpt_helper.c:64 +#2 0x00005555558748ed in cpu_x86_update_dr7 (env=0x555556a7be60, + new_dr7=<optimised out>) + at /media/sdd2/qemu-work/target-i386/bpt_helper.c:160 +#3 0x00007fffa17421f6 in code_gen_buffer () +#4 0x000055555577fcb4 in cpu_tb_exec (itb=<optimised out>, + itb=<optimised out>, cpu=0x7fff8b7763b0) + at /media/sdd2/qemu-work/cpu-exec.c:164 +It seems that XP sets some breakpoints during it's load, and it leads to frequent TB flushes and slow execution. + +Supposedly fixed by commit 406bc339b0505fcfc2ffcbca1f05a3756e338a65 + diff --git a/results/classifier/105/instruction/1680679 b/results/classifier/105/instruction/1680679 new file mode 100644 index 00000000..093a392c --- /dev/null +++ b/results/classifier/105/instruction/1680679 @@ -0,0 +1,215 @@ +instruction: 0.894 +mistranslation: 0.884 +boot: 0.865 +assembly: 0.862 +other: 0.861 +socket: 0.855 +semantic: 0.850 +device: 0.847 +graphic: 0.818 +network: 0.802 +KVM: 0.772 +vnc: 0.746 + +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/105/instruction/1681398 b/results/classifier/105/instruction/1681398 new file mode 100644 index 00000000..6d4179e0 --- /dev/null +++ b/results/classifier/105/instruction/1681398 @@ -0,0 +1,32 @@ +instruction: 0.840 +device: 0.825 +graphic: 0.739 +semantic: 0.648 +network: 0.630 +socket: 0.598 +mistranslation: 0.583 +vnc: 0.430 +boot: 0.366 +other: 0.307 +assembly: 0.190 +KVM: 0.135 + +hw/core: segmentation fault + +Reproducer: + $i386-softmmu/qemu-system-i386 -S -machine isapc,accel=tcg -device amd-iommu +Segmentation fault (core dumped) + +Partial bt: +#0 bus_add_child (child=0x555556d4e520, bus=0x0) at hw/core/qdev.c:88 +#1 qdev_set_parent_bus (dev=0x555556d4e520, bus=bus@entry=0x0) +at hw/core/qdev.c:119 + +This bug seems to have been fixed: we now report the command line issue with a more helpful message: + +$ qemu-system-i386 -S -machine isapc,accel=tcg -device amd-iommu +qemu-system-i386: -device amd-iommu: Machine-type 'isapc' not supported by IOMMU + +This was in QEMU 3.1, so I'm closing this bug. + + diff --git a/results/classifier/105/instruction/1683 b/results/classifier/105/instruction/1683 new file mode 100644 index 00000000..b69a66b0 --- /dev/null +++ b/results/classifier/105/instruction/1683 @@ -0,0 +1,14 @@ +instruction: 0.612 +device: 0.485 +graphic: 0.355 +mistranslation: 0.192 +semantic: 0.162 +network: 0.083 +boot: 0.044 +socket: 0.012 +vnc: 0.006 +other: 0.004 +assembly: 0.003 +KVM: 0.001 + +How to run qemu inside ubuntu:latest docker container? diff --git a/results/classifier/105/instruction/1689367 b/results/classifier/105/instruction/1689367 new file mode 100644 index 00000000..9aa2212f --- /dev/null +++ b/results/classifier/105/instruction/1689367 @@ -0,0 +1,120 @@ +instruction: 0.828 +graphic: 0.818 +device: 0.811 +semantic: 0.804 +vnc: 0.792 +KVM: 0.789 +network: 0.747 +assembly: 0.741 +other: 0.735 +socket: 0.710 +mistranslation: 0.709 +boot: 0.572 + +In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ? + +On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via + + /usr/sbin/qemu-binfmt-conf.sh + +from + + qemu-linux-user-2.9.0-374.1.x86_64 + +on the host, inside the chroot any compile activity is laced with repetitions of + + qemu: Unsupported syscall: 384 + +messages. + +This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim. These messages appear to be non-fatal, with no particular effect at all; at least not so far ... + +From a chat in #IRC, + + [10:05] davidgiluk clever/pgnd: I see it as getrandom + [10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html sort it on the ARM table and you can easily see it + [10:05] clever arch/arm/tools/syscall.tbl:384 common getrandom sys_getrandom + [10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom + [10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational? + [10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point + +arm32 syscall 384 is indeed getrandom, but QEMU implemented this in commit f894efd19917321 as of Feb 2016, which should be in 2.6 or later. I've just checked and the LTP test cases for getrandom all pass with qemu-arm-user and do invoke the getrandom syscall and don't provoke the warning from QEMU. + +Can you check that the qemu-arm-static binary inside the chroot is really 2.9 and not an older version? + + +The statically linked qemu files in chroot are cp'd from the host env + + file $(which qemu-arm) $(which qemu-arm-binfmt) + /usr/bin/qemu-arm: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.0.0, BuildID[sha1]=a6c50ab9b8f1845daab2f41d85936712aabafd89, not stripped + /usr/bin/qemu-arm-binfmt: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.0.0, BuildID[sha1]=ff78e29b45699433557fab5396b79f07211fd3d5, not stripped + +where + + rpm -q --whatprovides $(which qemu-arm) $(which qemu-arm-binfmt) + qemu-linux-user-2.10.1-412.1.x86_64 + qemu-linux-user-2.10.1-412.1.x86_64 + +pkg + + qemu-linux-user-2.10.1-412.1.x86_64 + +is sourced/installed from the openSUSE 'Virtualization' repo, + + https://build.opensuse.org/package/show/Virtualization/qemu-linux-user + +and, + + rpm -q --changelog qemu-linux-user-2.10.1-412.1.x86_64 | head -n 20 + * Thu Oct 19 2017 <email address hidden> + - Patch queue updated from git://github.com/openSUSE/qemu.git opensuse-2.10 + * Patches added: + 0040-io-monitor-encoutput-buffer-size-fr.patch + 0041-cirrus-fix-oob-access-in-mode4and5-.patch + 0042-9pfs-use-g_malloc0-to-allocate-spac.patch + + * Tue Oct 03 2017 <email address hidden> + - Update to v2.10.1 a stable, bug-fix-only release + * Patches dropped (upstream): + 0034-slirp-fix-clearing-ifq_so-from-pend.patch + 0035-s390-ccw-Fix-alignment-for-CCW1.patch + 0038-s390x-ais-for-2.10-stable-disable-a.patch + 0039-s390x-cpumodel-remove-ais-from-z14-.patch + * Patches renamed: + 0036-target-i386-cpu-Add-new-EPYC-CPU-mo.patch + - > 0034-target-i386-cpu-Add-new-EPYC-CPU-mo.patch + 0037-chardev-baum-fix-baum-that-releases.patch + - > 0035-chardev-baum-fix-baum-that-releases.patch + 0040-io-fix-temp-directory-used-by-test-.patch + + +Can you just run /usr/bin/qemu-arm-static --version in the chroot, please ? (or whatever suse calls its statically linked binary). + + +The other interesting question is what version of the (host) kernel headers the QEMU binary was built against -- if that's earlier than 3.17 then the headers won't define __NR_getrandom for the host system and we won't implement the syscall. + + +> Can you just run /usr/bin/qemu-arm-static --version in the chroot, +please ? (or whatever suse calls its statically linked binary). + +Yep, as soon as I'm sitting back in front of the machine with the chroot on it. Bit later ... + +> The other interesting question is what version of the (host) kernel headers the QEMU binary was built against -- if that's earlier than 3.17 then the headers won't define __NR_getrandom for the host system and we won't implement the syscall. + +The qemu build uses headers from a repo which tracks Kernel/Stable's regular releases. It _currently_ holds kernel 4.13.10. + + +> run /usr/bin/qemu-arm-static --version in the chroot + +:/# /usr/bin/qemu-arm --version + qemu-arm version 2.10.1 + Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +In that case I'm confused about what is happening here -- the emulation of getrandom() for arm guests on x86-64 targets works for me. The only other thing I can suggest is that you try building an upstream QEMU -- perhaps there's something odd going on with the SUSE patches or build environment. + + +[Expired for QEMU because there has been no activity for 60 days.] + +I am able to reproduce using docker and qemu-arm version 1.5.93 + diff --git a/results/classifier/105/instruction/1694998 b/results/classifier/105/instruction/1694998 new file mode 100644 index 00000000..5120a73d --- /dev/null +++ b/results/classifier/105/instruction/1694998 @@ -0,0 +1,62 @@ +instruction: 0.955 +device: 0.830 +network: 0.825 +graphic: 0.795 +socket: 0.792 +semantic: 0.758 +mistranslation: 0.749 +boot: 0.706 +vnc: 0.688 +other: 0.671 +KVM: 0.667 +assembly: 0.444 + +PPC: msgsnd instruction leads to assertion + +I tried to send doorbells (using msgsnd) between cores in guest OS. On QEMU v2.9.0 usage of msgsnd instruction leads to error: +ERROR: <...>/qemu-new/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) + + +QEMU v2.8.0 works fine. + +QEMU run options: qemu-system-ppc -serial stdio -M ppce500 -cpu e500mc -smp 2 -m 512M -kernel pok.elf + +pok.elf attached + + + +Could you please check whether this patch fixes the issue for you: + +diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c +--- a/target/ppc/excp_helper.c ++++ b/target/ppc/excp_helper.c +@@ -17,6 +17,7 @@ + * License along with this library; if not, see <http://www.gnu.org/licenses/>. + */ + #include "qemu/osdep.h" ++#include "qemu/main-loop.h" + #include "cpu.h" + #include "exec/helper-proto.h" + #include "exec/exec-all.h" +@@ -1132,6 +1133,7 @@ void helper_msgsnd(target_ulong rb) + return; + } + ++ qemu_mutex_lock_iothread(); + CPU_FOREACH(cs) { + PowerPCCPU *cpu = POWERPC_CPU(cs); + CPUPPCState *cenv = &cpu->env; +@@ -1141,5 +1143,6 @@ void helper_msgsnd(target_ulong rb) + cpu_interrupt(cs, CPU_INTERRUPT_HARD); + } + } ++ qemu_mutex_unlock_iothread(); + } + #endif + + +Yes, Thomas, this patch fixes the issue. + +Fix has now been included: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f1c29ebc51be77bd64178c8d + diff --git a/results/classifier/105/instruction/1699567 b/results/classifier/105/instruction/1699567 new file mode 100644 index 00000000..3b94c0ea --- /dev/null +++ b/results/classifier/105/instruction/1699567 @@ -0,0 +1,45 @@ +instruction: 0.841 +device: 0.765 +socket: 0.608 +mistranslation: 0.606 +other: 0.581 +semantic: 0.565 +graphic: 0.530 +vnc: 0.506 +network: 0.461 +assembly: 0.460 +boot: 0.421 +KVM: 0.160 + +Qemu does not force SSE data alignment + +I have an OS that tries to use SSE operations. It works fine in qemu. But it crashes when I try to run the OS at the host cpu using KVM. + +The instruction that crahes with #GP(0) is + movaps ADDR,%xmm0 + +The documentation says ADDR has to be 16-bytes alignment otherwise #GP is generated. And indeed the problem was with the data alignment. After adjusting it at my side the OS works fine both with Qemu and KVM. + +It would be great if QEMU followed specification more closely and forced SSE data alignment requirements. It will help to catch alignment issues early and debug it easier. + + +$ qemu-system-x86_64 -version +QEMU emulator version 2.9.50 (v2.9.0-1363-g95eef1c68b) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +I am currently running into this bug on QEMU emulator version 5.1.0. +movaps unaligned access works fine in qemu, when it should throw a GP. Likewise, the same code on physical hardware throws a GP. + +Yep. Long-standing bug. + + +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/217 + + diff --git a/results/classifier/105/instruction/1705 b/results/classifier/105/instruction/1705 new file mode 100644 index 00000000..39100602 --- /dev/null +++ b/results/classifier/105/instruction/1705 @@ -0,0 +1,79 @@ +instruction: 0.833 +graphic: 0.829 +vnc: 0.789 +mistranslation: 0.788 +semantic: 0.785 +device: 0.781 +boot: 0.745 +assembly: 0.728 +other: 0.726 +network: 0.725 +KVM: 0.699 +socket: 0.679 + +Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory +Description of problem: +I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1 ls` , I got `Illegal instruction` +The numa node 1 was the CXL DRAM simulated by QEMU. + +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 free: 31325 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 + +When I ran on numa node 1, no failed + +> root@8003:~# numactl --membind=0 ls +> ndctl + +When I ran on numa node 1(CXL DRAM),it failed. + +> root@8003:~# numactl --membind=1 ls +> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000] +> **Illegal instruction** +Steps to reproduce: +1. start the guest +2. cxl list (we could see the simulated CXL DRAM) +> root@8003:~# cxl list +> [ +> { +> "memdev":"mem0", +> "ram_size":34359738368, +> "serial":0, +> "host":"0000:0d:00.0" +> } +> ] +3. cxl create-region -t ram -d decoder0.0 -m mem0 +4. daxctl reconfigure-device dax0.0 --mode=system-ram +5. numactl -H +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 fr +> ee: 31254 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 +6. numactl --membind=1 ls +> root@8003:~# numactl --membind=1 ls +> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000] +> **Illegal instruction** +Additional information: +When I run dmesg, I found an error. +> root@8003:~# dmesg|grep error +> [ 2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 + +Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to Xeon IV. diff --git a/results/classifier/105/instruction/1709 b/results/classifier/105/instruction/1709 new file mode 100644 index 00000000..d1840c6e --- /dev/null +++ b/results/classifier/105/instruction/1709 @@ -0,0 +1,49 @@ +instruction: 0.843 +graphic: 0.837 +device: 0.758 +semantic: 0.729 +socket: 0.616 +network: 0.590 +other: 0.545 +vnc: 0.516 +mistranslation: 0.447 +boot: 0.379 +assembly: 0.374 +KVM: 0.367 + +Qemu commit 7efd65423a cannot be built: Couldn't find file "symbols/ar" in include paths +Description of problem: +Hello. + +I try to build qemu based on commit 7efd65423a but it breaks in step 9035/10108, complaining about a missing "symbols/ar". + +The last time I get a full build was with commit fdd0df5340. + +Configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror` + +Here is the error log I got: + +``` +Running postconf script '/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/symlink-install-tree.py' +[9035/10108] Generating pc-bios/keymaps/ar with a custom command +FAILED: pc-bios/keymaps/ar +/home/fred/qemu-git/src/qemu/build-full/qemu-keymap -f pc-bios/keymaps/ar -l ar +xkbcommon: ERROR: Couldn't find file "symbols/ar" in include paths +xkbcommon: ERROR: 1 include paths searched: +xkbcommon: ERROR: /usr/share/X11/xkb +xkbcommon: ERROR: 3 include paths could not be added: +xkbcommon: ERROR: /home/fred/.config/xkb +xkbcommon: ERROR: /home/fred/.xkb +xkbcommon: ERROR: /etc/xkb +xkbcommon: ERROR: Abandoning symbols file "(unnamed)" +xkbcommon: ERROR: Failed to compile xkb_symbols +xkbcommon: ERROR: Failed to compile keymap +[9040/10108] Generating pc-bios/edk2-x...d (wrapped by meson to capture output) +ninja: build stopped: subcommand failed. +``` + +I'll try to do a bisect as soon as possible to see which commit break all. +Steps to reproduce: +1. Just grab commit 7efd65423a +2. Apply these configure options: `--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror` +3. launch make and wait diff --git a/results/classifier/105/instruction/1715007 b/results/classifier/105/instruction/1715007 new file mode 100644 index 00000000..30e83300 --- /dev/null +++ b/results/classifier/105/instruction/1715007 @@ -0,0 +1,33 @@ +instruction: 0.657 +mistranslation: 0.600 +socket: 0.569 +semantic: 0.536 +graphic: 0.520 +device: 0.469 +network: 0.458 +vnc: 0.209 +KVM: 0.101 +boot: 0.095 +assembly: 0.085 +other: 0.063 + +hw/block/onenand.c:520: dead code ? + +qemu/hw/block/onenand.c:520] -> [qemu/hw/block/onenand.c:521]: (warning) Opposite inner 'if' condition leads to a dead code block. + +Source code is + + for (b = 0; b < s->blocks; b ++) { + if (b >= s->blocks) { + s->status |= ONEN_ERR_CMD; + break; + } + +I am not sure if the if condition can be merely deleted, or something more +complex needs to be implemented. + +Recent qemu trunk. + +Fix has now been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=dbfa934106d22402d + diff --git a/results/classifier/105/instruction/1716028 b/results/classifier/105/instruction/1716028 new file mode 100644 index 00000000..065af1e9 --- /dev/null +++ b/results/classifier/105/instruction/1716028 @@ -0,0 +1,542 @@ +instruction: 0.901 +assembly: 0.896 +other: 0.882 +device: 0.874 +graphic: 0.864 +boot: 0.860 +KVM: 0.829 +network: 0.818 +socket: 0.810 +vnc: 0.810 +semantic: 0.805 +mistranslation: 0.440 + +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/105/instruction/1716510 b/results/classifier/105/instruction/1716510 new file mode 100644 index 00000000..d685916b --- /dev/null +++ b/results/classifier/105/instruction/1716510 @@ -0,0 +1,33 @@ +instruction: 0.832 +other: 0.831 +mistranslation: 0.803 +vnc: 0.795 +KVM: 0.778 +boot: 0.777 +semantic: 0.769 +graphic: 0.743 +device: 0.742 +socket: 0.728 +assembly: 0.727 +network: 0.664 + +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/105/instruction/1718118 b/results/classifier/105/instruction/1718118 new file mode 100644 index 00000000..d4be599c --- /dev/null +++ b/results/classifier/105/instruction/1718118 @@ -0,0 +1,74 @@ +instruction: 0.855 +device: 0.855 +graphic: 0.851 +other: 0.839 +boot: 0.838 +mistranslation: 0.837 +socket: 0.836 +network: 0.835 +assembly: 0.834 +KVM: 0.831 +vnc: 0.820 +semantic: 0.807 + +qemu crashes with hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) + +Qemu crashes with error "hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev)" when memory hotplug and hotunplug was done continuously. + +Steps to re-produce: +1. git clone (today's i.e 19th Sept) +2. Bring up ppc64le guest with memory hotplug capabilities ( I used libvirt xml to do this). +3. And do continuous memory hotplug and unplug using the following memory xml (mem_hp_8g.xml) +<memory model='dimm'> +<target> +<size unit='KiB'>8388608</size> +<node>1</node> +</target> +</memory> +4. Run the following +for i in `seq 1 100`; do virsh attach-device nrs mem_hp_8g.xml --live; virsh detach-device nrs mem_hp_8g.xml --live; done +5. Guest will crash +6. Following is from qemu log + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-ppc64 -name guest=nrs,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-nrs/master-key.aes -machine pseries-2.10,accel=kvm,usb=off,dump-guest-core=off -m size=8388608k,slots=256,maxmem=419430400k -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -numa node,nodeid=1,cpus=2-3,mem=4096 -uuid d7987973-2467-43ff-b8d2-acefc6ac59e5 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-19-nrs/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/nasastry/pegas-1.0-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:89:8a:8b,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -s -msg timestamp=on +2017-09-19 06:59:07.878+0000: Domain id=19 is tainted: custom-argv +2017-09-19T06:59:07.918273Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/5 (label charserial0) +** +ERROR:/home/nasastry/qemu/hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) +2017-09-19 06:59:51.428+0000: shutting down, reason=crashed + +(gdb) bt +#0 0x00003fffb24beff0 in raise () at /lib64/libc.so.6 +#1 0x00003fffb24c136c in abort () at /lib64/libc.so.6 +#2 0x00003fffb2bcaa04 in g_assertion_message () at /lib64/libglib-2.0.so.0 +#3 0x00003fffb2bcab0c in g_assertion_message_expr () at /lib64/libglib-2.0.so.0 +#4 0x00000000101b85a0 in spapr_drc_detach (drc=0x2fc31220) at /home/nasastry/qemu/hw/ppc/spapr_drc.c:417 +#5 0x00000000101972e0 in spapr_memory_unplug_request (hotplug_dev=0x2faa60b0, dev=0x2fb8fb10, errp=0x3fffe92bfa90) at /home/nasastry/qemu/hw/ppc/spapr.c:3084 +#6 0x000000001019856c in spapr_machine_device_unplug_request (hotplug_dev=0x2faa60b0, dev=0x2fb8fb10, errp=0x3fffe92bfa90) + at /home/nasastry/qemu/hw/ppc/spapr.c:3354 +#7 0x00000000104461a8 in hotplug_handler_unplug_request (plug_handler=0x2faa60b0, plugged_dev=0x2fb8fb10, errp=0x3fffe92bfa90) at hw/core/hotplug.c:45 +#8 0x000000001036e15c in qdev_unplug (dev=0x2fb8fb10, errp=0x3fffe92bfa90) at qdev-monitor.c:878 +#9 0x000000001036e1e4 in qmp_device_del (id=0x2fab2880 "dimm0", errp=0x3fffe92bfa90) at qdev-monitor.c:888 +#10 0x000000001038975c in qmp_marshal_device_del (args=0x30658db0, ret=0x3fffe92bfb50, errp=0x3fffe92bfb48) at qmp-marshal.c:1462 +#11 0x000000001081fd98 in do_qmp_dispatch (cmds=0x10c0e078 <qmp_commands>, request=0x3093ebf0, errp=0x3fffe92bfbc0) at qapi/qmp-dispatch.c:104 +#12 0x000000001081ff84 in qmp_dispatch (cmds=0x10c0e078 <qmp_commands>, request=0x3093ebf0) at qapi/qmp-dispatch.c:131 +#13 0x00000000100983dc in handle_qmp_command (parser=0x2fae1e80, tokens=0x2faa44e0) at /home/nasastry/qemu/monitor.c:3852 +#14 0x000000001082aef0 in json_message_process_token (lexer=0x2fae1e88, input=0x2faa2420, type=JSON_RCURLY, x=70, y=374) at qobject/json-streamer.c:105 +#15 0x000000001086d5d0 in json_lexer_feed_char (lexer=0x2fae1e88, ch=125 '}', flush=false) at qobject/json-lexer.c:323 +#16 0x000000001086d7c4 in json_lexer_feed (lexer=0x2fae1e88, buffer=0x3fffe92bff88 "}", size=1) at qobject/json-lexer.c:373 +#17 0x000000001082b004 in json_message_parser_feed (parser=0x2fae1e80, buffer=0x3fffe92bff88 "}", size=1) at qobject/json-streamer.c:124 +#18 0x000000001009863c in monitor_qmp_read (opaque=0x2fae1df0, buf=0x3fffe92bff88 "}", size=1) at /home/nasastry/qemu/monitor.c:3894 +#19 0x000000001078e3c8 in qemu_chr_be_write_impl (s=0x2fab36b0, buf=0x3fffe92bff88 "}", len=1) at chardev/char.c:167 +#20 0x000000001078e484 in qemu_chr_be_write (s=0x2fab36b0, buf=0x3fffe92bff88 "}", len=1) at chardev/char.c:179 +#21 0x000000001079a910 in tcp_chr_read (chan=0x2fbfbbc0, cond=G_IO_IN, opaque=0x2fab36b0) at chardev/char-socket.c:441 +#22 0x00000000107be3d4 in qio_channel_fd_source_dispatch (source=0x2fab4770, callback=0x1079a760 <tcp_chr_read>, user_data=0x2fab36b0) at io/channel-watch.c:84 +#23 0x00003fffb2b93ab0 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#24 0x0000000010837e9c in glib_pollfds_poll () at util/main-loop.c:213 +#25 0x0000000010838064 in os_host_main_loop_wait (timeout=-1) at util/main-loop.c:261 +#26 0x000000001083818c in main_loop_wait (nonblocking=0) at util/main-loop.c:515 +#27 0x00000000103771c4 in main_loop () at vl.c:1999 +#28 0x0000000010381828 in main (argc=54, argv=0x3fffe92c1988, envp=0x3fffe92c1b40) at vl.c:4877 + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2a129767ebb13ffc29dad + diff --git a/results/classifier/105/instruction/1719984 b/results/classifier/105/instruction/1719984 new file mode 100644 index 00000000..909f6f0d --- /dev/null +++ b/results/classifier/105/instruction/1719984 @@ -0,0 +1,27 @@ +instruction: 0.917 +graphic: 0.887 +mistranslation: 0.851 +device: 0.786 +network: 0.762 +semantic: 0.650 +boot: 0.624 +socket: 0.597 +vnc: 0.595 +KVM: 0.312 +other: 0.185 +assembly: 0.157 + +wrgsbase misemulated in x86_64-softmmu + +qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4 +command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true ' + +On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1. In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference. + +For further data, the faulting instruction is +f3 48 0f ae df wrgsbase %rdi + +Fix is in staging: https://github.com/ehabkost/qemu/commit/cdcc80d41360e278b45c91de29a29d797264e85d + +Fix is in master: https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550 + diff --git a/results/classifier/105/instruction/1721275 b/results/classifier/105/instruction/1721275 new file mode 100644 index 00000000..d5dbab8e --- /dev/null +++ b/results/classifier/105/instruction/1721275 @@ -0,0 +1,100 @@ +instruction: 0.778 +other: 0.733 +device: 0.695 +vnc: 0.673 +semantic: 0.609 +assembly: 0.600 +graphic: 0.575 +boot: 0.559 +socket: 0.533 +mistranslation: 0.506 +network: 0.449 +KVM: 0.415 + +Support more ARM CPUs + +Hi, + +This is an enhancement request, rather than a bug report. + +After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters. + +I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for. + +I'd like to have: +cortex-m0 +cortex-m4 +cortex-m7 +cortex-m23 +cortex-m33 + +cortex-a35 +cortex-a53 +cortex-a57 + +Is it possible? +Is it the right place to ask? +Should I file separate requests for each? + +Thanks + +M0 is hard, because it's v6M which we don't support. M4 we already have (but only the no-fpu variant). M7 we don't currently have -- what would be the differences from M4? M33 is in the works (it's v8M). M23 is harder, because it's v8M-baseline which is the v8M equivalent to v6M. A53 and A57 we already have. How would A35 differ from A53/A57 ? + + +PS: in general I wouldn't unconditionally trust that QEMU emulating CPU X definitely does not implement any instructions that CPU X doesn't have -- no real world code will notice, and we don't have any mechanism to automatically verify that we didn't accidentally forget to conditionalize an instruction on an architecture feature. + + +Thanks for PS, I thought QEMU was stricter than that. + +Regarding M7 vs M$ or A35 vs A53/A57, even though there's no functional difference, it would be convenient in Makefiles to have CPU=cortex-a53, and use $(CPU) to expand GCC and QEMU options, without having to guess which CPU I should use for QEMU that would match the one I pass to GCC. + +Regarding v[68]M, are there any plans to add support for these variants to QEMU? + + +On 16 October 2017 at 14:16, Christophe Lyon +<email address hidden> wrote: +> Thanks for PS, I thought QEMU was stricter than that. + +Well, I hope we get it right, and we'll treat cases where +we get it wrong as bugs, but we're not testing... + +> Regarding v[68]M, are there any plans to add support for these variants +> to QEMU? + +v8M we're working on. v6M we have no plans for currently. + +thankns +-- PMM + + +We now support Cortex-M0 (v6M) and Cortex-M33 (v8M mainline). We don't have Cortex-M7, Cortex-M23 (v8M baseline) or Cortex-A35. + +In general, adding an extra CPU to QEMU really requires us to have a decent use-case for it, probably including a board model for it, especially for the M-profile CPUs. There are a lot of CPUs out there and I'm not too keen on adding large numbers of them unless there's a real need. + +I'm going to close this bug report because I don't think it really adds anything to have it sitting open indefinitely. + + +Regarding Cortex-M7, I've noticed that unlike Cortex-M4, it supports double precision floating-point. Is DP supported by qemu? + + +Yes, QEMU supports DP (I actually had to go to some lengths to disable the DP support for the M4 :-)) + + +How do I activate it since --cpu cortex-m7 isn't supported? + +You can't for an M-profile CPU. It would work without any further coding beyond getting the ID register values right if we had a Cortex-M7 model, though. + + +It seemed "easy" to add cortex-m7 based on cortex-m4 (copy m4 description, update ID register values), but I realized that QEMU does not support FPv5 which not only supports DP, but also adds new instructions that QEMU does not handle yet (see section A2.5 of the ARMv7-M ARM). + +* Are there plans to implement them? +* If not, how difficult is it? (for a developer not very familiar with the QEMU code base) + + +They are implemented, because they also appear in A-profile. +We just need to set the corresponding MVFR field to enable them. + +Setting MVFR2.FPMISC = 4 will do the job, I believe. + +Good news, I thought at least some of them were not implemented because for instance I couldn't find where VRINTA is handled (I noticed code for NEON_2RM_VRINTA, but I thought there should be something in vfp.decode for VRINT[ANPM]) + diff --git a/results/classifier/105/instruction/1724485 b/results/classifier/105/instruction/1724485 new file mode 100644 index 00000000..1beb3d53 --- /dev/null +++ b/results/classifier/105/instruction/1724485 @@ -0,0 +1,64 @@ +instruction: 0.876 +semantic: 0.846 +mistranslation: 0.730 +assembly: 0.707 +device: 0.670 +other: 0.635 +graphic: 0.621 +network: 0.457 +socket: 0.447 +boot: 0.372 +vnc: 0.335 +KVM: 0.238 + +Invalid assertion in arm_read_memory_func + +Hi, + +I think there is an invalid assertion in arm_read_memory_func: +assert(info->endian == BFD_ENDIAN_LITTLE) + +I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. + +At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. + +If I remove the assert, execution continues OK. + +With the assert, I get the error message from the assert, and qemu then stalls. + +Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? + +Thanks + +The tarball contains: +scoped1.exe +etc/ld.so.cache +lib/libm.so.6 +lib/libstdc++.so.6 +lib/lib.c.so.6 +lib/ld-linux-armhf.so.3 +lib/libgcc_s.so.1 + +I can reproduce the problem with qemu-2.10.1: +qemu-armeb -E LD_LIBRARY_PATH=$PWD/lib -cpu any -R 0 -d in_asm -L $PWD $PWD/scoped1.exe + +Removing '-d in_asm' works OK, because the offending assert is triggered while disassembling. + +BTW, the program (scoped1.exe) does abort, it is a GCC testcase I was trying to debug ;-) + +Removing the assert lets execution continue, but the disassembly is incorrect. Without the assert, I see: +IN: strlen +0x40a1a880: f000 f890 bl 0x40a1a9a4 +0x40a1a884: 4502 cmp r2, r0 +but strlen normally starts with a pld instruction. + +So probably print_insn_arm needs also a change like +given = (b[1]) | (b[0] <<8)<<16 | given; +instead of +given = (b[1]) | (b[0] <<8)|(given << 16); + + + +This should be fixed in QEMU master by commits 6cd61517fb5217098, 7bcdbf51eeb674e4. + + diff --git a/results/classifier/105/instruction/1728448 b/results/classifier/105/instruction/1728448 new file mode 100644 index 00000000..73ff5678 --- /dev/null +++ b/results/classifier/105/instruction/1728448 @@ -0,0 +1,85 @@ +instruction: 0.885 +device: 0.885 +other: 0.832 +assembly: 0.822 +graphic: 0.767 +semantic: 0.733 +boot: 0.729 +socket: 0.726 +network: 0.687 +mistranslation: 0.645 +KVM: 0.604 +vnc: 0.422 + +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/105/instruction/1728639 b/results/classifier/105/instruction/1728639 new file mode 100644 index 00000000..bf1ae36e --- /dev/null +++ b/results/classifier/105/instruction/1728639 @@ -0,0 +1,124 @@ +instruction: 0.874 +other: 0.872 +device: 0.852 +graphic: 0.832 +semantic: 0.818 +socket: 0.795 +boot: 0.789 +assembly: 0.783 +KVM: 0.756 +network: 0.691 +mistranslation: 0.688 +vnc: 0.647 + +qemu-io crashes with SIGSEGV when did -c truncate 320000 on a image_fuzzer image + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached files 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 320000" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 +723 if (drv->bdrv_getlength) { +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 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 +#1 0x000000001000fa10 in bdrv_open_driver (bs=0x1fe86f60, drv=0x102036f0 <bdrv_qcow2>, node_name=0x0, options=0x1fe8c240, open_flags=24578, + errp=0x3fffea0fc920) at block.c:1153 +#2 0x0000000010010480 in bdrv_open_common (bs=0x1fe86f60, file=0x1fe92540, options=0x1fe8c240, errp=0x3fffea0fc920) at block.c:1395 +#3 0x0000000010013ac8 in bdrv_open_inherit (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x1fe8c240, flags=24578, parent=0x0, child_role=0x0, + errp=0x3fffea0fcae0) at block.c:2616 +#4 0x0000000010013e8c in bdrv_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) at block.c:2698 +#5 0x000000001008b6d4 in blk_new_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) + at block/block-backend.c:321 +#6 0x000000001000a6ec in openfile (name=0x3fffea0ff661 "copy.img", flags=16386, writethrough=true, force_share=false, opts=0x0) at qemu-io.c:81 +#7 0x000000001000c040 in main (argc=4, argv=0x3fffea0fd208) at qemu-io.c:624 +(gdb) bt full +#0 0x000000001000e444 in refresh_total_sectors (bs=0x1fe86f60, hint=11648) at block.c:723 + drv = 0x0 +#1 0x000000001000fa10 in bdrv_open_driver (bs=0x1fe86f60, drv=0x102036f0 <bdrv_qcow2>, node_name=0x0, options=0x1fe8c240, open_flags=24578, + errp=0x3fffea0fc920) at block.c:1153 + local_err = 0x0 + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_open_driver" + __func__ = "bdrv_open_driver" +#2 0x0000000010010480 in bdrv_open_common (bs=0x1fe86f60, file=0x1fe92540, options=0x1fe8c240, errp=0x3fffea0fc920) at block.c:1395 + ret = 16383 + open_flags = 24578 + filename = 0x1fe8e2b1 "copy.img" + driver_name = 0x1fe54810 "qcow2" + node_name = 0x0 + discard = 0x0 + detect_zeroes = 0x0 + opts = 0x1fe93100 + drv = 0x102036f0 <bdrv_qcow2> + local_err = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_common" + __func__ = "bdrv_open_common" +#3 0x0000000010013ac8 in bdrv_open_inherit (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x1fe8c240, flags=24578, parent=0x0, child_role=0x0, + errp=0x3fffea0fcae0) at block.c:2616 + ret = 512 + file = 0x1fe92540 + bs = 0x1fe86f60 + drv = 0x102036f0 <bdrv_qcow2> + drvname = 0x0 + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +#4 0x0000000010013e8c in bdrv_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) at block.c:2698 +No locals. +#5 0x000000001008b6d4 in blk_new_open (filename=0x3fffea0ff661 "copy.img", reference=0x0, options=0x0, flags=16386, errp=0x3fffea0fcae0) + at block/block-backend.c:321 + blk = 0x1fe79410 + bs = 0x0 + perm = 3 +#6 0x000000001000a6ec in openfile (name=0x3fffea0ff661 "copy.img", flags=16386, writethrough=true, force_share=false, opts=0x0) at qemu-io.c:81 + local_err = 0x0 +#7 0x000000001000c040 in main (argc=4, argv=0x3fffea0fd208) at qemu-io.c:624 + 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}, { +---Type <return> to continue, or q <return> to quit--- + 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 +(gdb) +(gdb) quit + +Will attach image_fuzzer image. + + + +Hi, + +Thanks a lot for reporting this bug! 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=791fff504cad4d935df + diff --git a/results/classifier/105/instruction/1729 b/results/classifier/105/instruction/1729 new file mode 100644 index 00000000..bdae74b5 --- /dev/null +++ b/results/classifier/105/instruction/1729 @@ -0,0 +1,60 @@ +instruction: 0.929 +device: 0.875 +graphic: 0.865 +network: 0.847 +socket: 0.801 +vnc: 0.769 +assembly: 0.751 +boot: 0.616 +semantic: 0.563 +KVM: 0.397 +mistranslation: 0.373 +other: 0.235 + +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/105/instruction/1734 b/results/classifier/105/instruction/1734 new file mode 100644 index 00000000..5ad7418b --- /dev/null +++ b/results/classifier/105/instruction/1734 @@ -0,0 +1,29 @@ +instruction: 0.815 +device: 0.768 +other: 0.647 +graphic: 0.625 +semantic: 0.498 +network: 0.470 +boot: 0.468 +socket: 0.438 +vnc: 0.437 +mistranslation: 0.250 +assembly: 0.171 +KVM: 0.133 + +mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version +Description of problem: +Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. + +I created a repo with a readme, and a simple application that you can use to demonstrate the problem: +https://github.com/mwales/qemu_mmap_test + +Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. +Steps to reproduce: +1. Compile test application that mmaps entire files +2. Create 5 256MB test files +3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. +Additional information: +Lots of details on my github writeup and a demo of the bug in question. + +It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. diff --git a/results/classifier/105/instruction/1735082 b/results/classifier/105/instruction/1735082 new file mode 100644 index 00000000..55a0730a --- /dev/null +++ b/results/classifier/105/instruction/1735082 @@ -0,0 +1,42 @@ +instruction: 0.808 +vnc: 0.740 +device: 0.647 +network: 0.623 +mistranslation: 0.578 +other: 0.546 +graphic: 0.481 +semantic: 0.425 +socket: 0.384 +KVM: 0.308 +boot: 0.296 +assembly: 0.184 + +NVME pass through in th eguest VM + +Hi Qemu Team + +i am new in qemu and trying for nvme pass through .. +for that i used below git repo for nvme + +https://github.com/famz/qemu/tree/nvme + +and trying to launch the VM by below qemu command .. + +/usr/local/bin/qemu-system-x86_64 -name sl7.0 -m 1024 -object memory-backend-file,id=mem,size=1G,mem-path=/dev/hugepages,share=on -nographic -no-user-config -nodefaults -serial mon:telnet:localhost:7704,server,nowait -monitor mon:telnet:localhost:8804,server,nowait -numa node,memdev=mem -drive file=/home/qemu/qcows,format=qcow2,if=none,id=disk -device ide-hd,drive=disk,bootindex=0 -drive file=nvme://0000:d8:00.0,if=none,id=drive0 -device virtio-blk,drive=drive0,id=virtio0 --enable-kvm + +i am getting kernel panic and not proceed further..please help + +PS:- our guest VM version is + +Scientific Linux 7.0 (Nitrogen) +Kernel 3.10.0-123.el7.x86_64 on an x86_64 + +Regards +Nitin + + + +Can you reproduce the problem with the latest official upstream version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1736042 b/results/classifier/105/instruction/1736042 new file mode 100644 index 00000000..10d7fd10 --- /dev/null +++ b/results/classifier/105/instruction/1736042 @@ -0,0 +1,53 @@ +instruction: 0.828 +graphic: 0.809 +other: 0.780 +semantic: 0.715 +mistranslation: 0.678 +KVM: 0.655 +boot: 0.516 +device: 0.508 +network: 0.329 +socket: 0.280 +vnc: 0.213 +assembly: 0.149 + +qemu-system-x86_64 does not boot image reliably + +Booting image as root user with following command works randomly. + +./qemu-system-x86_64 -enable-kvm -curses -smp cpus=4 -m 8192 /root/ructfe2917_g.qcow2 + +Most of the time it ends up on "800x600 Graphic mode"(been stuck there even for 4 hours before killed), but 1 out of ~20 it boots image correctly(and instantly). + +This is visible in v2.5.0 build from sources, v2.5.0 from Ubuntu Xenial and v2.1.2 from Debian Jessie. + +The image in question was converted from vmdk using: + +qemu-img convert -O qcow2 file.vmdk file.qcow2 + +The image contains Ubuntu with grub. + +I can provide debug logs, but will need guidance how to enable them(and what logs are necessary). + +As a side note, it seems that booting is more certain after connecting(or mounting) partition using qemu-nbd/mount. + +Please always use the latest version of QEMU (currently v2.10, soon v2.11) when reporting bugs to the upstream QEMU project - we don't support old versions like v2.5 any more. So I guess you wanted to report a bug agains v2.5 in Ubuntu instead and I changed the target of this bug accordingly. + +I want a fix ;) and I do expect qemu to get it faster then Ubuntu. +So I set up Ubuntu Zesty(to fullfill dependencies) and build qemu: +QEMU emulator version 2.10.1 (v2.10.1-dirty) +and... it's still there. + +Can you tell me how and what logs to provide? + +And it still happens on: + +QEMU emulator version 2.10.93 (v2.11.0-rc3-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +This looks not a QEMU bug to me. You may drop "-curses" first, and run again. Once get inside, change grub file(/etc/default/grub) by uncomment GRUB_TERMINAL=console. It should work then. If still not, then blacklist vga16fb and add "fbcon=map:99 text" in grub command line. Remember to run update-grub after change configure file. + +Have you ever tried the suggestions from Liang Yan ? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1736655 b/results/classifier/105/instruction/1736655 new file mode 100644 index 00000000..a663f87d --- /dev/null +++ b/results/classifier/105/instruction/1736655 @@ -0,0 +1,88 @@ +instruction: 0.850 +network: 0.844 +semantic: 0.841 +mistranslation: 0.829 +device: 0.822 +other: 0.821 +vnc: 0.797 +boot: 0.797 +assembly: 0.791 +KVM: 0.784 +graphic: 0.782 +socket: 0.713 + +2k3/xp guests w/virtio-net randomly DHCP fail on boot + +Host: +Debian GNU/Linux 9 with Linux 4.13.0-0.bpo.1-amd64 +QEMU 2.10.1 + +Guest: +Windows 2003 Standard SP2 (x64) +Windows XP SP3 (i386) + +QEMU command line: +http://cfp.vim-cn.com/cbdF3 + +Description: +After upgrading from QEMU 2.8 to 2.10.1, my Windows 2003 x64 and Windows XP guests with "virtio-net-pci" NIC would randomly fail to aquire DHCP address on boot. When it fails, cycle disable/enable the connection in Control Panel could make it connect successfully. As an immediate workaround, I switched to the RTL8139 NIC which works fine. Further investigation showed that manually reverting commit '4a3f03ba8dbf53fce36d0c1dd5d0cc0f340fe5f3' on top of 2.10.1 "fixed" the problem. + +Here are the test results: +git branch 4a3f03b: 25 boots, 8 failures +git branch 39f099e: 60 boots, 0 failure +2.10.1 with revert: 194 boots, 0 failure + +Hi Patrick, +thank you so much for the report and your help to make Ubuntu better. +Also for all the bisecting that is very helpful. + +While backporting the change itself would be very trivial we need to find what the final solution has to be first. + +I checked latest upstream which is about to release 2.11 these days and there was not related change. +- no revert to this commit +- no other major disabling/fixes for ioeventfd in these cases + +That would imply that this is an issue unknown to upstream - and that means that we need to make it known there to not end up carrying a Delta forever and deriving more and more. +So we should bring it up there and find a solution for everyone. + +First of all let me try if I can reproduce it over here, then we can decide on next steps. +Very likely one of them would be to report it to upstream as well - which since you have a great bug description already they track Launchpad I can easily do for you by adding a bug Task. + +Well I see you already opened it against upstream - sorry (too early for me) - great. +Adding an Ubuntu task then to track potential fixes to take eventually. + +I wanted an XP guest testbed anyway for some time, so this was the perfect reason to create one. +# virtio drivers from [1] and otherwise a "normal" virt-manager setup of a winxp sp3 (32bit) guest + +- Modified to use virtio for net +- Modified to have the virtio drivers as floppy +- Installed virtio drivers for network afer base install + +So after that I assume I'm at the same stage you are. +- WinXP Guest +- Virtio Driver for network +- Host provides DHCP to a bridged network + +I set that to a rebot loop and checked the internet connection through the dhcp virtiop net after reboot. This worked through 10 reboots without an issue, but then IIRC with vhost ioeventfd was on all the time. + +I realized the change identified by you should only make a differenc on non-vhost virtio-net. +But libvirt will make use of vhost automatically if available, so I set the interface to use driver qemu explicitly. + +Another 10 reboots without issue - the virtio version is of 7/19/2017 version 51.75.104.14100 +There must be something more to your case, so please if you have more info how to trigger the case let us know. + +I really think I have the same case you were describing as affected by the change you identified: +$ virsh qemu-monitor-command --hmp winxp 'info network' +net0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:ce:ca:72 + \ hostnet0: index=0,type=tap,fd=26 +Here from qtree on the device [2] ioeventfd is on. + +Could you try and run it with vhost and see if this changes behavior it for you? + +[1]: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_amd64.vfd +[2]: http://paste.ubuntu.com/26123654/ + +[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/105/instruction/1737 b/results/classifier/105/instruction/1737 new file mode 100644 index 00000000..3b07da09 --- /dev/null +++ b/results/classifier/105/instruction/1737 @@ -0,0 +1,62 @@ +instruction: 0.968 +graphic: 0.919 +device: 0.848 +assembly: 0.842 +socket: 0.826 +vnc: 0.774 +network: 0.701 +semantic: 0.687 +boot: 0.686 +mistranslation: 0.642 +other: 0.581 +KVM: 0.346 + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/105/instruction/1738283 b/results/classifier/105/instruction/1738283 new file mode 100644 index 00000000..a788fd24 --- /dev/null +++ b/results/classifier/105/instruction/1738283 @@ -0,0 +1,172 @@ +instruction: 0.916 +vnc: 0.912 +graphic: 0.909 +network: 0.907 +assembly: 0.906 +device: 0.906 +semantic: 0.891 +other: 0.889 +boot: 0.885 +mistranslation: 0.883 +socket: 0.864 +KVM: 0.834 + +'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC + +If I start QEMU 2.11 (from https://build.opensuse.org/package/show/Virtualization/qemu) VM with VNC, I am unable to type following three characters: 'less than' (<), 'more than' (>), and 'pipe' (|) on en_US QWERTY keyboard. Other characters work fine. QEMu version 2.10.1 worked fine. + +/usr/bin/qemu-kvm -m 2048 -cpu kvm64 -drive media=cdrom,if=none,id=cd0,format=raw,file=OI-hipster-minimal-20171031.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -vnc :91,share=force-shared + +The ISO can be downloaded here: https://www.openindiana.org/download/ + +Also tried Fedora-Server-dvd-x86_64-25-1.3.iso and it's the same situation. + +If I run the same command without '-vnc :91,share=force-shared', everything works just fine. + +Wondering if it's a SUSE-specific problem: https://build.opensuse.org/package/view_file/Virtualization/qemu/0026-Fix-tigervnc-long-press-issue.patch?expand=1 + +Should have mention I use openSUSE Leap 42.3 with above mentioned virtualization repo. + +Removed the 0026-Fix-tigervnc-long-press-issue patch and rebuilt QEMU but no change. + +But I noticed that if I run the ISO via libvirt and connect to it via virt-manager (virt-manager-1.4.1-4.1.noarch), the keys are there as expected: + +/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=OI,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-OI/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu kvm64 -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 5664149e-26ad-4ee8-8170-16701f107b4b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-OI/monitor.sock,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 PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x3.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x3 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x3.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x3.0x2 -drive file=/var/lib/libvirt/images/OI-hipster-minimal-20171031.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -vnc 127.0.0.1:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +Connection via TigerVNC (tigervnc-1.6.0-21.1.x86_64) to the same VM is unable to write those characters. + +Well, if virt-manager is configured to run the VM with `-k en-us` I can't enter <>| even in virt-manager. keycodemapdb? + +By default virt-manager will *not* enable the '-k en-us' argument, because that forces use of a specific keyboard layout in QEMU's VNC server. For that to work, the VNC client keymap must exactly match the QEMU VNC server keymap, and must also exactly match the guest OS keymap. + +Instead virt-manager leaves off the "-k en-us" argument, which will cause the VNC servers raw scancode extension to be activated with compatible clients. Virt-manager uses GTK-VNC which activates this extension, and so passes raw XT scancodes from virt-manager to QEMU to the guest OS, which generally makes everything "just work" + +IOW, if virt-manager works correctly, but tigerVNC does not work correctly, this probably means that tigervnc is not activating the raw scancode extension. + +Hello, + +I confirm the same problem on Fedora 27 Server using Source code release 2.11.0 + +The problem remains no matter if I use the "-k en-us" parameter or not. + +Worked fine up to 2.10.1 + +If the guess is Windows, then when trying to type the "<" character then the pipe ("|") appears. + +If the guess is Linux, the same key produces the ">" character. + +Both operating systems use the US English keyboard layout. + +Thanks a lot for your time and help. + +Miguel + + + +If I start QEMU with `-k en-gb` at least '<' and '>' work, '|' doesn't (and obviously 'Shift-2' produces '"' not '@'). + +My host `locale` is 'en_US.UTF-8' top to bottom. + +I tried to update TigerVNC to 1.8 but no change. I run `vncviewer` with '-Log *:stderr:100' and QEMU without '-k' option and at least on the VNC client side it reports expected key code names. + +Aha. This looks like my bug! + +I'm running into this in what I suspect is the same situation as Michal Nowak: openQA. But in Fedora. openQA (well, its test runner, os-autoinst) works by running virtual machines and interacting with them over VNC. It seems that with qemu 2.11, typing certain characters doesn't work right, where it worked fine with 2.10. The case I ran into is the < case: when os-autoinst intends to type a < (which it does by sending the keysym for shift and then the keysym 60, for <), it winds up typing a > . This winds up causing os-autoinst's test suite to fail when attempting to build the package on Fedora Rawhide. The test suite passes on Fedora 27 (qemu 2.10). + +The qemu command in my test is: + +/usr/bin/qemu-system-i386 -serial file:serial0 -soundhw ac97 -vga cirrus -m 1024 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -device ide-drive,drive=hd1,serial=1 -drive file=raid/l1,cache=unsafe,if=none,id=hd1,format=qcow2 -drive media=cdrom,if=none,id=cd0,format=raw,file=/builddir/build/BUILD/os-autoinst-25191d50d54eaded10b6b26199bb986728dcd5c2/t/data//Core-7.2.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -smp 1 -no-shutdown -vnc :90,share=force-shared -qmp unix:qmp_socket,server,nowait -monitor unix:hmp_socket,server,nowait -S -monitor telnet:127.0.0.1:15222,server,nowait + +note there doesn't appear to be any explicit keyboard map setting there. + +Note, os-autoinst is its own VNC client. Most of the implementation can be found in https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm . The functions relevant to sending key events are `shift_keys`, `init_x11_keymap`, `map_and_send_key`, and `_send_key_event`. + +I also confirm Michal's observation of virt-manager and tigervnc behaving differently with the same VM: I ran a VM set up with VNC display server in virt-manager and can type < from the virt-manager UI fine, but if I connect to the same VM with tigervnc and try to type < , I get > . This is with current Fedora Rawhide qemu, virt-manager and tigervnc: + +qemu-common-2.11.0-1.fc28.x86_64 +virt-manager-1.4.3-2.fc28.noarch +tigervnc-1.8.0-5.fc28.x86_64 + +I found something interesting using showkey in the VM. This is all assuming en-US everywhere, note. On a US keyboard, "<" is a shifted comma (shift-,), ">" is a shifted period (shift-.), and "|" is a shifted backslash (shift-\). + +If I run showkey and try the affected characters in virt-manager, the results are kinda what I'd expect. It reports keycode 42 for the shift key, keycode 51 for comma key, keycode 52 for period key, and keycode 43 for backslash key. If I do shift-, (to get a <), it shows keycode 42 down, keycode 51 down, keycode 51 up, keycode 42 up - just what you'd expect. Ditto for > and |: it shows 42d/52d/52u/42u and 42d/43d/43u/42u in those cases. + +But if I do this while typing in tigervnc, it reports something quite different. Just pressing the keys alone gives the right codes - 51, 52, 43. But when I try the shifted combinations, it reports keycode *86* for all three keys. That is, so long as shift is held down, pressing the comma, period or backslash key reports keycode 86 - not 51, 52 or 43. Somehow this results in the generation of a > character, not sure how. + +I note this block in pc-bios/keymaps/en-us with interest: + +# evdev 86 (0x56), QKeyCode "less", number 0x56 +less 0x56 +greater 0x56 shift +bar 0x56 altgr +brokenbar 0x56 shift altgr + +That block was added in commit a7815faffb2bd594b92aa3542d7b799cc89c5414 , which I am very suspicious was the cause of this problem. I strongly suspect that removing it will fix the problem. Will test now. + +FWIW, I think this keycode represents the key between the left shift key and the first letter key on the fourth row, if there is one. European keyboards have one, and on e.g. a UK keyboard it types a \ unshifted and a | shifted - this is exactly how it looks in the en-gb keymap file: + +# evdev 86 (0x56), QKeyCode "less", number 0x56 +backslash 0x56 +bar 0x56 shift +bar 0x56 altgr +brokenbar 0x56 shift altgr + +The definition that somehow gets into the en-us keymap file appears to be actually how the key is intended to work on *German* keyboards: + +https://en.wikipedia.org/wiki/German_keyboard_layout + +Note how the key is labelled with <, > and | characters there. The French layout has the same key labelled with < and > but not |. So basically it seems like that same definition for this key shows up when you ask xkb for an en_US map. + +Bonus historical note: modern US keyboards don't have a key there at all, they're 101/104-key keyboards, where the left shift key is very wide and the key next to it is the first letter key. But *old* US keyboards, specifically the 83-key 'XT' layout, *DID* have a key there! + +https://en.wikipedia.org/wiki/IBM_PC_keyboard#/media/File:IBM_Model_F_XT.png + +From that picture, the key was labelled with \ and | characters, like a modern UK keyboard (presumably this is where the modern UK keyboard derived its use for the key from). I wonder if there's a keyboard nerd out there somewhere with a working US XT keyboard who we could ask to press that key and see what keycode it generates...:) I suppose if it's this keycode, we could arguably report a bug in xkb that for en_US, that keycode should work like a modern UK keyboard (backslash / bar / bar / brokenbar), not a modern German keyboard...:) + +Confirmed that dropping the offending keycode 86 definition out of keymaps/en-us fixes the problem. Scratch build for Fedora Rawhide was https://koji.fedoraproject.org/koji/taskinfo?taskID=23814932 , I'll probably send this out as an official build so I can get os-autoinst built without hacking up the tests, but as the files are generated by qemu-keymap just hand editing the file isn't really the 'right' solution for upstream; someone will need to tweak qemu-keymap, or else leave the keymap alone but somehow tweak the relevant bits in qemu/ui/keymaps.c and fix the problem that way. + +Note: I wondered if specifying a correct model for qemu-keymap to pass to xkb would help. But it doesn't :( That is, these: + +qemu-keymap -l us +qemu-keymap -l us -m pc101 +qemu-keymap -l us -m pc104 +qemu-keymap -l us -m pc105 + +all produce the same output except for the commented-out 'model' line at the top. It appears xkb doesn't really consider the model when deciding what keycodes to include in the generated keymap. + +I found Adam's patch from Fedora Rawhide (https://src.fedoraproject.org/rpms/qemu/c/f81be8f0261cce74799f946e99f23d57f8db7e17?branch=master) when applied to openSUSE's 2.11.0 QEMU effective in openQA as well as manually with vncviewer. + +We ran into this as well, using qemu 2.11.0. We're not using the "-k en-us" command line flag, and we're using noVNC as a client (which supports the QEMUExtendedKeyEvent encoding) + +FYI this seems to be fixed with qemu.git master, I didn't track down the specific commit but there were several keymap related changes. so qemu 2.12 will be fixed + +QEMU 2.12 has now been release, so marking this one as "Fix Released". + +Indeed the bug does not exist in this exact form any more, but it seems the stray '86' keymap entry *does* still cause problems in current qemu in one specific case: + +https://bugzilla.redhat.com/show_bug.cgi?id=1658676 + +basically, if using 'usb-kbd', we still get trouble when openQA (os-autoinst) tries to type a '<' character, because it does this: + +shift down +comma down +shift up +comma up + +(note it does *not* do shift down, comma down, comma up, shift up), and qemu gets confused and converts that into this sequence of input_event_key_qcode events: + +shift down +comma down +shift up +less up + +and that seems to mess with the key state and cause any subsequent attempts to type a '<' to go wrong. + +Removing the '86' key definition avoids the bug. + +Discussing the problem & likely solution here: + + https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04631.html + +I'm not subscribed there, so will note here: I tried the proposed changes - the commits from https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04819.html , backported to 3.0.0 - and that seems to work. A test which would previously have hit this bug ran OK, without the changes to the en-us keymap. + diff --git a/results/classifier/105/instruction/1738434 b/results/classifier/105/instruction/1738434 new file mode 100644 index 00000000..e6167f2d --- /dev/null +++ b/results/classifier/105/instruction/1738434 @@ -0,0 +1,50 @@ +instruction: 0.851 +socket: 0.767 +graphic: 0.763 +device: 0.757 +mistranslation: 0.729 +network: 0.680 +vnc: 0.670 +assembly: 0.666 +other: 0.625 +semantic: 0.586 +KVM: 0.558 +boot: 0.530 + +CALL FWORD PTR [ESP] handled incorrectly + +To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: + + push 33h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: + + push 23h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +0x23 is a default 32-bit selector for 32-bit processes running under WoW64. + +Environment: +QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img +Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 +Host OS: Windows 10 x64 version 1703 build 15063.786 + + + +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/105/instruction/1741 b/results/classifier/105/instruction/1741 new file mode 100644 index 00000000..bc8ed70e --- /dev/null +++ b/results/classifier/105/instruction/1741 @@ -0,0 +1,14 @@ +instruction: 0.892 +device: 0.843 +graphic: 0.812 +network: 0.442 +boot: 0.421 +mistranslation: 0.334 +vnc: 0.269 +other: 0.249 +socket: 0.237 +semantic: 0.190 +KVM: 0.163 +assembly: 0.117 + +95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/105/instruction/1744 b/results/classifier/105/instruction/1744 new file mode 100644 index 00000000..a821d967 --- /dev/null +++ b/results/classifier/105/instruction/1744 @@ -0,0 +1,14 @@ +instruction: 0.928 +device: 0.797 +graphic: 0.652 +semantic: 0.211 +boot: 0.121 +mistranslation: 0.103 +vnc: 0.088 +network: 0.034 +other: 0.025 +assembly: 0.022 +KVM: 0.013 +socket: 0.003 + +Divide-by-zero in virtio_gpu_simple_process_cmd diff --git a/results/classifier/105/instruction/1751422 b/results/classifier/105/instruction/1751422 new file mode 100644 index 00000000..df415ac9 --- /dev/null +++ b/results/classifier/105/instruction/1751422 @@ -0,0 +1,71 @@ +instruction: 0.738 +mistranslation: 0.597 +semantic: 0.524 +graphic: 0.506 +socket: 0.497 +other: 0.473 +device: 0.451 +vnc: 0.425 +network: 0.386 +boot: 0.348 +assembly: 0.324 +KVM: 0.292 + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. + +Could you please provide some more information about the problem? What's exactly the error? If you've already got a patch, please have a look at https://wiki.qemu.org/Contribute/SubmitAPatch to get some information how to submit it. + +The patch is In this mail attachments, which is patch for version 2.11.1 target/i386/translate.c. +The patch is created by diff. +my English is so poor to explain how the error come, but you can see the patch result to get it. + + + + + + + + +At 2018-02-25 17:41:15, "Thomas Huth" <email address hidden> wrote: +>Could you please provide some more information about the problem? What's +>exactly the error? If you've already got a patch, please have a look at +>https://wiki.qemu.org/Contribute/SubmitAPatch to get some information +>how to submit it. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1751422 +> +>Title: +> some instructions translate error in x86 +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +> The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1751422/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + +We shouldn't really have let this expire, the submitter has a patch attached to the bug. + +Yabi: do you have a simple test program which fails without this patch and works with it? If so can you attach it to the bug ? + + +I believe this to be fixed by cfcca361d77, which is present in 2.12 but not 2.11. + +Since Richard pointed out a commit which fixed this in 2.12 and we haven't heard back from the submitter, I'm going to close this bug as fixed. + + diff --git a/results/classifier/105/instruction/1751494 b/results/classifier/105/instruction/1751494 new file mode 100644 index 00000000..2e2e48a4 --- /dev/null +++ b/results/classifier/105/instruction/1751494 @@ -0,0 +1,38 @@ +instruction: 0.878 +graphic: 0.676 +assembly: 0.586 +device: 0.585 +semantic: 0.580 +mistranslation: 0.510 +other: 0.502 +socket: 0.335 +network: 0.320 +vnc: 0.279 +boot: 0.154 +KVM: 0.051 + +tcg-target.inc.c:3495:no such instruction: `xgetbv' + +While building QEMU on Mac OS 10.6.8 I saw this error message: +tag-target.inc.c:3495:no such instruction: `xgetbv' +In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: +asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); + +https://github.com/asmjit/asmjit/issues/78 +According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. + +Host info: +Mac OS 10.6.8 +GCC 5.2.0 + +Additional information: +This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. + +The exact commit that causes this problem is this: + +commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac +tcg/i386: Add vector operations + +This has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252 + diff --git a/results/classifier/105/instruction/1755912 b/results/classifier/105/instruction/1755912 new file mode 100644 index 00000000..0af9c222 --- /dev/null +++ b/results/classifier/105/instruction/1755912 @@ -0,0 +1,346 @@ +instruction: 0.841 +device: 0.839 +network: 0.836 +KVM: 0.827 +graphic: 0.826 +boot: 0.825 +mistranslation: 0.822 +socket: 0.801 +assembly: 0.761 +vnc: 0.754 +other: 0.728 +semantic: 0.708 + +qemu-system-x86_64 crashed with SIGABRT when using option -vga qxl + +When using qemu-system-x86_64 with the option -vga qxl, it crashes. The easiest way to crash it is by trying to change the guest's resolution. However, the system may randomly crash too, not happening only when changing resolution. Here is the terminal output of one of these random crashes: + +-------- + +$ qemu-system-x86_64 -hda /dev/sdb -m 2048 -enable-kvm -cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device virtio-net-pci,id=net0,netdev=hostnet0 +WARNING: Image format was not specified for '/dev/sdb' 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. + +(process:21313): Spice-WARNING **: 16:01:45.759: display-channel.c:2431:display_channel_validate_surface: canvas address is 0x7f8eb948ab18 for 0 (and is NULL) + + +(process:21313): Spice-WARNING **: 16:01:45.759: display-channel.c:2432:display_channel_validate_surface: failed on 0 + +(process:21313): Spice-CRITICAL **: 16:01:45.759: display-channel.c:2035:display_channel_update: condition `display_channel_validate_surface(display, surface_id)' failed +Abortado (imagem do núcleo gravada) + +-------- + +I was running QEMU as a normal user which is on the groups kvm and disk. Initially I supposed the problem was because I was running QEMU as root, but as a normal user this happens too. + +I have tested with guests with different Ubuntu version: 18.04, 17.10 and 16.04. It is happening with them all. + +ProblemType: Crash +DistroRelease: Ubuntu 18.04 +Package: qemu-system-x86 1:2.11+dfsg-1ubuntu4 +ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 +Uname: Linux 4.15.0-10-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Wed Mar 14 17:13:52 2018 +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2017-06-13 (273 days ago) +InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +MachineType: LENOVO 80UG +ProcCmdline: qemu-system-x86_64 -hda /dev/sdb -smp cpus=2 -m 512 -enable-kvm -cpu host -vga qxl -nodefaults -netdev user,id=hostnet0 -device virtio-net-pci,id=net0,netdev=hostnet0 +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic.efi.signed root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet +Signal: 6 +SourcePackage: qemu +StacktraceTop: + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 + () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1 +Title: qemu-system-x86_64 crashed with SIGABRT +UpgradeStatus: Upgraded to bionic on 2017-10-20 (145 days ago) +UserGroups: adm bluetooth cdrom dialout dip disk kvm libvirt lpadmin netdev plugdev sambashare sudo +dmi.bios.date: 07/10/2017 +dmi.bios.vendor: LENOVO +dmi.bios.version: 0XCN43WW +dmi.board.asset.tag: NO Asset Tag +dmi.board.name: Toronto 4A2 +dmi.board.vendor: LENOVO +dmi.board.version: SDK0J40679 WIN +dmi.chassis.asset.tag: NO Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo ideapad 310-14ISK +dmi.modalias: dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK: +dmi.product.family: IDEAPAD +dmi.product.name: 80UG +dmi.product.version: Lenovo ideapad 310-14ISK +dmi.sys.vendor: LENOVO + + + +StacktraceTop: + spice_logv (log_domain=0x7fb001524195 "Spice", args=0x7fafbf9fe600, format=0x7fb001525015 "condition `%s' failed", function=0x7fb001527ef0 <__func__.47520> "display_channel_update", strloc=0x7fb001527c0f "display-channel.c:2035", log_level=G_LOG_LEVEL_CRITICAL) at log.c:183 + spice_log (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, strloc=strloc@entry=0x7fb001527c0f "display-channel.c:2035", function=function@entry=0x7fb001527ef0 <__func__.47520> "display_channel_update", format=format@entry=0x7fb001525015 "condition `%s' failed") at log.c:196 + display_channel_update (display=0x56421590aa30, surface_id=0, area=area@entry=0x56421590ee1c, clear_dirty=1, qxl_dirty_rects=qxl_dirty_rects@entry=0x7fafbf9fe770, num_dirty_rects=num_dirty_rects@entry=0x7fafbf9fe76c) at display-channel.c:2035 + handle_dev_update_async (opaque=0x56421590ebe0, payload=0x56421590ee10) at red-worker.c:428 + dispatcher_handle_single_read (dispatcher=0x56421590e080) at dispatcher.c:284 + + + + + + + + +Subscribed Christian Ehrhardt, who might have an idea. + +Hmm, +I have no good idea unfortunately. +I tried it a few times (18.04 desktop guest 8 resolution changes) - showed no issue for me. +Is this depending on the type of guests that you run? + +I drive ti through libvirt, which adds quite some variables in the new format. +-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 +You might experiment if some of them set would mitigate your issue. + +Looking at the warnings - they are from display_channel_validate_surface but they are "safe" which means they check, detect it is null and then skips. +But maybe later on something else crashes on the same canvas being Null maybe? + +Are the warnings like: +Spice-WARNING **: 16:01:45.759: display-channel.c:2431:display_channel_validate_surface: canvas address is 0x7f8eb948ab18 for 0 (and is NULL) +appearing right before the crash or when you start? + +The crash itself seems to be: +display_channel_update -> display_channel_validate_surface (which emits the warnings) -> spice_warning -> spice_log -> spice_logv +This crashes if >= a certain log level - the warning above triggers it. +So the question is why is the canvas Null? + +2429 if (!display->priv->surfaces[surface_id].context.canvas) { +2430 spice_warning("canvas address is %p for %d (and is NULL)\n", +2431 &(display->priv->surfaces[surface_id].context.canvas), surface_id); +2432 spice_warning("failed on %d", surface_id); +2433 return FALSE; +2434 } + +handle_dev_update_async gets that value indirectly via + RedWorker *worker = opaque; + ... + display_channel_update(worker->display_channel, +So the update that kills the pointer might be anywhere in between in this async paths. +I'm not a subject matter expert on this async UI updating :-/ + +If this really affects all releases way back including the latest we should try to build you the latest from source and if it affects this as well open the bug against upstream as well. As there we need a fix/discussion first then. +Can you compile qemu from source for yourself for this check or do you need help with that. + +I was able to build it from source. In the first try I was unable to test because it hadn't the spice protocol enabled. + +The interface QEMU is using is different, as it has a menu bar with "Machine" and "View" with some options, but I could test and I could reproduce the crash. To clarify, I have recorded the VMs crashing. + +Please note I have the notebook screen and a external monitor, so the resolution is a bit strange. + +With the command: ./qemu-system-x86_64 -hda ~/Downloads/xubuntu-bionic-desktop-amd64-2018-04-22.iso -m 1536 -vga qxl -enable-kvm -cpu host -smp cpus=2 + +https://mega.nz/#!98ZiHY5b!ZOaNjb1OaZVj0V80GRjkqafOAL2UinVlAEiTP9aazdk + +With the command: ./qemu-system-x86_64 -hda ~/Downloads/xubuntu-bionic-desktop-amd64-2018-04-22.iso -m 1536 -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=0x3 -enable-kvm -cpu host -smp cpus=2 + +https://mega.nz/#!lwRDRA7I!no-6S6cWxmRf8Q8cjSWfN269PM9DISjLmN7QM6LYBC4 + +The examples are with Live ISOs, Using -cdrom (the most correct option) instead of -hda still have the same crashes. I can reproduce with a installed VM and with a physical system started in QEMU. + +Additional effects I've seen are the guests freezing instead of crashing and a significant RAM memory peak when starting the VM using libvirt. If high amounts of memory are being used in the moment the VM is started, approximately 128 MB of memory goes to SWAP that is never freed. The only way to freed it is to umount the SWAP partition (I tested until SWAP had 658 MB of memory). + +What I meant is that with a Bionic host, the guests crash regardless of what the guest is. For now I've tested only with Ubuntu and its derivatives, from 12.04 to 18.04 and they consistently have the issue. I'm downloading CentOS but the download is slow, so it will take some time. I will add the CentOS guest test results after I test it. + +The download of CentOS 7 was finished and I downloaded Fedora Workstation 27 later. With both as guests the VM still crash, so it's not a issue exclusive to Ubuntu guests. + +The crash may happen after 8 resolution changes (CentOS) or in the first one (Fedora 27) or if the system is running and suddenly crashes (Xubuntu 17.10 in a external HDD). + +Thanks Leonardo, with that confirmed: +- not dependent on the guest distribution +- affecting latest upstream +- good logs on the crash + +The videos are not needed but nice to proove your case (just as my pre-analysis of the code path is nice but likely not useful to a developer that regularly works on that code sections). + +Overall this should really be ready for upstreams attention, I added a Qemu task which will auto mirror this to the Mailing list. + +The bug traces so far had no private information, so I opened up the state to be visible to everyone. + +QEMU from git apparently is fixed, but Ubuntu's version is still problematic. + +Using an Xubuntu 18.04 guest, it's possible to reproduce the crash using: + +while true ; do xrandr --output Virtual-0 --mode 640x480 ; sleep 1 ; xrandr --output Virtual-0 --mode 1280x720 ; sleep 1 ; xrandr --output Virtual-0 --mode 1920x1080 ; sleep 1 ; done + +In less than 20 seconds the guest crash with: + +(process:16447): Spice-CRITICAL **: 15:34:52.047: display-channel.c:2035:display_channel_update: condition `display_channel_validate_surface(display, surface_id)' failed +Abortado (imagem do núcleo gravada) + +Very interesting, Still not triggering for me :-/ +Could you check if the PPA in [1] (with qemu 2.12 planned for Cosmic) already fixes it for you? + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3306/+packages + +Link is better as https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3306 + +Unfortunately it did not work, the error is still the same although it used the GTK interface this time. The command I used was: + +$ qemu-system-x86_64 -vga qxl -enable-kvm -cpu host -smp cores=2,threads=2 -m 2048 -cdrom xubuntu-18.04-desktop-amd64.iso + +I have noticed Ubuntu's QEMU and this QEMU don't have the OpenGL option enabled, may this be related to the issue? + +Yeah we switched to gtk. +With OpenGL which do you mean - the virtgl based support or some other config option? + +Since it still fails to reproduce for me, but you already have a self build qemu that is good. +Could you based on this build 2.12 from source as well and confirm that it fails. +If it does you could bisect from 2.12 to master what fixed it so that we can consider that patch. +Otherwise if 2.12 from source in your own build works lets take a look at the build options that you mentioned. + +I meant the option --enable-opengl and, for old versions, --enable-gtk-gl. I know it is required to use virtual machines using Intel GVT-g with dma-buf, and is a option strangely absent from QEMU configuration from Ubuntu's build. Without it, virgl fails too, making virt-manager have an option that does not work (under Spice Display, OpenGL option does not work). + +The 2.12 build does crash when tested. That while loop is pretty efficient to trigger it. The git version can keep running it for hours straight with no problem, while the problematic versions crash in seconds. + +As QEMU configuration is a result mixed between packages found automatically and those manually set by me, here is the configure command and its results from my QEMU build: https://paste.ubuntu.com/p/z9vnFdTnkD/ + +Please note that I had no need to build other targets for my use, so the configuration is much smaller than the one used by Ubuntu's QEMU. + +The bisect is done and this is the result: + +5bd5c27c7d284d01477c5cc022ce22438c46bf9f is the first new commit +commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f +Author: Gerd Hoffmann <email address hidden> +Date: Fri Apr 27 13:55:28 2018 +0200 + + qxl: fix local renderer crash + + Make sure we only ask the spice local renderer for display updates in + case we have a valid primary surface. Without that spice is confused + and throws errors in case a display update request (triggered by + screendump for example) happens in parallel to a mode switch and hits + the race window where the old primary surface is gone and the new isn't + establisted yet. + + Cc: <email address hidden> + Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733 + Signed-off-by: Gerd Hoffmann <email address hidden> + Reviewed-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + +:040000 040000 ed86f864314483660b3c2abe045361ae7c98a5dc f0d55b3e98dd0864d6686fba052d83ae5545d007 M hw + + +Nice, thanks Leonardo for the Bisect - lets call upstream Fixed Committed then (as there is no 2.13 released yet). + +For the separate gl discussion feel free to subscribe/chime in on bug 1657409 + +Currently 2.12 is on its way into Cosmic. +I'll add and test that patch afterwards, it looks small and safe to me. + +This bug was fixed in the package qemu - 1:2.12+dfsg-3ubuntu3 + +--------------- +qemu (1:2.12+dfsg-3ubuntu3) cosmic; urgency=medium + + * d/p/lp-1755912-qxl-fix-local-renderer-crash.patch: Fix an issue triggered + by migrations with UI frontends or frequent guest resolution changes + (LP: #1755912) + + -- Christian Ehrhardt <email address hidden> Thu, 19 Jul 2018 08:26:52 +0200 + +Working on Bionic SRu prep in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3367/+packages + +Hello Leonardo, 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.5 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! + +Thank you for the effort to backport this bug fix, I have tested the proposed version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5) and the crash when changing resolution is no longer happening. Unfortunately, after some time (about 10 minutes, much longer than without this fix), the guest freezes. + +I reported that in https://bugs.launchpad.net/qemu/+bug/1787070 + +I'll change the tag to verification-done-bionic, as this particular issue was corrected. The other issue still exists in QEMU upstream. + +Note: The code change already passed the general regression checks on the identical content against a PPA (Also on the weekend prior to the full maturing period I'll have another automated run on proposed). + +Running the Bionic ISO like: +$ qemu-system-x86_64 -cpu host -smp cores=4,threads=2 -boot d -m 2048 -enable-kvm -vga qxl -vnc :21 -cdrom ubuntu-18.04-desktop-amd64.iso + +Attaching like: +$ vncviewer FullColor=1 AutoSelect=0 10.245.168.42:5921 +(alternatives on tigervnc) +Well for me it had "-k de" as well :-) + +Then boot into the "try Ubuntu" live CD mode. +There opened a terminal to loop on xrandr. + +Running the loop of above in that guest to crash it after a while. + + + +Upgrade to proposed: +$ sudo apt install qemu-system-x86=1:2.11+dfsg-1ubuntu7.5 +Reading package lists... Done +Building dependency tree +Reading state information... Done +Suggested packages: + samba vde2 qemu-block-extra sgabios ovmf +The following packages will be upgraded: + qemu-system-x86 +1 upgraded, 0 newly installed, 0 to remove and 16 not upgraded. +Need to get 5.168 kB of archives. +After this operation, 0 B of additional disk space will be used. +Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 qemu-system-x86 amd64 1:2.11+dfsg-1ubuntu7.5 [5.168 kB] +Fetched 5.168 kB in 1s (7.666 kB/s) +(Reading database ... 127990 files and directories currently installed.) +Preparing to unpack .../qemu-system-x86_1%3a2.11+dfsg-1ubuntu7.5_amd64.deb ... +Unpacking qemu-system-x86 (1:2.11+dfsg-1ubuntu7.5) over (1:2.11+dfsg-1ubuntu7.4) ... +Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu7.5) ... +Processing triggers for man-db (2.8.3-2ubuntu0.1) ... + + +Running the loop again with the same setup - no crash in 15 minutes - assume that means good now. +I'd be glad about someone else checking the result as well, best someone formerly affected by it. +(and having a tick in the eye for seeing my right screen change sizes and flicker all the time) + +Setting verified + +Thanks Leonardo for your check as well! +I agree that this particular issue here is fixed as we hoped. +The other one with the freeze did not occur for me, you might open another bug if you have any pointers how we could go on on this. + +Arr reading is hard today, you had the other bug open already ... grml :-) + +Never the less - This bug here is fixed in the proposed version and for now that is the important part. + +Subscribed there as well now to stay on top of it if upstream gets to a conclusion. + +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.11+dfsg-1ubuntu7.5 + +--------------- +qemu (1:2.11+dfsg-1ubuntu7.5) bionic; urgency=medium + + [Christian Ehrhardt] + * d/p/lp-1755912-qxl-fix-local-renderer-crash.patch: Fix an issue triggered + by migrations with UI frontends or frequent guest resolution changes + (LP: #1755912) + + [ Murilo Opsfelder Araujo ] + * d/p/ubuntu/target-ppc-extend-eieio-for-POWER9.patch: Backport to + extend eieio for POWER9 emulation (LP: #1787408). + + -- Christian Ehrhardt <email address hidden> Tue, 21 Aug 2018 11:25:45 +0200 + diff --git a/results/classifier/105/instruction/1756927 b/results/classifier/105/instruction/1756927 new file mode 100644 index 00000000..3ec2692a --- /dev/null +++ b/results/classifier/105/instruction/1756927 @@ -0,0 +1,47 @@ +instruction: 0.816 +device: 0.753 +boot: 0.666 +mistranslation: 0.622 +semantic: 0.554 +graphic: 0.551 +network: 0.531 +vnc: 0.523 +socket: 0.491 +assembly: 0.407 +KVM: 0.400 +other: 0.370 + +ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT + +When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception. + +You'll find attached a minimal example to reproduce the issue (just run 'make all'). +The output I get is: + +supervisor +user +prefetch +short-descriptor + +The last entry should read 'long-descriptor'. + + +Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69 +Ubuntu verison: 16.04 LTS +Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi + + + +I've just sent this patchset: +http://<email address hidden>/ +which should fix this bug and a couple of others that I noticed with our debug exception handling while I was doing that. + + +thanks Peter ! Any news on the review ? + +The patches are in master now. + + +Hi Peter, +we tested the fix and it work correctly now, thank you very much ! + diff --git a/results/classifier/105/instruction/1759333 b/results/classifier/105/instruction/1759333 new file mode 100644 index 00000000..4b1467a0 --- /dev/null +++ b/results/classifier/105/instruction/1759333 @@ -0,0 +1,34 @@ +instruction: 0.801 +device: 0.737 +graphic: 0.659 +semantic: 0.549 +network: 0.494 +vnc: 0.478 +socket: 0.475 +boot: 0.429 +other: 0.427 +mistranslation: 0.382 +assembly: 0.244 +KVM: 0.205 + +Illegal Instruction with HVF when encountering SSE instructions in the emulator + +The latest version of QEMU doesn't seem to support emulated SSE instructions with HVF acceleration on macOS. +The decoder will treat SSE instructions as invalid, get the instruction sizes wrong and quickly crash the guest OS because of illegal instructions. +After having a quick look at target/i386/hvf/x86_decode.c, it seems that SSE instruction emulation isn't implemented in the current version of the x86 emulator. + +A way to reproduce the issue is to run a macOS 10.13 guest with HVF acceleration enabled, this will crash once it's loading up the GUI. + +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. + +Thomas, I think the issue is there. SSE/MMX weren't yet added for HVF. + + +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/150 + + diff --git a/results/classifier/105/instruction/1762707 b/results/classifier/105/instruction/1762707 new file mode 100644 index 00000000..aac80a2d --- /dev/null +++ b/results/classifier/105/instruction/1762707 @@ -0,0 +1,51 @@ +instruction: 0.855 +graphic: 0.853 +device: 0.846 +other: 0.823 +socket: 0.753 +semantic: 0.752 +mistranslation: 0.751 +assembly: 0.750 +network: 0.740 +KVM: 0.608 +vnc: 0.594 +boot: 0.524 + +VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem + +Is there any known conflict between VFIO passthrough device and virtio-balloon? + +The VM has: +1. 4GB system memory +2. one VFIO passthrough device which supports high address memory DMA and uses GFP_HIGHUSER pages. +3. Memory balloon device with 4GB target. + +When setting the memory balloon target to 1GB and 4GB in loop during runtime (I used the command "virsh qemu-monitor-command debian --hmp --cmd balloon 1024"), the VFIO device DMA randomly gets failure. + +More clues: +1. configure 2GB system memory (no highmem) VM, no issue with similar operations +2. setting the memory balloon to higher like 8GB, no issue with similar operations + +I'm also trying to narrow down this issue. It's appreciated for that you guys may share some thoughts. + +Ballooning is currently incompatible with device assignment. When the balloon is inflated (memory removed from the VM), the pages are zapped from the process without actually removing them from the vfio DMA mapping. The pages are still pinned from the previous mapping, making the balloon inflation ineffective (pages are not available for re-use). When the balloon is deflated, new (different) pages are faulted in for the previously zapped pages, but these are again not DMA mapped for the IOMMU, so now the physical memory backing a given address in the VM are different for processor and assigned device access and DMA will fail. In order to support this, QEMU would need to do more than simply zap pages from the process address space, they'd need to be unmapped from the IOMMU, but we can only do that using the original mapping size. Effectively, memory hotplug is a better solution when device assignment is involved. + +Hi Alex, Thanks for your confirming. change the status to invalid. + +I think we can raise this issue to libvirt. When using virsh or virt-manager, the memory balloon is still enabled by default even if there's a device assignment. + +Alex, I see this issue is closed but I have a question, do you know if the problem only comes the balloon is resized to return memory to the host. I ask because we have a situation where we will start a VM with balloon enabled, and later it maybe possible a devices is assigned via hot-plug. So I would like to avoid this issue by doing the following: + +if a vfio devices is assigned; + resize the balloon size the the maximal guest memory +end + +Then because we know we added a vfio devices never resize the balloon to return memory again. + +More information about what we want to do: https://github.com/kata-containers/runtime/pull/793 + +Regards, +Carlos + +There are two scenarios here, if we have a regular, directly assigned physical device (including VFs), vfio's page pinning will populate the full memory footprint of the guest regardless of the balloon. The balloon is effectively fully deflated, but the balloon driver in the guest hasn't released the pages back for guest kernel use. In that case marking the balloon as deflated at least allows those pages to be used since they're allocated. However, if the assigned device is an mdev device, then the pages might only be pinned on usage, depending on the vendor driver, and pages acquired by the guest balloon driver are unlikely to be used by the in-guest driver for the device. It's always possible that the mdev vendor driver could pin them anyway, but there is a chance that those pages are actually still freed to the host until that point. Latest QEMU will of course enable the balloon inhibitor for either case so further balloon inflation will no longer zap pages. + diff --git a/results/classifier/105/instruction/1767176 b/results/classifier/105/instruction/1767176 new file mode 100644 index 00000000..fa77b788 --- /dev/null +++ b/results/classifier/105/instruction/1767176 @@ -0,0 +1,64 @@ +instruction: 0.868 +other: 0.863 +device: 0.849 +semantic: 0.843 +network: 0.838 +graphic: 0.822 +boot: 0.816 +vnc: 0.812 +socket: 0.810 +mistranslation: 0.749 +KVM: 0.749 +assembly: 0.724 + +GTK build fails with qemu 2.12.0 + +With the 2.12.0 release of QEMU passing `--enable-gtk` to configure causes the build to fail. I'm running macOS 10.13.5 with Xcode 9.3 FWIW. + +I'm building against GTK 2.24.32, which I appreciate is no longer the preferred version here, but I don't think the error is related to that aspect. I'll try and find the time later to attempt a GTK3 build to check that though. + +``` +ui/gtk.c:1147:16: error: use of undeclared identifier 'qemu_input_map_osx_to_qcode'; did you mean 'qemu_input_map_usb_to_qcode'? + return qemu_input_map_osx_to_qcode; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + qemu_input_map_usb_to_qcode +/private/tmp/qemu-20180426-60786-1av6pq8/qemu-2.12.0/include/ui/input.h:99:22: note: 'qemu_input_map_usb_to_qcode' declared here +extern const guint16 qemu_input_map_usb_to_qcode[]; + ^ +``` + +I tried poking around locally by applying the following diff, based off of a very brief glance over the code involved, but that simply causes the build to error out in a different way at a later point, so I assume I'm doing something stupid. + + +``` +diff --git a/Makefile b/Makefile +index d71dd5b..e857c3c 100644 +--- a/Makefile ++++ b/Makefile +@@ -313,6 +313,7 @@ KEYCODEMAP_FILES = \ + ui/input-keymap-qnum-to-qcode.c \ + ui/input-keymap-usb-to-qcode.c \ + ui/input-keymap-win32-to-qcode.c \ ++ ui/input-keymap-osx-to-qcode.c \ + ui/input-keymap-x11-to-qcode.c \ + ui/input-keymap-xorgevdev-to-qcode.c \ + ui/input-keymap-xorgkbd-to-qcode.c \ +diff --git a/include/ui/input.h b/include/ui/input.h +index 16395ab..8183840 100644 +--- a/include/ui/input.h ++++ b/include/ui/input.h +@@ -101,6 +101,9 @@ extern const guint16 qemu_input_map_usb_to_qcode[]; + extern const guint qemu_input_map_win32_to_qcode_len; + extern const guint16 qemu_input_map_win32_to_qcode[]; + ++extern const guint qemu_input_map_osx_to_qcode_len; ++extern const guint16 qemu_input_map_osx_to_qcode[]; ++ + extern const guint qemu_input_map_x11_to_qcode_len; + extern const guint16 qemu_input_map_x11_to_qcode[]; +``` + +Reproduces with GTK+3 rather than GTK+ as expected, FWIW. + +Resolved via https://git.qemu.org/?p=qemu.git;a=patch;h=656282d245b49b84d4a1a47d7b7ede482d541776, FYI. + diff --git a/results/classifier/105/instruction/1768 b/results/classifier/105/instruction/1768 new file mode 100644 index 00000000..49df8f75 --- /dev/null +++ b/results/classifier/105/instruction/1768 @@ -0,0 +1,45 @@ +instruction: 0.897 +mistranslation: 0.839 +graphic: 0.794 +device: 0.756 +assembly: 0.541 +vnc: 0.511 +semantic: 0.438 +network: 0.338 +socket: 0.336 +other: 0.318 +boot: 0.307 +KVM: 0.084 + +Could not allocate more than ~2GB with qemu-user +Description of problem: +On qemu-user, failed to allocate more than about 2GB on 32bit platform supporting up to 4GB (arm, ppc, etc.) +Steps to reproduce: +1. Try to allocate more than 2GB [e.g. for(i=0;i<64;i++) if(malloc(64*1024*1024)==NULL) perror("Failed to allocate 64MB");] +2. Only 1 64MB chunck is allocated in the upper 2GB memory space +3. Failed to allocate after about 2GB. +Additional information: +The problem is in **pageflags_find** and **pageflags_next** functions (found in _accel/tcg/user-exec.c_) 3rd parameters, that should be **target_ulong** instead of incorrect _target_long_ (the parameter will be converted signed extended to uint64_t). +The testing program is the following: +``` +#include <stdio.h> +#include <stdlib.h> + +int main(int argc,char *argv[]) { + unsigned int a; + unsigned int i; + char *al; + unsigned int sss=1U*1024*1024*64; + for(a=0;a<128;a++) { + al=malloc(sss); + if(al!=NULL) { + printf("ALLOC OK %u (%08lX)!\n",sss*(a+1),al); + } + else { + printf("Cannot alloc %d\n",(a+1)*sss); + perror("Cannot alloc"); + exit(1); + } + } +} +``` diff --git a/results/classifier/105/instruction/1771 b/results/classifier/105/instruction/1771 new file mode 100644 index 00000000..3195f46f --- /dev/null +++ b/results/classifier/105/instruction/1771 @@ -0,0 +1,46 @@ +instruction: 0.977 +graphic: 0.917 +device: 0.843 +socket: 0.778 +semantic: 0.749 +vnc: 0.729 +network: 0.581 +boot: 0.572 +other: 0.534 +mistranslation: 0.523 +assembly: 0.491 +KVM: 0.118 + +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/105/instruction/1771570 b/results/classifier/105/instruction/1771570 new file mode 100644 index 00000000..543655b2 --- /dev/null +++ b/results/classifier/105/instruction/1771570 @@ -0,0 +1,40 @@ +instruction: 0.671 +other: 0.667 +device: 0.647 +semantic: 0.634 +graphic: 0.544 +mistranslation: 0.467 +socket: 0.435 +network: 0.434 +boot: 0.344 +vnc: 0.296 +KVM: 0.121 +assembly: 0.096 + +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/105/instruction/1771948 b/results/classifier/105/instruction/1771948 new file mode 100644 index 00000000..636db688 --- /dev/null +++ b/results/classifier/105/instruction/1771948 @@ -0,0 +1,51 @@ +instruction: 0.898 +other: 0.852 +graphic: 0.837 +semantic: 0.818 +device: 0.763 +network: 0.610 +vnc: 0.606 +socket: 0.601 +mistranslation: 0.540 +assembly: 0.504 +boot: 0.482 +KVM: 0.408 + +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/105/instruction/1775011 b/results/classifier/105/instruction/1775011 new file mode 100644 index 00000000..e91c4fe2 --- /dev/null +++ b/results/classifier/105/instruction/1775011 @@ -0,0 +1,37 @@ +instruction: 0.880 +graphic: 0.870 +boot: 0.767 +device: 0.728 +other: 0.623 +mistranslation: 0.555 +semantic: 0.530 +vnc: 0.369 +network: 0.363 +socket: 0.317 +assembly: 0.197 +KVM: 0.130 + +-display gtk,gl=on crashes on Wayland + +steps to reproduce: + +1. run a Wayland compositor (I use sway, probably the same bug exists for other compositors) +2. execute qemu -display gtk,gl=on + +expected results: + +a GTK window is created that shows SeaBIOS failing to boot + +actual results: + +segmentation fault qemu-system-x86_64 -display gtk,gl=on + +additional information: + +qemu version 2.12.0 from Arch Linux + +looks like qemu is trying to take the Wayland display from GTK and initialize EGL but telling EGL it's a X11 display, which is not correct. setting GDK_BACKEND=x11 works around the issue. + +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. + diff --git a/results/classifier/105/instruction/1776486 b/results/classifier/105/instruction/1776486 new file mode 100644 index 00000000..ac7ec2ea --- /dev/null +++ b/results/classifier/105/instruction/1776486 @@ -0,0 +1,27 @@ +instruction: 0.739 +device: 0.712 +KVM: 0.706 +boot: 0.654 +graphic: 0.616 +vnc: 0.603 +semantic: 0.532 +mistranslation: 0.494 +other: 0.487 +network: 0.443 +socket: 0.430 +assembly: 0.304 + +detect error when kernel and initrd images exceed ram size + +I was unable to figure out why my VM wasn't booting when I added a "-initrd" image. I would launch qemu and get no output, and no error message, it would just spin. + +Turns out my initrd image was around 270 MB but I wasn't giving an explicit ram size to qemu. I was told the default memory size was around 120 MB so this was definitely a problem. I think that the qemu "pseudo-bootloader" should detect when the kernel image and initrd image sizes exceed the size of ram and print a nice error to the user, something like: + +Error: the total size of the given boot images (342M) exceeds the size allocated for memory (120M) + +We could also do a better job of identifying when different things (initrd, kernel, dtb) overlap in memory. + + +As of the 4.1 release we should now do a better job of identifying overlaps between initrd, kernel, end of ram, etc, for the built-in arm bootloader. + + diff --git a/results/classifier/105/instruction/1777786 b/results/classifier/105/instruction/1777786 new file mode 100644 index 00000000..315a2e2f --- /dev/null +++ b/results/classifier/105/instruction/1777786 @@ -0,0 +1,68 @@ +instruction: 0.595 +device: 0.477 +graphic: 0.474 +boot: 0.362 +other: 0.339 +semantic: 0.322 +KVM: 0.314 +mistranslation: 0.311 +network: 0.290 +assembly: 0.261 +vnc: 0.233 +socket: 0.231 + +virtio-gpu-3d.c: change virtio_gpu_fence_poll timer scale + +We use virtio-gpu to accelerate Unigine Heaven Benchmark in VM. But we get only 5 FPS when we use AMD RX460 in our host. +We found that guest os spent a lot of time in waiting for the return of glMapBufferRange/glUnmapBuffer commad. We suspected the host GPU was waiting for fence. So we finally change the timer of fence_poll. Afer change timer from + ms to us， Benchmark result raise up to 22 FPS. + +From a4003af5c4fe92d55353f42767d0c45de95bb78f Mon Sep 17 00:00:00 2001 +From: chen wei <email address hidden> +Date: Fri, 8 Jun 2018 17:34:45 +0800 +Subject: [PATCH] virtio-gpu:improve 3d performance greatly + + opengl function need fence support.when CPU execute opengl function, it need wait fence for synchronize GPU. +so qemu must deal with fence timely as possible. but now the expire time of the timer to deal with fence is 10 ms. +I think it is too long for opengl. So i will change it to 20 ns. + Before change, when i play Unigine_Heaven 3d game with virglrenderer, the fps is 3. atfer change the fps up to 23. + +Signed-off-by: chen wei <email address hidden> +Signed-off-by: wang qiang <email address hidden> +--- + hw/display/virtio-gpu-3d.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c +index 3558f38..c0a5d21 100644 +--- a/hw/display/virtio-gpu-3d.c ++++ b/hw/display/virtio-gpu-3d.c +@@ -582,7 +582,7 @@ static void virtio_gpu_fence_poll(void *opaque) + virgl_renderer_poll(); + virtio_gpu_process_cmdq(g); + if (!QTAILQ_EMPTY(&g->cmdq) || !QTAILQ_EMPTY(&g->fenceq)) { +- timer_mod(g->fence_poll, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 10); ++ timer_mod(g->fence_poll, qemu_clock_get_us(QEMU_CLOCK_VIRTUAL) + 20); + } + } + +@@ -629,7 +629,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g) + return ret; + } + +- g->fence_poll = timer_new_ms(QEMU_CLOCK_VIRTUAL, ++ g->fence_poll = timer_new_us(QEMU_CLOCK_VIRTUAL, + virtio_gpu_fence_poll, g); + + if (virtio_gpu_stats_enabled(g->conf)) { +-- +2.7.4 + + + +Please don't use the bug tracker for providing patches, and send it to the mailing list instead, see: https://wiki.qemu.org/Contribute/SubmitAPatch + +Did you ever send your patch to the mailing list for discussion? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1778473 b/results/classifier/105/instruction/1778473 new file mode 100644 index 00000000..8530c885 --- /dev/null +++ b/results/classifier/105/instruction/1778473 @@ -0,0 +1,151 @@ +instruction: 0.870 +device: 0.842 +graphic: 0.838 +other: 0.832 +assembly: 0.819 +KVM: 0.814 +boot: 0.794 +socket: 0.775 +semantic: 0.773 +mistranslation: 0.710 +vnc: 0.707 +network: 0.695 + +[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/105/instruction/1780 b/results/classifier/105/instruction/1780 new file mode 100644 index 00000000..354a178d --- /dev/null +++ b/results/classifier/105/instruction/1780 @@ -0,0 +1,30 @@ +instruction: 0.971 +graphic: 0.882 +device: 0.724 +network: 0.589 +semantic: 0.561 +vnc: 0.436 +boot: 0.398 +socket: 0.311 +assembly: 0.172 +mistranslation: 0.130 +other: 0.041 +KVM: 0.040 + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/105/instruction/1781281 b/results/classifier/105/instruction/1781281 new file mode 100644 index 00000000..c749479f --- /dev/null +++ b/results/classifier/105/instruction/1781281 @@ -0,0 +1,65 @@ +instruction: 0.853 +graphic: 0.844 +other: 0.720 +vnc: 0.696 +mistranslation: 0.687 +semantic: 0.664 +device: 0.614 +assembly: 0.496 +network: 0.469 +socket: 0.462 +boot: 0.421 +KVM: 0.323 + +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/105/instruction/1782107 b/results/classifier/105/instruction/1782107 new file mode 100644 index 00000000..76193cf0 --- /dev/null +++ b/results/classifier/105/instruction/1782107 @@ -0,0 +1,48 @@ +instruction: 0.647 +other: 0.641 +graphic: 0.637 +device: 0.590 +semantic: 0.550 +network: 0.491 +mistranslation: 0.404 +socket: 0.338 +vnc: 0.311 +boot: 0.303 +KVM: 0.284 +assembly: 0.277 + +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/105/instruction/1786 b/results/classifier/105/instruction/1786 new file mode 100644 index 00000000..3e0a4b67 --- /dev/null +++ b/results/classifier/105/instruction/1786 @@ -0,0 +1,37 @@ +instruction: 0.880 +graphic: 0.785 +device: 0.759 +network: 0.560 +semantic: 0.536 +mistranslation: 0.498 +socket: 0.494 +vnc: 0.467 +assembly: 0.464 +boot: 0.409 +KVM: 0.273 +other: 0.236 + +Impossible to create an uncompressed QCOW2 disk +Description of problem: +An QCOW2 image is created compressed unconditionally. There is no way to disable compression, albeit the QCOW format specification allows this. + +``` +$ qemu-img --version +qemu-img version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-img create -f qcow2 test.qcow2 1G +Formatting 'test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +$ +``` + +Same is applicable for 8-x qemu-img version (I built it for testing purposes) +``` +$ ./build/qemu-img create -f qcow2 disk.qcow2 1G +Formatting 'disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +$ ./build/qemu-img --version +qemu-img version 8.0.90 (v8.1.0-rc0-21-gd1181d2937) +Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers +$ +``` +Steps to reproduce: +Create a QCOW2 disk with `qemu-img` of never versions. diff --git a/results/classifier/105/instruction/1788 b/results/classifier/105/instruction/1788 new file mode 100644 index 00000000..0f39860e --- /dev/null +++ b/results/classifier/105/instruction/1788 @@ -0,0 +1,42 @@ +instruction: 0.965 +device: 0.884 +other: 0.878 +graphic: 0.868 +semantic: 0.861 +network: 0.795 +vnc: 0.790 +assembly: 0.750 +boot: 0.728 +socket: 0.726 +KVM: 0.711 +mistranslation: 0.593 + +Floating point rounding fails on mps3-an547 amd cortex-m55 while using LLVM-embedded-toolchain-for-Arm and Picolibic. +Description of problem: +Rounding of long double gives unexpected result. Simple code as example: +``` +#include <math.h> +int main(void) +{ + long double value = -8.5L; + long rounded_value = lrintl(value); + if( -8 == rounded_value ) + { + return 0; + } + return 1; +} +``` +Steps to reproduce: +1. Checkout project: [LLVM-embedded-toolchain-for-ARM](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm) +2. Configure it with option -DLLVM_TOOLCHAIN_LIBRARY_VARIANTS=armv8.1m.main_hard_nofp_mve +3. Build project +4. Run Picolbic tests with ninja picolibc_armv8.1m.main_hard_nofp_mve-test + +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. +Additional information: +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. diff --git a/results/classifier/105/instruction/1790 b/results/classifier/105/instruction/1790 new file mode 100644 index 00000000..2a0a409b --- /dev/null +++ b/results/classifier/105/instruction/1790 @@ -0,0 +1,42 @@ +instruction: 0.969 +graphic: 0.821 +boot: 0.809 +semantic: 0.738 +device: 0.730 +mistranslation: 0.585 +assembly: 0.543 +network: 0.505 +vnc: 0.500 +other: 0.437 +socket: 0.425 +KVM: 0.068 + +[AARCH64] STGP instruction is not writing the value of the second register to memory +Description of problem: +My application is built with Clang 16 and the option -fsanitize=memtag-stack. +It means the the MTE protection is activated for the stack. +The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory. +The following instruction was not working as expected: + 18004: 69000895 stgp x21, x2, [x4] +The value of the second register x2 is not transferred to the memory. +Only x21 is written. + +I think that the issue is in trans_STGP(). +We don't call finalize_memop_pair() like we do for in the general trans_STP(). + +``` +diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c +index 7d0c8f79a7..f599f3e136 100644 +--- a/target/arm/tcg/translate-a64.c ++++ b/target/arm/tcg/translate-a64.c +@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a) + + tcg_rt = cpu_reg(s, a->rt); + tcg_rt2 = cpu_reg(s, a->rt2); ++ mop = a->sz + 1; ++ mop = finalize_memop_pair(s, mop); + + assert(a->sz == 3); +``` + +With this fix, my OS (Kinibi) is now able to boot. diff --git a/results/classifier/105/instruction/1792 b/results/classifier/105/instruction/1792 new file mode 100644 index 00000000..6613b27c --- /dev/null +++ b/results/classifier/105/instruction/1792 @@ -0,0 +1,94 @@ +instruction: 0.710 +other: 0.708 +network: 0.671 +assembly: 0.662 +socket: 0.654 +device: 0.636 +boot: 0.631 +KVM: 0.627 +semantic: 0.615 +vnc: 0.612 +graphic: 0.560 +mistranslation: 0.313 + +qemu-8.1-rc1 and rc0 fail build. 8.0 is fine +Description of problem: +Build error with 8.1.0-rc0 and 8.1.0-rc1. +Build of 8.0.3 works correctly, using the same build configuration. +Steps to reproduce: +1. Run configure as below in logs +2.`/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3 -m ensurepip --upgrade --default-pip` +3. +Additional information: +``` +$ s/build qemu:host +CLEAN qemu + * Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc0 ... + * Removing /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/qa_checks/qemu-* ... +UNPACK qemu +BUILD qemu (host) + TOOLCHAIN configure +Executing (host): /var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/configure --bindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin --extra-cflags=-I/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/include --extra-ldflags=-L/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --libexecdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib --localstatedir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/var --prefix=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain --sbindir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/sbin --sysconfdir=/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/etc --enable-tools --enable-malloc=system --disable-attr --disable-auth-pam --disable-install-blobs --disable-capstone --disable-curl --disable-debug-info --disable-debug-mutex --disable-debug-tcg --disable-docs --disable-gcrypt --disable-gnutls --disable-system --disable-user --disable-vnc --disable-werror --disable-xkbcommon --disable-zstd +python determined to be '/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/bin/python3' +python version: Python 3.11.4 +mkvenv: Creating non-isolated virtual environment at 'pyvenv' +mkvenv subprocess failed: +cmd: ['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip'] +returncode: 1 +========== stdout ========== +Looking in links: /tmp/tmpio395oka +Processing /tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl +Processing /tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl +Installing collected packages: setuptools, pip +ERROR: Exception: +Traceback (most recent call last): + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/base_command.py", line 169, in exc_logging_wrapper + status = run_func(*args) + ^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/cli/req_command.py", line 248, in wrapper + return func(self, options, args) + ^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/commands/install.py", line 449, in run + installed = install_given_reqs( + ^^^^^^^^^^^^^^^^^^^ + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/__init__.py", line 72, in install_given_reqs + requirement.install( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/req/req_install.py", line 800, in install + install_wheel( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 731, in install_wheel + _install_wheel( + File "/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 620, in _install_wheel + assert os.path.exists(pyc_path) +AssertionError +Traceback (most recent call last): + File "<frozen runpy>", line 198, in _run_module_as_main + File "<frozen runpy>", line 88, in _run_code + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__main__.py", line 5, in <module> + sys.exit(ensurepip._main()) + ^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 286, in _main + return _bootstrap( + ^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 202, in _bootstrap + return _run_pip([*args, *_PACKAGE_NAMES], additional_paths) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/ensurepip/__init__.py", line 103, in _run_pip + return subprocess.run(cmd, check=True).returncode + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/toolchain/lib/python3.11/subprocess.py", line 571, in run + raise CalledProcessError(retcode, process.args, +subprocess.CalledProcessError: Command '['/var/media/DATA/home-rudi/LibreELEC.tv/build.LibreELEC-Generic.x86_64-12.0-devel/build/qemu-8.1.0-rc1/.x86_64-linux-gnu/pyvenv/bin/python3', '-W', 'ignore::DeprecationWarning', '-c', '\nimport runpy\nimport sys\nsys.path = [\'/tmp/tmpio395oka/setuptools-65.5.0-py3-none-any.whl\', \'/tmp/tmpio395oka/pip-23.1.2-py3-none-any.whl\'] + sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\', \'--no-index\', \'--find-links\', \'/tmp/tmpio395oka\', \'--upgrade\', \'setuptools\', \'pip\']\nrunpy.run_module("pip", run_name="__main__", alter_sys=True)\n']' returned non-zero exit status 2. + +============================ + +*** Ouch! *** + +VENV creation subprocess failed. + + + +ERROR: python venv creation failed + +FAILURE: s/build qemu:host during configure_host (default) + +``` diff --git a/results/classifier/105/instruction/1792659 b/results/classifier/105/instruction/1792659 new file mode 100644 index 00000000..86c2323a --- /dev/null +++ b/results/classifier/105/instruction/1792659 @@ -0,0 +1,65 @@ +instruction: 0.709 +graphic: 0.664 +semantic: 0.650 +device: 0.625 +socket: 0.581 +other: 0.580 +assembly: 0.502 +vnc: 0.488 +network: 0.484 +boot: 0.417 +KVM: 0.335 +mistranslation: 0.301 + +watchpoints might not properly stop execution at the right address + +This bug has been tested with the latest development tree (19b599f7664b2ebfd0f405fb79c14dd241557452). + +I am using qemu-system-i386 with the gdbserver stub. I set a watchpoint on some address. When the watchpoint is hit, it will be reported by gdb, but it might happen that eip points to the wrong address (execution has not properly stopped when the watchpoint was hit). + +The setup I used to reproduce it is quite complex, but I believe I have found the cause of the bug, so I will describe that. + +The check_watchpoint() function sets cflags_next_tb in order to force the execution of only one instruction, and then exits the current tb. It then expects to be called again after that one instruction is executed, the watchpoint is hit and it is reported to gdb. + +The problem is that another interrupt might have been generated around the same time as the watchpoint. If the interrupt changes eip and execution goes on in another address, the value of cflags_next_tb will be spoiled. When we come back from the interrupt to the address where the watchpoint is hit, it is possible that a tb with multiple instructions is been executed, and therefore eip points to the wrong address, ahead of where it should be. + +In my case, the order is as follows: +* i8259 generates an IRQ + - cpu->interrupt_request contains both CPU_INTERRUPT_TGT_EXT_1 and CPU_INTERRUPT_HARD +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with CPU_INTERRUPT_TGT_EXT_1 + - execution continues +* I am exactly at the instruction where the watchpoint is hit. + - check_watchpoint() is called and cflags_next_tb is set to force the execution of only one instruction. + - execution breaks out of the loop with siglongjmp() +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with the IRQ. eip is changed and cflags_next_tb is spoiled + - execution continues at the IRQ + +[...] +* The kernel finishes dealing with the IRQ + +* I am back at the instruction where the watchpoint is hit. + - A tb is created and executed with two instructions instead of one + - eip is now ahead of the instruction that hit the watchpoint +* cpu_handle_interrupt() is called + - it deals with CPU_INTERRUPT_DEBUG + - the watchpoint is reported by gdb, but with the wrong eip. + +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 can follow the logic here and agree there's a bug. + +It would be nice if there were a reproducer, to verify +that the bug is actually fixed, but I can make a stab +at it without. + + +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/245 + + diff --git a/results/classifier/105/instruction/1793275 b/results/classifier/105/instruction/1793275 new file mode 100644 index 00000000..4cd8e42b --- /dev/null +++ b/results/classifier/105/instruction/1793275 @@ -0,0 +1,46 @@ +instruction: 0.183 +boot: 0.169 +network: 0.159 +KVM: 0.139 +vnc: 0.129 +device: 0.100 +graphic: 0.100 +assembly: 0.100 +socket: 0.095 +other: 0.082 +mistranslation: 0.074 +semantic: 0.066 + +Hosts fail to start after update to QEMU 3.0 + +Host OS: Archlinux +Host Architecture: AMD64 +Guest OS: FreeBSD-11.2 (x2) and Archlinux (x1) +Guest Architecture: AMD64 + +I have been using QEMU 2.x without issue for a number of years but since updating to QEMU 3.0 my guests do not complete startup. + +FreeBSD 11.2 guest failure symptom: +The two FreeBSD-11.2 guests output repeated messages of "unexpected cache type 4". This appears to be an internal error message and I've not found any instances of it through Google search. + +Archlinux guest failure symptom: +The single Archlinux guest gets no further than the message "uncompressing initial ramdisk". + +The guests are started by a qemu-kvm invokation. No virtual machine managers are used. The command lines used (from ps awx) to launch the VMs are: + +[neil@optimus ~]$ ps awx |grep qemu + 1492 ? Sl 3:19 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps1.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps1,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_1 -net nic,macaddr=52:54:AD:86:64:00,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.2:23,server,nowait -vnc 192.168.0.1:0 + 1510 ? Sl 0:54 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps2.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps2,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name Archlinux -net nic,macaddr=52:54:AD:86:64:01,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.3:23,server,nowait -vnc 192.168.0.1:1 + 1529 ? Sl 3:07 /usr/bin/qemu-system-x86_64 -daemonize -pidfile /run/qemu_vps3.pid -enable-kvm -cpu host -smp 2 -k en-gb -boot order=c -drive file=/dev/system/vps3,cache=none,format=raw,if=virtio,index=0,media=disk -m 1024 -name FreeBSD_2 -net nic,macaddr=52:54:AD:86:64:02,model=virtio -net vde,sock=/run/vde_switch-tap0.sock -monitor telnet:127.0.0.4:23,server,nowait -vnc 192.168.0.1:2 + +The VMs were installed to LVM volumes on the host machine (hence the /dev/system/vpsN device names). Networking is over a Linux tap interface connected to a VDE2 virtual network switch. + +Currently working version of QEMU: qemu-headless 2.12.1-1 +Failing version of QEMU: qemu-headless-3.0.0-1 + +Archlinux have released qemu-headless-3.0.0-3 which includes a backported patch for virtio. I have tested this version and the problem still persists. + +This bug is not present in QEMU-3.1.0. + +Ok, thanks for the update. Closing this bug since it seems to be fixed in 3.1. + diff --git a/results/classifier/105/instruction/1793608 b/results/classifier/105/instruction/1793608 new file mode 100644 index 00000000..b6a6faa1 --- /dev/null +++ b/results/classifier/105/instruction/1793608 @@ -0,0 +1,49 @@ +instruction: 0.899 +mistranslation: 0.794 +graphic: 0.781 +semantic: 0.777 +assembly: 0.747 +device: 0.645 +other: 0.636 +network: 0.605 +socket: 0.600 +vnc: 0.548 +KVM: 0.477 +boot: 0.423 + +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/105/instruction/1793904 b/results/classifier/105/instruction/1793904 new file mode 100644 index 00000000..859d5f63 --- /dev/null +++ b/results/classifier/105/instruction/1793904 @@ -0,0 +1,154 @@ +instruction: 0.713 +device: 0.710 +semantic: 0.688 +assembly: 0.686 +other: 0.681 +graphic: 0.655 +network: 0.635 +vnc: 0.610 +KVM: 0.600 +mistranslation: 0.551 +socket: 0.528 +boot: 0.492 + +files are randomly overwritten by Zero Bytes + +Hello together, + +I am currently tracking down a "Hard to reproduce" bug on my systems that I first discovered during gitlab installation: + + +Here is the Text from the Gitlab Bug https://gitlab.com/gitlab-org/gitlab-ce/issues/51023 +---------------------------------------------------------------------------------------------- + +Steps to reproduce + +I still do not have all the steps together to reproduce, so far it is: +apt install gitlab-ce and +gitlab-rake backup:recovery +Then it works for some time before it fails. + +What is the current bug behavior? + +I have a 12 hour old Installation of gitlab ce 11.2.3-ce.0 for debian stretch on a fresh debian stretch system together with our imported data. However it turns out that some gitlab related files contain Zero bytes instead of actual data. + +root@gitlab:~# xxd -l 16 /opt/gitlab/bin/gitlab-ctl +00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ + +This behaviour is somewhat strange because it was working for a few minutes/hours. I did write a shell script to find out which files are affected of this memory loss. It turns out that only files located under /opt/gitlab are affected, if I rule out files like /var/log/faillog and some postgresql table files. + +What I find even stranger is that it does not seem to affect Logfiles/databases/git_repositorys but application files, like .rb scripts. and not all of them. No non gitlab package is affected. + +What is the expected correct behavior? +Binarys and .rb files should stay as they are. + +Possible fixes + +I am still investigating, I hope that it is not an infrastructure problem (libvirt/qemu/glusterfs) it can still be one but the point that files of /opt/gitlab are affected and not any logfile and that we to not have similar problems with any other system leads me to the application for now. +If I would have used docker the same problem might have caused a reboot of the container. +But for the Debian package it is a bit of work to recover. That is all a workaround, however. +--------------------------------------------------------------------------------------------- + +I do have found 2 more systems having the same problem with different software: + +root@erp:~# xxd -l 16 /usr/share/perl/5.26.2/constant.pm +00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ + +The Filesize itself is, compared with another machine 00001660 Bytes for both the corrupted and the intact file. It looks to me from the outside that if some data in the qcow2 file is written too many bytes get written so it sometimes overwites data of existing files located right after the position in memory where the write goes to. + +I would like to rule out Linux+Ext4 filesystems because I find it highly unlikely that such an error keeps undiscovered in that part of the environment for long. I think the same might go for qemu. + +Which leaves qemu, gemu+gluster:// mount, qcow2 volumes, glusterfs, network. So I am now going to check if I can find any system which gets its volumes via fusermount instead of gluster:// path if the error is gone there. This may take a while. + + +----- some software versions--------------- + +QEMU emulator version 2.12.0 (Debian 1:2.12+dfsg-3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +libvirt-daemon-driver-storage-gluster/testing,unstable,now 4.6.0-2 amd64 [installed] + +ii glusterfs-client 4.1.3-1 amd64 + +Update: I do have changed all important vms to a fuserfs image mount. + +The problem seems to occur when you write a lot of smaller files in a short period of time on the VMs ext4 filesystem. The best way for me to reproduce that is by doing an "apt upgrade" (see attachment) + +This particular VM is configured with a virtio storage device (vda) with the following URL (resolved via /etc/hosts): gluster://this.virt.local:24007/images/conesphere_oldschool_testerp.qcow2 + +The gluster volume images has a 2 replica 1 arbiter layout. and is located on one physical vlan which is spread via a fibre optics link between 2 datacenters. All Gigabit all TCP. + +I could not reproduce the behaviour when I did mount the glusterfs volume via fuse into /var/lib/libvirt/images and started my machine from there. So this might be a suitable workaround despite of the performance loss. + +As far as I can see from here, direct access from qemu on 'glusterfs://' storage is seriously broken the moment and no one should use it until it is fixed. + + +Looks like you've narrowed it down to QEMU's usage of gluster, but some additional details might still be nice just to be sure: + +Can you produce the command-line for QEMU so we can see the configuration you're running? + +I believe on Debian that QEMU makes use of the glusterfs-common package, can you post that version too? + +Once you are witnessing files coming back as zeroes, if you shut the VM down (cleanly if at all possible), are you able to run qemu-img check on the qcow2 file? Do you see any errors? + +And, as a debugging step, are you able to test with a raw file over gluster:// to see if you can reproduce that way? I'm wondering if there's an interaction with qcow2 and gluster that can maybe be eliminated or highlighted here. (qcow2 might drive gluster in ways differently than raw does, which might help narrow down the problem one way or the other.) + +--js + + + +Hi John, + + +As for your second question: +ii glusterfs-comm 4.1.3-1 amd64 GlusterFS common libraries and tr + + +As for the other parts: I was playing with this one ealier, therefore this is not completely relieable: + +qemu-img check images/conesphere_internet_meeting1.qcow2 +No errors were found on the image. +143086/491520 = 29.11% allocated, 7.72% fragmented, 0.00% compressed clusters +Image end offset: 9379708928 + + +I will try to reproduce your Ideas as soon as I can. :) + + + +I will have to put more efford into that: The bug applies to oVirt 4.3 too which seems to use a fuse filesystem. + +I did some undocumented testing to circle the issue down: It seems to affect Files that are stored as sparsed files either raw or qcow2. + +There was a big event and I had the chance to find some people using glusterfs with qemu, too. the biggest difference as far as I could see was that they all where using xfs based backends while I am using ext4. + +I have to fix a few more issues in Production this week, then I will run more tests. + +Please note the updates on: + +https://bugzilla.redhat.com/show_bug.cgi?id=1701736 + +It turns out that you can reproduce the broken images on glusterfs fuse mounts by using: + + aio=native + cache=none, + write-cache=on + + +I have a set of vms running here on my fedora 29 desktop providing a test glusterfs and a vm to reproduce the bug, at least for the current ovirt case. + +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/105/instruction/1794086 b/results/classifier/105/instruction/1794086 new file mode 100644 index 00000000..1fad1e57 --- /dev/null +++ b/results/classifier/105/instruction/1794086 @@ -0,0 +1,72 @@ +instruction: 0.701 +socket: 0.686 +device: 0.673 +boot: 0.647 +mistranslation: 0.612 +other: 0.594 +vnc: 0.593 +semantic: 0.560 +network: 0.554 +graphic: 0.373 +KVM: 0.347 +assembly: 0.263 + +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/105/instruction/1797033 b/results/classifier/105/instruction/1797033 new file mode 100644 index 00000000..100eb7cd --- /dev/null +++ b/results/classifier/105/instruction/1797033 @@ -0,0 +1,29 @@ +instruction: 0.588 +device: 0.450 +graphic: 0.334 +other: 0.312 +semantic: 0.280 +boot: 0.265 +vnc: 0.239 +socket: 0.187 +mistranslation: 0.136 +network: 0.113 +KVM: 0.057 +assembly: 0.023 + +Running with -rtc clock=vm,base=<datetime> introduces arbitrary base shift at guest startup + +When specifying 'base' for RTC to start with, it has incorrect implementation in combination with clock=vm. + +I inspected source code. This is because it uses host clock (qemu_time() function return value) as reference with 'rtc_date_offset' operations across several places in code before guest execution starts, which has no relevance with clock=vm. + +It works in vast majority of cases only thanks to combination of some luck and fast execution of qemu initialization phase relative to host real time (i.e. multiple calls of qemu_time() returns same value). But if qemu execution is being slow down by high CPU load on host or started just before value of second changes, it may accumulate at least 1 second (and in hard circumstances even 2+ seconds) of delay from specified base datetime before guest becomes ready to start. + +This behavior breaks determinism of guest execution in icount mode. (Even if guest doesn't cares about precise time, just one second shift may trigger such chain of changes which accumulates significant difference in guest state at the moment when guest OS finishes booting.) + +Why I didn't posted patch to qemu-devel ? +I have no idea how to patch it correctly, because it isn't clear how these things are expected to work when referenced across all qemu code and different use cases. Should vl.c/qemu_get_timedate() just be fixed ? Does each caller expect same behavior from it? Or only selected hw/* RTC implementations (such as hw/timer/mc146818rtc.c) have to be modified to use alternative function ? Or maybe it isn't specific to clock=vm and should be considered bad behavior in any case (i.e. time shouldn't advance before guest execution being started)? + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=eb6a52099160f1a6e66d7e + diff --git a/results/classifier/105/instruction/1799 b/results/classifier/105/instruction/1799 new file mode 100644 index 00000000..8bb6d1d8 --- /dev/null +++ b/results/classifier/105/instruction/1799 @@ -0,0 +1,190 @@ +instruction: 0.682 +device: 0.658 +other: 0.656 +boot: 0.628 +vnc: 0.599 +graphic: 0.589 +KVM: 0.564 +network: 0.528 +semantic: 0.516 +assembly: 0.504 +socket: 0.466 +mistranslation: 0.379 + +Support running real-world Android on Arm by supporting one-register list for the POP (LDMIA) Thumb32 instruction. +Steps to reproduce: +1. Get any aarch64 Linux on QEMU for x86_64 running. Make sure that Wayland is running. (For example, build PostmarketOS with "phosh" for aarch64 and install it.) +2. Install waydroid (e.g. `apk add waydroid`). +3. Install the LineageOS 18.1 for waydroid image (e.g. `waydroid init`). +4. Run the waydroid-container (e.g. `rc-service waydroid-container restart`). +5. Start the waydroid session (e.g. click on the "Waydroid" symbol on the graphical user interface). +6. Observe the waydroid log file (e.g. run `waydroid logcat`). +Additional information: +The output of the Android log (using `waydroid logcat`) will be akin: + +``` +23908 23908 D AndroidRuntime: >>>>>> START com.android.internal.os.ZygoteInit uid 0 <<<<<< +23908 23908 I AndroidRuntime: Using default boot image +23908 23908 I AndroidRuntime: Leaving lock profiling enabled +23908 23908 E cutils-trace: Error opening trace file: No such file or directory (2) +23908 23908 I zygote : option[0]=-Xzygote +23908 23908 I zygote : option[1]=exit +23908 23908 I zygote : option[2]=vfprintf +23908 23908 I zygote : option[3]=sensitiveThread +23908 23908 I zygote : option[4]=-verbose:gc +23908 23908 I zygote : option[5]=-XX:PerfettoHprof=true +23908 23908 I zygote : option[6]=-Xms8m +23908 23908 I zygote : option[7]=-Xmx512m +23908 23908 I zygote : option[8]=-XX:HeapGrowthLimit=192m +23908 23908 I zygote : option[9]=-XX:HeapMinFree=8m +23908 23908 I zygote : option[10]=-XX:HeapMaxFree=16m +23908 23908 I zygote : option[11]=-XX:HeapTargetUtilization=0.6 +23908 23908 I zygote : option[12]=-Xusejit:true +23908 23908 I zygote : option[13]=-Xjitsaveprofilinginfo +23908 23908 I zygote : option[14]=-XjdwpOptions:suspend=n,server=y +23908 23908 I zygote : option[15]=-XjdwpProvider:default +23908 23908 I zygote : option[16]=-Xopaque-jni-ids:swapable +23908 23908 I zygote : option[17]=-Xlockprofthreshold:500 +23908 23908 I zygote : option[18]=-Xcompiler-option +23908 23908 I zygote : option[19]=--instruction-set-variant=generic +23908 23908 I zygote : option[20]=-Xcompiler-option +23908 23908 I zygote : option[21]=--instruction-set-features=default +23908 23908 I zygote : option[22]=-Xcompiler-option +23908 23908 I zygote : option[23]=--generate-mini-debug-info +23908 23908 I zygote : option[24]=-Ximage-compiler-option +23908 23908 I zygote : option[25]=--runtime-arg +23908 23908 I zygote : option[26]=-Ximage-compiler-option +23908 23908 I zygote : option[27]=-Xms64m +23908 23908 I zygote : option[28]=-Ximage-compiler-option +23908 23908 I zygote : option[29]=--runtime-arg +23908 23908 I zygote : option[30]=-Ximage-compiler-option +23908 23908 I zygote : option[31]=-Xmx64m +23908 23908 I zygote : option[32]=-Ximage-compiler-option +23908 23908 I zygote : option[33]=--dirty-image-objects=/system/etc/dirty-image-objects +23908 23908 I zygote : option[34]=-Ximage-compiler-option +23908 23908 I zygote : option[35]=--instruction-set-variant=generic +23908 23908 I zygote : option[36]=-Ximage-compiler-option +23908 23908 I zygote : option[37]=--instruction-set-features=default +23908 23908 I zygote : option[38]=-Ximage-compiler-option +23908 23908 I zygote : option[39]=--generate-mini-debug-info +23908 23908 I zygote : option[40]=-Duser.locale=en-US +23908 23908 I zygote : option[41]=--cpu-abilist=armeabi-v7a,armeabi +23908 23908 I zygote : option[42]=-Xcore-platform-api-policy:just-warn +23908 23908 I zygote : option[43]=-Xfingerprint:waydroid/lineage_waydroid_arm64/waydroid_arm64:11/RQ3A.211001.001/48:userdebug/test-keys +23908 23908 I zygote : Core platform API reporting enabled, enforcing=false +23908 23908 D zygote : Time zone APEX ICU file found: /apex/com.android.tzdata/etc/icu/icu_tzdata.dat +23908 23908 D zygote : I18n APEX ICU file found: /apex/com.android.i18n/etc/icu/icudt66l.dat +23908 23908 I zygote : Using memfd for future sealing +23908 23908 W zygote : Using default instruction set features for ARM CPU variant (generic) using conservative defaults + 49 49 I tombstoned: received crash request for pid 23908 +23908 23908 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** +23908 23908 F DEBUG : LineageOS Version: '18.1-20230723-VANILLA-waydroid_arm64' +23908 23908 F DEBUG : Build fingerprint: 'waydroid/lineage_waydroid_arm64/waydroid_arm64:11/RQ3A.211001.001/48:userdebug/test-keys' +23908 23908 F DEBUG : Revision: '0' +23908 23908 F DEBUG : ABI: 'arm' +23908 23908 F DEBUG : Timestamp: 2023-07-28 14:13:34+0000 +23908 23908 F DEBUG : pid: 23908, tid: 23908, name: main >>> zygote <<< +23908 23908 F DEBUG : uid: 0 +23908 23908 F DEBUG : signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x709443da (*pc=0x4000e8bd) +23908 23908 F DEBUG : r0 54647764 r1 3fb9709b r2 fffffe56 r3 4337ffff +23908 23908 F DEBUG : r4 707184b0 r5 3fdaaaaa r6 f295837e r7 00000001 +23908 23908 F DEBUG : r8 00000000 r9 f7986e00 r10 ffa33320 r11 ffa332e4 +23908 23908 F DEBUG : ip e9930ba4 sp ffa332cc lr 709443d5 pc 709443da +23908 23908 F DEBUG : +23908 23908 F DEBUG : backtrace: +23908 23908 F DEBUG : #00 pc 0007e3da /apex/com.android.art/javalib/arm/boot.oat (art_jni_trampoline+34) (BuildId: 4af94ec040111dd87be55d34780e36769428675c) +23908 23908 F DEBUG : #01 pc 000d39d5 /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #02 pc 004f0759 /apex/com.android.art/lib/libart.so (art_quick_invoke_static_stub+276) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #03 pc 0012ca93 /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+166) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #04 pc 00240bbf /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #05 pc 002388df /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+746) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #06 pc 004e44db /apex/com.android.art/lib/libart.so (MterpInvokeStatic+482) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #07 pc 000ce594 /apex/com.android.art/lib/libart.so (mterp_op_invoke_static+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #08 pc 003bdaa0 /system/framework/framework.jar +23908 23908 F DEBUG : #09 pc 0023182b /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #10 pc 00238109 /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+144) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #11 pc 00239581 /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+536) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #12 pc 004e7239 /apex/com.android.art/lib/libart.so (MterpInvokeStaticRange+372) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #13 pc 000ce894 /apex/com.android.art/lib/libart.so (mterp_op_invoke_static_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #14 pc 003bd9d4 /system/framework/framework.jar +23908 23908 F DEBUG : #15 pc 0023182b /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #16 pc 00238109 /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+144) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #17 pc 00239581 /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+536) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #18 pc 004e7239 /apex/com.android.art/lib/libart.so (MterpInvokeStaticRange+372) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #19 pc 000ce894 /apex/com.android.art/lib/libart.so (mterp_op_invoke_static_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #20 pc 003bc286 /system/framework/framework.jar +23908 23908 F DEBUG : #21 pc 0023182b /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #22 pc 00238109 /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+144) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #23 pc 002388c7 /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+722) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #24 pc 004e44db /apex/com.android.art/lib/libart.so (MterpInvokeStatic+482) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #25 pc 000ce594 /apex/com.android.art/lib/libart.so (mterp_op_invoke_static+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #26 pc 003b1c7c /system/framework/framework.jar +23908 23908 F DEBUG : #27 pc 0023182b /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #28 pc 0023803d /apex/com.android.art/lib/libart.so (art::interpreter::EnterInterpreterFromEntryPoint(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*)+120) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #29 pc 004d321b /apex/com.android.art/lib/libart.so (artQuickToInterpreterBridge+686) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #30 pc 000d8561 /apex/com.android.art/lib/libart.so (art_quick_to_interpreter_bridge+32) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #31 pc 0042dbaf /system/framework/arm/boot-framework.oat (android.graphics.ColorSpace$Rgb.isSrgb+446) (BuildId: 7ce3c24f3f20164927036fc8f58e1baa2a8f4020) +23908 23908 F DEBUG : #32 pc 0042cddf /system/framework/arm/boot-framework.oat (android.graphics.ColorSpace$Rgb.<init>+822) (BuildId: 7ce3c24f3f20164927036fc8f58e1baa2a8f4020) +23908 23908 F DEBUG : #33 pc 000d39d5 /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #34 pc 004f0627 /apex/com.android.art/lib/libart.so (art_quick_invoke_stub+282) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #35 pc 0012ca81 /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+148) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #36 pc 00240bbf /apex/com.android.art/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #37 pc 00239597 /apex/com.android.art/lib/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+558) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #38 pc 004e6b7d /apex/com.android.art/lib/libart.so (MterpInvokeDirectRange+392) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #39 pc 000ce814 /apex/com.android.art/lib/libart.so (mterp_op_invoke_direct_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #40 pc 003bce74 /system/framework/framework.jar +23908 23908 F DEBUG : #41 pc 004e6cdd /apex/com.android.art/lib/libart.so (MterpInvokeDirectRange+744) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #42 pc 000ce814 /apex/com.android.art/lib/libart.so (mterp_op_invoke_direct_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #43 pc 003bce8c /system/framework/framework.jar +23908 23908 F DEBUG : #44 pc 004e6cdd /apex/com.android.art/lib/libart.so (MterpInvokeDirectRange+744) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #45 pc 000ce814 /apex/com.android.art/lib/libart.so (mterp_op_invoke_direct_range+20) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #46 pc 003be6b6 /system/framework/framework.jar +23908 23908 F DEBUG : #47 pc 0023182b /apex/com.android.art/lib/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10727712076471079728)+254) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #48 pc 0023803d /apex/com.android.art/lib/libart.so (art::interpreter::EnterInterpreterFromEntryPoint(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*)+120) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #49 pc 004d321b /apex/com.android.art/lib/libart.so (artQuickToInterpreterBridge+686) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #50 pc 000d8561 /apex/com.android.art/lib/libart.so (art_quick_to_interpreter_bridge+32) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #51 pc 000d39d5 /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #52 pc 004f0759 /apex/com.android.art/lib/libart.so (art_quick_invoke_static_stub+276) (BuildId: d0f40e4862987997ffa9c0a264e61174) +23908 23908 F DEBUG : #53 pc 0012ca93 /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+166) (BuildId: d0f40e4862987997ffa9c0a264e61174) +``` + + +Analyzing with `gdb` (by repeatedly calling `gdb -p "$(ps xua | grep zygote | grep -v grep | grep -v zygote64 | awk {'print $2'})"` until `gdb` attaches earlier to the current `zygote` process than the offending instruction is reached) reveals that the crash happens here: + +``` + 0x6fc373b0 <+944>: cmp r3, #223 @ 0xdf + 0x6fc373b2 <+946>: movs r6, r0 + 0x6fc373b4 <+948>: movs r0, r5 + 0x6fc373b6 <+950>: movs r0, r0 + 0x6fc373b8 <+952>: push {lr} + 0x6fc373ba <+954>: sub sp, #4 + 0x6fc373bc <+956>: vstr d0, [sp, #12] + 0x6fc373c0 <+960>: vstr d1, [sp, #20] + 0x6fc373c4 <+964>: mov r4, r0 + 0x6fc373c6 <+966>: ldr r2, [sp, #20] + 0x6fc373c8 <+968>: ldr r3, [sp, #24] + 0x6fc373ca <+970>: ldr r0, [sp, #12] + 0x6fc373cc <+972>: ldr r1, [sp, #16] + 0x6fc373ce <+974>: ldr.w r12, [r4, #20] + 0x6fc373d2 <+978>: blx r12 + 0x6fc373d4 <+980>: vmov d0, r0, r1 + 0x6fc373d8 <+984>: add sp, #4 +=> 0x6fc373da <+986>: ldmia.w sp!, {lr} + 0x6fc373de <+990>: bx lr +``` + +(note that the actual address changes for every instance of `zygote`, probably due to address-space layout randomization) + +The instruction at this location is 0xe8bd4000, as evidenced by: + +``` +(gdb) x/16hx 0x6fc373da +0x6fc373da <oatexec+986>: 0xe8bd 0x4000 0x4770 0x2c0f 0x0006 0x0020 0x0000 0xb500 +0x6fc373ea <oatexec+1002>: 0xb081 0xed8d 0x0b03 0x4604 0x9803 0x9904 0xf8d4 0xc014 +``` + +The disassembly into `ldmia.w sp!, {lr}` is indeed correct. However, such an instruction [would be assembled](https://developer.arm.com/documentation/ddi0308/d/Thumb-Instructions/Alphabetical-list-of-Thumb-instructions/POP?lang=en) into `pop lr` and then into `ldr.w lr,[sp,#-4]`, which would be encoded differently. Hence, the assembly into this instruction was incorrect in the first place. + +It turns out that the assembly error is due to an error in the [`vixl` ARMv8 Runtime Code Generation Library](https://github.com/Linaro/vixl), which is also used by Android. This error [has been fixed by Feb 9, 2021](https://github.com/Linaro/vixl/commit/b0a2e281aebbf93e6ee521dcc40ba6dd2aa5124d). However, this fix has [not made it into Android 13](https://android.googlesource.com/platform/external/vixl/+log/02ab12aafeb5278d89184ae6a3ff3a7883b34c5e). Thus, at least Android 11, Android 12, Android 13 cannot run on current `qemu-system-aarch64`, while it should. + +Users of the Android emulator (also based on QEMU) do not seem to suffer from this bug because the Android QEMU [has bitrotted since the year 2018](https://android.googlesource.com/platform/external/qemu/+log/e7390f2265257d66093dfe858ce3a47b2e1de539/target/arm/translate.c) and hence has not seen any Arm emulation modernization in QEMU (e.g. the Tiny Code Generator) since, and only this modernization has exposed this bug in the first place. diff --git a/results/classifier/105/instruction/1801674 b/results/classifier/105/instruction/1801674 new file mode 100644 index 00000000..b33879a2 --- /dev/null +++ b/results/classifier/105/instruction/1801674 @@ -0,0 +1,95 @@ +instruction: 0.845 +KVM: 0.841 +semantic: 0.802 +network: 0.792 +device: 0.790 +vnc: 0.766 +socket: 0.758 +assembly: 0.757 +graphic: 0.754 +boot: 0.751 +other: 0.730 +mistranslation: 0.686 + +Ubuntu16.04 LTS - PCI Pass Through in Ubuntu KVM 16.04.x must use QEMU with DDW support from PPA (Documentation) + +== Comment: #0 - Siraj M. Ismail <email address hidden> - 2016-10-05 11:35:38 == +---Problem Description--- + +Customer running PCI pass through with 16.04.1 KVM and with the stock QEMU packages will hit a DI if they do not update to the QEMU packages with DDW support. The packages are in PPA for customers to download, and test has verified the fix. The details are in Bugzilla 144123. + +---uname output--- +Ubuntu 16.04.1 with 4.4.0 Kernel + +Machine Type = 8247-22L + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + Run guest with adapters assigned via PCI PT, The guest will start having DI issues as soon as I/O started on the Pass Through adapter. + +Contact Information = <email address hidden> + +---Patches Installed--- +QEMU was updated from 2.5 version to 2.6.1 with patches for DDW support, can be found at PPA location : +https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw + +Userspace tool common name: QEMU + +Documentation version: N/A + +The userspace tool has the following bit modes: N/A + +Userspace rpm: N/A + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. + +== Comment: #5 - Leonardo Augusto Guimaraes Garcia <email address hidden> - 2017-04-25 16:23:57 == +I would rephrase to: + +------------------------------- + +Under KVM recommendations + +PCI passthrough recommendations + +If you are running PCI passthrough with 16.04.x KVM and with the stock QEMU package, update to the QEMU package that have DDW support. If you do not update the package, you will hit data integrity issues as soon as I/O is started on the adapter. + +The package is available at: https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw + +------------------------------- + +Some time ago DDW was discussed in this ticket: +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1541902 +And it got introduced in Yakkety and higher only. +Due to pretty complex changes and changes in the virtual machine attributes there is no plan to get it into xenial. +Also 'bugproxy' changed "targetmilestone-inin16041" to "targetmilestone-inin1610". +We are wondering why this now came up again? + +------- Comment From <email address hidden> 2018-11-05 05:57 EDT------- +(In reply to comment #14) +> Some time ago DDW was discussed in this ticket: +> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1541902 +> And it got introduced in Yakkety and higher only. +> Due to pretty complex changes and changes in the virtual machine attributes +> there is no plan to get it into xenial. +> Also 'bugproxy' changed "targetmilestone-inin16041" to +> "targetmilestone-inin1610". +> We are wondering why this now came up again? + +This bug was lying in LTC bugzilla since a while and i happen to +mirror it today after the previous QA left IBM. Its a documentation +bug for 16.04.x + +Okay, added it to: +- uKVM + https://wiki.ubuntu.com/ppc64el/uKVM#PCI_pass-through_with_QEMU-KVM_on_Ubuntu_16.04_using_kernel_4.4 +- and to the Release Notes: + https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#PCI_pass-through_with_QEMU-KVM +Closing ticket. + diff --git a/results/classifier/105/instruction/1803872 b/results/classifier/105/instruction/1803872 new file mode 100644 index 00000000..42f16c86 --- /dev/null +++ b/results/classifier/105/instruction/1803872 @@ -0,0 +1,1336 @@ +instruction: 0.611 +device: 0.603 +semantic: 0.601 +assembly: 0.588 +other: 0.568 +network: 0.557 +graphic: 0.555 +vnc: 0.528 +socket: 0.528 +boot: 0.514 +KVM: 0.464 +mistranslation: 0.449 + +gcc 8.2 reports stringop-truncation when building qemu + +QEMU 3.0 + +block/sheepdog.c: In function 'find_vdi_name': +block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] + strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +If this is the intended behavior, please suppress the warning. For example: + +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstringop-truncation" + strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +#pragma GCC diagnostic pop + +On Tue, Dec 18, 2018 at 3:09 PM Philippe Mathieu-Daudé +<email address hidden> wrote: +> +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> The runstate name doesn't require the strings to be NUL-terminated, +> therefore strncpy is the right function to use here. +> +> We could add a #pragma GCC diagnostic ignored "-Wstringop-truncation" +> around, disable the warning globally using -Wno-stringop-truncation, +> but since QEMU provides the strpadcpy() which does the same purpose, +> simply use it to avoid the annoying warning. +> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> + +Reviewed-by: Marc-André Lureau <email address hidden> + +> --- +> migration/global_state.c | 4 ++-- +> 1 file changed, 2 insertions(+), 2 deletions(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 8e8ab5c51e..c7e7618118 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -42,8 +42,8 @@ int global_state_store(void) +> void global_state_store_running(void) +> { +> const char *state = RunState_str(RUN_STATE_RUNNING); +> - strncpy((char *)global_state.runstate, +> - state, sizeof(global_state.runstate)); +> + strpadcpy((char *)global_state.runstate, +> + sizeof(global_state.runstate), state, '\0'); +> } +> +> bool global_state_received(void) +> -- +> 2.17.2 +> +> + + +-- +Marc-André Lureau + + +On Tue, 18 Dec 2018 12:03:31 +0100 +Philippe Mathieu-Daudé <email address hidden> wrote: + +> From: Marc-André Lureau <email address hidden> +> +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC hw/acpi/core.o +> In function 'acpi_table_install', inlined from 'acpi_table_add' at qemu/hw/acpi/core.c:296:5: +> qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation] +> strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> +> The ACPI tables don't require the strings to be NUL-terminated, +> therefore strncpy is the right function to use here. +> +> We could add a #pragma GCC diagnostic ignored "-Wstringop-truncation" +> around, disable the warning globally using -Wno-stringop-truncation, +> but since QEMU provides the strpadcpy() which does the same purpose, +> simply use it to avoid the annoying warning. +> +> Signed-off-by: Marc-André Lureau <email address hidden> +> Reviewed-by: Eric Blake <email address hidden> +> Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +> [PMD: reword commit subject and description] +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> + +Reviewed-by: Igor Mammedov <email address hidden> + +> --- +> hw/acpi/aml-build.c | 6 ++++-- +> hw/acpi/core.c | 13 +++++++------ +> 2 files changed, 11 insertions(+), 8 deletions(-) +> +> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c +> index 1e43cd736d..397833462a 100644 +> --- a/hw/acpi/aml-build.c +> +++ b/hw/acpi/aml-build.c +> @@ -24,6 +24,7 @@ +> #include "hw/acpi/aml-build.h" +> #include "qemu/bswap.h" +> #include "qemu/bitops.h" +> +#include "qemu/cutils.h" +> #include "sysemu/numa.h" +> +> static GArray *build_alloc_array(void) +> @@ -1532,13 +1533,14 @@ build_header(BIOSLinker *linker, GArray *table_data, +> h->revision = rev; +> +> if (oem_id) { +> - strncpy((char *)h->oem_id, oem_id, sizeof h->oem_id); +> + strpadcpy((char *)h->oem_id, sizeof h->oem_id, oem_id, '\0'); +> } else { +> memcpy(h->oem_id, ACPI_BUILD_APPNAME6, 6); +> } +> +> if (oem_table_id) { +> - strncpy((char *)h->oem_table_id, oem_table_id, sizeof(h->oem_table_id)); +> + strpadcpy((char *)h->oem_table_id, sizeof(h->oem_table_id), +> + oem_table_id, '\0'); +> } else { +> memcpy(h->oem_table_id, ACPI_BUILD_APPNAME4, 4); +> memcpy(h->oem_table_id + 4, sig, 4); +> diff --git a/hw/acpi/core.c b/hw/acpi/core.c +> index aafdc61648..6e8f4e5713 100644 +> --- a/hw/acpi/core.c +> +++ b/hw/acpi/core.c +> @@ -31,6 +31,7 @@ +> #include "qapi/qapi-visit-misc.h" +> #include "qemu/error-report.h" +> #include "qemu/option.h" +> +#include "qemu/cutils.h" +> +> struct acpi_table_header { +> uint16_t _length; /* our length, not actual part of the hdr */ +> @@ -181,7 +182,7 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen, +> ext_hdr->_length = cpu_to_le16(acpi_payload_size); +> +> if (hdrs->has_sig) { +> - strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> + strpadcpy(ext_hdr->sig, sizeof ext_hdr->sig, hdrs->sig, '\0'); +> ++changed_fields; +> } +> +> @@ -200,12 +201,12 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen, +> ext_hdr->checksum = 0; +> +> if (hdrs->has_oem_id) { +> - strncpy(ext_hdr->oem_id, hdrs->oem_id, sizeof ext_hdr->oem_id); +> + strpadcpy(ext_hdr->oem_id, sizeof ext_hdr->oem_id, hdrs->oem_id, '\0'); +> ++changed_fields; +> } +> if (hdrs->has_oem_table_id) { +> - strncpy(ext_hdr->oem_table_id, hdrs->oem_table_id, +> - sizeof ext_hdr->oem_table_id); +> + strpadcpy(ext_hdr->oem_table_id, sizeof ext_hdr->oem_table_id, +> + hdrs->oem_table_id, '\0'); +> ++changed_fields; +> } +> if (hdrs->has_oem_rev) { +> @@ -213,8 +214,8 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen, +> ++changed_fields; +> } +> if (hdrs->has_asl_compiler_id) { +> - strncpy(ext_hdr->asl_compiler_id, hdrs->asl_compiler_id, +> - sizeof ext_hdr->asl_compiler_id); +> + strpadcpy(ext_hdr->asl_compiler_id, sizeof ext_hdr->asl_compiler_id, +> + hdrs->asl_compiler_id, '\0'); +> ++changed_fields; +> } +> if (hdrs->has_asl_compiler_rev) { + + + +On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 new warning prevents builds to success since quite some time. +> First report on the mailing list is in July 2018: +> https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> +> Various intents has been sent to fix this: +> - Incorrectly using g_strlcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> - Using assert() and strpadcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - adding an inline wrapper with said pragma in there +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - -Wno-stringop-truncation is the makefile +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> +> This series replace the strncpy() calls by strpadcpy() which seemed +> to me the saniest option. +> +> Regards, +> +> Phil. + +Do you happen to know why does it build fine with +Gcc 8.2.1? + +Reading the GCC manual it seems that +there is a "nostring" attribute that means +"might not be 0 terminated". +I think we should switch to that which fixes the warning +but also warns if someone tries to misuse these +as C-strings. + +Seems to be a better option, does it not? + + +> Marc-André Lureau (1): +> hw/acpi: Replace strncpy() by strpadcpy(pad='\0') +> +> Philippe Mathieu-Daudé (2): +> block/sheepdog: Replace strncpy() by strpadcpy(pad='\0') +> migration: Replace strncpy() by strpadcpy(pad='\0') +> +> block/sheepdog.c | 6 +++--- +> hw/acpi/aml-build.c | 6 ++++-- +> hw/acpi/core.c | 13 +++++++------ +> migration/global_state.c | 4 ++-- +> 4 files changed, 16 insertions(+), 13 deletions(-) +> +> -- +> 2.17.2 + + +On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote: +> On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: +> > GCC 8 new warning prevents builds to success since quite some time. +> > First report on the mailing list is in July 2018: +> > https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> > +> > Various intents has been sent to fix this: +> > - Incorrectly using g_strlcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> > - Using assert() and strpadcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> > - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - adding an inline wrapper with said pragma in there +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - -Wno-stringop-truncation is the makefile +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > +> > This series replace the strncpy() calls by strpadcpy() which seemed +> > to me the saniest option. +> > +> > Regards, +> > +> > Phil. +> +> Do you happen to know why does it build fine with +> Gcc 8.2.1? +> +> Reading the GCC manual it seems that +> there is a "nostring" attribute that means + +typo - its "nonstring" + +> "might not be 0 terminated". +> I think we should switch to that which fixes the warning +> but also warns if someone tries to misuse these +> as C-strings. +> +> Seems to be a better option, does it not? + +Yes, it does look best as gcc manual explicitly suggests "nonstring" +as the way to stop this strncpy warning. + + +Regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + +On Tue, Dec 18, 2018 at 09:31:00AM -0500, Michael S. Tsirkin wrote: +> On Tue, Dec 18, 2018 at 12:03:30PM +0100, Philippe Mathieu-Daudé wrote: +> > GCC 8 new warning prevents builds to success since quite some time. +> > First report on the mailing list is in July 2018: +> > https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> > +> > Various intents has been sent to fix this: +> > - Incorrectly using g_strlcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> > - Using assert() and strpadcpy() +> > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> > - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - adding an inline wrapper with said pragma in there +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > - -Wno-stringop-truncation is the makefile +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> > +> > This series replace the strncpy() calls by strpadcpy() which seemed +> > to me the saniest option. +> > +> > Regards, +> > +> > Phil. +> +> Do you happen to know why does it build fine with +> Gcc 8.2.1? +> +> Reading the GCC manual it seems that +> there is a "nostring" attribute + +Sorry that should be "nonstring". + + +> that means +> "might not be 0 terminated". +> I think we should switch to that which fixes the warning +> but also warns if someone tries to misuse these +> as C-strings. +> +> Seems to be a better option, does it not? +> + +Also maybe we can make strpadcpy check for the nonstring +attribute too somehow? +Or did gcc just hardcode the strncpy name? + +> > Marc-André Lureau (1): +> > hw/acpi: Replace strncpy() by strpadcpy(pad='\0') +> > +> > Philippe Mathieu-Daudé (2): +> > block/sheepdog: Replace strncpy() by strpadcpy(pad='\0') +> > migration: Replace strncpy() by strpadcpy(pad='\0') +> > +> > block/sheepdog.c | 6 +++--- +> > hw/acpi/aml-build.c | 6 ++++-- +> > hw/acpi/core.c | 13 +++++++------ +> > migration/global_state.c | 4 ++-- +> > 4 files changed, 16 insertions(+), 13 deletions(-) +> > +> > -- +> > 2.17.2 + + +On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> > Do you happen to know why does it build fine with +> > Gcc 8.2.1? +> > +> > Reading the GCC manual it seems that +> > there is a "nostring" attribute that means +> > "might not be 0 terminated". +> > I think we should switch to that which fixes the warning +> > but also warns if someone tries to misuse these +> > as C-strings. +> > +> > Seems to be a better option, does it not? +> > +> > +> +> Using strpadcpy is clever and self-documenting, though. We have it +> already, so why not use it. +> +> Paolo + +The advantage of nonstring is that it will catch attempts to +use these fields with functions that expect a 0 terminated string. + +strpadcpy will instead just silence the warning. + + +-- +MST + + +On Tue, Dec 18, 2018 at 05:38:17PM +0100, Paolo Bonzini wrote: +> On 18/12/18 15:54, Michael S. Tsirkin wrote: +> > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> >> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> >>> Do you happen to know why does it build fine with +> >>> Gcc 8.2.1? +> >>> +> >>> Reading the GCC manual it seems that +> >>> there is a "nostring" attribute that means +> >>> "might not be 0 terminated". +> >>> I think we should switch to that which fixes the warning +> >>> but also warns if someone tries to misuse these +> >>> as C-strings. +> >>> +> >>> Seems to be a better option, does it not? +> >>> +> >>> +> >> +> >> Using strpadcpy is clever and self-documenting, though. We have it +> >> already, so why not use it. +> >> +> >> Paolo +> > +> > The advantage of nonstring is that it will catch attempts to +> > use these fields with functions that expect a 0 terminated string. +> > +> > strpadcpy will instead just silence the warning. +> +> Ah, I see. We could also do both, that's a matter of taste. +> +> Paolo + +Do you happen to know how to make gcc check the buffer size +for strpadcpy? Is the name strncpy just hard-coded? + +-- +MST + + +On Tue, Dec 18, 2018 at 05:55:27PM +0100, Philippe Mathieu-Daudé wrote: +> On 12/18/18 3:54 PM, Michael S. Tsirkin wrote: +> > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> >> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> >>> Do you happen to know why does it build fine with +> >>> Gcc 8.2.1? +> >>> +> >>> Reading the GCC manual it seems that +> >>> there is a "nostring" attribute that means +> >>> "might not be 0 terminated". +> >>> I think we should switch to that which fixes the warning +> >>> but also warns if someone tries to misuse these +> >>> as C-strings. +> >>> +> >>> Seems to be a better option, does it not? +> >>> +> >>> +> >> +> >> Using strpadcpy is clever and self-documenting, though. We have it +> >> already, so why not use it. +> >> +> >> Paolo +> > +> > The advantage of nonstring is that it will catch attempts to +> > use these fields with functions that expect a 0 terminated string. +> > +> > strpadcpy will instead just silence the warning. +> +> migration/global_state.c:109:15: error: 'strlen' argument 1 declared +> attribute 'nonstring' [-Werror=stringop-overflow=] +> s->size = strlen((char *)s->runstate) + 1; +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> +> GCC won... It is true this strlen() is buggy, indeed s->runstate might +> be not NUL-terminated. + + +Ooh nice. I smell some CVE fixes coming from this effort. + + +-- +MST + + +On Tue, Dec 18, 2018 at 06:12:05PM +0100, Paolo Bonzini wrote: +> On 18/12/18 17:55, Philippe Mathieu-Daudé wrote: +> >> strpadcpy will instead just silence the warning. +> > migration/global_state.c:109:15: error: 'strlen' argument 1 declared +> > attribute 'nonstring' [-Werror=stringop-overflow=] +> > s->size = strlen((char *)s->runstate) + 1; +> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> > +> > GCC won... It is true this strlen() is buggy, indeed s->runstate might +> > be not NUL-terminated. +> +> No, runstate is declared as an array of 100 bytes, which are more than +> enough. It's ugly code but not buggy. +> +> Paolo + +Yes ... but it is loaded using + VMSTATE_BUFFER(runstate, GlobalState), +and parsed using qapi_enum_parse which does not get +the buffer length. + +So unless we are lucky there's a buffer overrun +on a remote/file input here. + +Seems buggy to me - what am I missing? + +-- +MST + + +On Tue, Dec 18, 2018 at 12:03:34PM -0500, Michael S. Tsirkin wrote: +> On Tue, Dec 18, 2018 at 05:38:17PM +0100, Paolo Bonzini wrote: +> > On 18/12/18 15:54, Michael S. Tsirkin wrote: +> > > On Tue, Dec 18, 2018 at 03:45:08PM +0100, Paolo Bonzini wrote: +> > >> On 18/12/18 15:31, Michael S. Tsirkin wrote: +> > >>> Do you happen to know why does it build fine with +> > >>> Gcc 8.2.1? +> > >>> +> > >>> Reading the GCC manual it seems that +> > >>> there is a "nostring" attribute that means +> > >>> "might not be 0 terminated". +> > >>> I think we should switch to that which fixes the warning +> > >>> but also warns if someone tries to misuse these +> > >>> as C-strings. +> > >>> +> > >>> Seems to be a better option, does it not? +> > >>> +> > >>> +> > >> +> > >> Using strpadcpy is clever and self-documenting, though. We have it +> > >> already, so why not use it. +> > >> +> > >> Paolo +> > > +> > > The advantage of nonstring is that it will catch attempts to +> > > use these fields with functions that expect a 0 terminated string. +> > > +> > > strpadcpy will instead just silence the warning. +> > +> > Ah, I see. We could also do both, that's a matter of taste. +> > +> > Paolo +> +> Do you happen to know how to make gcc check the buffer size +> for strpadcpy? Is the name strncpy just hard-coded? + +GCC provides strncpy as a builtin function and its warning only +checks its builtin. + +Regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 introduced the -Wstringop-truncation checker to detect truncation by +> the strncat and strncpy functions (closely related to -Wstringop-overflow, +> which detect buffer overflow by string-modifying functions declared in +> <string.h>). + +This paragraph talks about a new warning checker, but makes no mention +of an attribute. + +> +> Add the QEMU_NONSTRING macro which checks if the compiler supports this +> attribute. + +Thus, "this attribute" has no antecedent; did you forget to add a +sentence to the previous paragraph, or maybe put the mention of adding +QEMU_NONSTRING after... + +> +>>From the GCC manual [*]: +> +> The nonstring variable attribute specifies that an object or member +> declaration with type array of char, signed char, or unsigned char, +> or pointer to such a type is intended to store character arrays that +> do not necessarily contain a terminating NUL. This is useful in detecting +> uses of such arrays or pointers with functions that expect NUL-terminated +> strings, and to avoid warnings when such an array or pointer is used as +> an argument to a bounded string manipulation function such as strncpy. + +...the explanation of how the attribute was added in tandem with the new +warning checker for silencing specific instances of the warning? + +> +> [*] https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-nonstring-variable-attribute +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> include/qemu/compiler.h | 15 +++++++++++++++ +> 1 file changed, 15 insertions(+) +> + +Reviewed-by: Eric Blake <email address hidden> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC block/sheepdog.o +> qemu/block/sheepdog.c: In function 'find_vdi_name': +> qemu/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1 +> +> As described previous to the strncpy() calls, the use of strncpy() is +> correct here: +> +> /* This pair of strncpy calls ensures that the buffer is zero-filled, +> * which is desirable since we'll soon be sending those bytes, and +> * don't want the send_req to read uninitialized data. +> */ +> strncpy(buf, filename, SD_MAX_VDI_LEN); +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> block/sheepdog.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) + +Reviewed-by: Eric Blake <email address hidden> + +> +> diff --git a/block/sheepdog.c b/block/sheepdog.c +> index 0125df9d49..d4ad6b119d 100644 +> --- a/block/sheepdog.c +> +++ b/block/sheepdog.c +> @@ -1224,7 +1224,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const char *filename, +> SheepdogVdiReq hdr; +> SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr; +> unsigned int wlen, rlen = 0; +> - char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; +> + QEMU_NONSTRING char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; +> +> fd = connect_to_sdog(s, errp); +> if (fd < 0) { +> + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) + +Should this be squashed with 5/5? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 introduced the -Wstringop-overflow, which detect buffer overflow +> by string-modifying functions declared in <string.h>, such strncpy(), +> used in global_state_store_running(). +> +> Since the global_state.runstate does not necessarily contains a +> terminating NUL character, We had to use the QEMU_NONSTRING attribute. + +s/We/we/ + +> +> The GCC manual says about the nonstring attribute: +> +> However, when the array is declared with the attribute the call to +> strlen is diagnosed because when the array doesn’t contain a +> NUL-terminated string the call is undefined. [...] +> In addition, calling strnlen and strndup with such arrays is safe +> provided a suitable bound is specified, and not diagnosed. +> +> GCC indeed found an incorrect use of strlen(), because this array +> is loaded by VMSTATE_BUFFER(runstate, GlobalState) then parsed +> using qapi_enum_parse which does not get the buffer length. +> +> Use strnlen() which returns sizeof(s->runstate) if the array is not +> NUL-terminated. +> +> This fixes: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_pre_save': +> qemu/migration/global_state.c:109:15: error: 'strlen' argument 1 declared attribute 'nonstring' [-Werror=stringop-overflow=] +> s->size = strlen((char *)s->runstate) + 1; +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> qemu/migration/global_state.c:24:13: note: argument 'runstate' declared here +> uint8_t runstate[100] QEMU_NONSTRING; +> ^~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 6e19333422..c19030ef62 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -106,7 +106,7 @@ static int global_state_pre_save(void *opaque) +> GlobalState *s = opaque; +> +> trace_migrate_global_state_pre_save((char *)s->runstate); +> - s->size = strlen((char *)s->runstate) + 1; + +The old code sets s->size to the string length + space for the NUL byte +(by assuming that a NUL byte was present), and accidentally sets it +beyond the s->runstate array if there was no NUL byte (our existing +runstate names are shorter than 100 bytes, so this could only happen on +a malicious stream). + +> + s->size = strnlen((char *)s->runstate, sizeof(s->runstate)) + 1; + +The new code can still end up setting s->size beyond the array. Is that +intended, or would it be better to use strnlen(s->runstate, +sizeof(s->runstate) - 1) + 1? + +Also, as I argued on 4/5, why isn't this squashed in with the patch that +marks the field NONSTRING? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On 12/18/18 11:51 AM, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. + +> typedef struct { +> uint32_t size; +> - uint8_t runstate[100]; +> + uint8_t runstate[100] QEMU_NONSTRING; + +Since 100 bytes for runstate[] is larger than any string possible in our +current enum string values, could we instead add an assert that +strlen(state) < sizeof(global_state.runstate), and then use strpadcpy() +to make our intent obvious while still shutting up the compiler warning, +but without having to deal with the fallout of marking runstate as a +non-string? + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +On Tue, Dec 18, 2018 at 06:51:17PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 new warning prevents builds to success since quite some time. +> First report on the mailing list is in July 2018: +> https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html +> +> Various intents has been sent to fix this: +> - Incorrectly using g_strlcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html +> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html +> - Using assert() and strpadcpy() +> https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html +> - Use #pragma GCC diagnostic ignored "-Wstringop-truncation" +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - adding an inline wrapper with said pragma in there +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - -Wno-stringop-truncation is the makefile +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html +> - Use the 'nonstring' attribute +> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04493.html +> +> This series add the QEMU_NONSTRING definition and use it. +> +> Regards, +> +> Phil. + + +Reviewed-by: Michael S. Tsirkin <email address hidden> + +> Philippe Mathieu-Daudé (5): +> qemu/compiler: Define QEMU_NONSTRING +> block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays +> hw/acpi: Use QEMU_NONSTRING for non NUL-terminated arrays +> migration: Use QEMU_NONSTRING for non NUL-terminated arrays +> migration: Use strnlen() for fixed-size string +> +> block/sheepdog.c | 2 +- +> hw/acpi/core.c | 8 ++++---- +> include/hw/acpi/acpi-defs.h | 8 ++++---- +> include/qemu/compiler.h | 15 +++++++++++++++ +> migration/global_state.c | 4 ++-- +> 5 files changed, 26 insertions(+), 11 deletions(-) +> +> -- +> 2.17.2 + + +On Tue, Dec 18, 2018 at 06:51:19PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC block/sheepdog.o +> qemu/block/sheepdog.c: In function 'find_vdi_name': +> qemu/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1 +> +> As described previous to the strncpy() calls, the use of strncpy() is +> correct here: +> +> /* This pair of strncpy calls ensures that the buffer is zero-filled, +> * which is desirable since we'll soon be sending those bytes, and +> * don't want the send_req to read uninitialized data. +> */ +> strncpy(buf, filename, SD_MAX_VDI_LEN); +> strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN); +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> block/sheepdog.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/block/sheepdog.c b/block/sheepdog.c +> index 0125df9d49..d4ad6b119d 100644 +> --- a/block/sheepdog.c +> +++ b/block/sheepdog.c +> @@ -1224,7 +1224,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const char *filename, +> SheepdogVdiReq hdr; +> SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr; +> unsigned int wlen, rlen = 0; +> - char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; +> + QEMU_NONSTRING char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN]; + +In case you decide to respin anyway - this would be +a bit nicer as: + char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN] QEMU_NONSTRING + + + + +> fd = connect_to_sdog(s, errp); +> if (fd < 0) { +> -- +> 2.17.2 + + +On Tue, Dec 18, 2018 at 06:51:22PM +0100, Philippe Mathieu-Daudé wrote: +> GCC 8 introduced the -Wstringop-overflow, which detect buffer overflow +> by string-modifying functions declared in <string.h>, such strncpy(), +> used in global_state_store_running(). +> +> Since the global_state.runstate does not necessarily contains a +> terminating NUL character, We had to use the QEMU_NONSTRING attribute. +> +> The GCC manual says about the nonstring attribute: +> +> However, when the array is declared with the attribute the call to +> strlen is diagnosed because when the array doesn’t contain a +> NUL-terminated string the call is undefined. [...] +> In addition, calling strnlen and strndup with such arrays is safe +> provided a suitable bound is specified, and not diagnosed. +> +> GCC indeed found an incorrect use of strlen(), because this array +> is loaded by VMSTATE_BUFFER(runstate, GlobalState) then parsed +> using qapi_enum_parse which does not get the buffer length. +> +> Use strnlen() which returns sizeof(s->runstate) if the array is not +> NUL-terminated. +> +> This fixes: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_pre_save': +> qemu/migration/global_state.c:109:15: error: 'strlen' argument 1 declared attribute 'nonstring' [-Werror=stringop-overflow=] +> s->size = strlen((char *)s->runstate) + 1; +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +> qemu/migration/global_state.c:24:13: note: argument 'runstate' declared here +> uint8_t runstate[100] QEMU_NONSTRING; +> ^~~~~~~~ +> cc1: all warnings being treated as errors +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 6e19333422..c19030ef62 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -106,7 +106,7 @@ static int global_state_pre_save(void *opaque) +> GlobalState *s = opaque; +> +> trace_migrate_global_state_pre_save((char *)s->runstate); +> - s->size = strlen((char *)s->runstate) + 1; +> + s->size = strnlen((char *)s->runstate, sizeof(s->runstate)) + 1; +> +> return 0; + +I don't think this works correctly if strnlen returns +sizeof(s->runstate). Which never happens so we probably should +jus add + + assert(e->size is <= sizeof(s->runstate)); + +But also I think this is not enough, there's a problem in post-load +in the call to qapi_enum_parse. You probably want to force +the last character to 0 there. + + +> } +> -- +> 2.17.2 + + +On Tue, 18 Dec 2018 18:51:20 +0100 +Philippe Mathieu-Daudé <email address hidden> wrote: + +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC hw/acpi/core.o +> In function 'acpi_table_install', inlined from 'acpi_table_add' at qemu/hw/acpi/core.c:296:5: +> qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation] +> strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since ACPI tables don't require the +> strings to be NUL-terminated. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> hw/acpi/core.c | 8 ++++---- +> include/hw/acpi/acpi-defs.h | 8 ++++---- +> 2 files changed, 8 insertions(+), 8 deletions(-) +> +> diff --git a/hw/acpi/core.c b/hw/acpi/core.c +> index aafdc61648..f60f750c3d 100644 +> --- a/hw/acpi/core.c +> +++ b/hw/acpi/core.c +> @@ -35,14 +35,14 @@ +> struct acpi_table_header { +> uint16_t _length; /* our length, not actual part of the hdr */ +> /* allows easier parsing for fw_cfg clients */ +> - char sig[4]; /* ACPI signature (4 ASCII characters) */ +> + char sig[4] QEMU_NONSTRING; /* ACPI signature (4 ASCII characters) */ +> uint32_t length; /* Length of table, in bytes, including header */ +> uint8_t revision; /* ACPI Specification minor version # */ +> uint8_t checksum; /* To make sum of entire table == 0 */ +> - char oem_id[6]; /* OEM identification */ +> - char oem_table_id[8]; /* OEM table identification */ +> + char oem_id[6] QEMU_NONSTRING; /* OEM identification */ +> + char oem_table_id[8] QEMU_NONSTRING; /* OEM table identification */ +> uint32_t oem_revision; /* OEM revision number */ +> - char asl_compiler_id[4]; /* ASL compiler vendor ID */ +> + char asl_compiler_id[4] QEMU_NONSTRING; /* ASL compiler vendor ID */ +> uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> } QEMU_PACKED; +> +> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h +> index af8e023968..3bf0bec8ba 100644 +> --- a/include/hw/acpi/acpi-defs.h +> +++ b/include/hw/acpi/acpi-defs.h +> @@ -43,7 +43,7 @@ enum { +> struct AcpiRsdpDescriptor { /* Root System Descriptor Pointer */ +> uint64_t signature; /* ACPI signature, contains "RSD PTR " */ +> uint8_t checksum; /* To make sum of struct == 0 */ +> - uint8_t oem_id [6]; /* OEM identification */ +> + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ +> uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */ +> uint32_t rsdt_physical_address; /* 32-bit physical address of RSDT */ +> uint32_t length; /* XSDT Length in bytes including hdr */ + +you'll need to rebase this on top the latest Michael's pull request. +[PULL v2 25/30] hw: arm: Carry RSDP specific data through AcpiRsdpData +[PULL v2 29/30] hw: acpi: Remove AcpiRsdpDescriptor and fix tests + +> @@ -62,10 +62,10 @@ typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor; +> uint32_t length; /* Length of table, in bytes, including header */ \ +> uint8_t revision; /* ACPI Specification minor version # */ \ +> uint8_t checksum; /* To make sum of entire table == 0 */ \ +> - uint8_t oem_id [6]; /* OEM identification */ \ +> - uint8_t oem_table_id [8]; /* OEM table identification */ \ +> + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ \ +> + uint8_t oem_table_id [8] QEMU_NONSTRING; /* OEM table identification */ \ +> uint32_t oem_revision; /* OEM revision number */ \ +> - uint8_t asl_compiler_id [4]; /* ASL compiler vendor ID */ \ +> + uint8_t asl_compiler_id [4] QEMU_NONSTRING; /* ASL compiler vendor ID */ \ +> uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> +> + + + +On Wed, 19 Dec 2018 10:20:36 +0100 +Philippe Mathieu-Daudé <email address hidden> wrote: + +> Le mer. 19 déc. 2018 10:16, Igor Mammedov <email address hidden> a écrit : +> +> > On Tue, 18 Dec 2018 18:51:20 +0100 +> > Philippe Mathieu-Daudé <email address hidden> wrote: +> > +> > > GCC 8 added a -Wstringop-truncation warning: +> > > +> > > The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> > > bug 81117 is specifically intended to highlight likely unintended +> > > uses of the strncpy function that truncate the terminating NUL +> > > character from the source string. +> > > +> > > This new warning leads to compilation failures: +> > > +> > > CC hw/acpi/core.o +> > > In function 'acpi_table_install', inlined from 'acpi_table_add' at +> > qemu/hw/acpi/core.c:296:5: +> > > qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals +> > destination size [-Werror=stringop-truncation] +> > > strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> > > make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> > > +> > > Use the QEMU_NONSTRING attribute, since ACPI tables don't require the +> > > strings to be NUL-terminated. +> > > +> > > Suggested-by: Michael S. Tsirkin <email address hidden> +> > > Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> > > --- +> > > hw/acpi/core.c | 8 ++++---- +> > > include/hw/acpi/acpi-defs.h | 8 ++++---- +> > > 2 files changed, 8 insertions(+), 8 deletions(-) +> > > +> > > diff --git a/hw/acpi/core.c b/hw/acpi/core.c +> > > index aafdc61648..f60f750c3d 100644 +> > > --- a/hw/acpi/core.c +> > > +++ b/hw/acpi/core.c +> > > @@ -35,14 +35,14 @@ +> > > struct acpi_table_header { +> > > uint16_t _length; /* our length, not actual part of the hdr +> > */ +> > > /* allows easier parsing for fw_cfg +> > clients */ +> > > - char sig[4]; /* ACPI signature (4 ASCII characters) */ +> > > + char sig[4] QEMU_NONSTRING; /* ACPI signature (4 ASCII characters) +> > */ +> > > uint32_t length; /* Length of table, in bytes, including +> > header */ +> > > uint8_t revision; /* ACPI Specification minor version # */ +> > > uint8_t checksum; /* To make sum of entire table == 0 */ +> > > - char oem_id[6]; /* OEM identification */ +> > > - char oem_table_id[8]; /* OEM table identification */ +> > > + char oem_id[6] QEMU_NONSTRING; /* OEM identification */ +> > > + char oem_table_id[8] QEMU_NONSTRING; /* OEM table identification */ +> > > uint32_t oem_revision; /* OEM revision number */ +> > > - char asl_compiler_id[4]; /* ASL compiler vendor ID */ +> > > + char asl_compiler_id[4] QEMU_NONSTRING; /* ASL compiler vendor ID */ +> > > uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> > > } QEMU_PACKED; +> > > +> > > diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h +> > > index af8e023968..3bf0bec8ba 100644 +> > > --- a/include/hw/acpi/acpi-defs.h +> > > +++ b/include/hw/acpi/acpi-defs.h +> > > @@ -43,7 +43,7 @@ enum { +> > > struct AcpiRsdpDescriptor { /* Root System Descriptor Pointer */ +> > > uint64_t signature; /* ACPI signature, contains "RSD +> > PTR " */ +> > > uint8_t checksum; /* To make sum of struct == 0 */ +> > > - uint8_t oem_id [6]; /* OEM identification */ +> > > + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ +> > > uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */ +> > > uint32_t rsdt_physical_address; /* 32-bit physical address of RSDT +> > */ +> > > uint32_t length; /* XSDT Length in bytes including +> > hdr */ +> > +> > you'll need to rebase this on top the latest Michael's pull request. +> > [PULL v2 25/30] hw: arm: Carry RSDP specific data through AcpiRsdpData +> > [PULL v2 29/30] hw: acpi: Remove AcpiRsdpDescriptor and fix tests +> > +> +> OK. Can I add your Ack-by then? +pls note that new AcpiRsdpData has oem_id field that needs the same treatment + +with rebase +Reviewed-by: Igor Mammedov <email address hidden> + +> +> > @@ -62,10 +62,10 @@ typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor; +> > > uint32_t length; /* Length of table, in bytes, +> > including header */ \ +> > > uint8_t revision; /* ACPI Specification minor +> > version # */ \ +> > > uint8_t checksum; /* To make sum of entire table == +> > 0 */ \ +> > > - uint8_t oem_id [6]; /* OEM identification */ \ +> > > - uint8_t oem_table_id [8]; /* OEM table identification */ \ +> > > + uint8_t oem_id [6] QEMU_NONSTRING; /* OEM identification */ \ +> > > + uint8_t oem_table_id [8] QEMU_NONSTRING; /* OEM table +> > identification */ \ +> > > uint32_t oem_revision; /* OEM revision number */ \ +> > > - uint8_t asl_compiler_id [4]; /* ASL compiler vendor ID */ \ +> > > + uint8_t asl_compiler_id [4] QEMU_NONSTRING; /* ASL compiler vendor +> > ID */ \ +> > > uint32_t asl_compiler_revision; /* ASL compiler revision number */ +> > > +> > > +> > +> > + + + +On Wed, 19 Dec 2018 14:00:37 +0100 +Andrew Jones <email address hidden> wrote: + +> On Wed, Dec 19, 2018 at 01:43:40PM +0100, Philippe Mathieu-Daudé wrote: +> > Hi Drew, +> > +> > On 12/19/18 11:10 AM, Andrew Jones wrote: +> > > On Tue, Dec 18, 2018 at 06:51:20PM +0100, Philippe Mathieu-Daudé wrote: +> > >> GCC 8 added a -Wstringop-truncation warning: +> > >> +> > >> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> > >> bug 81117 is specifically intended to highlight likely unintended +> > >> uses of the strncpy function that truncate the terminating NUL +> > >> character from the source string. +> > >> +> > >> This new warning leads to compilation failures: +> > >> +> > >> CC hw/acpi/core.o +> > >> In function 'acpi_table_install', inlined from 'acpi_table_add' at qemu/hw/acpi/core.c:296:5: +> > >> qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals destination size [-Werror=stringop-truncation] +> > >> strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig); +> > >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> > >> make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1 +> > >> +> > >> Use the QEMU_NONSTRING attribute, since ACPI tables don't require the +> > >> strings to be NUL-terminated. +> > > +> > > Aren't we always starting with zero-initialized structures in ACPI code? +> > > If so, then we should be able to change the strncpy's to memcpy's. +> > +> > The first call zero-initializes, but then we call realloc(): +> > +> > /* We won't fail from here on. Initialize / extend the globals. */ +> > if (acpi_tables == NULL) { +> > acpi_tables_len = sizeof(uint16_t); +> > acpi_tables = g_malloc0(acpi_tables_len); +> > } +> > +> > acpi_tables = g_realloc(acpi_tables, acpi_tables_len + +> > ACPI_TABLE_PFX_SIZE + +> > sizeof dfl_hdr + body_size); +> > +> > ext_hdr = (struct acpi_table_header *)(acpi_tables + +> > acpi_tables_len); +> > +> > So memcpy() isn't enough. +> +> Ah, thanks. +> +> > +> > I can resend the previous patch which uses strpadcpy() if you prefer, +> > Igor already reviewed it: +> > +> > https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04406.html +> > +> +> I do like strpadcpy() better, but I'm not going to lose sleep about +> this either way it goes. +I'm ok with both ways, but v2 consensus was to use QEMU_NONSTRING if I got it right + +> +> Thanks, +> drew + + + +* Philippe Mathieu-Daudé (<email address hidden>) wrote: +> GCC 8 added a -Wstringop-truncation warning: +> +> The -Wstringop-truncation warning added in GCC 8.0 via r254630 for +> bug 81117 is specifically intended to highlight likely unintended +> uses of the strncpy function that truncate the terminating NUL +> character from the source string. +> +> This new warning leads to compilation failures: +> +> CC migration/global_state.o +> qemu/migration/global_state.c: In function 'global_state_store_running': +> qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] +> strncpy((char *)global_state.runstate, state, sizeof(global_state.runstate)); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1 +> +> Use the QEMU_NONSTRING attribute, since this array is intended to store +> character arrays that do not necessarily contain a terminating NUL. +> +> Suggested-by: Michael S. Tsirkin <email address hidden> +> Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +> --- +> migration/global_state.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/migration/global_state.c b/migration/global_state.c +> index 8e8ab5c51e..6e19333422 100644 +> --- a/migration/global_state.c +> +++ b/migration/global_state.c +> @@ -21,7 +21,7 @@ +> +> typedef struct { +> uint32_t size; +> - uint8_t runstate[100]; +> + uint8_t runstate[100] QEMU_NONSTRING; + +Hmm; global_state_post_load needs to be fixed for this; it +uses s->runsate and ends up passing it to both a trace +and a qapi_enum_parse - so it's really treating it as a string. +That code is unsafe anyway since it's assuming the received +runstate would be terminated. + +Dave + +> RunState state; +> bool received; +> } GlobalState; +> -- +> 2.17.2 +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + +We think we've fixed all the GCC 8.2 stringop-truncation warnings now, so current QEMU git master and the 4.0 rc1 we've just tagged should both build cleanly. Please reopen the bug if we missed one somehow. + + diff --git a/results/classifier/105/instruction/1807675 b/results/classifier/105/instruction/1807675 new file mode 100644 index 00000000..b0b750f6 --- /dev/null +++ b/results/classifier/105/instruction/1807675 @@ -0,0 +1,55 @@ +instruction: 0.953 +device: 0.760 +graphic: 0.730 +socket: 0.633 +semantic: 0.561 +network: 0.547 +other: 0.532 +vnc: 0.505 +boot: 0.464 +mistranslation: 0.399 +KVM: 0.233 +assembly: 0.152 + +qemu commit 80422b0: tcg.c crash in temp_load + +As discussed in #1803160 I'm opening a new ticket for the new bug. + +QEMU version: +------------- + +qemu from git, master branch commit 80422b00196a7af4c6efb628fae0ad8b644e98af + +Summary: +-------- + +TCG crashes in i386 and x86_64 when it tries to execute some specific illegal instructions. When running full OS emulation, both the guest system and QEMU crash. + +$ qemu-i386 tcg_crash1.elf +/home/alberto/Documents/qemu/tcg/tcg.c:2863: tcg fatal error +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +zsh: segmentation fault (core dumped) ./qemu/build/i386-linux-user/qemu-i386 tcg_crash1.elf + +Invalid instructions: + +f0 invalid +40 inc eax +a7 cmpsd dword [esi], dword ptr es:[edi] +48 dec eax + +Testcase: +--------- + +Find ELF file attached. + + + +(Still repros as of commit d37bfe142382fa82585.) + + +I've sent patch https://patchwork.ozlabs.org/patch/1068003/ to the list which fixes this. (There might be other failures to check for bogus LOCK prefixes elsewhere, though.) + + +The patch from comment #3 is now in git master and will be in the 4.0 release. + + diff --git a/results/classifier/105/instruction/1809144 b/results/classifier/105/instruction/1809144 new file mode 100644 index 00000000..42ef5ac6 --- /dev/null +++ b/results/classifier/105/instruction/1809144 @@ -0,0 +1,54 @@ +instruction: 0.949 +assembly: 0.884 +graphic: 0.745 +mistranslation: 0.706 +device: 0.703 +vnc: 0.649 +network: 0.644 +socket: 0.572 +semantic: 0.566 +other: 0.558 +boot: 0.424 +KVM: 0.362 + +SVM instructions fail with SVME bit enabled + +I was trying to use QEMU/TCG to emulate some stuff that uses SVM. +I know SVM is only partially implemented but I gave it a try anyway. + +I found that if SVM is enabled in the same basic block in which there's a call to VMSAVE/etc, +the call fails as illegal op because the flags don't get updated correctly. + +The pseudocode for the asm I'm running is: + +``` +EFER |= SVME; set the appropriate bit with wrmsr +vmsave +``` + +This is an example of the relevant translate.c code: + +``` + if (!(s->flags & HF_SVME_MASK) || !s->pe) { + goto illegal_op; + } + if (s->cpl != 0) { + gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base); + break; + } +``` + +s->flags doesn't get updated after the wrmsr instruction and so QEMU raises an illegal opcode interrupt. + +A quick fix is to make the tb end after `wrmsr` instructions, but it's an hack afaik. +I'm not too comfortable with QEMU's code, so I don't know what a proper fix would be. + +Cheers, + +thebabush + +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/105/instruction/1809684 b/results/classifier/105/instruction/1809684 new file mode 100644 index 00000000..cd97f3a9 --- /dev/null +++ b/results/classifier/105/instruction/1809684 @@ -0,0 +1,45 @@ +instruction: 0.816 +socket: 0.762 +other: 0.755 +semantic: 0.749 +graphic: 0.745 +mistranslation: 0.715 +device: 0.714 +network: 0.626 +vnc: 0.596 +assembly: 0.478 +KVM: 0.464 +boot: 0.439 + +amdgpu passthrough on POWER9 (ppc64el) not working + +When attempting to pass a Vega 56 GPU to a virtualized guest using QEMU 3.1 on ppc64el (POWER9), the guest is unable to initialize the GPU. Further digging reveals the driver attempting to allocate a large BAR, which then fails: + +[ 6.058544] [drm] PCI I/O BAR is not found. +<snip uninteresting bits> +[ 6.679193] amdgpu 0000:00:03.0: BAR 2: releasing [mem 0x210400000000-0x2104001fffff pref] +[ 6.679306] amdgpu 0000:00:03.0: BAR 0: releasing [mem 0x210200000000-0x2103ffffffff pref] +[ 6.679361] amdgpu 0000:00:03.0: BAR 0: no space for [mem size 0x200000000 pref] +[ 6.679403] amdgpu 0000:00:03.0: BAR 0: failed to assign [mem size 0x200000000 pref] +[ 6.679444] amdgpu 0000:00:03.0: BAR 2: assigned [mem 0x200080200000-0x2000803fffff pref] +[ 6.681420] amdgpu 0000:00:03.0: VRAM: 8176M 0x000000F400000000 - 0x000000F5FEFFFFFF (8176M used) +[ 6.681507] amdgpu 0000:00:03.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF +[ 6.681594] amdgpu 0000:00:03.0: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF +[ 6.681653] [drm] Detected VRAM RAM=8176M, BAR=0M +[ 6.681688] [drm] RAM width 2048bits HBM +[ 6.681885] [TTM] Zone kernel: Available graphics memory: 4176288 kiB +[ 6.681978] [TTM] Zone dma32: Available graphics memory: 2097152 kiB +[ 6.682043] [TTM] Initializing pool allocator +[ 6.682159] [drm] amdgpu: 8176M of VRAM memory ready +[ 6.682249] [drm] amdgpu: 6117M of GTT memory ready. +[ 6.682387] [drm] GART: num cpu pages 8192, num gpu pages 131072 +[ 6.682466] amdgpu 0000:00:03.0: (-22) kernel bo map failed +[ 6.682539] [drm:amdgpu_device_init [amdgpu]] *ERROR* amdgpu_vram_scratch_init failed -22 +[ 6.682592] amdgpu 0000:00:03.0: amdgpu_device_ip_init failed +[ 6.682636] amdgpu 0000:00:03.0: Fatal error during GPU init + +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/105/instruction/1810545 b/results/classifier/105/instruction/1810545 new file mode 100644 index 00000000..7bfb8394 --- /dev/null +++ b/results/classifier/105/instruction/1810545 @@ -0,0 +1,44 @@ +instruction: 0.827 +mistranslation: 0.780 +device: 0.577 +semantic: 0.559 +other: 0.538 +socket: 0.513 +graphic: 0.454 +network: 0.454 +vnc: 0.330 +boot: 0.219 +assembly: 0.111 +KVM: 0.080 + +[alpha] Strange exception address reported + +For some reason the SIGILL handler receives a different address under qemu than it used to on real hardware. I don't know specifics about the hardware used back then – it was some sort of 21264a somewhere between 600-800 MHz –, and I cannot say anything about the kernel as well, but I know that it delivered the faulting address +4, while under qemu it receives +8. I know because CACAO, an early Java JIT compiler extracts the address from the SIGILL handler and inspects the code at the faulting site, and it has substracted 4 from the handler address since the dawn of time, and this used to produce the desired result on the Alpha hardware. It actually ran on two different Alpha machines over the years, and both behaved identically. + +The handler looks like this: +void handler_sigill(int sig, siginfo_t *siginfo, void *_p) +{ + uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4; +} + +(paraphrasing, the actual code is here: https://bitbucket.org/cacaovm/cacao-staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux/md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65) + +I don't know much about the qemu source code and cannot say where this is coming from at first glance. The gen_invalid function uses pc_next, which sounds like the next instruction, not the next-to-next ;). In theory it could actually be the kernel's fault, although I consider this unlikely. + +This is qemu-system-alpha with apparently the last Debian which existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it is the same with any version. + +Hmm, qemu-system-alpha ? The guest kernel should be doing the same thing it would on real hardware -- I guess we're getting the value of the exception address wrong when we deliver the exception to it. + + +The problem seems to be that the PC we report for an OPCDEC is first selected by gen_invalid()/gen-excp() in target/alpha/translate.c, which uses pc_next (ie the insn's address plus 4). But that is then handed through to our custom PALcode (https://git.qemu.org/?p=qemu-palcode.git;a=blob;f=pal.S;h=1781c4b415700ca3a68af07fdae90ae43e722501;hb=HEAD) which does + addq p6, 4, p1 // increment past the faulting insn +resulting in insn + 8. + +That is, the palcode and the QEMU code have a disagreement about what the (private) API between them is. I'm not sure which side is wrong and should be corrected. I think the linux-user code assumes the same thing that translate.c is doing, so perhaps the palcode. + + +commit ac89de40ef5d4eb1704aa now in QEMU git master updates the palcode guest ROM blob to a version which includes the fix for this bug. + + +Works, thanks! + diff --git a/results/classifier/105/instruction/1812861 b/results/classifier/105/instruction/1812861 new file mode 100644 index 00000000..f6b68ed1 --- /dev/null +++ b/results/classifier/105/instruction/1812861 @@ -0,0 +1,41 @@ +instruction: 0.901 +device: 0.769 +semantic: 0.692 +socket: 0.564 +assembly: 0.548 +graphic: 0.532 +mistranslation: 0.528 +vnc: 0.455 +boot: 0.450 +network: 0.424 +other: 0.156 +KVM: 0.132 + +QEMU in user-mode emulation mode crashes when the user program jumps to an invalid address + +Running this code: + +void (*func)() = 0x12345678; + +int main() +{ + func(); + return 0; +} + +Produces the following output: + +qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +Segmentation fault + +The expected result is as follows: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + + + +I'm not sure exactly when we fixed this (the fix is probably in the 4.1 release) but as of current head-of-git this correctly generates the SIGSEGV. + + diff --git a/results/classifier/105/instruction/1813460 b/results/classifier/105/instruction/1813460 new file mode 100644 index 00000000..20c81762 --- /dev/null +++ b/results/classifier/105/instruction/1813460 @@ -0,0 +1,34 @@ +instruction: 0.824 +device: 0.666 +semantic: 0.513 +graphic: 0.512 +network: 0.445 +socket: 0.363 +mistranslation: 0.275 +vnc: 0.267 +boot: 0.233 +assembly: 0.224 +KVM: 0.214 +other: 0.169 + +qemu/target/arm/translate-a64.c:2039: bad test ? + +qemu/target/arm/translate-a64.c:2039]: (warning) Logical disjunction always evaluates to true: op3 != 2 || op3 != 3. + +Source code is + + if (op3 != 2 || op3 != 3) { + +Maybe better code + + if (op3 != 2 && op3 != 3) { + +Maybe using gcc flag -Wlogical-op might help find bugs like this in future. + +There is a patch on list for this: +https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06728.html + +Using the flag is a good idea. + +The patch is now in master. + diff --git a/results/classifier/105/instruction/1814343 b/results/classifier/105/instruction/1814343 new file mode 100644 index 00000000..9f35d310 --- /dev/null +++ b/results/classifier/105/instruction/1814343 @@ -0,0 +1,49 @@ +instruction: 0.886 +graphic: 0.881 +device: 0.786 +mistranslation: 0.752 +semantic: 0.721 +other: 0.699 +socket: 0.511 +network: 0.481 +vnc: 0.468 +boot: 0.445 +KVM: 0.418 +assembly: 0.346 + +Initrd not loaded on riscv32 + +I attempted to run qemu with a ram disk. However, when reading the contents of the disk from within the VM I only get back zeros. + +I was able to trace the issue to a mismatch of expectations on line 93 of hw/riscv/virt.c. Specifically, when running in 32-bit mode the value of kernel_entry is sign extended to 64-bits, but load_image_targphys expects the start address to not be sign extended. + +Straw man patch (works for 32-bit but would probably break 64-bit VMs?): + +diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c +index e7f0716fb6..32216f993c 100644 +--- a/hw/riscv/virt.c ++++ b/hw/riscv/virt.c +@@ -90,7 +90,7 @@ static hwaddr load_initrd(const char *filename, uint64_t mem_size, + * halfway into RAM, and for boards with 256MB of RAM or more we put + * the initrd at 128MB. + */ +- *start = kernel_entry + MIN(mem_size / 2, 128 * MiB); ++ *start = (kernel_entry & 0xffffffff) + MIN(mem_size / 2, 128 * MiB); + + size = load_ramdisk(filename, *start, mem_size - *start); + if (size == -1) { + + +Run command: + +$ qemu/build/riscv32-softmmu/qemu-system-riscv32 -machine virt -kernel mykernel.elf -nographic -initrd payload + +Commit hash: + +3a183e330dbd7dbcac3841737ac874979552cca2 + +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/105/instruction/1815024 b/results/classifier/105/instruction/1815024 new file mode 100644 index 00000000..03b24075 --- /dev/null +++ b/results/classifier/105/instruction/1815024 @@ -0,0 +1,40 @@ +instruction: 0.891 +device: 0.568 +semantic: 0.558 +socket: 0.532 +vnc: 0.525 +network: 0.462 +graphic: 0.386 +boot: 0.322 +assembly: 0.299 +other: 0.220 +KVM: 0.167 +mistranslation: 0.098 + +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/105/instruction/1815423 b/results/classifier/105/instruction/1815423 new file mode 100644 index 00000000..ff0339c5 --- /dev/null +++ b/results/classifier/105/instruction/1815423 @@ -0,0 +1,84 @@ +instruction: 0.667 +other: 0.490 +graphic: 0.458 +device: 0.442 +vnc: 0.394 +socket: 0.392 +network: 0.375 +boot: 0.337 +semantic: 0.333 +mistranslation: 0.326 +assembly: 0.284 +KVM: 0.144 + +x86_64 TCG: Incorrect floating point cast to int. + +I used exaample from: +https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c + +#include <stdio.h> +#include <math.h> + +int main(int argc, char** argv) { + float a = INFINITY; + float b = -INFINITY; + float c = NAN; + + printf("float %f %f %f\n", a, b, c); + printf("int %d %d %d\n", (int) a, (int) b, (int) c); + printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned int) c); + printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); + printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, (unsigned long int) c); + + return 0; +} + +And got different results on real computer and on qemu. + +output from real HW is the same as on stackoverflow: + +$ gcc test.c && ./a.out +float inf -inf nan +int -2147483648 -2147483648 -2147483648 +uint 0 0 0 +lint -9223372036854775808 -9223372036854775808 -9223372036854775808 +luint 0 9223372036854775808 9223372036854775808 + + +But on qemu I got another results: + +float inf -inf nan +int 2147483647 -2147483648 2147483647 +uint 4294967295 0 4294967295 +lint 9223372036854775807 -9223372036854775808 -9223372036854775808 +luint 18446744073709551615 9223372036854775808 9223372036854775807 + +qemu launch string: +/qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev user,id=network0 -device e1000,netdev=network0 -kernel my_kernel + + +qemu version: +x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +This bug affect some javascript (surprise) calculations: + +var conversion = "01234567890"; +var x; +var result = conversion[x & 42]; +console.log(result) + + +In example, var x is "undefined" +and when do calculation "x & 42" on js we should get 0 (it is documented feature), but actually got "42" + +and "result" sould be "0" but actually we got "undefined" + +https://<email address hidden>/ is a patch which fixes the C test case (and may also fix the node.js case, though I don't have a setup to test that). + + +This should be fixed by commit 1e8a98b53867f61da9, which will be in the 4.2 release. + + diff --git a/results/classifier/105/instruction/1815721 b/results/classifier/105/instruction/1815721 new file mode 100644 index 00000000..98bd9cb0 --- /dev/null +++ b/results/classifier/105/instruction/1815721 @@ -0,0 +1,86 @@ +instruction: 0.829 +other: 0.817 +device: 0.812 +semantic: 0.800 +vnc: 0.797 +graphic: 0.778 +network: 0.718 +KVM: 0.708 +assembly: 0.699 +boot: 0.696 +socket: 0.668 +mistranslation: 0.664 + +RISC-V PLIC enable interrupt for multicore + +Hello all, + +There is a bug in Qemu related to the enabling of external interrupts for multicores (Virt machine). + +After correcting Qemu as described in #1815078 (https://bugs.launchpad.net/qemu/+bug/1815078), when we try to enable interrupts for core 1 at address 0x0C00_2080 we don't seem to be able to trigger an external interrupt (e.g. UART0). + +This works perfectly for core 0, but fore core 1 it does not work at all. I assume that given bug #1815078 does not enable any external interrupt then this feature has not been tested. I tried to look at the qemu source code but with no luck so far. + +I guess the problem is related to function parse_hart_config (in sfive_plic.c) that initializes incorrectly the plic->addr_config[addrid].hartid, which is later on read in sifive_plic_update. But this is a guess. + +Best regards, +Pharos team + +Hi, + +After some debugging (and luck), the problem (at least in the Virt board) was that the PLIC code inside QEMU addresses the core x 2 instead of just the core (core=hart). That is why it worked for core 0 (0x2 = 0) but for core 1 it has to address the PLIC memory area for core 2. + +For example, the interrupt enable address for core 1 starts at offset 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc) but we actually have to change the enable bit for core 2 (at 0x002100) to make to work for core 1. + +The same is true for the priority threshold and claim complete registers (we need to multiply the core by 2) + +Either the documentation at https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc does not have the correct memory addresses for qemu virt board, or qemu appears to be wrong. + +On Tue, Mar 24, 2020 at 4:20 PM RTOS Pharos <email address hidden> wrote: +> +> Hi, +> +> After some debugging (and luck), the problem (at least in the Virt +> board) was that the PLIC code inside QEMU addresses the core x 2 instead +> of just the core (core=hart). That is why it worked for core 0 (0x2 = 0) +> but for core 1 it has to address the PLIC memory area for core 2. +> +> For example, the interrupt enable address for core 1 starts at offset +> 0x002080 (see https://github.com/riscv/riscv-plic-spec/blob/master +> /riscv-plic.adoc) but we actually have to change the enable bit for core +> 2 (at 0x002100) to make to work for core 1. + + +https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc says: + +"base + 0x002080: Enable bits for sources 0-31 on context 1" + +This is context 1, not core 1. + +It looks to me you were running an image built for SiFive FU540. +Please test your image against "sifive_u" machine instead. + +> +> The same is true for the priority threshold and claim complete registers +> (we need to multiply the core by 2) +> +> Either the documentation at https://github.com/riscv/riscv-plic- +> spec/blob/master/riscv-plic.adoc does not have the correct memory +> addresses for qemu virt board, or qemu appears to be wrong. +> +> -- + +Regards, +Bin + + +Thank you for the explanation. I actually built it for "Virt" machine. I'll try the "sifive_u" when I can. + +But I guess your explanation is correct so this bug could be closed from my part. + +Hello as far as I can tell, there is a major problem with PLIC implementation. When decompiling DTB on virt board with X harts, I see that hartid 0 has MEI and SEI, hartid 1 has MEI and SEI, etc... But when configuring context 1 (hartid 0 SEI) no interrupt is generated, but context 0, 2, 4 etc... work. So for me the problem is within PLIC or RISC-V implementation... If anyone wants to correct it, I can help. Best regards. Serge Teodori + +I'm going to close this bug as it seems like the issue that RTOS Pharos raised is not an issue. + +@Teodori Serge please open a new issue if you have a bug. Make sure to include as much detail as possible and steps to reproduce it. + diff --git a/results/classifier/105/instruction/1816614 b/results/classifier/105/instruction/1816614 new file mode 100644 index 00000000..be2b52d7 --- /dev/null +++ b/results/classifier/105/instruction/1816614 @@ -0,0 +1,42 @@ +instruction: 0.902 +other: 0.806 +mistranslation: 0.659 +device: 0.655 +semantic: 0.650 +graphic: 0.647 +socket: 0.464 +vnc: 0.436 +network: 0.436 +KVM: 0.416 +boot: 0.331 +assembly: 0.244 + +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/105/instruction/1817268 b/results/classifier/105/instruction/1817268 new file mode 100644 index 00000000..e1d26571 --- /dev/null +++ b/results/classifier/105/instruction/1817268 @@ -0,0 +1,208 @@ +instruction: 0.917 +graphic: 0.914 +boot: 0.911 +assembly: 0.907 +other: 0.905 +device: 0.902 +semantic: 0.900 +socket: 0.880 +vnc: 0.878 +KVM: 0.832 +network: 0.815 +mistranslation: 0.806 + +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/105/instruction/1818075 b/results/classifier/105/instruction/1818075 new file mode 100644 index 00000000..26b345c1 --- /dev/null +++ b/results/classifier/105/instruction/1818075 @@ -0,0 +1,133 @@ +instruction: 0.940 +graphic: 0.906 +assembly: 0.878 +other: 0.877 +device: 0.848 +KVM: 0.820 +vnc: 0.809 +network: 0.800 +semantic: 0.791 +socket: 0.778 +mistranslation: 0.773 +boot: 0.655 + +qemu x86 TCG doesn't support AVX insns + +I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. + +Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +IN: +0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 +0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx +0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx +0x4000b4ef47: 48 85 d2 testq %rdx, %rdx +0x4000b4ef4a: 79 9e jns 0x4000b4eeea + +[ hangs ] + +Attaching a gdb produces this stacktrace: + +(gdb) bt +#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 +#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 +#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 +#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 +#4 0x000055a20cfcfea8 in static_code_gen_buffer () +#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 +#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 + +<pm215> my guess is we're doing something unhelpful with the AVX insn, and so the guest code which is checking the result and using it as its loop condition for the jns is just looping forever + +<rburton> in_asm log just stopped with this as the last line +<rburton> 0x4000b4ef4a: 79 9e jns 0x4000b4eeea + + +Further debugging on IRC reveals that QEMU itself is not hanging, but the guest code is looping infinitely, because QEMU doesn't implement the AVX instruction set and isn't generating an undefined-instruction exception either. So the %rdx output from the AVX insn is wrong and the guest code never exits the loop (whose condition depends on %rdx). + +We should ideally: + * make the x86 decoder properly handle insns that don't exist for the CPU being emulated (not too difficult, but doesn't actually help in running this test program) + * implement AVX (a fair chunk of effort; it is being proposed as a GSoC project for this summer) + + +If I may be so free: + +It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. + +My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. +Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. + +If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. earlier versions of MacOS. + +Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: +-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc + +Attempting to emulate a more feature laden intel CPU results in even more issues. + +I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it. + +We do care about emulation; but as always with open source software projects, the parts that get more care and attention are the parts that people are either paid to work on or are personally interested in. x86 guest emulation in particular is not very well maintained (though it is better than some targets), because mostly people are happy to use x86 hardware, and adding support for emulation of large new architectural features like AVX is a lot of work. If you would like to help improve x86 guest emulation, you are welcome to submit patches to fix bugs or add new features. Merely saying "X should be better and you should somehow magically find three months worth of developer time to make it so" doesn't really do anything to move the situation forwards. + + +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. Thus simply declaring that an open source project, must support something won't magically make it happen. + +IOW, the lack of coverage of newer x86 instructions is largely a reflection of the relative priorities of the current pool of contributors and where/what they feel are the best places/features to spend their time on. + +If any person does want to work on improving x86 TCG though, the project would happily receive patches, and existing contributors can offer guidance & advice along the way to help get to a successful outcome. + + +Of course it’s open source, I get that. When I say „xyz should be done“ then in the sense of „2+2 should be 4“ not in the sense of „you must implement xyz right now“ ;) + +Nonetheless, if you run e.g. on an ARM platform the command + +qemu-system-x86_64 -cpu help + +then it shouldn’t list a slew of CPUs as „available“ that clearly aren’t working. + +It should then list fully implemented CPUs separately from partially implemented CPUs (if listing them at all), and if it does list incomplete implementations, it should indicate what’s missing. +It’s just a horrible user experience, if based on such output, one spends significant time trying to get some emulation running, only to then discover from runtime error messages, that an „available“ CPU isn’t actually available. + + +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/164 + + diff --git a/results/classifier/105/instruction/1820686 b/results/classifier/105/instruction/1820686 new file mode 100644 index 00000000..f7fd19f6 --- /dev/null +++ b/results/classifier/105/instruction/1820686 @@ -0,0 +1,25 @@ +instruction: 0.949 +device: 0.824 +network: 0.809 +other: 0.742 +socket: 0.724 +semantic: 0.691 +vnc: 0.683 +mistranslation: 0.678 +graphic: 0.598 +boot: 0.498 +KVM: 0.321 +assembly: 0.305 + +risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' + +QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. + +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. + + + +Thanks. If you spin a full patch (ie, "git commit -s" and then "git show") I can drop it on riscv-qemu-3.1, our backports branch. Otherwise hopefully we got the bug via the decodetree conversion. + +Since this bug isn't present in the decodetree version of the riscv decoder, we might as well just close this as fix-released; we won't be doing more point-releases of QEMU versions as old as 3.1. + diff --git a/results/classifier/105/instruction/1824344 b/results/classifier/105/instruction/1824344 new file mode 100644 index 00000000..9886d36a --- /dev/null +++ b/results/classifier/105/instruction/1824344 @@ -0,0 +1,71 @@ +instruction: 0.928 +assembly: 0.842 +device: 0.543 +semantic: 0.396 +network: 0.367 +socket: 0.356 +other: 0.327 +boot: 0.303 +vnc: 0.251 +graphic: 0.236 +mistranslation: 0.196 +KVM: 0.008 + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> + + + +This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler) + + +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/265 + + diff --git a/results/classifier/105/instruction/1824778 b/results/classifier/105/instruction/1824778 new file mode 100644 index 00000000..d9e3e95d --- /dev/null +++ b/results/classifier/105/instruction/1824778 @@ -0,0 +1,30 @@ +instruction: 0.756 +device: 0.493 +semantic: 0.280 +graphic: 0.275 +network: 0.264 +other: 0.245 +boot: 0.202 +vnc: 0.194 +socket: 0.151 +mistranslation: 0.124 +KVM: 0.054 +assembly: 0.052 + +PowerPC64: tlbivax does not work for addresses above 4G + +The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. +Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. + +I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. + +Issue can be seen in all version of QEMU. + + +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/52 + + diff --git a/results/classifier/105/instruction/1825 b/results/classifier/105/instruction/1825 new file mode 100644 index 00000000..197522df --- /dev/null +++ b/results/classifier/105/instruction/1825 @@ -0,0 +1,27 @@ +instruction: 0.779 +device: 0.751 +graphic: 0.738 +semantic: 0.636 +other: 0.450 +network: 0.409 +vnc: 0.341 +mistranslation: 0.269 +socket: 0.263 +boot: 0.256 +KVM: 0.035 +assembly: 0.031 + +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/105/instruction/1825002 b/results/classifier/105/instruction/1825002 new file mode 100644 index 00000000..064fcfa8 --- /dev/null +++ b/results/classifier/105/instruction/1825002 @@ -0,0 +1,194 @@ +instruction: 0.697 +other: 0.658 +network: 0.654 +assembly: 0.646 +device: 0.596 +graphic: 0.563 +socket: 0.557 +mistranslation: 0.495 +semantic: 0.467 +vnc: 0.434 +KVM: 0.398 +boot: 0.379 + +"qemu: Unexpected FPU mode" since 0c1bbedc10e86ea9366b6af8c5520fafa3266b2f + +This happens every time I attempt to chroot into a gentoo-mips image unless I load the executable via ld.so + +/home (root)# chroot gentoo-mips32r2el /bin/sh +qemu: Unexpected FPU mode +/home (root)# chroot gentoo-mips32r2el /lib/ld-2.19.so /bin/sh +sh-4.2# exit +/home (root)# + +I don't know the underlying cause, but keep in mind that we may lie and claim to have an FPU when our CPU doesn't because of kernel emulation that may not be present in the host kernel. Don't know if that's related. + +I get this with various gentoo-mips stage3 tarballs, but not with OpenWRT. (e.g., https://gentoo.osuosl.org/experimental/mips/stages/mips32r2el/2014) + + + +# emerge --info app-emulation/qemu +Portage 2.3.51 (python 3.6.5-final-0, default/linux/amd64/17.0/desktop/plasma, gcc-8.2.0, glibc-2.27-r6, 4.14.96-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-4.14.96-gentoo-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.6 +KiB Mem: 32890732 total, 3480024 free +KiB Swap: 16777212 total, 10575592 free +Timestamp of repository gentoo: Thu, 11 Apr 2019 06:00:01 +0000 +Head commit of repository gentoo: 66eaaa28926103e690db0699466a274a17ab1979 +sh bash 4.4_p23-r1 +ld GNU ld (Gentoo 2.30 p5) 2.30.0 +distcc 3.3.2 x86_64-pc-linux-gnu [disabled] +ccache version 3.3.4 [disabled] +app-shells/bash: 4.4_p23-r1::gentoo +dev-java/java-config: 2.2.0-r4::gentoo +dev-lang/perl: 5.26.2::gentoo +dev-lang/python: 2.7.15::gentoo, 3.6.5::gentoo +dev-util/ccache: 3.3.4-r1::gentoo +dev-util/cmake: 3.9.6::gentoo +dev-util/pkgconfig: 0.29.2::gentoo +sys-apps/baselayout: 2.6-r1::gentoo +sys-apps/openrc: 0.38.3-r1::gentoo +sys-apps/sandbox: 2.13::gentoo +sys-devel/autoconf: 2.13-r1::gentoo, 2.64-r1::gentoo, 2.69-r4::gentoo +sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo +sys-devel/binutils: 2.30-r4::gentoo +sys-devel/gcc: 4.9.4::gentoo, 5.4.0-r6::gentoo, 6.4.0-r5::gentoo, 7.3.0-r6::gentoo, 8.1.0-r3::gentoo, 8.2.0-r6::gentoo, 8.3.0::gentoo +sys-devel/gcc-config: 2.0::gentoo +sys-devel/libtool: 2.4.6-r3::gentoo +sys-devel/make: 4.2.1-r4::gentoo +sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers) +sys-libs/glibc: 2.27-r6::gentoo +Repositories: + +gentoo + location: /usr/portage + sync-type: rsync + sync-uri: rsync://rsync.gentoo.org/gentoo-portage + priority: -1000 + sync-rsync-verify-jobs: 1 + sync-rsync-extra-opts: + sync-rsync-verify-metamanifest: yes + sync-rsync-verify-max-age: 24 + +love-local + location: /usr/local/portage + masters: gentoo + priority: 0 + +chaoslab + location: /var/lib/layman/chaoslab + masters: gentoo + priority: 50 + +java + location: /var/lib/layman/java + masters: gentoo + priority: 50 + +steam-overlay + location: /var/lib/layman/steam-overlay + masters: gentoo + priority: 50 + +zugaina + location: /var/lib/layman/zugaina + masters: gentoo + priority: 50 + +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-march=native -O2 -ggdb3 -pipe" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" +CXXFLAGS="-march=native -O2 -ggdb3 -pipe" +DISTDIR="/mnt/large/distfiles" +EMERGE_DEFAULT_OPTS="-j3 --load-average=17.5 --with-bdeps=y --autounmask=n" +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs buildpkg candy cgroup compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog split-log splitdebug strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.osuosl.org/ http://mirrors.rit.edu/gentoo/ http://gentoo.cs.uni.edu/ http://gentoo.osuosl.org/ " +LANG="en_US.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed" +LINGUAS="en en-US en_US" +MAKEOPTS="-j15 --load-average=17" +PKGDIR="/mnt/large/packages" +PORTAGE_COMPRESS="pxz" +PORTAGE_COMPRESS_FLAGS="-9e" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" +PORTAGE_TMPDIR="/tmp" +USE="X a52 aac aacs acl acpi activities aes aio alsa amd64 amr avx avx2 bcache berkdb bluetooth bluray branding bzip2 cairo cdda cddb cdio cdr celt cli consolekit crypt cups cxx d3d9 dbus declarative designer device-mapper dirac directfb dot dri dts dvd dvdr emboss encode exif f16c fam ffmpeg fftw flac fluidsynth fma3 fontconfig fortran fuse gdbm geolocation gif git glamor go gphoto2 gpm gps graphite graphviz gsm gstreamer gtk hardened hddtemp highlight iconv icu ipv6 jpeg jpeg2k kde kerberos kipi kwallet lame latex lcms ldap libass libcaca libnotify libsamplerate libtirpc lm_sensors lto lvm lz4 lzma lzo mad matroska midi mjpeg mmx mmxext mng mono mp3 mp4 mpeg mtp multicall multilib multitarget musepack natspec ncurses netlink networkmanager nfs nls nptl nsplugin ogg openal openexr opengl openh264 openmp openssl opus osmesa pam pango pcap pch pclmul pcre pdf perl pgo phonon plasma playlist png policykit popcnt postgres postproc ppds pulseaudio python qml qt5 rar raw readline samba sasl savedconfig scanner schroedinger sdl seccomp sensors sid smp snappy speex spell spice sqlite sqlite3 squashfs sse sse2 sse3 sse4_1 sse4_2 sse4a ssh ssl ssse3 startup-notification static-libs subversion svg syslog systemtap taglib tcpd theora threads tiff timidity tools tremor truetype tty-helpers twolame udev udisks unicode upnp-av upower usb usbredir utils v4l vaapi valgrind vcdx vdpau vim-syntax virt-network virtio vlc vorbis vpx webdav webp widgets wxwidgets x264 x265 xattr xcb xcomposite xen xine xml xspice xv xvid xvmc zeroconf zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc coreboot emu multiboot qemu xen" INPUT_DEVICES="keyboard mouse joystick evdev wacom vmmouse" KERNEL="linux" L10N="en en-US en_US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="AMDGPU ARM BPF NVPTX Mips X86" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" QEMU_SOFTMMU_TARGETS="aarch64 arm armeb i386 hppa m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64" QEMU_USER_TARGETS="aarch64 arm armeb i386 hppa m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="radeon radeonsi vesa qxl vmware amdgpu" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-3.1.0-r4::gentoo was built with the following: +USE="aio alsa bzip2 caps curl fdt filecaps gtk jpeg lzo ncurses nfs nls opengl pin-upstream-blobs png pulseaudio python sasl sdl seccomp snappy spice ssh static-user systemtap usb usbredir vde vhost-net virtfs vnc vte xattr xen -accessibility (-capstone) -debug (-glusterfs) -gnutls -infiniband -iscsi -numa -rbd (-selinux) -smartcard (-static) -tci -test -virgl -xfs" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 -python3_5 (-python3_7)" QEMU_SOFTMMU_TARGETS="aarch64 arm hppa i386 m68k microblaze microblazeel mips mips64 mips64el mipsel ppc ppc64 s390x sparc sparc64 x86_64 -alpha -cris -lm32 -moxie -nios2 -or1k -riscv32 -riscv64 -sh4 -sh4eb -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="aarch64 arm armeb hppa i386 m68k microblaze microblazeel mips mips64 mips64el mipsel mipsn32 mipsn32el ppc ppc64 ppc64abi32 ppc64le s390x sparc sparc32plus sparc64 x86_64 -aarch64_be -alpha -cris -nios2 -or1k -riscv32 -riscv64 -sh4 -sh4eb -tilegx -xtensa -xtensaeb" + +>>> Attempting to run pkg_info() for 'app-emulation/qemu-3.1.0-r4' +Using: + app-emulation/spice-protocol-0.12.14 + sys-firmware/edk2-ovmf-2017_p20180211 + USE=binary + sys-firmware/ipxe-1.0.0_p20180211 + sys-firmware/seabios-1.11.0 + USE=binary + sys-firmware/sgabios-0.1_pre8-r1 + +The check in target_cpu_copy_regs at linux-user/mips/cpu_loop.c:776 Is reading an uninitialized value: + + if ((info->fp_abi > MAX_FP_ABI && info->fp_abi != MIPS_ABI_FP_UNKNOWN) + || (info->interp_fp_abi > MAX_FP_ABI && + info->interp_fp_abi != MIPS_ABI_FP_UNKNOWN)) { + fprintf(stderr, "qemu: Unexpected FPU mode\n"); + exit(1); + } + +info->interp_fp_abi is actually initialized, but by reading a value that isn't. It was previously 0x601de662 at the above if statement, but when I add this memset to load_elf_binary... + +int load_elf_binary(struct linux_binprm *bprm, struct image_info *info) +{ + struct image_info interp_info; + struct elfhdr elf_ex; + char *elf_interpreter = NULL; + char *scratch; + + memset(&interp_info, 0xfd, sizeof(interp_info)); + +... then it is 0xfdfdfdfd. + + + +In load_elf_binary (linux-user/elfload.c b/linux-user/elfload.c:2644) the entire interp_info struct should be inited, I would call this a CVE. At a very minimum, init the fp_abi field so we don't use whatever happened to be on the stack for the FPU mode should the ELF header not specify otherwise. + +Please send patches to the mailing list for inclusion. QEMU maintainers normally don't take patches from the bug tracker. See https://wiki.qemu.org/Contribute/SubmitAPatch + +Actually, this is a better patch. Let's sanitize struct image_info interp_info. + +This is certainly a bug, but it's not a a CVE, ie not a security bug. The entire purpose of the linux-user mode is to run the guest ELF file and let it perform whatever syscalls it likes -- it doesn't need to exploit any kind of bug in the ELF loader to be able to control what the process is doing. + + +Thanks Peter. I was just reading up on the CVE process and I agree. Obviously, it's dangerous to use uninitialized values, but that doesn't necessarily make it a vulnerability. + +And thank you Thomas for the instructions! + +Fix posted on the list: +https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04037.html + +A fix for this was committed as abcac736c1505254ec3 and will be in the upcoming 4.1 release. + +FWIW I am still seeing a similar failure with 5.1.0rc3 (using a "Hello World" like program in Ubuntu 20.04 x86_64 built statically): + +$ mipsisa32r6el-linux-gnu-gcc --static -o h h.c +$ ./qemu-mipsn32el ./h +qemu: Unexpected FPU mode + +big endian also seems to be affected + diff --git a/results/classifier/105/instruction/1825311 b/results/classifier/105/instruction/1825311 new file mode 100644 index 00000000..df058a86 --- /dev/null +++ b/results/classifier/105/instruction/1825311 @@ -0,0 +1,70 @@ +instruction: 0.754 +device: 0.732 +graphic: 0.681 +network: 0.660 +socket: 0.640 +assembly: 0.637 +vnc: 0.606 +mistranslation: 0.604 +semantic: 0.557 +boot: 0.506 +KVM: 0.415 +other: 0.381 + +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/105/instruction/1825359 b/results/classifier/105/instruction/1825359 new file mode 100644 index 00000000..49e0ba1d --- /dev/null +++ b/results/classifier/105/instruction/1825359 @@ -0,0 +1,200 @@ +instruction: 0.814 +other: 0.812 +semantic: 0.811 +graphic: 0.809 +assembly: 0.786 +vnc: 0.759 +device: 0.753 +mistranslation: 0.719 +network: 0.683 +KVM: 0.681 +socket: 0.669 +boot: 0.601 + +cpu_ld*_code() triggers MMU_DATA_LOAD i.s.o. MMU_INST_FETCH + +commit 377b155bde451d5ac545fbdcdfbf6ca17a4228f5 +Merge: c876180938 328eb60dc1 +Author: Peter Maydell <peter.x@x.x> ; masked for anti-spamming purposes +Date: Mon Mar 11 18:26:37 2019 +0000 +https://github.com/qemu/qemu/commit/377b155bde451d5ac545fbdcdfbf6ca17a4228f5 +-------------------------------------------------- + +cpu_ld*_code() is used for loading code data as the name suggests. Although, it begins +accessing memory with MMU_INST_FETCH access type, somewhere down the road, when the +"io_readx(..., access_type=MMU_INST_FETCH, ...)" is called, it is ignoring this "access_type" +while calling the "tlb_fill()" with a _hardcoded_ MMU_DATA_LOAD: + +cputlb.c +-------- +static uint64_t io_readx(..., MMUAccessType access_type, ...) +{ + + if (recheck) { + CPUTLBEntry *entry; + target_ulong tlb_addr; + + tlb_fill(cpu, addr, size, MMU_DATA_LOAD, mmu_idx, retaddr); + ... +} +-------- + +This is an issue, because there can exist _small_ regions of memory (smaller than the +TARGET_PAGE_SIZE) that are only executable and not readable. + +TL;DR + +What happens is at first, a "tlb_fill(..., access_type=MMU_INST_FETCH, ...)" is +triggered by "tb_lookup_cpu_state()". To be precise, this is the call stack which is good behavior: +--- +#0 tlb_fill (cs=..., vaddr=684, size=0, access_type=MMU_INST_FETCH, mmu_idx=0, retaddr=0) at target/arc/mmu.c:602 +#1 get_page_addr_code (env=..., addr=684) at accel/tcg/cputlb.c:1045 +#2 tb_htable_lookup (cpu=..., pc=684, cs_base=0, flags=0, cf_mask=4278190080) at accel/tcg/cpu-exec.c:337 +#3 tb_lookup__cpu_state (cpu=..., pc=..., cs_base=..., flags=..., cf_mask=4278190080) at include/exec/tb-lookup.h:43 +#4 tb_find (cpu=..., last_tb=... <code_gen_buffer+17811>, tb_exit=0, cf_mask=0) at accel/tcg/cpu-exec.c:404 +#5 cpu_exec (cpu=...) at accel/tcg/cpu-exec.c:729 +#6 tcg_cpu_exec (cpu=...) at cpus.c:1430 +#7 qemu_tcg_rr_cpu_thread_fn (arg=...) at cpus.c:1531 +#8 qemu_thread_start (args=...) at util/qemu-thread-posix.c:502 +--- + +After this call, TLB is filled with an entry that its size field is small, say 32 bytes. +This causes a TLB_RECHECK for consequent memory accesses, which is logical. However, +in our decoder, we use cpu_lduw_code() to read the instructions and decode them. As mentioned, +in the beginning, the access_type=MMU_INST_FETCH is lost in "io_readx()" while calling "tlb_fill()", +and now THIS CAUSES A GUEST EXCEPTION BECAUSE THAT REGION IS NOT ALLOWED TO BE READ. Here, +comes that trace call of the _bad_ behavior: +--- +#0 tlb_fill (..., access_type=MMU_DATA_LOAD, ...) at target/arc/mmu.c:605 +#1 io_readx (..., access_type=MMU_INST_FETCH, size=2) at accel/tcg/cputlb.c:881 +#2 io_readw (..., access_type=MMU_INST_FETCH) at accel/tcg/softmmu_template.h:106 +#3 helper_le_ldw_cmmu (..., oi=16, retaddr=0) at accel/tcg/softmmu_template.h:146 +#4 cpu_lduw_code_ra (env=..., ptr=684, retaddr=0) at include/exec/cpu_ldst_template.h:102 +#5 cpu_lduw_code (env=..., ptr=684) at include/exec/cpu_ldst_template.h:114 +#6 read_and_decode_context (ctx=..., opcode_p=...) at target/arc/arc-decoder.c:1479 +#7 arc_decode (ctx=...) at target/arc/arc-decoder.c:1736 +#8 decode_opc (env=..., ctx=...) at target/arc/translate.c:313 +#9 arc_tr_translate_insn (dcbase=..., cpu=...) at target/arc/translate.c:335 +#10 translator_loop (.. <code_gen_buffer+18131>) at accel/tcg/translator.c:107 +#11 gen_intermediate_code (cpu=..., tb=... <code_gen_buffer+18131>) at target/arc/translate.c:413 +#12 tb_gen_code (cpu=..., pc=684, cs_base=0, flags=0, cflags=-16711679) at accel/tcg/translate-all.c:1723 +#13 tb_find (cpu=..., last_tb=... <code_gen_buffer+17811>, tb_exit=0, cf_mask=0) at accel/tcg/cpu-exec.c:407 +#14 cpu_exec (cpu=...) at accel/tcg/cpu-exec.c:729 +#15 tcg_cpu_exec (cpu=...) at cpus.c:1430 + +--- + +Do you confirm if this is an issue? Maybe there are other ways to read an instruction with +MMU_INST_FETCH access that I don't know about. + +Last but not least, although this is not a security issue for QEMU per se, but it is hindering a +security feature for the guest. + +Yeah, this looks like a bug -- we should pass the access_type through rather than using MMU_DATA_LOAD. + + +Should I make a patch then? + + + + + + +The patch looks OK code-wise, but could you submit it to the mailing list, please? +https://wiki.qemu.org/Contribute/SubmitAPatch has the details, but the most important part is that it needs a Signed-off-by: line from you that says you have the legal right and are willing to contribute it to QEMU under our license. Otherwise we can't use the patch. + + +I have to say, after applying this patch, my test still fails while fetching the instructions from this _small_ region. Although there is no MMU_DATA_LOAD anymore, a few iterations later (while guest code has just jumped to the beginning of the executable region), QEmu segfaults (call stack is attached): + +memory.c +-------- +static MemTxResult +memory_region_read_with_attrs_accessor(MemoryRegion *mr, + ...) +{ + uint64_t tmp = 0; + MemTxResult r; + + r = mr->ops->read_with_attrs(mr->opaque, addr, &tmp, size, attrs); + ... +} +-------- + +Here, "read_with_attrs" is null. The call stack looks like: +--- +#0 memory_region_read_with_attrs_accessor at memory.c:465 +#1 access_with_adjusted_size at memory.c:568 +#2 memory_region_dispatch_read1 at memory.c:1425 +#3 memory_region_dispatch_read at memory.c:1446 +#4 io_readx at accel/tcg/cputlb.c:909 +#5 io_readw at accel/tcg/softmmu_template.h:106 +#6 helper_le_ldw_cmmu at accel/tcg/softmmu_template.h:146 +#7 cpu_lduw_code_ra at include/exec/cpu_ldst_template.h:102 +#8 cpu_lduw_code at include/exec/cpu_ldst_template.h:114 +#9 read_and_decode_context at target/arc/arc-decoder.c:1479 +#10 arc_decode at target/arc/arc-decoder.c:1736 +#11 decode_opc at target/arc/translate.c:313 +#12 arc_tr_translate_insn at target/arc/translate.c:335 +#13 translator_loop at accel/tcg/translator.c:107 +#14 gen_intermediate_code at target/arc/translate.c:413 +#15 tb_gen_code at accel/tcg/translate-all.c:1723 +#16 tb_find at accel/tcg/cpu-exec.c:407 +#17 cpu_exec at accel/tcg/cpu-exec.c:729 +#18 tcg_cpu_exec at cpus.c:1430 +--- +more detailed call stack is attached. + +call stack for SEGFAULT that happens during the execution of small region. This will go away IF THE ENTRY ADDED TO TLB FOR THIS REGION IS OF SIZE TARGET_PAGE_SIZE. However, that would not be correct behavior. + +That should not happen unless you have some device that is incorrectly not providing a suitable read function in its MemoryRegionOps. If you look at 'mr' in the debugger you should be able to figure out which device is the problem. + + +The problem seems to be this piece of code: + +cputlb.c +-------- +static uint64_t io_readx(...) +{ + + if (recheck) { + ... + + tlb_fill(cpu, addr, size, MMU_DATA_LOAD, mmu_idx, retaddr); + + entry = tlb_entry(env, mmu_idx, addr); + tlb_addr = entry->addr_read; + ... +} +-------- + +"entry->addr_read" is indeed looking for a "reading address". in this case, it must look for an +"executing address", i.e. "entry->addr_code". + +I see softmmu_template.h does something like this: +---- +... +#ifdef SOFTMMU_CODE_ACCESS +#define READ_ACCESS_TYPE MMU_INST_FETCH +#define ADDR_READ addr_code +#else +#define READ_ACCESS_TYPE MMU_DATA_LOAD +#define ADDR_READ addr_read +#endif +... + +WORD_TYPE helper_le_ld_name(...) +{ + ... + target_ulong tlb_addr = entry->ADDR_READ; + ... +} +---- + +This patch has fixed for me both issues. Although I am not very proud of the changes in the second hunk. Please let me know if there is a better way. + + +Your patch is now in git master as commit ef5dae6805cce7b59d129 -- thanks! + + +Thank YOU for all the supports along the way :) + diff --git a/results/classifier/105/instruction/1826568 b/results/classifier/105/instruction/1826568 new file mode 100644 index 00000000..7542ba2a --- /dev/null +++ b/results/classifier/105/instruction/1826568 @@ -0,0 +1,50 @@ +instruction: 0.909 +mistranslation: 0.703 +other: 0.593 +device: 0.565 +semantic: 0.515 +socket: 0.288 +network: 0.230 +assembly: 0.222 +vnc: 0.206 +graphic: 0.178 +boot: 0.090 +KVM: 0.048 + +RISC-V Disassembler/translator instruction decoding disagreement + + +When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: + + 0x000000008002cade: 051300009517e2bf illegal + Disassembler disagrees with translator over instruction decoding + Please report this to <email address hidden> + + +You may want to resolve the disagreement. + +Axel + +Hi Axel, + +can you link us to your test code, such that we can try to reproduce it. + +Cheers, +Bastian + +Sorry, I don't have the test code, since this was created by a memory corruption. However, the way I understand the message is, that there is some internal disagreement how to decode the op-code "051300009517e2bf" - which mige be an invalid opcode anyway. So a simple test application would just consist of this opcode. + +I've encountered this message before for invalid instructions, and it often doesn't really mean there was an error. In particular for variable instruction length ISAs you'll see the error if the translator reads part of the insn and determines that it's invalid without needing to read the rest of it -- https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06845.html talks about a case of that for x86. + + +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/53 + + diff --git a/results/classifier/105/instruction/1828507 b/results/classifier/105/instruction/1828507 new file mode 100644 index 00000000..edcf5b70 --- /dev/null +++ b/results/classifier/105/instruction/1828507 @@ -0,0 +1,78 @@ +instruction: 0.758 +graphic: 0.679 +device: 0.671 +other: 0.655 +network: 0.600 +boot: 0.561 +semantic: 0.550 +socket: 0.508 +assembly: 0.445 +vnc: 0.435 +mistranslation: 0.391 +KVM: 0.163 + +qemu-system-ppc64 smp crash on manual reset + +Host Environment: + x86_64 Linux v5.0.2 + QEMU emulator version 4.0.50 (v4.0.0-354-g812b835fb4) + SLOF: + Build Date = Jan 14 2019 18:00:39 + FW Version = git-a5b428e1c1eae703 + +Problem: Qemu crash immediately after a manual reset + (this is not the initial reset which launches the guest). + +Steps: + +1. Download Debian ppc64el mini.iso: + http://ftp.debian.org/debian/dists/sid/main/installer-ppc64el/current/images/netboot/mini.iso +2. Run qemu on the host. Ensure that it runs with more than one CPUs. With a single CPU, I was unable + to reproduce the crash. + qemu-system-ppc64 -M pseries -cpu power9 -smp 2 -m 512 -cdrom mini.iso +3. SLOF prints the version info on the serial device, and proceeds to boot. +4. After a few seconds, the GRUB menu appears on the VGA screen. +5. Select one of the install options (I have tested with Default and Expert), and wait + for the Debian's text-mode installer (blue-gray-red) screen to appear. +6. Click Machine->Reset (or enter system_reset on the qemu monitor). +7. Notice that, on the serial device, SLOF has printed the version info. That is, the system + has reset and is attempting to boot again. +8. On the host cmd prompt, qemu dies after printing this fatal error and spewing the + contents of the CPU registers: + + qemu: fatal: Trying to deliver HV exception (MSR) 70 with no HV support + <CPU contents> (See attached out.txt for details) + Aborted (core dumped) + + +The HV exception is either + (a) 70 = HISI, which occurs when NIP contains an outright bogus or inaccessible value, or + (b) 69 = HDSI, which occurs when NIP happens to contain a somewhat saner value, and + the cpu attempts to run the instruction at that address. + +The exception can occur on either of the CPUs. It occurs when qemu is running the SLOF +code. + + + +If one continues with the iso, and installs the OS in the +guest, the rebooting of the guest from within the guest +OS too causes qemu to exit fatally. So, one can run +'systemctl reboot' or 'reboot' within the guest OS and +see qemu crash (immediately after SLOF prints version, +etc. as part of the reboot sequence, as described before). + +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/105/instruction/1828867 b/results/classifier/105/instruction/1828867 new file mode 100644 index 00000000..05260e5d --- /dev/null +++ b/results/classifier/105/instruction/1828867 @@ -0,0 +1,48 @@ +instruction: 0.527 +device: 0.454 +socket: 0.435 +mistranslation: 0.388 +assembly: 0.285 +network: 0.264 +vnc: 0.258 +graphic: 0.231 +semantic: 0.225 +boot: 0.171 +other: 0.169 +KVM: 0.124 + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" + + + +Here's also a basic test that can be run on hardware and have rflags and rsp inspected after each instruction just to see how hardware doesn't effect it. + +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 is still relevant. + + +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/130 + + diff --git a/results/classifier/105/instruction/1830031 b/results/classifier/105/instruction/1830031 new file mode 100644 index 00000000..7cfee416 --- /dev/null +++ b/results/classifier/105/instruction/1830031 @@ -0,0 +1,111 @@ +instruction: 0.942 +device: 0.914 +semantic: 0.904 +mistranslation: 0.896 +other: 0.890 +graphic: 0.879 +assembly: 0.871 +socket: 0.833 +network: 0.802 +vnc: 0.793 +boot: 0.791 +KVM: 0.785 + +fatal error: float32nan on QEmu 3.1 + +Docker throws float32nan errors when running alpine container on a CentOS 7.6 ppc64le Distro VM, when using Fedora 30 Host qemu 3.1. I Compiled qemu 2.11.2 on the Fedora 30 and using this qemu-system-ppc64 we don't see the error. Even using qemu 3.1 and machine 2.11 we still get the same issue. + +Nothing changed on the OS level on the two runs. just the qemu-system-ppc64 used to run the virtual machine. + + Docker on CentOS 7: docker.ppc64le 2:1.13.1-96 + +Running with qemu 2.11.2 behavior and machine 2.11: +[root@machine ~]# /usr/local/bin/qemu-system-ppc64 -version +QEMU emulator version 2.11.2(qemu-2.11.2-5.fc30) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +[root@powericp ~]# docker run -i -t alpine /bin/sh +/ # exit +[root@powericp ~]# uname -a +Linux powericp 3.10.0-957.12.2.el7.ppc64le #1 SMP Tue May 14 22:24:22 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux +[root@powericp ~]# docker version +Client: + Version: 1.13.1 + API version: 1.26 + Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.ppc64le + Go version: go1.10.3 + Git commit: b2f74b2/1.13.1 + Built: Wed May 1 15:05:41 2019 + OS/Arch: linux/ppc64le +… +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 +################################################################################################# +#Running with qemu3.1 +################################################################################################# +[root@machine ~]# qemu-system-ppc64 -version +QEMU emulator version 3.1.0 (qemu-3.1.0-8.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +[root@powericp ~]# docker run -i -t alpine /bin/sh +/usr/bin/docker-current: Error response from daemon: oci runtime error: error running hook: exit status 4, stdout: , stderr: fatal error: float32nan +runtime: panic before malloc heap initialized + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +panic during panic + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +stack trace unavailable. +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 + + +strace 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 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/105/instruction/1830864 b/results/classifier/105/instruction/1830864 new file mode 100644 index 00000000..c79b5cdd --- /dev/null +++ b/results/classifier/105/instruction/1830864 @@ -0,0 +1,101 @@ +instruction: 0.782 +other: 0.741 +boot: 0.738 +device: 0.735 +semantic: 0.721 +mistranslation: 0.697 +assembly: 0.672 +graphic: 0.663 +vnc: 0.660 +KVM: 0.644 +socket: 0.623 +network: 0.595 + +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/105/instruction/1831 b/results/classifier/105/instruction/1831 new file mode 100644 index 00000000..431afd2b --- /dev/null +++ b/results/classifier/105/instruction/1831 @@ -0,0 +1,14 @@ +instruction: 0.944 +device: 0.751 +socket: 0.617 +mistranslation: 0.610 +graphic: 0.472 +assembly: 0.356 +vnc: 0.317 +semantic: 0.252 +other: 0.200 +boot: 0.153 +network: 0.085 +KVM: 0.082 + +qemu-system-m68k: ../hw/scsi/scsi-disk.c:557: scsi_write_data: Assertion `r->req.aiocb == NULL' failed. diff --git a/results/classifier/105/instruction/1831545 b/results/classifier/105/instruction/1831545 new file mode 100644 index 00000000..3262e006 --- /dev/null +++ b/results/classifier/105/instruction/1831545 @@ -0,0 +1,37 @@ +instruction: 0.471 +graphic: 0.461 +device: 0.433 +boot: 0.407 +other: 0.274 +semantic: 0.198 +socket: 0.109 +mistranslation: 0.078 +network: 0.071 +vnc: 0.068 +assembly: 0.036 +KVM: 0.020 + +"accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host + +As described in https://lists.gnu.org/archive/html/qemu-devel//2019-05/msg07362.html I run into TCG regression in qemu-git. + +Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-effective for my case. + +For reproduction (on 32-bit x86 host, in my case Slackware with gcc 5.5.0): + +./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg + +make (-j5 in my case) + +try to boot any 64-bit kernel: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg + +result is - qemu appear to hang right after "Booting the kernel" line. Decompression (xz) was ok. + +Tested with qemu-git commit e2a58ff493a2e00db3e963c1839c5374500110f2 + +32-bit OS can be booted fine, and -enable-kvm also allow 64 bit kernel/os to boot. + +bug fixed in current git (commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde). Thanks, Alex! + diff --git a/results/classifier/105/instruction/1832353 b/results/classifier/105/instruction/1832353 new file mode 100644 index 00000000..66ed63d8 --- /dev/null +++ b/results/classifier/105/instruction/1832353 @@ -0,0 +1,70 @@ +instruction: 0.861 +mistranslation: 0.824 +device: 0.784 +network: 0.621 +other: 0.595 +graphic: 0.592 +socket: 0.586 +vnc: 0.569 +semantic: 0.511 +boot: 0.470 +KVM: 0.245 +assembly: 0.213 + +cpu_exec: Assertion !have_mmap_lock() failed + +Hi, + +I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: + +qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. + +including with master qemu as of today. + +I'm attaching a tarball containing: +qemu-assert: +cmd lib proc_ptr_51.exe + +qemu-assert/lib: +ld-linux-armhf.so.3 libc.so.6 libgcc_s.so.1 libgfortran.so.5 libm.so.6 + +where cmd is the basic command used to launch the test & reproduce the failure. + +Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts. + + + +What version of qemu where you running? My HEAD is failing in a different way. + +It's fairly recent: +qemu-arm version 4.0.50 (v4.0.0-1215-ga578cdf-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf +Merge: 19735c8 43b3952 +Author: Peter Maydell <email address hidden> +Date: Mon Jun 10 16:09:19 2019 +0100 + + Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190610' into staging + + Move softmmu tlb into CPUNegativeOffsetState + +configured with: +--target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-debug + +Confirmed. The exact failure mode depends on debugging enabled or not. + +The test case is "buggy" in the sense that it makes a call to a NULL +function pointer, and the failure happens while trying to translate +the instructions at address 0. + +That said, the correct behaviour for QEMU is a SIGSEGV delivered to +the guest, not an assertion failure. + +The fix for this bug is now in master and will be in QEMU 4.1. + + +See series: https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg02189.html + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=52ba13f042714c4086416 + diff --git a/results/classifier/105/instruction/1832422 b/results/classifier/105/instruction/1832422 new file mode 100644 index 00000000..39c39a63 --- /dev/null +++ b/results/classifier/105/instruction/1832422 @@ -0,0 +1,33 @@ +instruction: 0.815 +device: 0.667 +network: 0.510 +socket: 0.486 +graphic: 0.457 +semantic: 0.453 +vnc: 0.413 +boot: 0.294 +other: 0.278 +mistranslation: 0.276 +assembly: 0.233 +KVM: 0.224 + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. + + + + +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/184 + + diff --git a/results/classifier/105/instruction/1834496 b/results/classifier/105/instruction/1834496 new file mode 100644 index 00000000..017654cf --- /dev/null +++ b/results/classifier/105/instruction/1834496 @@ -0,0 +1,66 @@ +instruction: 0.878 +device: 0.757 +graphic: 0.755 +network: 0.722 +semantic: 0.696 +other: 0.687 +vnc: 0.621 +KVM: 0.602 +socket: 0.580 +assembly: 0.570 +boot: 0.558 +mistranslation: 0.503 + +Regressions on arm target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +I found several regressions compared to qemu-3.1 when running the GCC testsuite. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error (one of them is verbose), but with a recent qemu, all of them make qemu crash: + +qemu: uncaught target signal 6 (Aborted) - core dumped + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabi +--with-mode arm +--with-cpu cortex-a9 + +and calling qemu with --cpu cortex-a9 (the script uses "any", this makes no difference). + +I have noticed other failures with arm-v8 code, but this is probably the same root cause. Since it's a bit tedious to manually rebuild & extract the testcases, I'd prefer to start with this subset, and I can extract more if needed later. + +Thanks + + + +I bisected a chunk of the errors to: + + commit c6fb8c0cf704c4a1a48c3e99e995ad4c58150dab (refs/bisect/bad) + Author: Richard Henderson <email address hidden> + Date: Mon Feb 25 11:42:35 2019 -0800 + + tcg/i386: Support INDEX_op_extract2_{i32,i64} + + Signed-off-by: Richard Henderson <email address hidden> + +Specifically I think when tcg_gen_deposit_i32 handles the if (ofs + len == 32) case. + + +Fixed by: + +Subject: [PATCH for-4.1] tcg: Fix constant folding of INDEX_op_extract2_i32 +Date: Tue, 9 Jul 2019 14:19:00 +0200 +Message-Id: <email address hidden> + + +I confirm this patch fixes the problem I reported. Thanks! + + diff --git a/results/classifier/105/instruction/1838475 b/results/classifier/105/instruction/1838475 new file mode 100644 index 00000000..8fe5571a --- /dev/null +++ b/results/classifier/105/instruction/1838475 @@ -0,0 +1,48 @@ +instruction: 0.848 +semantic: 0.780 +device: 0.738 +socket: 0.693 +network: 0.620 +vnc: 0.608 +other: 0.602 +graphic: 0.542 +boot: 0.517 +mistranslation: 0.452 +KVM: 0.343 +assembly: 0.245 + +qemu-system-arm exits when cortex-m4 floating point used and irq occurs + +qemu-system-arm exits with + +"...Secure UsageFault with CFSR.NOCP because NSACR.CP10 prevents stacking FP regs +...taking pending nonsecure exception 3 +Taking exception 7 [Breakpoint] +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)" + +when emulating Cortex-m4, executing at least 1 floating point instruction, and then an irq (e.g. sys tick) occurring. + +CPACR.CP10 and CPACR.CP11 are set to 0x3 respectively prior to executing the fp instructions. + +NOTE: NSACR does not appear to be a cortex m4 register. + +Attached is a simplified elf to repro the issue. + +The qemu command line is: "qemu-system-arm --gdb tcp::1234 -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel QemuExitWhenUsingFPAndIRQOccurs.elf -d int" + + + +I think this patch should fix this bug: + +https://<email address hidden>/ + + +I confirm that this fixes the issue above. + +Thank you for your help! It is much appreciated. + +Now fixed in git master; will be in the imminent 4.1 release. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=02ac2f7f613b47f6a5b3 + diff --git a/results/classifier/105/instruction/1838913 b/results/classifier/105/instruction/1838913 new file mode 100644 index 00000000..494d2f58 --- /dev/null +++ b/results/classifier/105/instruction/1838913 @@ -0,0 +1,64 @@ +instruction: 0.644 +graphic: 0.625 +device: 0.590 +semantic: 0.587 +socket: 0.466 +mistranslation: 0.362 +other: 0.356 +vnc: 0.352 +network: 0.346 +assembly: 0.334 +boot: 0.312 +KVM: 0.219 + +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/105/instruction/1839807 b/results/classifier/105/instruction/1839807 new file mode 100644 index 00000000..b1488975 --- /dev/null +++ b/results/classifier/105/instruction/1839807 @@ -0,0 +1,120 @@ +instruction: 0.728 +graphic: 0.714 +mistranslation: 0.654 +vnc: 0.605 +boot: 0.598 +assembly: 0.598 +device: 0.590 +network: 0.589 +semantic: 0.587 +KVM: 0.566 +other: 0.564 +socket: 0.294 + +Snapshots freeze guest Sabrelite IMX.6 board + +Hello, + +I'm trying to take and restore a snapshot with the whole system state of the Sabrelite IMX.6 board running on QEMU with commands savevm/loadvm. +It seems that I am able to take a snapshot but loading the snapshot fails. + +For comparison I checked out snapshots on 32bit ARM Virt with Debian as well as on the Versatilepb board with a bare metal application and it works fine. +The problem occurs only with that one particular board. + +My environment is: +Ubuntu 18.04 +QEMU 3.0.1 (I see the same issue in QEMU 4.0.0 as well) +The kernel and device tree used for the board was 5.1.14 version from kernel.org + +The file system was build from imx_v6_v7_defconfig config in buildroot as and sd card image. + +Problem: + +Loading snapshot stops the whole machine and it's impossible to resume it. + +Steps to reproduce problem: + +1. I converted the sdcard.img built from the buildroot to qcow2 using command qemu-img convert -f raw -O qcow2 sdcard.img sdcard.qcow2, since the raw doesn't support snapshots. + +2. I start QEMU with a command +./arm-softmmu/qemu-system-arm -m 512 -M sabrelite -kernel zImage -append "rootfstype=ext4 root=/dev/mmcblk2p2 rw rootwait" -rtc base=localtime,clock=vm -dtb imx6dl-sabresd.dtb -drive file=sdcard.qcow2,index=2,format=qcow2,id=mycard -device sd-card,drive=mycard -nographic -net nic -net user + +3. I run a simple program which print characters to the console in the background and add some files in user directory, to differ from original image. + +4. I switch to QEMU monitor, and type “savevm <name>”. +When I type “info snapshots”, the snapshot is listed. +So I assume it was saved correctly. + +5. Then I switch back to Linux console from monitor, remove the added files and stop the background printing process. + +6. I switch back to monitor and I'm trying now to load the snapshot by “loadvm <name>” command. + +That’s where the problem occurs. QEMU stops and I can't switch back from monitor to Linux. +Typing “cont” doesn’t help. +It seems like the simulation has freezed. CPU usage on my Laptop machine equals 100% until I exit QEMU. + + +What’s interesting when I exit the QEMU and then start it again the Linux boots and after it reaches the command prompt I can see the files which were removed after saving the snapshot. + +It looks like loading the snapshots works for restoring disk space but it fails for restoring the running processes. + +Due to the answer on QEMU mailing list (https://lists.nongnu.org/archive/html/qemu-discuss/2019-08/msg00016.html) it is QEMUs bug. + +The underlying cause of this is that we're not migrating the Secure banked cp15 register contents. So boards which don't enable TrustZone or where the guest runs in the NonSecure state (like the virt board, etc) can save/restore fine, but since the imx6 happens to run the guest in the Secure state it gets hit by the bug and its MMU setup etc is completely broken on restore. + +This is a bug I knew about (I mentioned it in LP:1739378 comment #5), but I've forgotten the detail of why it happens and don't seem to have written it down, so I'm going to have to think it through again... + + +Hello again, + +I have tried to disable TrustZone using argument mentioned in comment #5 by changing -M sabrelite to -M sabrelite,secure=off, but I get error "qemu-system-arm: Property '.secure' not found". It works with virt though. Is there any other way to disable it? + +Thank you, +... + +That property doesn't exist for the sabrelite board, it's only on some of the others like vexpress or virt. + + +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.] + +Save/restore with TrustZone enabled is stil broken. + + + +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/467 + + diff --git a/results/classifier/105/instruction/1840 b/results/classifier/105/instruction/1840 new file mode 100644 index 00000000..5db68bdc --- /dev/null +++ b/results/classifier/105/instruction/1840 @@ -0,0 +1,14 @@ +instruction: 0.952 +device: 0.672 +assembly: 0.508 +semantic: 0.499 +mistranslation: 0.466 +graphic: 0.390 +boot: 0.173 +other: 0.166 +vnc: 0.129 +network: 0.075 +socket: 0.028 +KVM: 0.003 + +Amend RISCV machine default value diff --git a/results/classifier/105/instruction/1840249 b/results/classifier/105/instruction/1840249 new file mode 100644 index 00000000..f072eafa --- /dev/null +++ b/results/classifier/105/instruction/1840249 @@ -0,0 +1,35 @@ +instruction: 0.800 +graphic: 0.800 +other: 0.760 +mistranslation: 0.733 +semantic: 0.653 +device: 0.636 +vnc: 0.554 +network: 0.503 +assembly: 0.490 +socket: 0.434 +boot: 0.344 +KVM: 0.215 + +Cancelling 'make docker-test-build' does not cancel running containers + +version: v4.1.0-rc5 + +Run 'make -k docker-test-build', wait a few, cancel with ^C: + +$ make -k docker-test-build 2>&1 > /dev/null +^C + +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS +62264a2d777a qemu:debian-mips-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +80807c47d0df qemu:debian-armel-cross "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes +06027b5dfd4a qemu:debian-amd64 "/var/tmp/qemu/run t…" 10 minutes ago Up 10 minutes + +The docker containers are still up building QEMU. + +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/105/instruction/1840777 b/results/classifier/105/instruction/1840777 new file mode 100644 index 00000000..3444fd45 --- /dev/null +++ b/results/classifier/105/instruction/1840777 @@ -0,0 +1,89 @@ +instruction: 0.913 +assembly: 0.911 +graphic: 0.909 +device: 0.901 +KVM: 0.892 +other: 0.880 +mistranslation: 0.879 +boot: 0.875 +vnc: 0.860 +semantic: 0.846 +socket: 0.780 +network: 0.773 + +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/105/instruction/1842 b/results/classifier/105/instruction/1842 new file mode 100644 index 00000000..d9a8b6bc --- /dev/null +++ b/results/classifier/105/instruction/1842 @@ -0,0 +1,28 @@ +instruction: 0.808 +device: 0.770 +graphic: 0.670 +network: 0.638 +socket: 0.540 +vnc: 0.458 +boot: 0.407 +semantic: 0.311 +mistranslation: 0.257 +KVM: 0.142 +assembly: 0.088 +other: 0.074 + +keyutils meson regression in 8.1.0 +Description of problem: +keyutils is no longer found by meson during the build. + +commit 0db0fbb5cf8955d4f7a4a82bde32cfd93bd042ea appears to be buggy: +``` +$ grep KEYUTILS config-host.h +#undef CONFIG_KEYUTILS +``` +Steps to reproduce: +1. Have keyutils installed +2. Build QEMU 8.1.0 +3. Note that keyutils is no longer linked into the build + +Thanks diff --git a/results/classifier/105/instruction/1842916 b/results/classifier/105/instruction/1842916 new file mode 100644 index 00000000..528ecd94 --- /dev/null +++ b/results/classifier/105/instruction/1842916 @@ -0,0 +1,66 @@ +instruction: 0.913 +device: 0.847 +other: 0.748 +graphic: 0.704 +socket: 0.701 +assembly: 0.631 +boot: 0.612 +semantic: 0.588 +network: 0.581 +vnc: 0.560 +mistranslation: 0.539 +KVM: 0.416 + +[18.04 FEAT] Enhanced Hardware Support - Finalize Naming + +This feature request will provide the final naming of the next machine + +A similar ticket for Eoan/19.10 was created, too: +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842774 + +Disco also needs to be addressed, but let's track that here, too. + +------- Comment From <email address hidden> 2019-09-18 08:43 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/bionic + +Marking this as duplicate of LP 1842774, since both LPs deal with the same patch, just for different Ubuntu releases. +But the affected Ubuntu releases are now all listed in LP 1842774, which makes the requested kernel SRU simpler. + +------- Comment From <email address hidden> 2019-10-04 03:42 EDT------- +For reference the QEMU part, which is already done in eoan via +> 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 + +is upstream commit 7505deca0bfa859136ec6419dbafc504f22fcac2 +s390x/cpumodel: Add the z15 name to the description of gen15a + +------- Comment From <email address hidden> 2019-11-04 11:27 EDT------- +*** This bug has been marked as a duplicate of bug 181268 *** + +------- Comment From <email address hidden> 2019-11-04 11:28 EDT------- +IBM Bugzilla status -> closed, + +Will be tracked with LP: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842774 + diff --git a/results/classifier/105/instruction/1843254 b/results/classifier/105/instruction/1843254 new file mode 100644 index 00000000..84901efd --- /dev/null +++ b/results/classifier/105/instruction/1843254 @@ -0,0 +1,26 @@ +instruction: 0.742 +device: 0.723 +mistranslation: 0.638 +other: 0.589 +network: 0.572 +socket: 0.561 +vnc: 0.554 +graphic: 0.510 +boot: 0.426 +semantic: 0.425 +KVM: 0.396 +assembly: 0.323 + +arm emulation of HCR.TID3 traps are not implemented + +On ARM (aarch64), HCR_EL2.TID3 [bit18] is supposed to trap ID group 3, which includes the ID_AA64{PFR,DFR,ISAR,MMFR,AFR}*_EL1 registers. However, setting that HCR bit has no effect and accesses to those ID registers are not trapped to EL2 with an EC syndrome value of 0x18. + +Yes, we don't currently implement most of the 'trap system register access' bits in HCR_EL2. Last time I checked we were missing TID0 TID1 TID2 TID3 TIDCP TAC TSW TPC TPU TTLB TVM TRVM TDZ, but it's possible we've implemented one or two of those since then. + + +TID3 trapping should be mostly fixed for 4.2 -- we will trap accesses to all the coprocessor/sysreg ID registers that TID3 covers. Trapping of aarch32 MVFR* (which are accessed via vmrs) will not make it into this release, but should be in 5.0. + + +The last bit of TID3 trapping is now in QEMU git master and will be in 5.0. + + diff --git a/results/classifier/105/instruction/1845185 b/results/classifier/105/instruction/1845185 new file mode 100644 index 00000000..21111394 --- /dev/null +++ b/results/classifier/105/instruction/1845185 @@ -0,0 +1,97 @@ +instruction: 0.778 +other: 0.775 +graphic: 0.769 +KVM: 0.763 +device: 0.728 +assembly: 0.725 +vnc: 0.715 +semantic: 0.687 +socket: 0.678 +boot: 0.674 +network: 0.638 +mistranslation: 0.611 + +Cannot build qemu utils (qemu-img.exe, qemu-edid.exe, qemu-io.exe) statically with MSYS64 on Windows because intl and iconv libs are not loaded + +Using MSYS2 and mingw32 instructions from https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2, I could not statically build the qemu-utils using the latest qemu master branch. + +Steps to reproduce the issue: +1. Install MSYS2 on a Windows 10 x64 box +2. Install required mingw64 toolchain: pacman -S base-devel mingw-w64-x86_64-toolchain git python mingw-w64-x86_64-glib2 mingw64/mingw-w64-x86_64-gtk3 mingw64/mingw-w64-x86_64-SDL2 +3. clone qemu +4. Run configure for static build for the tools only + ./configure --disable-user --disable-system --disable-docs --enable-tools --disable-guest-agent --disable-capstone --disable-sheepdog --enable-debug --static + # I had to remove sheepdog, capstone and guest agent because other errors popped out, but this not the purpose of this bug report +5. Run 'make -j'. the following errors appeared, signaling that intl lib is not loaded. If I add intl lib, iconv lib need to be loaded too. + +make: *** [/home/ader1990/qemu/rules.mak:124: qemu-img.exe] Error 1 +make: *** Waiting for unfinished jobs.... +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1522): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x154f): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x157e): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15ad): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15dc): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1622): more undefined references to `libintl_sprintf' follow +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x43): undefined reference to `libintl_textdomain' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x52): undefined reference to `libintl_gettext' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x203): undefined reference to `libintl_bindtextdomain' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x21e): undefined reference to `libintl_bind_textdomain_codeset' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x2c1): undefined reference to `libintl_dgettext' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x4e1): undefined reference to `libintl_dcgettext' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x53a): undefined reference to `libintl_dngettext' + + +Patch to fix the issue (added intl and iconv to the libs): + +diff --git a/configure b/configure +index 30aad233d1..e2ab8ef026 100755 +--- a/configure ++++ b/configure +@@ -920,7 +920,7 @@ if test "$mingw32" = "yes" ; then + DSOSUF=".dll" + # MinGW needs -mthreads for TLS and macro _MT. + QEMU_CFLAGS="-mthreads $QEMU_CFLAGS" +- LIBS="-lwinmm -lws2_32 -liphlpapi $LIBS" ++ LIBS="-lwinmm -lws2_32 -liphlpapi -lintl -liconv $LIBS" + write_c_skeleton; + if compile_prog "" "-liberty" ; then + LIBS="-liberty $LIBS" + +I think this is probably a bug in the packaging of glib. What does "pkg-config --static --libs glib-2.0" say? If it doesn't say that you need to add -lintl -liconv to do a static link against glib, then that's a glib packaging bug. If it does say you need those flags, then we have a QEMU configure script bug where we're failing to get the link line correct (but we should fix it by using pkg-config correctly, not by manually adding the libraries to the LIBS variable). + +I'm not sure how much this applies to Windows, but in general we don't support static linking for anything except the linux-user executables, largely because so often the libraries we depend on don't ship with correct pkg-config data for how to statically link them. + + +I checked the glib package static deps: +pkg-config.exe --static --libs glib-2.0 +-LC:/msys64/mingw64/lib -lintl -lglib-2.0 -lws2_32 -lole32 -lwinmm -lshlwapi -pthread -lpcre + + +Let me know if there is anything I can do next to get this issue fixed (if it is fixable). + +Thank you, +Adrian + +There is an open glib issue about this. See my comment. I'll try to address it myself. + +https://gitlab.gnome.org/GNOME/glib/-/issues/1851#note_603599 + +James, do you know if this has been fixed in GLib 2.65.0? + +My distribution has not added 2.65.0 yet but it should be fixed now, yes. + +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/105/instruction/1847232 b/results/classifier/105/instruction/1847232 new file mode 100644 index 00000000..9dde775b --- /dev/null +++ b/results/classifier/105/instruction/1847232 @@ -0,0 +1,536 @@ +instruction: 0.907 +other: 0.898 +assembly: 0.897 +socket: 0.884 +vnc: 0.883 +graphic: 0.880 +semantic: 0.876 +device: 0.871 +network: 0.865 +boot: 0.860 +KVM: 0.835 +mistranslation: 0.822 + +qemu TCG in s390x mode issue with calculating HASH + +When using go on s390x on Debian x64 (buster) (host) and debian s390x (sid) (guest) I run into the following problem : + +The following occurs while trying to build a custom project : + +go: <email address hidden>: Get https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: local error: tls: bad record MAC + +Doing a git bisect I find that this problem only occurs on and after commit 08ef92d556c584c7faf594ff3af46df456276e1b + +Before that commit, all works fine. Past this commit, build always fails. + +Without any proof, It looks like a hash calculation bug related to using z/Arch vector facilities... + +On 08.10.19 14:11, Cornelia Huck wrote: +> On Tue, 08 Oct 2019 11:19:25 -0000 +> Ivan Warren via <email address hidden> wrote: +> +>> Public bug reported: +>> +>> When using go on s390x on Debian x64 (buster) (host) and debian s390x +>> (sid) (guest) I run into the following problem : +>> +>> The following occurs while trying to build a custom project : +>> +>> go: <email address hidden>: +>> Get +>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: +>> local error: tls: bad record MAC +>> +>> Doing a git bisect I find that this problem only occurs on and after +>> commit 08ef92d556c584c7faf594ff3af46df456276e1b +>> +>> Before that commit, all works fine. Past this commit, build always +>> fails. +> +> What version are you using? Current master? +> +> Can you please share your command line? +> +>> +>> Without any proof, It looks like a hash calculation bug related to using +>> z/Arch vector facilities... +> +> Not an unreasonable guess, cc:ing David in case he has seen that before. +> + +Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command +line? Could be some fallout from vector instruction support. Currently +ill, will have a look when I'm feeling better. + +-- + +Thanks, + +David / dhildenb + + + +On 10/8/2019 3:35 PM, David Hildenbrand wrote: +> On 08.10.19 14:11, Cornelia Huck wrote: +>> On Tue, 08 Oct 2019 11:19:25 -0000 +>> Ivan Warren via <email address hidden> wrote: +>> +>>> Public bug reported: +>>> +>>> When using go on s390x on Debian x64 (buster) (host) and debian s390x +>>> (sid) (guest) I run into the following problem : +>>> +>>> The following occurs while trying to build a custom project : +>>> +>>> go: <email address hidden>: +>>> Get +>>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: +>>> local error: tls: bad record MAC +>>> +>>> Doing a git bisect I find that this problem only occurs on and after +>>> commit 08ef92d556c584c7faf594ff3af46df456276e1b +>>> +>>> Before that commit, all works fine. Past this commit, build always +>>> fails. +>> What version are you using? Current master? +>> +>> Can you please share your command line? +>> +>>> Without any proof, It looks like a hash calculation bug related to using +>>> z/Arch vector facilities... +>> Not an unreasonable guess, cc:ing David in case he has seen that before. +>> +> Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command +> line? Could be some fallout from vector instruction support. Currently +> ill, will have a look when I'm feeling better. + +Reposted with a reply all... (sorry for the duplicates) + +So it does ! + + +My qemu command line is now (forget the odd funny networking things..) + +qemu-system-s390x \ + -drive +file=DEB002.IMG.NEW,discard=unmap,cache=writeback,id=drive-0,if=none \ + -device virtio-scsi-ccw,id=virtio-scsi-0 \ + -device scsi-hd,id=scsi-hd-0,drive=drive-0 \ + -m 8G \ + -net nic,macaddr=52:54:00:00:00:02 \ + -net tap,ifname=taparm,script=no \ + -nographic -accel tcg,thread=multi \ + -monitor unix:ms,server,nowait \ + -cpu qemu,vx=off \ ##### THAT WAS ADDED as instructed - without it +everything goes kaput ! + -smp 12 + +And using the latest bleeding edge qemu from github, my build works (the +problem goes away). + +So the z/Arch vector instructions may have a glitch is a venue to +consider.. Probably one that couldn't be screened through conventional +methods. + +I'm not that versed into z/Arch vector instruction, but if there +anything I can help with, I will ! + +--Ivan + + + + + +On 08.10.19 16:11, Ivan Warren wrote: +> +> On 10/8/2019 3:35 PM, David Hildenbrand wrote: +>> On 08.10.19 14:11, Cornelia Huck wrote: +>>> On Tue, 08 Oct 2019 11:19:25 -0000 +>>> Ivan Warren via <email address hidden> wrote: +>>> +>>>> Public bug reported: +>>>> +>>>> When using go on s390x on Debian x64 (buster) (host) and debian s390x +>>>> (sid) (guest) I run into the following problem : +>>>> +>>>> The following occurs while trying to build a custom project : +>>>> +>>>> go: <email address hidden>: +>>>> Get +>>>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: +>>>> local error: tls: bad record MAC +>>>> +>>>> Doing a git bisect I find that this problem only occurs on and after +>>>> commit 08ef92d556c584c7faf594ff3af46df456276e1b +>>>> +>>>> Before that commit, all works fine. Past this commit, build always +>>>> fails. +>>> What version are you using? Current master? +>>> +>>> Can you please share your command line? +>>> +>>>> Without any proof, It looks like a hash calculation bug related to using +>>>> z/Arch vector facilities... +>>> Not an unreasonable guess, cc:ing David in case he has seen that before. +>>> +>> Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command +>> line? Could be some fallout from vector instruction support. Currently +>> ill, will have a look when I'm feeling better. +> +> Reposted with a reply all... (sorry for the duplicates) +> +> So it does ! +> +> +> My qemu command line is now (forget the odd funny networking things..) +> +> qemu-system-s390x \ +> -drive +> file=DEB002.IMG.NEW,discard=unmap,cache=writeback,id=drive-0,if=none \ +> -device virtio-scsi-ccw,id=virtio-scsi-0 \ +> -device scsi-hd,id=scsi-hd-0,drive=drive-0 \ +> -m 8G \ +> -net nic,macaddr=52:54:00:00:00:02 \ +> -net tap,ifname=taparm,script=no \ +> -nographic -accel tcg,thread=multi \ +> -monitor unix:ms,server,nowait \ +> -cpu qemu,vx=off \ ##### THAT WAS ADDED as instructed - without it +> everything goes kaput ! +> -smp 12 +> +> And using the latest bleeding edge qemu from github, my build works (the +> problem goes away). +> +> So the z/Arch vector instructions may have a glitch is a venue to +> consider.. Probably one that couldn't be screened through conventional +> methods. +> +> I'm not that versed into z/Arch vector instruction, but if there +> anything I can help with, I will ! + +I'll have to reproduce, can you outline the steps needed to trigger +this? (never had to build a go project before #luckyme ( ;) )). It looks +like https://github.com/FactomProject/basen is getting pulled in from +some other project? + +Thanks! + + +-- + +Thanks, + +David / dhildenb + + +On 14.10.19 11:53, David Hildenbrand wrote: +> On 08.10.19 16:11, Ivan Warren wrote: +>> +>> On 10/8/2019 3:35 PM, David Hildenbrand wrote: +>>> On 08.10.19 14:11, Cornelia Huck wrote: +>>>> On Tue, 08 Oct 2019 11:19:25 -0000 +>>>> Ivan Warren via <email address hidden> wrote: +>>>> +>>>>> Public bug reported: +>>>>> +>>>>> When using go on s390x on Debian x64 (buster) (host) and debian s390x +>>>>> (sid) (guest) I run into the following problem : +>>>>> +>>>>> The following occurs while trying to build a custom project : +>>>>> +>>>>> go: <email address hidden>: +>>>>> Get +>>>>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: +>>>>> local error: tls: bad record MAC +>>>>> +>>>>> Doing a git bisect I find that this problem only occurs on and after +>>>>> commit 08ef92d556c584c7faf594ff3af46df456276e1b +>>>>> +>>>>> Before that commit, all works fine. Past this commit, build always +>>>>> fails. +>>>> What version are you using? Current master? +>>>> +>>>> Can you please share your command line? +>>>> +>>>>> Without any proof, It looks like a hash calculation bug related to using +>>>>> z/Arch vector facilities... +>>>> Not an unreasonable guess, cc:ing David in case he has seen that before. +>>>> +>>> Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command +>>> line? Could be some fallout from vector instruction support. Currently +>>> ill, will have a look when I'm feeling better. +>> +>> Reposted with a reply all... (sorry for the duplicates) +>> +>> So it does ! +>> +>> +>> My qemu command line is now (forget the odd funny networking things..) +>> +>> qemu-system-s390x \ +>> -drive +>> file=DEB002.IMG.NEW,discard=unmap,cache=writeback,id=drive-0,if=none \ +>> -device virtio-scsi-ccw,id=virtio-scsi-0 \ +>> -device scsi-hd,id=scsi-hd-0,drive=drive-0 \ +>> -m 8G \ +>> -net nic,macaddr=52:54:00:00:00:02 \ +>> -net tap,ifname=taparm,script=no \ +>> -nographic -accel tcg,thread=multi \ +>> -monitor unix:ms,server,nowait \ +>> -cpu qemu,vx=off \ ##### THAT WAS ADDED as instructed - without it +>> everything goes kaput ! +>> -smp 12 +>> +>> And using the latest bleeding edge qemu from github, my build works (the +>> problem goes away). +>> +>> So the z/Arch vector instructions may have a glitch is a venue to +>> consider.. Probably one that couldn't be screened through conventional +>> methods. +>> +>> I'm not that versed into z/Arch vector instruction, but if there +>> anything I can help with, I will ! +> +> I'll have to reproduce, can you outline the steps needed to trigger +> this? (never had to build a go project before #luckyme ( ;) )). It looks +> like https://github.com/FactomProject/basen is getting pulled in from +> some other project? +> + +I just tried with Fedora 31 Nightly using "go get" + +[root@f31 ~]# go get -v -d github.com/FactomProject/factom +github.com/FactomProject/factom (download) +github.com/FactomProject/btcutil (download) +github.com/FactomProject/ed25519 (download) +github.com/FactomProject/go-bip32 (download) +github.com/FactomProject/btcutilecc (download) +package golang.org/x/crypto/ripemd160: unrecognized import path "golang.org/x/crypto/ripemd160" (https fetch: Get https://golang.org/x/crypto/ripemd160?go-get=1: local error: tls: bad record MAC) +github.com/FactomProject/go-bip39 (download) +package golang.org/x/crypto/pbkdf2: unrecognized import path "golang.org/x/crypto/pbkdf2" (https fetch: Get https://golang.org/x/crypto/pbkdf2?go-get=1: local error: tls: bad record MAC) +github.com/FactomProject/go-bip44 (download) +github.com/FactomProject/netki-go-partner-client (download) +github.com/FactomProject/go-simplejson (download) + +With vx=off: + +[root@f31 ~]# go get -v -d github.com/FactomProject/factom +github.com/FactomProject/factom (download) +github.com/FactomProject/btcutil (download) +github.com/FactomProject/ed25519 (download) +github.com/FactomProject/go-bip32 (download) +github.com/FactomProject/basen (download) +github.com/FactomProject/btcutilecc (download) +get "golang.org/x/crypto/ripemd160": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/ripemd160?go-get=1 +get "golang.org/x/crypto/ripemd160": verifying non-authoritative meta tag +golang.org/x/crypto (download) +github.com/FactomProject/go-bip39 (download) +github.com/FactomProject/go-bip44 (download) +github.com/FactomProject/netki-go-partner-client (download) +github.com/FactomProject/go-simplejson (download) + + +That should be sufficient to identify the instruction. Might take some time, though. E.g., +the HASH calculation in the kernel works just fine. + +-- + +Thanks, + +David / dhildenb + + +I was looking for a simpler method (without using go), but curl/wget and whatnot don't seem to have any problem.. There must be something go is doing that is different. + +My guess (but ONLY a guess) is that the "go" TLS code might be doing some dynamic checking on the z/Arch facility list (STFLE ?) and do some dynamic change to the code path. Maybe a bit far fetched... + +Since wget/curl use the openssl library - which (unless a specific engine is specified) uses the lowest common denominator - it will work even when z/Arch VX is present.. However, "golang" may be using a different technique (and may not be using openssl at all) - or invoke openssl with a specific engine if it detects z/Arch VX... + +However, I have the workaround (vx=off), but I'd love to see if there is something amiss with z/Arch VX (for purely educational purpose). + +On 14.10.19 12:22, David Hildenbrand wrote: +> On 14.10.19 11:53, David Hildenbrand wrote: +>> On 08.10.19 16:11, Ivan Warren wrote: +>>> +>>> On 10/8/2019 3:35 PM, David Hildenbrand wrote: +>>>> On 08.10.19 14:11, Cornelia Huck wrote: +>>>>> On Tue, 08 Oct 2019 11:19:25 -0000 +>>>>> Ivan Warren via <email address hidden> wrote: +>>>>> +>>>>>> Public bug reported: +>>>>>> +>>>>>> When using go on s390x on Debian x64 (buster) (host) and debian s390x +>>>>>> (sid) (guest) I run into the following problem : +>>>>>> +>>>>>> The following occurs while trying to build a custom project : +>>>>>> +>>>>>> go: <email address hidden>: +>>>>>> Get +>>>>>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: +>>>>>> local error: tls: bad record MAC +>>>>>> +>>>>>> Doing a git bisect I find that this problem only occurs on and after +>>>>>> commit 08ef92d556c584c7faf594ff3af46df456276e1b +>>>>>> +>>>>>> Before that commit, all works fine. Past this commit, build always +>>>>>> fails. +>>>>> What version are you using? Current master? +>>>>> +>>>>> Can you please share your command line? +>>>>> +>>>>>> Without any proof, It looks like a hash calculation bug related to using +>>>>>> z/Arch vector facilities... +>>>>> Not an unreasonable guess, cc:ing David in case he has seen that before. +>>>>> +>>>> Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command +>>>> line? Could be some fallout from vector instruction support. Currently +>>>> ill, will have a look when I'm feeling better. +>>> +>>> Reposted with a reply all... (sorry for the duplicates) +>>> +>>> So it does ! +>>> +>>> +>>> My qemu command line is now (forget the odd funny networking things..) +>>> +>>> qemu-system-s390x \ +>>> -drive +>>> file=DEB002.IMG.NEW,discard=unmap,cache=writeback,id=drive-0,if=none \ +>>> -device virtio-scsi-ccw,id=virtio-scsi-0 \ +>>> -device scsi-hd,id=scsi-hd-0,drive=drive-0 \ +>>> -m 8G \ +>>> -net nic,macaddr=52:54:00:00:00:02 \ +>>> -net tap,ifname=taparm,script=no \ +>>> -nographic -accel tcg,thread=multi \ +>>> -monitor unix:ms,server,nowait \ +>>> -cpu qemu,vx=off \ ##### THAT WAS ADDED as instructed - without it +>>> everything goes kaput ! +>>> -smp 12 +>>> +>>> And using the latest bleeding edge qemu from github, my build works (the +>>> problem goes away). +>>> +>>> So the z/Arch vector instructions may have a glitch is a venue to +>>> consider.. Probably one that couldn't be screened through conventional +>>> methods. +>>> +>>> I'm not that versed into z/Arch vector instruction, but if there +>>> anything I can help with, I will ! +>> +>> I'll have to reproduce, can you outline the steps needed to trigger +>> this? (never had to build a go project before #luckyme ( ;) )). It looks +>> like https://github.com/FactomProject/basen is getting pulled in from +>> some other project? +>> +> +> I just tried with Fedora 31 Nightly using "go get" +> +> [root@f31 ~]# go get -v -d github.com/FactomProject/factom +> github.com/FactomProject/factom (download) +> github.com/FactomProject/btcutil (download) +> github.com/FactomProject/ed25519 (download) +> github.com/FactomProject/go-bip32 (download) +> github.com/FactomProject/btcutilecc (download) +> package golang.org/x/crypto/ripemd160: unrecognized import path "golang.org/x/crypto/ripemd160" (https fetch: Get https://golang.org/x/crypto/ripemd160?go-get=1: local error: tls: bad record MAC) +> github.com/FactomProject/go-bip39 (download) +> package golang.org/x/crypto/pbkdf2: unrecognized import path "golang.org/x/crypto/pbkdf2" (https fetch: Get https://golang.org/x/crypto/pbkdf2?go-get=1: local error: tls: bad record MAC) +> github.com/FactomProject/go-bip44 (download) +> github.com/FactomProject/netki-go-partner-client (download) +> github.com/FactomProject/go-simplejson (download) +> +> With vx=off: +> +> [root@f31 ~]# go get -v -d github.com/FactomProject/factom +> github.com/FactomProject/factom (download) +> github.com/FactomProject/btcutil (download) +> github.com/FactomProject/ed25519 (download) +> github.com/FactomProject/go-bip32 (download) +> github.com/FactomProject/basen (download) +> github.com/FactomProject/btcutilecc (download) +> get "golang.org/x/crypto/ripemd160": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/ripemd160?go-get=1 +> get "golang.org/x/crypto/ripemd160": verifying non-authoritative meta tag +> golang.org/x/crypto (download) +> github.com/FactomProject/go-bip39 (download) +> github.com/FactomProject/go-bip44 (download) +> github.com/FactomProject/netki-go-partner-client (download) +> github.com/FactomProject/go-simplejson (download) +> +> +> That should be sufficient to identify the instruction. Might take some time, though. E.g., +> the HASH calculation in the kernel works just fine. +> + +By now I am pretty sure the code that gets triggered is + +src/vendor/golang.org/x/crypto/poly1305/sum_s390x.s + +in the go repository. + +I started writing unit tests for all involved vector instructions, no +luck so far. Could also be some side-effect/BUG of another instruction. + +Will let you know once I know more :) + +-- + +Thanks, + +David / dhildenb + + +Looks fixed to me ! The issue no longer shows even without specifying vx=off + +On 23.10.19 11:37, Ivan Warren wrote: +> Looks fixed to me ! The issue no longer shows even without specifying +> vx=off +> + +Nice, I suspect that there might be more issues when using golang (as it +really makes excessive use of vector registers to my surprise). So in +case you run into problems (and especially can't reproduce with vx=off), +please inform me! + +Thanks! + +-- + +Thanks, + +David / dhildenb + + + +I will exercise this thoroughly ! The go application involved is itself a blockchain signing/verification application, so I suspect it will be a good exercise (codenotary.io) + +Thanks for looking into this and fixing this ! + +--Ivan + +I assume David's fixes have been released with QEMU v4.2, so I'm closing this ticket now. + +Thank you so much! I've been hitting the same issue with s390x. + +Maybe an endian issue with hardware vx? + +Also affects RISC-V apparently. https://github.com/moby/moby/issues/40240 + +Tried applying the -cpu parameter into Qemu 4.1.1 but I got: + +qemu-system-riscv64: unable to find CPU model 'qemu' + +My command is: + +qemu-system-riscv64 \ + -machine virt \ + -cpu qemu,vx=off \ + -nographic \ + -smp 4 \ + -m 4G \ + -bios fw_payload.bin \ + -device virtio-blk-device,drive=hd0 \ + -object rng-random,filename=/dev/urandom,id=rng0 \ + -device virtio-rng-device,rng=rng0 \ + -drive file=riscv64-debianrootfs-qemu.qcow2,format=qcow2,id=hd0 \ + -device virtio-net-device,netdev=usernet \ + -netdev user,id=usernet,hostfwd=tcp::22222-:22" + diff --git a/results/classifier/105/instruction/1847467 b/results/classifier/105/instruction/1847467 new file mode 100644 index 00000000..62857ecf --- /dev/null +++ b/results/classifier/105/instruction/1847467 @@ -0,0 +1,56 @@ +instruction: 0.254 +device: 0.207 +mistranslation: 0.196 +network: 0.170 +graphic: 0.155 +semantic: 0.143 +vnc: 0.128 +other: 0.111 +socket: 0.102 +boot: 0.094 +KVM: 0.089 +assembly: 0.050 + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in QEMU + + + +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. + + +Repro case in comment #1 still demonstrates bug. + + + +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/267 + + diff --git a/results/classifier/105/instruction/1849879 b/results/classifier/105/instruction/1849879 new file mode 100644 index 00000000..2d3aa0dc --- /dev/null +++ b/results/classifier/105/instruction/1849879 @@ -0,0 +1,26 @@ +instruction: 0.972 +mistranslation: 0.778 +device: 0.774 +graphic: 0.721 +semantic: 0.574 +vnc: 0.498 +boot: 0.267 +socket: 0.259 +other: 0.240 +assembly: 0.184 +network: 0.142 +KVM: 0.036 + +qemu-arm should accept vmrs apsr_nzcv, fpscr on M-profile + +I've noticed that qemu-arm for cortex-M considers +vmrs apsr_nzcv, fpscr +as an illegal instruction. + +In this case, rt==15 means APSR, and the instruction should be accepted and executed like for A-profile. + +I posted a small patch: +https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg06978.html + +Fixed in 2529ab43b8a05534494704e803e0332d111d8b91, which is in 4.2. + diff --git a/results/classifier/105/instruction/1850 b/results/classifier/105/instruction/1850 new file mode 100644 index 00000000..d405cc8a --- /dev/null +++ b/results/classifier/105/instruction/1850 @@ -0,0 +1,42 @@ +instruction: 0.965 +semantic: 0.719 +device: 0.700 +graphic: 0.669 +assembly: 0.656 +network: 0.430 +vnc: 0.405 +socket: 0.378 +mistranslation: 0.282 +boot: 0.248 +other: 0.139 +KVM: 0.129 + +AARCH64 Illegal Instruction (CurrentEL) +Description of problem: +While emulating Aarch64 in QEMU, whenever the instruction `CurrentEL` is executed, +QEMU crashes with the following message. + +`qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped)` + +I've tried both QEMU user space translation (qemu-aarch64-static) and QEMU emulation (qemu-system-aarch64), +and both fail with the above message. + +C Code to reproduce bug, courtesy of https://github.com/cirosantilli/linux-kernel-module-cheat/blob/35684b1b7e0a04a68987056cb15abd97e3d2f0cc/baremetal/arch/aarch64/el.c +``` +#include <stdio.h> +#include <inttypes.h> + +int main(void) { + register uint64_t x0 __asm__ ("x0"); + __asm__ ("mrs x0, CurrentEL;" : : : "%x0"); + printf("%" PRIu64 "\n", x0 >> 2); + return 0; +} +``` +Steps to reproduce: +1. Copy C code above into file. +2. Compile code `gcc ./main.c --static` +3. Execute elf bin `./a.out` +Additional information: + diff --git a/results/classifier/105/instruction/1850378 b/results/classifier/105/instruction/1850378 new file mode 100644 index 00000000..2e39440f --- /dev/null +++ b/results/classifier/105/instruction/1850378 @@ -0,0 +1,53 @@ +instruction: 0.873 +graphic: 0.759 +device: 0.751 +other: 0.701 +semantic: 0.653 +mistranslation: 0.556 +network: 0.513 +assembly: 0.478 +socket: 0.463 +boot: 0.385 +vnc: 0.343 +KVM: 0.268 + +RISC-V unreliable IPIs + +I am working on a project with custom inter processor interrupts (IPIs) on the RISC-V virt machine. +After upgrading from version 3.1.0 to 4.1.0 which fixes a related issue (https://github.com/riscv/riscv-qemu/issues/132) I am able to use the CPU hotplug feature. + +However, if I try to use IPIs for communication between two cores, the wfi instruction behaves strangely. Either it does not return, or it returns on timer interrupts, even though they are disabled. The code, I use on one core to wait for an interrupt is the following. + + csr_clear(sie, SIE_SEIE | SIE_STIE); + do { + wait_for_interrupt(); + sipval = csr_read(sip); + sieval = csr_read(sie); + scauseval = csr_read(scause) & 0xFF; + /* only break if wfi returns for an software interrupt */ + } while ((sipval & sieval) == 0 && scauseval != 1); + csr_set(sie, SIE_SEIE | SIE_STIE); + +Since the resulting sequence does not seem to be deterministic, my guess is, that it has something to do with the communication of qemu's threads for the different cores. + +Can you post a whole program that reproduces this? freedom-e-sdk <https://github.com/sifive/freedom-e-sdk> will run bare-metal code on QEMU if you don't want to post the rest of the surrounding infrastructure. + +I created a minimal example from my setup. I'm running a kernel 4.19.57 with a custom firmware based on bbl (https://github.com/riscv/riscv-pk). +An ioctl device from a kernel module is used to execute the code above in kernel space. +In the example, the userspace application proceeds after a couple of seconds without receiving the custom IPI. + +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/105/instruction/1851939 b/results/classifier/105/instruction/1851939 new file mode 100644 index 00000000..f4991d18 --- /dev/null +++ b/results/classifier/105/instruction/1851939 @@ -0,0 +1,34 @@ +instruction: 0.908 +mistranslation: 0.790 +semantic: 0.781 +device: 0.768 +other: 0.672 +network: 0.629 +graphic: 0.625 +socket: 0.600 +vnc: 0.479 +boot: 0.380 +KVM: 0.350 +assembly: 0.269 + +RISC-V mstatus TSR bit not correctly implemented + +Hi, + +since qemu 4.1.0 the TSR bit in mstatus register is supported. But it does not allow for executing sret in m-mode. + +From the RISC-V specifications: +"When TSR=1, attempts to execute SRET while executing in S-mode will raise an illegal instruction +exception. When TSR=0, this operation is permitted in S-mode." + +This means an exception should only be raised when executing in S-mode, but not in M-mode, hence you should change the condition in helper_sret (target/riscv/op_helper.c) from: + if (env->priv_ver >= PRIV_VERSION_1_10_0 && + get_field(env->mstatus, MSTATUS_TSR)) +to: + if (env->priv_ver >= PRIV_VERSION_1_10_0 && + get_field(env->mstatus, MSTATUS_TSR) && !(env->priv >= PRV_M)) + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ed5abf46b3c4 + + diff --git a/results/classifier/105/instruction/1857143 b/results/classifier/105/instruction/1857143 new file mode 100644 index 00000000..4203c9cf --- /dev/null +++ b/results/classifier/105/instruction/1857143 @@ -0,0 +1,46 @@ +instruction: 0.888 +boot: 0.838 +other: 0.798 +graphic: 0.793 +KVM: 0.754 +device: 0.751 +vnc: 0.735 +mistranslation: 0.710 +socket: 0.699 +assembly: 0.688 +semantic: 0.677 +network: 0.663 + +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/105/instruction/1859989 b/results/classifier/105/instruction/1859989 new file mode 100644 index 00000000..ac61ccd5 --- /dev/null +++ b/results/classifier/105/instruction/1859989 @@ -0,0 +1,65 @@ +instruction: 0.820 +semantic: 0.814 +graphic: 0.792 +other: 0.759 +assembly: 0.735 +mistranslation: 0.727 +device: 0.690 +vnc: 0.676 +boot: 0.672 +network: 0.669 +socket: 0.631 +KVM: 0.571 + +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/105/instruction/1860056 b/results/classifier/105/instruction/1860056 new file mode 100644 index 00000000..c7ec19ef --- /dev/null +++ b/results/classifier/105/instruction/1860056 @@ -0,0 +1,54 @@ +instruction: 0.739 +device: 0.656 +graphic: 0.588 +mistranslation: 0.485 +semantic: 0.481 +other: 0.348 +boot: 0.268 +socket: 0.166 +vnc: 0.155 +assembly: 0.127 +network: 0.092 +KVM: 0.024 + +mips binaries segfault + +Hello World appears to segfault with qemu mips, on a Debian 10.0.0 Buster amd64 host. + +Example: + + +$ cat mips/test/hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ mips-linux-gnu-g++ -o hello hello.cpp && ./hello +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Note that 64-bit MIPS and little endian 32-bit MIPS qemu work fine. The problem is limited to big endian 32-bit MIPS. + +Could you attach the version of g++ and qemu? In other words, can you capture the output of: + +mips-linux-gnu-g++ --version + +and + +qemu-mips --version + +? + +Does the problem happen if you compile with "-static" option? + +Yours, +Aleksandar + + +Does the problem exist using c hello world and gcc? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1860920 b/results/classifier/105/instruction/1860920 new file mode 100644 index 00000000..d294da2a --- /dev/null +++ b/results/classifier/105/instruction/1860920 @@ -0,0 +1,51 @@ +instruction: 0.831 +mistranslation: 0.736 +device: 0.697 +semantic: 0.681 +network: 0.592 +other: 0.580 +socket: 0.500 +boot: 0.497 +graphic: 0.362 +vnc: 0.311 +assembly: 0.160 +KVM: 0.126 + +qemu-s390x-softmmu: crash + +Trying to compile and use rust programs on an s390x emulated machine, crash in qemu/target/s390x/translate.c line 3894 + +Steps to reproduce: +on a amd64 PC, installed debian on s390x emulated by qemu, seems to work fine (installed some packages, etc.) +installed rust cargo (both from rustup and from debian) +cargo install anything makes *qemu* crash when beginning to compile + +Technical details: +* host: amd64 Linux +* qemu v4.2.0 (recompiled from git with debug options using configure --target-list=s390x-softmmu --enable-debug) (problem appears also with older versions of qemu from git, with default compilation options, with qemu from debian, etc.) +* compiled with gcc 9.2 +* command line, relevant part: qemu-system-s390x -snapshot -machine s390-ccw-virtio -cpu max,zpci=on -serial mon:stdio -display none -m 512 +(tested with -smp 4 -m 4096 as well and without snapshotting) +* command line, less relevant part: -drive file=./debian.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-ccw,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,scsi=off -netdev user,id=mynet0,hostfwd=tcp::2223-:22 -device virtio-net-pci,netdev=mynet0 +* core dump: abort in qemu/target/s390x/translate.c line 3894 ; s->field: op has value 0xEC and op2 has value 0x54 +(more info available if needed) + +Tried to patch source to add 0x54 case to no avail. +Tried other cpu variants to no avail as well. + +Reporting this in security as well since it also looks very much like a DoS (albeit somewhat minor), feel free to tell me to report the bug somewhere else. + +There is definitely something wrong here ;-) According to the "Principles of Operations" ISA document, opcode 0xEC54 is the RNSBG instruction (ROTATE THEN AND SELECTED BITS). But op_rosbg() apparently currently handles 0xEC55, 0xEC56 and 0xEC57. 0xEC55 seems wrong there, since this opcode should be handled by op_risbg() instead (according to target/s390x/insn-data.def). So the "case 0x55" seems to be a typo. Does it work if you replace "case 0x55" with "case 0x54" ? + +Suggested patch: +https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg07514.html +"target/s390x/translate: Fix RNSBG instruction" + +Sorry for delay in answering, replacing 0x55 by 0x54 works fine for me. + +Thanks. + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0bab189c96c7 + diff --git a/results/classifier/105/instruction/1861562 b/results/classifier/105/instruction/1861562 new file mode 100644 index 00000000..0e33f9d5 --- /dev/null +++ b/results/classifier/105/instruction/1861562 @@ -0,0 +1,187 @@ +instruction: 0.591 +other: 0.569 +mistranslation: 0.534 +device: 0.489 +semantic: 0.487 +vnc: 0.466 +assembly: 0.456 +boot: 0.422 +graphic: 0.418 +socket: 0.410 +KVM: 0.402 +network: 0.339 + +piix crashes on mips when using multiple cpus + +Crash occurred while testing commit 330edfcc84a7: + +$ qemu-system-mips64el -cpu I6400 -append "clocksource=GIC console=ttyS0" -smp 8 -kernel vmlinux +Linux version 4.7.0-rc1 (phil@x1) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Sat Feb 1 13:15:19 UTC 2020 +earlycon: uart8250 at I/O port 0x3f8 (options '38400n8') +bootconsole [uart8250] enabled +CPU0 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +MIPS: machine is mti,malta +Software DMA cache coherency enabled +Determined physical RAM map: + memory: 0000000008000000 @ 0000000000000000 (usable) +Zone ranges: + DMA [mem 0x0000000000000000-0x0000000000ffffff] + DMA32 [mem 0x0000000001000000-0x00000000ffffffff] + Normal empty +Movable zone start for each node +Early memory node ranges + node 0: [mem 0x0000000000000000-0x0000000007ffffff] +Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] +VP topology {8} total 8 +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +percpu: Embedded 5 pages/cpu @980000000107c000 s29664 r8192 d44064 u81920 +Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8163 +Kernel command line: clocksource=GIC console=ttyS0 +log_buf_len individual max cpu contribution: 4096 bytes +log_buf_len total cpu_extra contributions: 28672 bytes +log_buf_len min size: 32768 bytes +log_buf_len: 65536 bytes +early log buf free: 30432(92%) +PID hash table entries: 512 (order: -2, 4096 bytes) +Dentry cache hash table entries: 16384 (order: 3, 131072 bytes) +Inode-cache hash table entries: 8192 (order: 2, 65536 bytes) +Writing ErrCtl register=00000000 +Readback ErrCtl register=00000000 +MAAR configuration: + [0]: 0x0000000000010000-0x0000000007ffffff speculate + [1]: disabled + [2]: disabled + [3]: disabled + [4]: disabled + [5]: disabled + [6]: disabled + [7]: disabled +Memory: 121104K/131072K available (5253K kernel code, 380K rwdata, 1276K rodata, 304K init, 278K bss, 9968K reserved, 0K cma-reserved) +Hierarchical RCU implementation. + Build-time adjustment of leaf fanout to 64. +NR_IRQS:256 +CPU frequency 200.00 MHz +GIC frequency 100.00 MHz +clocksource: GIC: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112702515 ns +clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112355619 ns +sched_clock: 32 bits at 100MHz, resolution 9ns, wraps every 21474556923ns +... +Primary instruction cache 64kB, VIPT, 4-way, linesize 64 bytes. +Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 64 bytes +CPU7 revision is: 0001a900 (MIPS I6400) +FPU revision is: 20f30300 +MSA revision is: 00000300 +Synchronize counters for CPU 7: done. +Brought up 8 CPUs +devtmpfs: initialized +clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +NET: Registered protocol family 16 +pm-cps: CPC does not support clock gating +vgaarb: loaded +SCSI subsystem initialized +PCI host bridge to bus 0000:00 +pci_bus 0000:00: root bus resource [mem 0x10000000-0x17ffffff] +pci_bus 0000:00: root bus resource [io 0x1000-0x1fffff] +pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] +pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] +pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size) +pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size) +pci 0000:00:0a.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x14: [io 0x03f6] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] +pci 0000:00:0a.1: legacy IDE quirk: reg 0x1c: [io 0x0376] +Aborted (core dumped) + +(gdb) bt +#0 0x00007fe1e8d37e35 in raise () at /lib64/libc.so.6 +#1 0x00007fe1e8d22895 in abort () at /lib64/libc.so.6 +#2 0x000055d442b388ba in acpi_gpe_ioport_get_ptr (addr=addr@entry=49312, ar=ar@entry=0x55d4444212d0) at hw/acpi/core.c:670 +#3 0x000055d442b388ba in acpi_gpe_ioport_writeb (ar=ar@entry=0x55d4444212d0, addr=addr@entry=49312, val=val@entry=181) at hw/acpi/core.c:680 +#4 0x000055d442d3f363 in gpe_writeb (opaque=0x55d444420800, addr=49312, val=181, width=<optimized out>) at hw/acpi/piix4.c:553 +#5 0x000055d442b9534b in memory_region_write_accessor (mr=mr@entry=0x55d4444211e0, addr=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) + at memory.c:483 +#6 0x000055d442b9305e in access_with_adjusted_size (addr=addr@entry=49312, value=value@entry=0x7fe1ddff9ef8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry= + 0x55d442b95220 <memory_region_write_accessor>, mr=0x55d4444211e0, attrs=...) at memory.c:544 +#7 0x000055d442b976b4 in memory_region_dispatch_write (mr=mr@entry=0x55d4444211e0, addr=addr@entry=49312, data=<optimized out>, data@entry=327163317, op=op@entry=MO_64, attrs=...) at memory.c:1475 +#8 0x000055d442ba44fd in io_writex + (env=env@entry=0x55d443ec8f60, mmu_idx=mmu_idx@entry=0, val=val@entry=327163317, addr=addr@entry=10376293541929074848, retaddr=140608199778784, op=MO_64, iotlbentry=<optimized out>, iotlbentry=<optimized out>) + at accel/tcg/cputlb.c:980 +#9 0x000055d442baa43c in store_helper (op=MO_64, retaddr=140608199778784, oi=<optimized out>, val=<optimized out>, addr=10376293541929074848, env=0x55d443ec8f60) at accel/tcg/cputlb.c:1788 +#10 0x000055d442baa43c in helper_le_stq_mmu (env=0x55d443ec8f60, addr=10376293541929074848, val=327163317, oi=<optimized out>, retaddr=140608199778784) at accel/tcg/cputlb.c:1920 +#11 0x00007fe1e5cce1e0 in code_gen_buffer () +#12 0x000055d442bbc6d3 in cpu_tb_exec (itb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:172 +#13 0x000055d442bbc6d3 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x0) at accel/tcg/cpu-exec.c:618 +#14 0x000055d442bbc6d3 in cpu_exec (cpu=cpu@entry=0x55d443ec0550) at accel/tcg/cpu-exec.c:731 +#15 0x000055d442b88580 in tcg_cpu_exec (cpu=0x55d443ec0550) at cpus.c:1405 +#16 0x000055d442b8a6f4 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x55d443ec0550) at cpus.c:1713 +#17 0x000055d442faeb7b in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:519 +#18 0x00007fe1e8ece4c0 in start_thread () at /lib64/libpthread.so.0 +#19 0x00007fe1e8dfc163 in clone () at /lib64/libc.so.6 + +ACPI GPE was added in: + +commit 5e3cb5347e9b650bdf8015da3c310b2669219294 +Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162> +Date: Wed Feb 11 15:21:35 2009 +0000 + + qemu: initialize hot add system / acpi gpe (Marcelo Tosatti) + + ACPI GPE support, used by PCI (and CPU) hotplug. + + From: Glauber Costa <email address hidden> + Signed-off-by: Marcelo Tosatti <email address hidden> + Signed-off-by: Anthony Liguori <email address hidden> + +GPE_LEN=4 definition was added in: + +commit 23910d3f669d46073b403876e30a7314599633af +Author: Isaku Yamahata <email address hidden> +Date: Fri Mar 25 19:54:41 2011 +0900 + + acpi, acpi_piix: factor out GPE logic + + factor out ACPI GPE logic. Later it will be used by ICH9 ACPI. + + Signed-off-by: Isaku Yamahata <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +I am not sure what '4' means here. + +Note, Linux kernels "256 GPEs can be masked": +https://github.com/torvalds/linux/commit/a7583e72a5f22 + +I can not find reference to GPE in the PIIX4 datasheet (290562-001). + + +The Malta + I6400 boots properly when disabling this feature using: +-- >8 --- +--- a/hw/acpi/piix4.c ++++ b/hw/acpi/piix4.c +@@ -502,9 +502,11 @@ static void piix4_pm_realize(PCIDevice *dev, Error **errp) + s->machine_ready.notify = piix4_pm_machine_ready; + qemu_add_machine_init_done_notifier(&s->machine_ready); + ++ if (0) { + piix4_acpi_system_hot_add_init(pci_address_space_io(dev), + pci_get_bus(dev), s); + qbus_set_hotplug_handler(BUS(pci_get_bus(dev)), OBJECT(s), &error_abort); ++ } + + piix4_pm_add_propeties(s); + } +--- + + +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/193 + + diff --git a/results/classifier/105/instruction/1862887 b/results/classifier/105/instruction/1862887 new file mode 100644 index 00000000..2f1dc567 --- /dev/null +++ b/results/classifier/105/instruction/1862887 @@ -0,0 +1,100 @@ +instruction: 0.906 +device: 0.894 +KVM: 0.887 +other: 0.887 +vnc: 0.869 +semantic: 0.848 +mistranslation: 0.845 +assembly: 0.842 +network: 0.831 +socket: 0.821 +boot: 0.816 +graphic: 0.728 + +qemu does not load pulseaudio modules properly + +Hello, + +This is on Arch-linux(latest) and the qemu 4.2.0 version made from git clone https://github.com/spheenik/qemu.git +with: + ./configure --prefix=/opt/qemu-test --python=/usr/bin/python2 --target-list=x86_64-softmmu +--audio-drv-list=pa --disable-werror +added to the build. + +I've been workin on a passthrough Windows 10 vm this month and have been steadily seeing some promising progress. My block/issue at the moment is integrating the audio now that the GPU has been succesfully passed through. +I've been going back and forth between the audio options for Pulseaudio and cannot change the following issue: +pulseaudio: pa_context_connect() failed +pulseaudio: Reason: Connection refused +pulseaudio: Failed to initialize PA contextlibusb: error [udev_hotplug_event] ignoring udev action bind +I leave my current operable build followed by some of the options that I have tried using to correct this despite the following errors not changing + +This is my current operable build: + +#!/bin/bash + +vmname="windows10vm" + +if ps -ef | grep /opt/qemu-test/bin/qemu-system-x86_64 | grep -q multifunction=on; then +echo "A passthrough VM is already running." & +exit 1 + +else + +/opt/qemu-test/bin/qemu-system-x86_64 \ +-m 12G \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=.../win2.img \ +-drive file=.../Win10_1909_English_x64.iso,index=1,media=cdrom \ +-drive file=.../virtio-win-0.1.171.iso,index=2,media=cdrom \ +-boot order=dc \ +-bios /usr/share/ovmf/x64/OVMF_CODE.fd \ +-name $vmname,process=$vmname \ +-machine type=q35,accel=kvm,vmport=off \ +-cpu host,kvm=off \ +-smp 3,sockets=1,cores=3,threads=1 \ +-device virtio-balloon \ +-rtc clock=host,base=localtime \ +-vga none \ +-nographic \ +-serial none \ +-parallel none \ +-soundhw hda \ +-usb \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device vfio-pci,host=...,multifunction=on \ +-device vfio-pci,host=... \ +-device e1000,netdev=net0 \ +-netdev user,id=net0,hostfwd=tcp::...-:22 \ + +Here's a list of setting combinations I had tried to resolve this: + +#export QEMU_AUDIO_DRV=pa +#QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 +#export QEMU_PA_SAMPLES=8192 +#export QEMU_AUDIO_TIMER_PERIOD=99 +#export QEMU_PA_SERVER=/run/user/1000/pulse/native +#export QEMU_PA_SINK=alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo +#export QEMU_PA_SOURCE=input + +-audiodev pa,id=pa1,server=server=/run/user/1000/pulse/native + +At best I have removed an XDG_RUNTIME_DIR error but other than that this build has no audio compatability. + +EDIT: This is for Arch 2020.02.01 + +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/105/instruction/1863247 b/results/classifier/105/instruction/1863247 new file mode 100644 index 00000000..072da78e --- /dev/null +++ b/results/classifier/105/instruction/1863247 @@ -0,0 +1,33 @@ +instruction: 0.742 +device: 0.668 +graphic: 0.540 +semantic: 0.501 +other: 0.498 +mistranslation: 0.393 +socket: 0.384 +network: 0.383 +vnc: 0.341 +boot: 0.254 +assembly: 0.250 +KVM: 0.178 + +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/105/instruction/1863685 b/results/classifier/105/instruction/1863685 new file mode 100644 index 00000000..ae214b91 --- /dev/null +++ b/results/classifier/105/instruction/1863685 @@ -0,0 +1,48 @@ +instruction: 0.867 +other: 0.742 +semantic: 0.658 +mistranslation: 0.656 +device: 0.596 +graphic: 0.384 +vnc: 0.359 +network: 0.346 +socket: 0.339 +assembly: 0.324 +KVM: 0.247 +boot: 0.220 + +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/105/instruction/1865348 b/results/classifier/105/instruction/1865348 new file mode 100644 index 00000000..3e6d9100 --- /dev/null +++ b/results/classifier/105/instruction/1865348 @@ -0,0 +1,61 @@ +instruction: 0.822 +device: 0.772 +graphic: 0.613 +semantic: 0.600 +other: 0.465 +mistranslation: 0.311 +network: 0.282 +socket: 0.228 +vnc: 0.186 +KVM: 0.125 +assembly: 0.087 +boot: 0.067 + +virsh domfsinfo testdom crashes the guest agent + + + +[@ ~]# virsh qemu-agent-command vps-01 '{"execute":"guest-get-fsinfo"}' + + +error: Guest agent is not responding: Guest agent disappeared while executing command + +[@ ~]# virsh domfsinfo vps-01 +error: Unable to get filesystem information +error: Guest agent is not responding: Guest agent disappeared while executing command + + +Fault bucket , type 0 +Event Name: APPCRASH +Response: Not available +Cab Id: 0 + +Problem signature: +P1: qemu-ga.exe +P2: 100.0.0.0 +P3: 5c473543 +P4: KERNELBASE.dll +P5: 6.1.7601.24545 +P6: 5e0eb6bd +P7: c0000005 +P8: 000000000000c4d2 +P9: +P10: + +Attached files: + +These files may be available here: +C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_qemu-ga.exe_bd2e6535bdb93328680e0285e89e08f2866db83_49df29e2 + +Analysis symbol: +Rechecking for solution: 0 +Report Id: 2ad29522-5bcc-11ea-bca6-525400e83365 +Report Status: 0 + + +guest os: windows server std 2008r2 + +Does this problem still reproduce with the latest versions of QEMU and libvirt? If so, could you please provide a backtrace of the crashed guest-agent? Thanks! + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1865626 b/results/classifier/105/instruction/1865626 new file mode 100644 index 00000000..6a4fcda9 --- /dev/null +++ b/results/classifier/105/instruction/1865626 @@ -0,0 +1,51 @@ +instruction: 0.646 +device: 0.585 +boot: 0.552 +socket: 0.550 +mistranslation: 0.412 +semantic: 0.399 +graphic: 0.264 +network: 0.245 +other: 0.235 +assembly: 0.232 +vnc: 0.196 +KVM: 0.007 + +s390x guest hang when ipl boot from a mdev dasd + +qemu latest +kernel 5.3.18 + +I am using a passthrough dasd as boot device, the installment looks fine and gets into reboot process. However VM could not boot and just hang as below after that. I have been checking on "s390: vfio-ccw dasd ipl support" series right now but no clue yet. Could anyone take a look for it? Thanks. + + + +s390vsw188:~ # bash test.sh +LOADPARM=[ ] +executing ccw chain at : 0x0000000000000018 +executing ccw chain at : 0x000000000000e000 + +2020-03-01T06:24:56.879314Z qemu-system-s390x: warning: vfio-ccw (devno fe.0.0000): PFCH flag forced + + + +s390zp12:~ # cat test.sh +/root/qemu/s390x-softmmu/qemu-system-s390x \ +-machine s390-ccw-virtio,accel=kvm \ +-nographic \ +-bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \ +-device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,,devno=fe.0.0000,bootindex=1 \ +-global vfio-ccw.force-orb-pfch=yes \ + +s390zp12:~ # cat test.sh +/root/qemu/s390x-softmmu/qemu-system-s390x \ +-machine s390-ccw-virtio,accel=kvm \ +-nographic \ +-bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \ +-device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,devno=fe.0.1234,bootindex=1 \ +-global vfio-ccw.force-orb-pfch=yes + +Can you still reproduce this issue with the latest version of QEMU? Which kind of guest did you install? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1873898 b/results/classifier/105/instruction/1873898 new file mode 100644 index 00000000..eed54160 --- /dev/null +++ b/results/classifier/105/instruction/1873898 @@ -0,0 +1,57 @@ +instruction: 0.797 +mistranslation: 0.554 +device: 0.554 +graphic: 0.552 +network: 0.536 +semantic: 0.510 +socket: 0.496 +other: 0.458 +vnc: 0.432 +assembly: 0.383 +boot: 0.316 +KVM: 0.182 + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). + +Should be fixed in current git, will be in 5.2. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=13a0c21e64bddf1a36 + diff --git a/results/classifier/105/instruction/1877706 b/results/classifier/105/instruction/1877706 new file mode 100644 index 00000000..7fa829a2 --- /dev/null +++ b/results/classifier/105/instruction/1877706 @@ -0,0 +1,64 @@ +instruction: 0.983 +other: 0.905 +semantic: 0.837 +device: 0.817 +graphic: 0.784 +vnc: 0.764 +boot: 0.760 +network: 0.737 +mistranslation: 0.714 +socket: 0.689 +assembly: 0.567 +KVM: 0.464 + + [Feature request] qemu does not support for Octeon MIPS64 on X86 + +Description of problem: + +I use mips64-octeon-linux-gnu-gcc cross toolchain on X86,and generate binary file. + +> mips64-octeon-linux-gnu-gcc hello.c -static +> file a.out +> a.out: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, not stripped + +I execute it with mips64-linux-user mode in qemu, it is invalid. + +> ./qemu-5.0.0/mips64-linux-user/qemu-mips64 a.out +> a.out: Invalid ELF image for this architecture + +when I choose mips-linux-user mode, it regards as illegal instruction. + +> ./qemu-5.0.0/mips-linux-user/qemu-mips a.out +> qemu: uncaught target signal 4 (Illegal instruction) - core dumped +> Illegal instruction (core dumped) + +I would like to know, is this due to my problem or does qemu not support Octeon MIPS64 on X86? + +if qemu has supported Octeon MIPS64 on X86, how can I emulate it. + +Probably not, but there may be a workaround. The closest cpu to Octeon that is supported in QEMU is "MIPS64R2-generic". + +Please try using switch -cpu MIPS64R2-generic in your QEMU command line. + +Also, I think you should use qemu-mipsn32 rather than qemu-mips or qemu-mips64. + +I don't have much hope that all this will work, but it is worth trying. + + + + + + +Hi, Lu. + +Where can I download Octeon toolchain you used? + +I want to try it by myself. + +Aleksandar + +Was the MIPS64R2-generic good enough for you? + +If your file is "ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1", +then you have to use the mipsn32-linux-user variant of QEMU (binary 'qemu-mipsn32'). + diff --git a/results/classifier/105/instruction/1877794 b/results/classifier/105/instruction/1877794 new file mode 100644 index 00000000..6164a2a8 --- /dev/null +++ b/results/classifier/105/instruction/1877794 @@ -0,0 +1,31 @@ +instruction: 0.918 +graphic: 0.877 +device: 0.788 +other: 0.785 +semantic: 0.687 +socket: 0.499 +mistranslation: 0.446 +boot: 0.440 +network: 0.413 +vnc: 0.386 +assembly: 0.281 +KVM: 0.097 + +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/105/instruction/1880424 b/results/classifier/105/instruction/1880424 new file mode 100644 index 00000000..04870385 --- /dev/null +++ b/results/classifier/105/instruction/1880424 @@ -0,0 +1,59 @@ +instruction: 0.902 +other: 0.899 +graphic: 0.894 +device: 0.889 +vnc: 0.885 +semantic: 0.880 +assembly: 0.878 +KVM: 0.876 +socket: 0.873 +mistranslation: 0.865 +boot: 0.858 +network: 0.852 + +I/O write make imx_epit_reset() crash + +libFuzzer found: + +qemu-fuzz-arm: hw/core/ptimer.c:377: void ptimer_transaction_begin(ptimer_state *): Assertion `!s->in_transaction' failed. +==6041== ERROR: libFuzzer: deadly signal + #8 0x7fcaba320565 in __GI___assert_fail (/lib64/libc.so.6+0x30565) + #9 0x563b46f91637 in ptimer_transaction_begin (qemu-fuzz-arm+0x1af1637) + #10 0x563b476cc4c6 in imx_epit_reset (qemu-fuzz-arm+0x222c4c6) + #11 0x563b476cd004 in imx_epit_write (qemu-fuzz-arm+0x222d004) + #12 0x563b46582377 in memory_region_write_accessor (qemu-fuzz-arm+0x10e2377) + #13 0x563b46581ee3 in access_with_adjusted_size (qemu-fuzz-arm+0x10e1ee3) + #14 0x563b46580a83 in memory_region_dispatch_write (qemu-fuzz-arm+0x10e0a83) + #15 0x563b463c5022 in flatview_write_continue (qemu-fuzz-arm+0xf25022) + #16 0x563b463b4ea2 in flatview_write (qemu-fuzz-arm+0xf14ea2) + #17 0x563b463b49d4 in address_space_write (qemu-fuzz-arm+0xf149d4) + +Reproducer: + +qemu-system-arm -M kzm -display none -S -qtest stdio << 'EOF' +writel 0x53f94000 0x110000 +EOF + +qemu-system-arm: hw/core/ptimer.c:377: ptimer_transaction_begin: Assertion `!s->in_transaction' failed. +Aborted (core dumped) + +(gdb) bt +#1 0x00007f4aa4daa895 in abort () at /lib64/libc.so.6 +#2 0x00007f4aa4daa769 in _nl_load_domain.cold () at /lib64/libc.so.6 +#3 0x00007f4aa4db8566 in annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x000055ee85400164 in ptimer_transaction_begin (s=0x55ee873bc4c0) at hw/core/ptimer.c:377 +#5 0x000055ee855c7936 in imx_epit_reset (dev=0x55ee871725c0) at hw/timer/imx_epit.c:111 +#6 0x000055ee855c7d1b in imx_epit_write (opaque=0x55ee871725c0, offset=0, value=1114112, size=4) at hw/timer/imx_epit.c:209 +#7 0x000055ee8513db85 in memory_region_write_accessor (mr=0x55ee871728f0, addr=0, value=0x7fff3012d6f8, size=4, shift=0, mask=4294967295, attrs=...) at memory.c:483 +#8 0x000055ee8513dd96 in access_with_adjusted_size (addr=0, value=0x7fff3012d6f8, size=4, access_size_min=1, access_size_max=4, access_fn= + 0x55ee8513daa2 <memory_region_write_accessor>, mr=0x55ee871728f0, attrs=...) at memory.c:545 +#9 0x000055ee85140cbd in memory_region_dispatch_write (mr=0x55ee871728f0, addr=0, data=1114112, op=MO_32, attrs=...) at memory.c:1477 +#10 0x000055ee850deba5 in flatview_write_continue (fv=0x55ee87181bd0, addr=1408843776, attrs=..., ptr=0x7fff3012d900, len=4, addr1=0, l=4, mr=0x55ee871728f0) at exec.c:3147 +#11 0x000055ee850decf3 in flatview_write (fv=0x55ee87181bd0, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3190 +#12 0x000055ee850df05d in address_space_write (as=0x55ee8730a560, addr=1408843776, attrs=..., buf=0x7fff3012d900, len=4) at exec.c:3289 + +Patch on list: https://<email address hidden>/ + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=13557fd392890cbd985 + diff --git a/results/classifier/105/instruction/1881450 b/results/classifier/105/instruction/1881450 new file mode 100644 index 00000000..596c04be --- /dev/null +++ b/results/classifier/105/instruction/1881450 @@ -0,0 +1,73 @@ +instruction: 0.948 +other: 0.864 +graphic: 0.802 +device: 0.789 +semantic: 0.763 +boot: 0.751 +socket: 0.708 +mistranslation: 0.700 +vnc: 0.622 +network: 0.605 +assembly: 0.582 +KVM: 0.473 + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125 + + + + + +Tracing gives me: + +IN: expm1f +0x800005cc: fetoxm1x %fp2,%fp0 +Disassembler disagrees with translator over instruction decoding +Please report this to <email address hidden> + +(gdb) x/2hx 0x800005cc +0x800005cc: 0xf200 0x0808 + +The instruction is not implemented in qemu. I fix that. + + + +Fix available. + +Execution doesn't fail anymore: + + Profiling function expm1f(): + Elapsed time: 41 ms + Control result: 71805.108342 + +Control result matches real hardware one: + + Profiling function expm1f(): + Elapsed time: 2152 ms + Control result: 71805.108342 + + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=250b1da35d579f423 + diff --git a/results/classifier/105/instruction/1882065 b/results/classifier/105/instruction/1882065 new file mode 100644 index 00000000..8dfea365 --- /dev/null +++ b/results/classifier/105/instruction/1882065 @@ -0,0 +1,50 @@ +instruction: 0.762 +graphic: 0.749 +network: 0.716 +device: 0.712 +mistranslation: 0.709 +semantic: 0.692 +vnc: 0.659 +socket: 0.636 +other: 0.589 +boot: 0.487 +KVM: 0.422 +assembly: 0.342 + +Could this cause OOB bug ? + +In function megasas_handle_scsi(hw/scsi/megasas.c): + +```c +static int megasas_handle_scsi(MegasasState *s, MegasasCmd *cmd, + int frame_cmd) +{ + ............................................................................ + cdb = cmd->frame->pass.cdb; + target_id = cmd->frame->header.target_id; + lun_id = cmd->frame->header.lun_id; + cdb_len = cmd->frame->header.cdb_len; + ............................................................................ + if (cdb_len > 16) { + trace_megasas_scsi_invalid_cdb_len( + mfi_frame_desc[frame_cmd], is_logical, + target_id, lun_id, cdb_len); + megasas_write_sense(cmd, SENSE_CODE(INVALID_OPCODE)); + cmd->frame->header.scsi_status = CHECK_CONDITION; + s->event_count++; + return MFI_STAT_SCSI_DONE_WITH_ERROR; + } +} +``` + +Two variables, frame_cmd and cdb_len, can be controlled by guest os. So can mfi_frame_desc[frame_cmd] cause OOB bug ? + +QEMU emulator version 5.0.50 (v5.0.0-533-gdebe78ce14-dirty) + +You must start the trace function of QEMU to trigger this BUG! + +I think we should fix this anyway, even if it can only be triggered when trace functions are enabled + +Fix has been included: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ee760ac80ac1f1 + diff --git a/results/classifier/105/instruction/1882497 b/results/classifier/105/instruction/1882497 new file mode 100644 index 00000000..dd4b1a6b --- /dev/null +++ b/results/classifier/105/instruction/1882497 @@ -0,0 +1,49 @@ +instruction: 0.674 +other: 0.581 +graphic: 0.535 +device: 0.527 +vnc: 0.503 +semantic: 0.469 +network: 0.461 +socket: 0.444 +boot: 0.281 +KVM: 0.235 +assembly: 0.186 +mistranslation: 0.167 + +Missing 'cmp' utility makes build take 10 times as long + +I have been doing some work cross compiling qemu for Windows using a minimal Fedora container. Recently I started hitting some timeouts on the CI service and noticed a build of all targets was going over 1 hour. + +It seems like the 'cmp' utility from diffutils is used somewhere in the process and if it's missing, either a configure or a make gets run way too many times - I'll try to pull logs from the CI system at some stage soon. + +Could a warning or error be added if cmp is missing? + +cmp is used in the makefiles. + +And there is some kind of warning during build if it is missing: + +/bin/sh: cmp: command not found + +But perhaps it should abort the build in this case. + +Something like that helps: + +diff --git a/Makefile b/Makefile +index 40e4f7677bde..05e029bd99db 100644 +--- a/Makefile ++++ b/Makefile +@@ -482,6 +482,7 @@ include $(SRC_PATH)/tests/Makefile.include + all: $(DOCS) $(if $(BUILD_DOCS),sphinxdocs) $(TOOLS) $(HELPERS-y) recurse-all modules $(vhost-user-json-y) + + qemu-version.h: FORCE ++ @type cmp + $(call quiet-command, \ + (printf '#define QEMU_PKGVERSION "$(QEMU_PKGVERSION)"\n'; \ + printf '#define QEMU_FULL_VERSION "$(FULL_VERSION)"\n'; \ + + +Does this problem still persist with the latest version of QEMU (since we switched the build system mostly to meson now)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1885350 b/results/classifier/105/instruction/1885350 new file mode 100644 index 00000000..79d797ae --- /dev/null +++ b/results/classifier/105/instruction/1885350 @@ -0,0 +1,60 @@ +instruction: 0.863 +other: 0.791 +mistranslation: 0.723 +graphic: 0.693 +semantic: 0.615 +device: 0.515 +socket: 0.349 +boot: 0.321 +vnc: 0.294 +network: 0.261 +assembly: 0.162 +KVM: 0.094 + +RISCV dynamic rounding mode is not behaving correctly + +Hello, + +I’ve gone through the RISC-V code in latest QEMU release (qemu-5.0.0-rc2) and when checking the Floating point encodings I found the rounding mode is only updated if the opcode field “rm” is changed “ctx->frm == rm”. But according to RISC-V Volume I: Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding mode is set with frm value. + +So for the same rm value (=7) and when changing frm value seeking different rounding modes, and according to the below code, the rounding mode won’t be updated. Please correct me if I got this implementation wrong. + +static void gen_set_rm(DisasContext *ctx, int rm) +{ + TCGv_i32 t0; + if (ctx->frm == rm) { + return; + } + ctx->frm = rm; + t0 = tcg_const_i32(rm); + gen_helper_set_rounding_mode(cpu_env, t0); + tcg_temp_free_i32(t0); +} + + +My testcase: +I set statically the rm field in the instruction to 7 and before this execution I changed the value of frm field in fcsr register. For the 1st time it worked (according to the code above, the rm is updated so the round mode will also be updated). But when changing fcsr register an re-execute the instruction, there's no difference and the rounding mode is the same like the previous frm value. + +After checking RISCY RTL code, i found the implementation is straight forward as stated in specs as follows: + if (FPU == 1) begin + if (fp_rnd_mode == 3'b111) + apu_flags = frm_i; + else + apu_flags = fp_rnd_mode; + end else + +where fp_rnd_mode is the round mode field in the instruction opcode. + +This does look like incorrect behaviour. I have sent a patch to the mailing list. You can see the patch here: https://<email address hidden>/ea4f280e6f77e734c8e555e3c98d10085ce9f5b6<email address hidden>/ + +Thank you Alistair Francis. + +As commented on the patch submission, this should already be handled: https://<email address hidden>/msg718331.html + +Can you attach the test case that is failing? + +The QEMU project is currently moving its bug tracking to another system. +Is there still anything left to do here? If so, please provide the test case and switch the state back to "New" or "Confirmed", or open a new ticket in the new bug tracker here: https://gitlab.com/qemu-project/qemu/-/issues + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1885719 b/results/classifier/105/instruction/1885719 new file mode 100644 index 00000000..c43a0073 --- /dev/null +++ b/results/classifier/105/instruction/1885719 @@ -0,0 +1,41 @@ +instruction: 0.957 +mistranslation: 0.922 +socket: 0.913 +network: 0.868 +graphic: 0.845 +semantic: 0.790 +device: 0.760 +other: 0.668 +vnc: 0.637 +assembly: 0.525 +boot: 0.343 +KVM: 0.280 + +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/105/instruction/1885720 b/results/classifier/105/instruction/1885720 new file mode 100644 index 00000000..b6e68c03 --- /dev/null +++ b/results/classifier/105/instruction/1885720 @@ -0,0 +1,35 @@ +instruction: 0.859 +socket: 0.753 +device: 0.727 +network: 0.680 +semantic: 0.658 +mistranslation: 0.651 +graphic: 0.635 +vnc: 0.628 +other: 0.307 +KVM: 0.279 +boot: 0.269 +assembly: 0.190 + +qemu/migration/postcopy-ram.c:387: bad return expression ? + +qemu/migration/postcopy-ram.c:387:9: style: Non-boolean value returned from function returning bool [returnNonBoolInBooleanFunction] + +Source code is + + return -1; + +but + +bool postcopy_ram_supported_by_host( + +That looks like a bug, indeed! + +Yes, I think a goto out; there makes sense; nearly 5 years old that error :-) + +Posted: +migration: postcopy take proper error return + +Fix has been merged: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=617a32f5295ee4e + diff --git a/results/classifier/105/instruction/1886811 b/results/classifier/105/instruction/1886811 new file mode 100644 index 00000000..f0ee941b --- /dev/null +++ b/results/classifier/105/instruction/1886811 @@ -0,0 +1,97 @@ +instruction: 0.818 +device: 0.813 +mistranslation: 0.800 +graphic: 0.799 +assembly: 0.797 +semantic: 0.795 +other: 0.779 +network: 0.776 +boot: 0.763 +KVM: 0.762 +vnc: 0.740 +socket: 0.731 + +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/105/instruction/1887641 b/results/classifier/105/instruction/1887641 new file mode 100644 index 00000000..892794a9 --- /dev/null +++ b/results/classifier/105/instruction/1887641 @@ -0,0 +1,56 @@ +instruction: 0.911 +boot: 0.905 +device: 0.895 +graphic: 0.880 +socket: 0.874 +other: 0.872 +assembly: 0.855 +semantic: 0.847 +network: 0.810 +vnc: 0.806 +KVM: 0.802 +mistranslation: 0.788 + +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/105/instruction/1888165 b/results/classifier/105/instruction/1888165 new file mode 100644 index 00000000..c9b247f0 --- /dev/null +++ b/results/classifier/105/instruction/1888165 @@ -0,0 +1,34 @@ +instruction: 0.812 +device: 0.594 +graphic: 0.445 +semantic: 0.425 +network: 0.402 +vnc: 0.336 +mistranslation: 0.311 +socket: 0.247 +other: 0.214 +boot: 0.185 +assembly: 0.089 +KVM: 0.051 + +loopz/loopnz clearing previous instruction's modified flags on cx -> 0 + +If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction. + +After executing a sequence like this in qemu: + + mov bx,1 + mov cx,1 + dec bx ; sets Z bit in flags +A: loopnz A ; should not modify flags + +Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting. + +Version 5.1.0-rc0, x86-64 host. + + + + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3cb3a7720b01830abd5 + diff --git a/results/classifier/105/instruction/1889288 b/results/classifier/105/instruction/1889288 new file mode 100644 index 00000000..4b1ea187 --- /dev/null +++ b/results/classifier/105/instruction/1889288 @@ -0,0 +1,26 @@ +instruction: 0.757 +mistranslation: 0.724 +semantic: 0.599 +graphic: 0.519 +assembly: 0.467 +other: 0.455 +device: 0.440 +socket: 0.381 +vnc: 0.348 +network: 0.348 +boot: 0.182 +KVM: 0.137 + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. + +The code is correct (though it is admittedly not entirely obvious at first glance). The switch statement at line 4753 is on "(opc | (invert << 2))" (where opc is a 2 bit field and invert a 1 bit field). Both ANDS and BICS have opc==3 and so will cause a call to gen_logic_CC(). The difference between the two insns is that ANDC has invert==0 and BICS has invert==1. + + +Oh yes I see. Sorry for the false report. + diff --git a/results/classifier/105/instruction/1889421 b/results/classifier/105/instruction/1889421 new file mode 100644 index 00000000..6314d5a3 --- /dev/null +++ b/results/classifier/105/instruction/1889421 @@ -0,0 +1,60 @@ +instruction: 0.892 +graphic: 0.848 +network: 0.834 +other: 0.805 +device: 0.740 +semantic: 0.711 +vnc: 0.692 +mistranslation: 0.670 +boot: 0.590 +socket: 0.505 +assembly: 0.486 +KVM: 0.472 + +VVFAT is not writable from Windows NT 3.5, 3.51 and 4.0 + +I'm running Windows NT 3.5, 3.51 and 4.0 in QEMU 4.2.0 on Linux. I'm using a VVFAT filesystem. Command lines: + +$ qemu-system-i386 -L pc -cpu 486 -m 64 -vga cirrus -drive file=nt351.img,format=raw -net nic,model=pcnet -net user -soundhw sb16,pcspk -drive file=fat:rw:drived,format=raw + +$ qemu-system-i386 --version +QEMU emulator version 4.2.0 (Debian 1:4.2-6) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Creating a new directory or file on drive D: (the VVFAT filesystem) fails on Windows NT 3.5, 3.51 and 4.0 (see screenshot). It succeeds on Windows NT 3.1. + +Is there a workaround, e.g. a QEMU flag or a change in the Windows NT driver settings? + + + +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/105/instruction/1890 b/results/classifier/105/instruction/1890 new file mode 100644 index 00000000..2e57942c --- /dev/null +++ b/results/classifier/105/instruction/1890 @@ -0,0 +1,38 @@ +instruction: 0.879 +graphic: 0.770 +device: 0.752 +vnc: 0.695 +semantic: 0.672 +socket: 0.662 +network: 0.580 +boot: 0.514 +mistranslation: 0.504 +assembly: 0.438 +KVM: 0.277 +other: 0.184 + +qemu-arm 8.1.0 Error mapping file: Operation not permitted +Description of problem: +failed to execute the cortex-m binary hello_world, and says: +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +Steps to reproduce: +1. +``` +cat > hello_new.c <<EOF +#include <stdio.h> +int main() +{printf("hello world"); return 0;} +EOF +``` +2. +``` +arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs +``` +3. +``` +qemu-arm -cpu cortex-m55 hello_world +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +``` +Additional information: +1, version 8.0.4 version is okay\ +2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/105/instruction/1890310 b/results/classifier/105/instruction/1890310 new file mode 100644 index 00000000..021e5107 --- /dev/null +++ b/results/classifier/105/instruction/1890310 @@ -0,0 +1,65 @@ +instruction: 0.540 +other: 0.538 +graphic: 0.516 +vnc: 0.465 +network: 0.452 +KVM: 0.444 +assembly: 0.434 +device: 0.432 +mistranslation: 0.424 +semantic: 0.400 +socket: 0.395 +boot: 0.357 + +Segfault in artist.c:block_move + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf8100802 0xff5c651ffffb7c5c +writeq 0xf8100afb 0x25e000000000000 +EOF + +AddressSanitizer:DEADLYSIGNAL +================================================================= +==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a540000 (pc 0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0) +==12686==The signal is caused by a READ memory access. + #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13 + #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9 + #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x55af39a54873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23 + #6 0x55af390ea866 in flatview_write /exec.c:3216:14 + #7 0x55af390ea387 in address_space_write /exec.c:3308:18 + #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x55af3c119474 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f0028f60897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11 + #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x55af3c151261 in main /softmmu/main.c:49:5 + #21 0x7f0027ae6e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x55af38ff5729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move +==12686==ABORTING + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex + +Fixed by commit a501bfc91763d4642390090dd4e6039d67b63702. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/instruction/1892081 b/results/classifier/105/instruction/1892081 new file mode 100644 index 00000000..11dd351a --- /dev/null +++ b/results/classifier/105/instruction/1892081 @@ -0,0 +1,48 @@ +instruction: 0.784 +graphic: 0.587 +device: 0.569 +vnc: 0.526 +network: 0.423 +semantic: 0.395 +socket: 0.363 +boot: 0.320 +KVM: 0.249 +mistranslation: 0.200 +assembly: 0.167 +other: 0.162 + +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions + +Attached below is a matrix multiplication program for double data +types. The program performs the casting operation "(double)rand()" +when generating random numbers. + +This operation calls the integer to float softfloat conversion +function "int32_to_float_64". + +Adding the "QEMU_FLATTEN" attribute to the function definition +decreases the instructions per call of the function by about 63%. + +Attached are before and after performance screenshots from +KCachegrind. + + + + + + + +Confirmed, although "65% decrease" is on 0.44% of the total +execution for this test case, so the decrease isn't actually +noticeable. + +Nevertheless, it's a simple enough change. + + +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/134 + + diff --git a/results/classifier/105/instruction/1892441 b/results/classifier/105/instruction/1892441 new file mode 100644 index 00000000..0bad2731 --- /dev/null +++ b/results/classifier/105/instruction/1892441 @@ -0,0 +1,57 @@ +instruction: 0.887 +graphic: 0.778 +boot: 0.744 +device: 0.729 +other: 0.727 +assembly: 0.657 +vnc: 0.621 +semantic: 0.592 +mistranslation: 0.553 +socket: 0.490 +network: 0.482 +KVM: 0.284 + +"No zIPL section in IPL2 record" error when emulating Debian 10.5.0 on s390x + +Hi, + +I want to emulate Debian 10.5.0 for the s390x architecture. +The Debian image is downloaded from the following link: +https://cdimage.debian.org/debian-cd/current/s390x/iso-cd/debian-10.5.0-s390x-netinst.iso + +Using the latest QEMU version 5.1.0, running the debian image using the given command: +qemu-system-s390x -boot d -m 4096 -hda debian.qcow -cdrom debian-10.5.0-s390x-netinst.iso -nographic + +causes the error output below: + +LOADPARM=[ ] +Using virtio-blk. +Using guessed DASD geometry. +Using ECKD scheme (block size 4096), CDL + +! No zIPL section in IPL2 record. ! + +As far as I know, the Debian CD ISO images are not bootable on s390x (they do not contain boot information according to the El-Torrito standard). Please open a bug against Debian instead if you want to have that changed. So far, you have to boot here manually instead (see http://people.redhat.com/~thuth/blog/qemu/2017/12/19/install-fedora.html for some more information). + + +Yes. For booting Debian images using QEMU (<= 5.0.0) I use this recipe: + +machine_args="-M s390-ccw-virtio -m 512" +disk_args="-drive file=debian86.img,if=none,format=raw,id=hd0 -device virtio-blk-ccw,drive=hd0" +net_args="" +display_args="-display gtk -monitor stdio" +common_args="$machine_args $disk_args $net_args $display_args" + +Pull kernel and initrd from the ftp server: +mkdir boot-for-install +(cd boot-for-install + wget ftp://ftp.de.debian.org/pub/debian/dists/jessie/main/installer-s390x/current/images/generic/kernel.debian + wget ftp://ftp.de.debian.org/pub/debian/dists/jessie/main/installer-s390x/current/images/generic/initrd.debian) + +Then, for running the installer: +qemu-system-s390x $common_args -kernel boot-for-install/kernel.debian -initrd boot-for-install/initrd.debian + +For booting from disk: +qemu-system-s390x $common_args -kernel boot/vmlinuz -initrd boot/initrd.img -append "root=/dev/vda2" + + diff --git a/results/classifier/105/instruction/1892533 b/results/classifier/105/instruction/1892533 new file mode 100644 index 00000000..57db294d --- /dev/null +++ b/results/classifier/105/instruction/1892533 @@ -0,0 +1,37 @@ +instruction: 0.730 +semantic: 0.660 +device: 0.628 +other: 0.589 +graphic: 0.567 +mistranslation: 0.542 +network: 0.518 +socket: 0.451 +vnc: 0.323 +assembly: 0.295 +KVM: 0.224 +boot: 0.224 + +Meson: Missing config-host.mak + +Wanted to give a try to the new build system, but a simple "meson build" gives that error: + +meson.build:15:0: ERROR: Failed to load /home/xclaesse/programmation/qemu/build/config-host.mak: [Errno 2] No such file or directory: '/home/xclaesse/programmation/qemu/build/config-host.mak' + +configure does not seems to work better: + +build$ ../configure +../configure: 232: shift: can't shift that many + + +Meson is still hidden, you need to use ../configure. + +"can't shift that many" will be fixed shortly (patch already on the list). + +btw, I'm surprised README does not mention meson, shouldn't you instruct that it's a build-dep? Maybe suggest pip install command? + +QEMU ships with the appropriate version of Meson included (see the "meson" directory), that's why it is not mentioned in the README. + +Anyway, does any of your build problems still persist with QEMU v6.0? Or could we close this ticket now? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1893010 b/results/classifier/105/instruction/1893010 new file mode 100644 index 00000000..d7260693 --- /dev/null +++ b/results/classifier/105/instruction/1893010 @@ -0,0 +1,38 @@ +instruction: 0.861 +device: 0.837 +semantic: 0.820 +other: 0.801 +network: 0.791 +graphic: 0.776 +mistranslation: 0.690 +socket: 0.651 +boot: 0.625 +vnc: 0.580 +KVM: 0.491 +assembly: 0.370 + +qemu linux-user doesn't support OFD fcntl locks + +"Open file description locks (non-POSIX)", as they are described in fcntl(2) man page, aren't supported by qemu-user and attempting to use those results in EINVAL. I'm on Gentoo with latest QEMU version currently available (5.0.0-r2), and trying to emulate ppc64 and s390x on x86_64. + +Looking at linux-user/syscall.c, I'm guessing the issue is in (at least) `target_to_host_fcntl_cmd` where switch reaches the default clause as there're no cases for F_OFD_SETLK / F_OFD_SETLKW / F_OFD_GETLK. + +The attached patch fixes the issue for me. + +New patch version: fix target_to_host_fcntl_cmd mapping, avoid do_fcntl code duplication. + +Please check qemu-5.1.0. + +This has been fixed by: + + 2d92c6827ca0 ("linux-user: implement OFD locks") + https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d92c6827ca0 + +perhaps you can send a patch to the qemu-devel ML to add the strace part. + +Thanks, the changes in 5.1.0 seem to work indeed. + +> perhaps you can send a patch to the qemu-devel ML to add the strace part + +Done. + diff --git a/results/classifier/105/instruction/1894029 b/results/classifier/105/instruction/1894029 new file mode 100644 index 00000000..7d584c81 --- /dev/null +++ b/results/classifier/105/instruction/1894029 @@ -0,0 +1,57 @@ +instruction: 0.849 +device: 0.754 +mistranslation: 0.696 +other: 0.646 +graphic: 0.627 +assembly: 0.619 +semantic: 0.449 +vnc: 0.320 +socket: 0.223 +network: 0.223 +boot: 0.221 +KVM: 0.173 + +qemu-i386 malloc error + +Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong. +This is my test program: + +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, char **argv) +{ + void *pa=0,*pb=0,*pc=0,*pd=0; + pa = malloc(sizeof(uint32_t)); + pb = malloc(sizeof(uint32_t)); + pc = malloc(4); + pd = malloc(4); + printf("pa: 0x%x\n",pa); + printf("pb: 0x%x\n",pb); + printf("pc: 0x%x\n",pc); + printf("pd: 0x%x\n",pd); + printf("uint32_t:%d\n",sizeof(uint32_t)); + free(pa); + free(pb); + free(pc); + free(pd); + return 0; +} + +And it is wrong: + +pa: 0x400051a0 +pb: 0x400051b0 +pc: 0x400051c0 +pd: 0x400051d0 +uint32_t:4 + +Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes?? +Is it a BUG?? + +Please stop asking questions using a bug tracking system, this is rude. + +No it is not a bug, it appears you can't do simple arithmetics, -- the pointer is increased by 16 bytes not 2. + diff --git a/results/classifier/105/instruction/1895305 b/results/classifier/105/instruction/1895305 new file mode 100644 index 00000000..17ed4a73 --- /dev/null +++ b/results/classifier/105/instruction/1895305 @@ -0,0 +1,66 @@ +instruction: 0.911 +device: 0.792 +graphic: 0.782 +other: 0.685 +mistranslation: 0.677 +socket: 0.662 +semantic: 0.611 +boot: 0.559 +network: 0.539 +vnc: 0.493 +KVM: 0.326 +assembly: 0.249 + +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/105/instruction/1897194 b/results/classifier/105/instruction/1897194 new file mode 100644 index 00000000..d6db7b4a --- /dev/null +++ b/results/classifier/105/instruction/1897194 @@ -0,0 +1,60 @@ +instruction: 0.577 +graphic: 0.460 +device: 0.450 +semantic: 0.440 +other: 0.415 +network: 0.413 +socket: 0.297 +boot: 0.245 +vnc: 0.237 +mistranslation: 0.207 +KVM: 0.132 +assembly: 0.084 + +Test failure in test-crypto-secret.c + +When running qemu test suite I'm seeing a test failure: + +ERROR:../qemu/tests/test-crypto-secret.c:144:test_secret_keyring_good: assertion failed: (key >= 0) + +Host is Arch Linux running in the standard Arch build environment (essentially an nspawn container). + +I first noticed this at release of 5.1.0 but it's still there on current trunk. For 5.1.0 I was able to sidestep the issue by building with `--disable-keyring' but this no longer works (I think due to 9866a33cbb7046891dec3dcc9ca2015828673afe) + +Any clues on what might be the cause? Not sure how to debug. + +Ping. Nobody else seeing this? + +I can only assume you don't have keyutils-dev (or equivalent) installed on your system. + +This is a key difference (pardon the pun!) between Arch and the bigger distros. Arch tends to avoid splitting development libs and headers into separate packages, which might explain why others are not seeing the test failure. + +strace shows the problem: + +add_key("user", "qemu_test_secret", "Test Payload", 12, KEY_SPEC_PROCESS_KEYRING) = -1 EPERM (Operation not permitted) + +It appears systemd-nspawn containers don't have CAP_SYS_ADMIN which is apparently needed for the keyring stuff to work. Fair enough. + +But the underlying problem here is configure switch `--disable-keyring' does not work. It previously worked in the 5.1.0 release but now it's broken. + + + +> systemd-nspawn containers don't have CAP_SYS_ADMIN + +Above statement is utter bollocks. Please ignore.. + + +I finally got to the bottom of all this and now have the test suite passing. + +- don't use `--disable-keyring', it's busted + +- systemd-nspawn containers need to be configured with additional capabilities/syscalls (see below) + +I noticed another test failing (postcopy-ram in tests/qtest/migration-test.c). It needs access to munlockall which is covered by CAP_IPC_LOCK capability. + +Here is my .nspawn config needed to get the test suite passing inside a systemd-nspawn container: + +[Exec] +Capability=CAP_IPC_LOCK +SystemCallFilter=add_key keyctl + diff --git a/results/classifier/105/instruction/1898954 b/results/classifier/105/instruction/1898954 new file mode 100644 index 00000000..77df51de --- /dev/null +++ b/results/classifier/105/instruction/1898954 @@ -0,0 +1,73 @@ +instruction: 0.923 +mistranslation: 0.880 +boot: 0.854 +graphic: 0.850 +other: 0.845 +KVM: 0.778 +device: 0.762 +semantic: 0.752 +socket: 0.648 +network: 0.624 +assembly: 0.575 +vnc: 0.567 + +x86 f1 opcode hangs qemu + +I have qemu installed and running in linux and windows +in linux i execute the following simple code in real mode of cpu in my vm +90 nop +90 nop +90 nop +f1 ;this should conjure up my interrupt handler from ivt int 1 +--------- end of code ---- +it works properly in vbox,qemu linux,and even in my boot loder +on a real platform + it doeas not work fine in windows 10 (32 bit efi) based qemu +--- +all of the below was retyped there may be typo +so onwards to the flawed software +********** for qemu-system-x86_64.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +********** for qemu-system-i386.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +*********************************************** +my startup code is +"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc +--- +also same flaw if i change above section to +"d:\programs\qemu\qemu-system-i386.exe" + +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/105/instruction/1899728 b/results/classifier/105/instruction/1899728 new file mode 100644 index 00000000..58065d41 --- /dev/null +++ b/results/classifier/105/instruction/1899728 @@ -0,0 +1,53 @@ +instruction: 0.854 +device: 0.762 +semantic: 0.740 +graphic: 0.706 +mistranslation: 0.703 +other: 0.633 +network: 0.600 +vnc: 0.573 +socket: 0.465 +boot: 0.433 +KVM: 0.393 +assembly: 0.255 + +Qemu-5.1.0 build from source man entry not found + +Hello together, + +i build qemu-5.1.0 from source on centos 8 withe the following command: + +../configure --prefix=/usr --target-list=x86_64-softmmu,x86_64-linux-user + +make -j4 + +make install + +The build and the installation finished successfully. But when i try the command + +man qemu-system-x86_64 + +i got the message "No manual entry found". What i do wrong ? + +Best regards +Damian + +You probably don't have the necessary dependencies to build the manual pages. Since 5.0 we have required Sphinx to be installed to build the docs (see https://wiki.qemu.org/ChangeLog/5.0#Build_Dependencies). + +Pass --enable-docs to configure if you want to force the docs to be built (and then configure will stop with an error if Sphinx or another required tool is missing); otherwise configure will default to "build docs if possible, skip if required tools are missing". + + +There is only one shared man-page for all qemu-system-xxx binaries ... have you tried to simply run "man qemu" ? + +Hello together, + +build with enable-docs and install the required packages now it works with man qemu. + +Many thanks for you help + +Problem resolved :-) + +Best regards +Damian + + diff --git a/results/classifier/105/instruction/1901 b/results/classifier/105/instruction/1901 new file mode 100644 index 00000000..33ec5566 --- /dev/null +++ b/results/classifier/105/instruction/1901 @@ -0,0 +1,32 @@ +instruction: 0.968 +graphic: 0.871 +device: 0.723 +semantic: 0.696 +other: 0.517 +network: 0.432 +socket: 0.404 +vnc: 0.392 +mistranslation: 0.243 +boot: 0.231 +assembly: 0.079 +KVM: 0.079 + +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. +Steps to reproduce: +1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. +Additional information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/105/instruction/1901981 b/results/classifier/105/instruction/1901981 new file mode 100644 index 00000000..04c375f9 --- /dev/null +++ b/results/classifier/105/instruction/1901981 @@ -0,0 +1,89 @@ +instruction: 0.897 +network: 0.893 +device: 0.890 +semantic: 0.880 +graphic: 0.870 +socket: 0.868 +assembly: 0.848 +other: 0.820 +vnc: 0.820 +boot: 0.796 +KVM: 0.788 +mistranslation: 0.733 + +assert issue locates in hw/usb/dev-storage.c:248: usb_msd_send_status + +Hello, + +I found an assertion failure through hw/usb/dev-storage.c. + +This was found in latest version 5.1.0. + +-------- + +qemu-system-x86_64: hw/usb/dev-storage.c:248: usb_msd_send_status: Assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed. +[1] 29544 abort sudo -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic + +To reproduce the assertion failure, please run the QEMU with following command line. + + +$ qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img -nic user,model=rtl8139,hostfwd=tcp:0.0.0.0:5555-:22 -device piix4-usb-uhci,id=uhci -device usb-storage,drive=mydrive -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none + +The poc is attached. + + + +poc doens't run on fedora: +uhci: common.c:59: gva_to_gpa: Assertion `gfn != -1' failed. + +Can you build qemu with DEBUG_MSD enabled (see hw/usb/dev-storage.c), +then attach both stderr log and stacktrace? + +thanks. + +Sorry, my reproduced environment is as follows: + Host: ubuntu 18.04 + Guest: ubuntu 18.04 + +Stderr log is as follows: +usb-msd: Reset +usb-msd: Command on LUN 0 +usb-msd: Command tag 0x0 flags 00000000 len 0 data 0 +[scsi.0 id=0] INQUIRY 0x00 0x00 0x00 0x01 0x00 - from-dev len=1 +usb-msd: Deferring packet 0x6110002d2d40 [wait status] +usb-msd: Command status 0 tag 0x0, len 256 +qemu-system-x86_64: hw/usb/dev-storage.c:248: usb_msd_send_status: Assertion `s->csw.sig == cpu_to_le32(0x53425355)' failed. +[1] 643 abort sudo -enable-kvm -boot c -m 4G -drive format=qcow2,file=./ubuntu.img -nic + + +Backtrace is as follows: +#0 0x00007f8b36a63f47 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007f8b36a658b1 in __GI_abort () at abort.c:79 +#2 0x00007f8b36a5542a in __assert_fail_base (fmt=0x7f8b36bdca38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55aef41e7440 "s->csw.sig == cpu_to_le32(0x53425355)", file=file@entry=0x55aef41e7180 "hw/usb/dev-storage.c", line=line@entry=248, function=function@entry=0x55aef41e7980 <__PRETTY_FUNCTION__.29124> "usb_msd_send_status") at assert.c:92 +#3 0x00007f8b36a554a2 in __GI___assert_fail (assertion=assertion@entry=0x55aef41e7440 "s->csw.sig == cpu_to_le32(0x53425355)", file=file@entry=0x55aef41e7180 "hw/usb/dev-storage.c", line=line@entry=248, function=function@entry=0x55aef41e7980 <__PRETTY_FUNCTION__.29124> "usb_msd_send_status") at assert.c:101 +#4 0x000055aef32226d5 in usb_msd_send_status (s=0x623000001d00, p=0x6110002e3500) at hw/usb/dev-storage.c:248 +#5 0x000055aef322804e in usb_msd_handle_data (dev=0x623000001d00, p=0x6110002e3500) at hw/usb/dev-storage.c:525 +#6 0x000055aef30bc46a in usb_device_handle_data (dev=dev@entry=0x623000001d00, p=p@entry=0x6110002e3500) at hw/usb/bus.c:179 +#7 0x000055aef30a0ab4 in usb_process_one (p=p@entry=0x6110002e3500) at hw/usb/core.c:387 +#8 0x000055aef30a9db0 in usb_handle_packet (dev=0x623000001d00, p=p@entry=0x6110002e3500) at hw/usb/core.c:419 +#9 0x000055aef30fe890 in uhci_handle_td (s=s@entry=0x61f000002a80, q=0x6060000c9200, q@entry=0x0, qh_addr=qh_addr@entry=0, td=td@entry=0x7ffd88f90620, td_addr=<optimized out>, int_mask=int_mask@entry=0x7ffd88f905a0) at hw/usb/hcd-uhci.c:899 +#10 0x000055aef3104c6f in uhci_process_frame (s=s@entry=0x61f000002a80) at hw/usb/hcd-uhci.c:1075 +#11 0x000055aef31098e0 in uhci_frame_timer (opaque=0x61f000002a80) at hw/usb/hcd-uhci.c:1174 +#12 0x000055aef3ae5f95 in timerlist_run_timers (timer_list=0x60b000051be0) at util/qemu-timer.c:572 +#13 0x000055aef3ae619b in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at util/qemu-timer.c:586 +#14 0x000055aef3ae6922 in qemu_clock_run_all_timers () at util/qemu-timer.c:672 +#15 0x000055aef3aca63d in main_loop_wait (nonblocking=0) at util/main-loop.c:523 +#16 0x000055aef1f320f5 in qemu_main_loop () at /home/zjusvn/new-hyper/qemu-5.1.0/softmmu/vl.c:1676 +#17 0x000055aef397475c in main (argc=18, argv=0x7ffd88f90e98, envp=0x7ffd88f90f30) at /home/zjusvn/new-hyper/qemu-5.1.0/softmmu/main.c:49 +#18 0x00007f8b36a46b97 in __libc_start_main (main=0x55aef397471d <main>, argc=18, argv=0x7ffd88f90e98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd88f90e88) at ../csu/libc-start.c:310 +#19 0x000055aef1a3481a in _start () + +thanks. + +https://git.kraxel.org/cgit/qemu/log/?h=sirius/usb-asserts +can you try that branch? + +OK, It seems to be fixed now. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/105/instruction/1902267 b/results/classifier/105/instruction/1902267 new file mode 100644 index 00000000..ee852c13 --- /dev/null +++ b/results/classifier/105/instruction/1902267 @@ -0,0 +1,81 @@ +instruction: 0.956 +graphic: 0.900 +mistranslation: 0.896 +other: 0.811 +device: 0.770 +semantic: 0.755 +network: 0.724 +assembly: 0.701 +socket: 0.626 +vnc: 0.616 +KVM: 0.595 +boot: 0.480 + +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/105/instruction/1903712 b/results/classifier/105/instruction/1903712 new file mode 100644 index 00000000..014f9ca9 --- /dev/null +++ b/results/classifier/105/instruction/1903712 @@ -0,0 +1,47 @@ +instruction: 0.756 +mistranslation: 0.739 +semantic: 0.708 +device: 0.574 +graphic: 0.549 +boot: 0.527 +socket: 0.333 +other: 0.317 +network: 0.279 +vnc: 0.222 +assembly: 0.198 +KVM: 0.072 + +when ../configure, cannot find Ninjia + +On unbuntu18.04, after finishing + +wget https://download.qemu.org/qemu-5.2.0-rc0.tar.xz +tar xvJf qemu-5.2.0-rc0.tar.xz +cd qemu-5.2.0-rc0 + +when I input + +wget https://download.qemu.org/qemu-5.2.0-rc0.tar.xz +tar xvJf qemu-5.2.0-rc0.tar.xz +cd qemu-5.2.0-rc0 + +Return Error: +cannot find Ninjia + +Can you confirm whether you have installed the "ninja-build" package ? It is a new build requirement for QEMU in 5.2.0 + +[Expired for QEMU because there has been no activity for 60 days.] + +1、install re2c。[url：http://re2c.org/index.html] +tar -xvzf re2c-1.0.3.tar.gz + cd re2c-1.0.3/ + autoreconf -i -W all + ./configure + make&&make install +2、git clone git://github.com/ninja-build/ninja.git && cd ninja + ./configure.py --bootstrap + cp ninja /usr/bin/ + +[root@aix7 ~]# ninja --version +1.10.2.git + diff --git a/results/classifier/105/instruction/1903833 b/results/classifier/105/instruction/1903833 new file mode 100644 index 00000000..ecfd9dbb --- /dev/null +++ b/results/classifier/105/instruction/1903833 @@ -0,0 +1,39 @@ +instruction: 0.749 +graphic: 0.619 +device: 0.618 +semantic: 0.533 +boot: 0.358 +network: 0.350 +assembly: 0.337 +socket: 0.330 +other: 0.314 +mistranslation: 0.286 +vnc: 0.230 +KVM: 0.119 + +User mode qemu-aarch: SIGGSEGV signal handler works wrong + +I have a user mode qemu-aarch issue. Program with SIGSEGV signal handler works wrong under qemu-aarch: +once the progam handles the SEGV signal, qemu marks the program's page protected, and signal handler gets SEGV on each subsequent memory access instruction within a program. + +The issue is reproduced on WSL Ubuntu 20.04 under Windows 10, qemu-aarch64 version 5.1.50 +The issue is also reproducible on the latest upstream qemu-aarch build. + +The following workaround disables mprotect call and fixes the issue: https://github.com/BorisUlasevich/qemu/commit/3063d9a64f8395185d65c6b6710d28ee92cd8be5 + +The issue can be reproduced on OpenJDK which reports SIGSEGV immediately after start. The small reproducer program is attached. + + + +The patch is most definitely wrong. The page protection +is required to implement self-modifying code, of which a +signal trampoline is a subset. + +Moreover, your test case works for me using both +x86_64-linux and aarch64-linux as hosts. + +There may be a bug, but I suspect it to be within WSL. +I have no way to test that one way or another. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/1905356 b/results/classifier/105/instruction/1905356 new file mode 100644 index 00000000..9caefedf --- /dev/null +++ b/results/classifier/105/instruction/1905356 @@ -0,0 +1,53 @@ +instruction: 0.757 +device: 0.574 +other: 0.545 +socket: 0.479 +semantic: 0.462 +network: 0.446 +vnc: 0.436 +mistranslation: 0.384 +graphic: 0.376 +boot: 0.342 +assembly: 0.333 +KVM: 0.248 + +No check for unaligned data access in ARM32 instructions + +hi + +According to the ARM documentation, there are alignment requirements of load/store instructions. Alignment fault should be raised if the alignment check is failed. However, it seems that QEMU doesn't implement this, which is against the documentation of ARM. For example, the instruction LDRD/STRD/LDREX/STREX must check the address is word alignment no matter what value the SCTLR.A is. + +I attached a testcase, which contains a instruction at VA 0x10240: ldrd r0,[pc.#1] in the main function. QEMU can successfully load the data in the unaligned address. The test is done in QEMU 5.1.0. I can provide more testcases for the other instructions if you need. Many thanks. + +To patch this, we need a check while we translate the instruction to tcg. If the address is unaligned, a signal number (i.e., SIGBUS) should be raised. + +Regards +Muhui + + + +We don't implement SCTLR.A, but you're right that we should be +checking the mandatory alignments. + +Note! Any fix will only apply to system mode (qemu-system-arm) +and not user-only mode (qemu-arm). + +Thanks for confirmation. + +Btw: I was wondering why the fix will only apply to system mode rather than user-only mode. Unaligned data access is not permitted in user level programs, either. + +Because for user-only, we cheat and use host load/store +operations directly. This makes for much faster emulation +but imposes a number of limitations -- including ignoring +of the alignment bits on hosts that have native unaligned +accesses. + +As a corollary, when running user-only on a host that +enforces alignment, you cannot emulate a guest that +*allows* unaligned accesses. + +Proposed patches: +https://<email address hidden>/ + +Richard's patches have been merged (see https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d753eb5fb03ee7bc71ec and the following ones), so I'm setting the state to "Fix committed" now. + diff --git a/results/classifier/105/instruction/1906295 b/results/classifier/105/instruction/1906295 new file mode 100644 index 00000000..984cc8bb --- /dev/null +++ b/results/classifier/105/instruction/1906295 @@ -0,0 +1,37 @@ +instruction: 0.942 +other: 0.882 +device: 0.861 +semantic: 0.675 +mistranslation: 0.648 +graphic: 0.646 +network: 0.587 +assembly: 0.581 +vnc: 0.538 +socket: 0.516 +KVM: 0.440 +boot: 0.402 + +Implementation of exclusive monitor in ARM + +Hi + +I refer to the implementation of exclusive monitor in ARM32. For instruction like STREX Rx,Ry,[Rz], we need to check whether the address [Rz] is in exclusive state. If not, we set the value Rx as 1 without doing the store operation. However, I noticed that QEMU will not check whether the address that Rz points to is a legal address or not. If the value of Rz is 0x0 but it is not in exclusive state. QEMU will set Rx as 1 and continue to execute the following instructions. + +However, physical devices will check the value of Rz. If Rz is an illegal address (e.g., 0x0), a SIGSEGV signal will be raised even the address is not in exclusive state. I searched many documentation about ARM and it seems that manual of ARM specification does not specify the implementation of exclusive monitor in detail. I am not sure which one is the right behavior. +Should QEMU add this check? This might not be a mistake. However, should it be better if QEMU has the same behavior as a physical device? Feel free if you need a testcase. Many thanks + +Regards +Muhui + +QEMU's load/store exclusive implementation is known to not be architecturally compliant. Most notably, it works on virtual addresses and the architecture specifies that exclusives are supposed to work on physical addresses. We provide a "good enough for what real code (not weird test cases) needs" implementation. + +However, in this specific case, we're within the architectural requirements. In the ARMv8A Arm ARM (DDI0487F.c) the pseudocode AArch32.ExclusiveMonitorsPass() function has this comment: + +// It is IMPLEMENTATION DEFINED whether the detection of memory aborts happens +// before or after the check on the local Exclusives monitor. As a result a failure +// of the local monitor can occur on some implementations even if the memory +// access would give a memory about. + +In other words, it's up to the implementation whether it detects and reports the invalid address first. QEMU's implementation chooses not to. + + diff --git a/results/classifier/105/instruction/1909392 b/results/classifier/105/instruction/1909392 new file mode 100644 index 00000000..95eca4c5 --- /dev/null +++ b/results/classifier/105/instruction/1909392 @@ -0,0 +1,48 @@ +instruction: 0.755 +assembly: 0.684 +mistranslation: 0.591 +device: 0.582 +other: 0.565 +semantic: 0.553 +vnc: 0.551 +socket: 0.479 +boot: 0.475 +graphic: 0.422 +KVM: 0.418 +network: 0.390 + +qemu-arm crashes (SIGSEGV) when executing push instruction + +Dear all, +I am afraid I found a problem, it seems like qemu-arm crashes when executing assembly push instruction. +I use qemu version 5.2.0, but it checked an older version (4.2.1) and the problem was also present. I start qemu using "qemu-arm -cpu cortex-m4 -singlestep -g 1234 <path to elf file>" +Callstack before crash (host) +#0 0x000055555575961f in stl_he_p (ptr=0x2002fffc, v=0) at /home/faust1002/Programming/qemu/qemu-5.2.0/include/qemu/bswap.h:353 +#1 0x0000555555759716 in stl_le_p (ptr=0x2002fffc, v=0) at /home/faust1002/Programming/qemu/qemu-5.2.0/include/qemu/bswap.h:395 +#2 0x000055555575d3c3 in tcg_qemu_tb_exec (env=0x555555d28050, tb_ptr=0x7fffe800010a "\r\b") at ../tcg/tci.c:1221 +#3 0x00005555556bd982 in cpu_tb_exec (cpu=0x555555d1fd70, itb=0x7fffe8000000) at ../accel/tcg/cpu-exec.c:178 +#4 0x00005555556be57e in cpu_loop_exec_tb (cpu=0x555555d1fd70, tb=0x7fffe8000000, last_tb=0x7fffffffd8a8, tb_exit=0x7fffffffd8a0) at ../accel/tcg/cpu-exec.c:658 +#5 0x00005555556be7ea in cpu_exec (cpu=0x555555d1fd70) at ../accel/tcg/cpu-exec.c:771 +#6 0x000055555560af1d in cpu_loop (env=0x555555d28050) at ../linux-user/arm/cpu_loop.c:237 +#7 0x00005555557415a7 in main (argc=7, argv=0x7fffffffe0f8, envp=0x7fffffffe138) at ../linux-user/main.c:861 +Callstack before crash (target) +Program received signal SIGSEGV, Segmentation fault. +Reset_Handler () at startup.s:48 +48 push {r14} +Please find the elf file I use attached. +Kind regards + + + +The program is buggy. + +The first instruction sets the stack to 0x20020000, +but that address is not mapped. + +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x010000 0x08000000 0x08000000 0x0025c 0x0025c R E 0x10000 + LOAD 0x020000 0x20000000 0x0800025c 0x00000 0x00600 RW 0x10000 + +The data segment only goes from 0x20000000 - 0x20000600. + diff --git a/results/classifier/105/instruction/1909823 b/results/classifier/105/instruction/1909823 new file mode 100644 index 00000000..d78af726 --- /dev/null +++ b/results/classifier/105/instruction/1909823 @@ -0,0 +1,53 @@ +instruction: 0.921 +semantic: 0.690 +device: 0.671 +graphic: 0.666 +other: 0.649 +network: 0.621 +socket: 0.595 +assembly: 0.526 +mistranslation: 0.511 +vnc: 0.503 +boot: 0.471 +KVM: 0.408 + +RDPMC check on PCE is backwards + +At [this line](https://github.com/qemu/qemu/blob/75ee62ac606bfc9eb59310b9446df3434bf6e8c2/target/i386/tcg/misc_helper.c#L225) the check on CR4_PCE_MASK is backwards: it's raising an exception if the flag is set (and CPL != 0) rather than if the flag is clear. + +It's low priority at the moment because the instruction isn't implemented, so you get an illegal opcode exception when expecting a GPF, or vice versa, but it's a time bomb for if it is ever implemented. + +The Intel docs also indicate that CR0.PE influences the protection; I don't know if that's already reflected in env->hflags & HF_CPL_MASK. + +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. + + +It looks like this was fixed in c45b426. + diff --git a/results/classifier/105/instruction/1910605 b/results/classifier/105/instruction/1910605 new file mode 100644 index 00000000..49e40873 --- /dev/null +++ b/results/classifier/105/instruction/1910605 @@ -0,0 +1,62 @@ +instruction: 0.917 +other: 0.899 +device: 0.886 +graphic: 0.885 +network: 0.846 +mistranslation: 0.830 +semantic: 0.782 +assembly: 0.736 +socket: 0.735 +vnc: 0.708 +boot: 0.683 +KVM: 0.574 + +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/105/instruction/1912107 b/results/classifier/105/instruction/1912107 new file mode 100644 index 00000000..94621f13 --- /dev/null +++ b/results/classifier/105/instruction/1912107 @@ -0,0 +1,60 @@ +instruction: 0.800 +graphic: 0.612 +semantic: 0.606 +other: 0.532 +device: 0.506 +mistranslation: 0.472 +network: 0.430 +socket: 0.406 +vnc: 0.349 +boot: 0.335 +assembly: 0.233 +KVM: 0.222 + +Option to constrain linux-user exec() to emulated CPU only + +When trying to reproduce a bug someone reported on an actual AMD K10[1], I tried to directly throw `qemu_x86-64 -cpu +phenom path/to/wrongly-labelled-instruction-set/gcc 1.c` at the problem, but failed to get an "illegal instruction" as expected. A quick investigation reveals that the error is actually caused by one of gcc's child processess, and that the said process is being ran directly on the host. A similar problem happens with trying to call stuff with /usr/bin/env. + + [1]: https://github.com/Homebrew/brew/issues/1034 + +Since both the host and the guest are x86_64, I deemed binfmt inapplicable to my case. I believe that QEMU should offer a way to modify exec() and other spawning syscalls so that execution remains on an emulated CPU in such a case. Call it an extra layer of binfmt, if you must. + +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/306 + + diff --git a/results/classifier/105/instruction/1912934 b/results/classifier/105/instruction/1912934 new file mode 100644 index 00000000..f487e30d --- /dev/null +++ b/results/classifier/105/instruction/1912934 @@ -0,0 +1,78 @@ +instruction: 0.655 +device: 0.618 +semantic: 0.589 +mistranslation: 0.555 +graphic: 0.466 +socket: 0.360 +vnc: 0.325 +assembly: 0.276 +network: 0.262 +boot: 0.230 +other: 0.223 +KVM: 0.145 + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). + + + +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. + + +The situation is still the same in QEMU 6.0.0. + +$ powerpc64le-linux-gnu-gcc-5 test-fmadds.c -static +$ ~/inst-qemu/6.0.0/bin/qemu-ppc64le ./a.out ; echo $? +32 + + + +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/312 + + diff --git a/results/classifier/105/instruction/1913667 b/results/classifier/105/instruction/1913667 new file mode 100644 index 00000000..1d786c7f --- /dev/null +++ b/results/classifier/105/instruction/1913667 @@ -0,0 +1,58 @@ +instruction: 0.629 +mistranslation: 0.612 +device: 0.608 +other: 0.589 +graphic: 0.579 +vnc: 0.539 +network: 0.476 +assembly: 0.474 +semantic: 0.458 +socket: 0.435 +boot: 0.432 +KVM: 0.402 + +FPE in npcm7xx_clk_update_pll + +I've been working on integrating the generic-fuzzer with ARM machines on OSS-Fuzz so we can fuzz devices on architectures beyond i386 devices. Since I saw that there is some active development for the Nuvoton machines, I thought it might be useful to fuzz the NPCM750 machine + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -M npcm750-evb \ +-accel qtest -qtest stdio +write 0xf080100c 0x4 0x00 +write 0xf080100c 0x4 0x00 +EOF + +Trace: +../hw/misc/npcm7xx_clk.c:131:14: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/misc/npcm7xx_clk.c:131:14 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==717855==ERROR: AddressSanitizer: FPE on unknown address 0x5619201fcd8c (pc 0x5619201fcd8c bp 0x7ffc94214e50 sp 0x7ffc94214e30 T0) +#0 0x5619201fcd8c in npcm7xx_clk_update_pll /hw/misc/npcm7xx_clk.c:131:14 +#1 0x5619201ff5dc in npcm7xx_clk_write /hw/misc/npcm7xx_clk.c:799:13 +#2 0x5619214781fe in memory_region_write_accessor /softmmu/memory.c:491:5 +#3 0x561921477bfb in access_with_adjusted_size /softmmu/memory.c:552:18 +#4 0x561921477467 in memory_region_dispatch_write /softmmu/memory.c +#5 0x561921807ffb in flatview_write_continue /softmmu/physmem.c:2759:23 +#6 0x5619217fd71b in flatview_write /softmmu/physmem.c:2799:14 +#7 0x5619217fd71b in address_space_write /softmmu/physmem.c:2891:18 +#8 0x561921465eee in qtest_process_command /softmmu/qtest.c:539:13 +#9 0x561921462b97 in qtest_process_inbuf /softmmu/qtest.c:797:9 +#10 0x561921cb3286 in fd_chr_read /chardev/char-fd.c:68:9 +#11 0x7f4ad283baae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +#12 0x56192230e363 in glib_pollfds_poll /util/main-loop.c:232:9 +#13 0x56192230e363 in os_host_main_loop_wait /util/main-loop.c:255:5 +#14 0x56192230e363 in main_loop_wait /util/main-loop.c:531:11 +#15 0x5619213c9599 in qemu_main_loop /softmmu/runstate.c:721:9 +#16 0x56191f6561fd in main /softmmu/main.c:50:5 +#17 0x7f4ad22e0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +#18 0x56191f5a9bc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +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/549 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/105/instruction/1913913 b/results/classifier/105/instruction/1913913 new file mode 100644 index 00000000..1ca71cfd --- /dev/null +++ b/results/classifier/105/instruction/1913913 @@ -0,0 +1,84 @@ +instruction: 0.870 +other: 0.862 +device: 0.756 +graphic: 0.695 +socket: 0.665 +network: 0.653 +semantic: 0.633 +mistranslation: 0.573 +vnc: 0.515 +boot: 0.487 +assembly: 0.476 +KVM: 0.330 + +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. + +I have identified the core issue: + +Synchronous exceptions/traps in linux-user/i386/cpu_loop.c are handled as a return value from cpu_exec(). +cpu_exec() resets exception_index to -1 in cpu_handle_exception() + +This means that queue_signal() (called from gen_signal() in the cpu loop) does not store the actual CPU trap value anywhere. + +If we abuse env->exception_nr to store the trapnr, and retrieve it from there in setup_sigcontext() in linux-user/i386/signal.c instead of using exception_index (which will be set to -1 for all synchronous excptions). + +The main issue is if this breaks asynchronous signals, and under what conditions exception_nr should be set to -1. + + + + + + + + + + +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/105/instruction/1913926 b/results/classifier/105/instruction/1913926 new file mode 100644 index 00000000..6be53595 --- /dev/null +++ b/results/classifier/105/instruction/1913926 @@ -0,0 +1,77 @@ +instruction: 0.932 +other: 0.906 +device: 0.901 +graphic: 0.866 +mistranslation: 0.790 +semantic: 0.658 +network: 0.533 +boot: 0.479 +vnc: 0.452 +assembly: 0.420 +socket: 0.354 +KVM: 0.351 + +[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/105/instruction/1915027 b/results/classifier/105/instruction/1915027 new file mode 100644 index 00000000..4df7ceb4 --- /dev/null +++ b/results/classifier/105/instruction/1915027 @@ -0,0 +1,27 @@ +instruction: 0.816 +assembly: 0.781 +graphic: 0.759 +other: 0.744 +device: 0.634 +semantic: 0.632 +mistranslation: 0.442 +vnc: 0.284 +network: 0.181 +boot: 0.140 +socket: 0.116 +KVM: 0.044 + +RISC-V 64, CPUs do ilegal 0x00 write with SMP + +When QEMU is runt like this: + +qemu-system-riscv64 -d unimp,guest_errors -smp 8 + +Other harts will do a illegal write on address 0x00. + +This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute. + +Even with -smp 1 you will see the same errors. The problem is because there is nothing to run after OpenSBI jumps to the next stage. + +If you load a kernel you will not see the error messages. + diff --git a/results/classifier/105/instruction/1916269 b/results/classifier/105/instruction/1916269 new file mode 100644 index 00000000..45a2ef61 --- /dev/null +++ b/results/classifier/105/instruction/1916269 @@ -0,0 +1,70 @@ +instruction: 0.884 +socket: 0.821 +graphic: 0.779 +device: 0.775 +other: 0.721 +network: 0.656 +semantic: 0.654 +vnc: 0.626 +mistranslation: 0.626 +boot: 0.615 +assembly: 0.473 +KVM: 0.297 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. + +Could someone familiar with the target/i386 decode logic could have a look at this? It should be a rather simple change to avoid the exception for the crc32 encoding. However, I am not familiar with x86 instruction encodings so it would take me a long time to come up with a correct patch. +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Reported on GitLab as https://gitlab.com/qemu-project/qemu/-/issues/427 + diff --git a/results/classifier/105/instruction/1917 b/results/classifier/105/instruction/1917 new file mode 100644 index 00000000..4f56c097 --- /dev/null +++ b/results/classifier/105/instruction/1917 @@ -0,0 +1,64 @@ +instruction: 0.918 +other: 0.887 +graphic: 0.864 +network: 0.820 +semantic: 0.781 +assembly: 0.778 +socket: 0.764 +boot: 0.732 +vnc: 0.724 +mistranslation: 0.722 +device: 0.722 +KVM: 0.680 + +cargo on ppc64 fails: invalid instruction: *EDIT*: on ntpdate as well +Description of problem: +Machine boots, +but when compiling a rust library, the following issue appears: +``` +cargo build --release --manifest-path rust-src/Cargo.toml +cargo[376]: illegal instruction (4) at 12e0933c0 nip 12e0933c0 lr 12dd7c768 code 1 in cargo[12dc10000+956000] +cargo[376]: code: 00000000 00000000 00000000 7c0802a6 f8010010 f821ff11 fba100d8 60000000 +cargo[376]: code: fbc100e0 8862cd50 28030000 418200d4 <104214c4> 38810070 3bc00000 7c4021ce +make: *** [Makefile:133: rust-src/target/release/libbcachefs_rust.a] Illegal instruction (core dumped) +make: *** Waiting for unfinished jobs.... +ar[375]: illegal instruction (4) at 3fff9b2a4dac nip 3fff9b2a4dac lr 3fff9b2a4da4 code 1 in libLLVM-16.so.1[3fff99f10000+792f000] +ar[375]: code: f87d0028 7fa3eb78 b29d0090 f89d0020 4810a8c1 60000000 7f83e378 7fa4eb78 +ar[375]: code: 7fc5f378 49bfd3e1 e8410028 60000000 <104214c4> 38810070 fb610080 eba29fe0 +make: *** [Makefile:129: libbcachefs.a] Illegal instruction (core dumped) +make: *** Deleting file 'libbcachefs.a' +``` +the core dump files of cargo and ar are attached + +~~I have no clue whether this is a rustc or qemu bug, so please let me know if this issue should be forwarded to rust devs~~ +EDIT: as this happens with ntpdate as well, I think it's an emulator issue: + +``` +ntpdig[1179]: illegal instruction (4) at 102382c4 nip 102382c4 lr 102382a8 code 1 in python3.11[10000000+63e000] +ntpdig[1179]: code: 3d22ffdd c8094448 fc1e0000 41c2022c 4bde9b5d e8410028 3d42ffdd 39200000 +ntpdig[1179]: code: c80a4450 91230000 fc1e0000 41c001a4 <ffe0f02c> fc1ff800 41c30280 3d22ffdd +``` +Steps to reproduce: +1. create a debian ppc64 root image using debian sid & debootstrap +2. install rust using rustup +3. compile bcachefs-tools in ppc64 + +2b. Install ntpdate using apt-get ntpdate +3b. run ntpdate +Additional information: +Core dump command: +``` +cat /proc/sys/kernel/core_pattern +|/bin/cp --sparse=always /dev/stdin /host//repos/janpieter/linux/bcachefs/ktest-out/core.%e.PID%p.SIG%s.TIME%t +``` + + +[core.ar.PID374.SIG4.TIME1696070088.xz](/uploads/6a540c4d13351871b1e22153ad87ab99/core.ar.PID374.SIG4.TIME1696070088.xz) AR core dump + +[core.ar.PID375.SIG4.TIME1696070088.xz](/uploads/7c314eba58c2190e3a9fbd88f8eb1242/core.ar.PID375.SIG4.TIME1696070088.xz) AR core dump + +[core.cargo.PID375.SIG4.TIME1696070087.xz](/uploads/0097d457eb2d25e0123874b59405647a/core.cargo.PID375.SIG4.TIME1696070087.xz) cargo core dump + +[core.cargo.PID376.SIG4.TIME1696070087.xz](/uploads/53834fa9608036d6de9dafc3f778f165/core.cargo.PID376.SIG4.TIME1696070087.xz) cargo core dump + +[core.ntpdig.PID1171.SIG4.TIME1696070657.xz](/uploads/8a96d86338d7c6bebe39657a24f570d8/core.ntpdig.PID1171.SIG4.TIME1696070657.xz) ntpdig core dump diff --git a/results/classifier/105/instruction/1917661 b/results/classifier/105/instruction/1917661 new file mode 100644 index 00000000..b4ffb0ed --- /dev/null +++ b/results/classifier/105/instruction/1917661 @@ -0,0 +1,67 @@ +instruction: 0.918 +other: 0.819 +graphic: 0.802 +mistranslation: 0.756 +device: 0.740 +semantic: 0.735 +vnc: 0.690 +network: 0.593 +socket: 0.589 +assembly: 0.514 +KVM: 0.492 +boot: 0.443 + +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/105/instruction/1921138 b/results/classifier/105/instruction/1921138 new file mode 100644 index 00000000..8f2114e2 --- /dev/null +++ b/results/classifier/105/instruction/1921138 @@ -0,0 +1,31 @@ +instruction: 0.815 +device: 0.778 +graphic: 0.747 +mistranslation: 0.678 +boot: 0.637 +semantic: 0.624 +socket: 0.530 +network: 0.513 +other: 0.485 +vnc: 0.410 +assembly: 0.068 +KVM: 0.016 + +tcg.c:3329: tcg fatal error + +I am currently building my own kernel with bootloader and qemu crashed after I have set an IDT in protected mode and then create a invalid opcode exception with the opcode 0xff. + +My code is here: https://github.com/Luis-Hebendanz/svm_kernel/blob/qemu_crash/svm_kernel/external/bootloader/src/main.rs#L80 + +Build instructions are here: https://github.com/Luis-Hebendanz/svm_kernel/tree/qemu_crash + +A precompiled binary is here: https://cloud.gchq.icu/s/LcjoDWRW2CbxJ5i + +I executed the following command: qemu-system-x86_64 -smp cores=4 -cdrom target/x86_64-os/debug/bootimage-svm_kernel.iso -serial stdio -display none -m 4G + +I am running QEMU emulator version 5.1.0 + +https://<email address hidden>/ + +https://gitlab.com/qemu-project/qemu/-/commit/10b8eb94c0902b58 + diff --git a/results/classifier/105/instruction/1922617 b/results/classifier/105/instruction/1922617 new file mode 100644 index 00000000..54605410 --- /dev/null +++ b/results/classifier/105/instruction/1922617 @@ -0,0 +1,255 @@ +instruction: 0.896 +other: 0.891 +graphic: 0.868 +device: 0.862 +boot: 0.829 +assembly: 0.828 +socket: 0.810 +semantic: 0.809 +vnc: 0.780 +network: 0.767 +mistranslation: 0.708 +KVM: 0.625 + +qemu-aarch64-static "Illegal instruction" with debootstrap + +This is reproducible against QEMU master. I apologize for the long reproduction steps, I tried to distill it down as much as possible. + +System info: + +# qemu-aarch64-static --version +qemu-aarch64 version 5.2.91 (v6.0.0-rc1-68-gee82c086ba) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +# cat /etc/os-release +PRETTY_NAME="Debian GNU/Linux 10 (buster)" +NAME="Debian GNU/Linux" +VERSION_ID="10" +VERSION="10 (buster)" +VERSION_CODENAME=buster +ID=debian +HOME_URL="https://www.debian.org/" +SUPPORT_URL="https://www.debian.org/support" +BUG_REPORT_URL="https://bugs.debian.org/" + +# head -n 26 /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 85 +model name : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz +stepping : 7 +microcode : 0x5002f01 +cpu MHz : 1000.716 +cache size : 22528 KB +physical id : 0 +siblings : 32 +core id : 0 +cpu cores : 16 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +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 pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities +bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs taa itlb_multihit +bogomips : 4600.00 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + +My reproduction steps: + +# apt-get install --no-install-recommends -y \ + build-essential \ + ca-certificates \ + debootstrap \ + git \ + libglib2.0-dev \ + libpixman-1-dev \ + ninja-build \ + pkg-config \ + python3 \ + zstd + +# git clone https://github.com/qemu/qemu + +# mkdir qemu/build + +# cd qemu/build + +# ../configure \ + --enable-debug \ + --enable-linux-user \ + --disable-bsd-user \ + --disable-werror \ + --disable-system \ + --disable-tools \ + --disable-docs \ + --disable-gtk \ + --disable-gnutls \ + --disable-nettle \ + --disable-gcrypt \ + --disable-glusterfs \ + --disable-libnfs \ + --disable-libiscsi \ + --disable-vnc \ + --disable-kvm \ + --disable-libssh \ + --disable-libxml2 \ + --disable-vde \ + --disable-sdl \ + --disable-opengl \ + --disable-xen \ + --disable-fdt \ + --disable-vhost-net \ + --disable-vhost-crypto \ + --disable-vhost-user \ + --disable-vhost-vsock \ + --disable-vhost-scsi \ + --disable-tpm \ + --disable-qom-cast-debug \ + --disable-capstone \ + --disable-zstd \ + --disable-linux-io-uring \ + --static \ + --target-list-exclude=hexagon-linux-user + +# ninja qemu-aarch64 + +# install -Dm755 qemu-aarch64 /usr/local/bin/qemu-aarch64-static + +# cat <<'EOF' >/proc/sys/fs/binfmt_misc/register +:qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-aarch64-static:CF +EOF + +# debootstrap --arch arm64 --foreign buster debian-rootfs + +# chroot debian-rootfs /debootstrap/debootstrap --second-stage +Illegal instruction + +This prevents me from building an arm64 Debian image on x86_64. If I am doing something wrong, please let me know. The binary has been uploaded for your convenience. + + + +This won't be the cause of the crash, but: don't run ninja directly. The build instructions (documented in README.rst) haven't changed: run configure, and then run make. The makefile still does some things and is not a pure does-absolutely-nothing wrapper around ninja in all cases. + + + +I'm able to reproduce a coredump o("Illegal Instruction", but of host type) during a debootstrap process. The coredump is for a grep process, I'm trying to bisect. + +Bisected to + +commit 26bab757d41b853ea84cb52a10fafc9c10069658 +Author: Richard Henderson <email address hidden> +Date: Fri Feb 12 10:48:33 2021 -0800 + + linux-user: Introduce PAGE_ANON + + Record whether the backing page is anonymous, or if it has file + backing. This will allow us to get close to the Linux AArch64 + ABI for MTE, which allows tag memory only on ram-backed VMAs. + + The real ABI allows tag memory on files, when those files are + on ram-backed filesystems, such as tmpfs. We will not be able + to implement that in QEMU linux-user. + + Thankfully, anonymous memory for malloc arenas is the primary + consumer of this feature, so this restricted version should + still be of use. + + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + + +Possible fix: +https://<email address hidden>/msg796781.html + +The fix that Phil links would only pertain if debootstrap were +actively using MTE. I think we can safely disregard that. + +I don't believe that the bisect has worked. There is nothing in +that 3 line patch that would affect *anything*, as the PAGE_ANON +value is not used at this point. + +Yes, applying the patch pointed out by Philippe doesn't fix the problem. + +But I think bisect has worked fine. + +If I revert this patch (26bab757d41), it works fine again. + +I revert: + +"target/arm: Add allocation tag storage for user mode" + "linux-user: Introduce PAGE_ANON" + +Only reverting the first patch doesn't fix the problem. + +Perhaps the reason is: + +include/exec/cpu-all.h + +#define PAGE_ANON 0x0080 +... +#define PAGE_TARGET_1 0x0080 + + +commit be5d6f4884021208ae0e73379c83e51500ad3a8d +Author: Richard Henderson <email address hidden> +Date: Wed Oct 21 10:37:39 2020 -0700 + + linux-user: Set PAGE_TARGET_1 for TARGET_PROT_BTI + + Transform the prot bit to a qemu internal page bit, and save + it in the page tables. + + Reviewed-by: Peter Maydell <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> +... + +diff --git a/target/arm/cpu.h b/target/arm/cpu.h +index 49cd5cabcf2a..c18a91676656 100644 +--- a/target/arm/cpu.h ++++ b/target/arm/cpu.h +@@ -3445,6 +3445,11 @@ static inline MemTxAttrs *typecheck_memtxattrs(MemTxAttrs *x) + #define arm_tlb_bti_gp(x) (typecheck_memtxattrs(x)->target_tlb_bit0) + #define arm_tlb_mte_tagged(x) (typecheck_memtxattrs(x)->target_tlb_bit1) + ++/* ++ * AArch64 usage of the PAGE_TARGET_* bits for linux-user. ++ */ ++#define PAGE_BTI PAGE_TARGET_1 ++ + /* + * Naming convention for isar_feature functions: + * Functions which test 32-bit ID registers should have _aa32_ in +diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c +index 71888083417d..072754fa24d4 100644 +--- a/target/arm/translate-a64.c ++++ b/target/arm/translate-a64.c +@@ -14507,10 +14507,10 @@ static void disas_data_proc_simd_fp(DisasContext *s, uint32_t insn) + */ + static bool is_guarded_page(CPUARMState *env, DisasContext *s) + { ++ uint64_t addr = s->base.pc_first; + #ifdef CONFIG_USER_ONLY +- return false; /* FIXME */ ++ return page_get_flags(addr) & PAGE_BTI; + #else +- uint64_t addr = s->base.pc_first; + int mmu_idx = arm_to_core_mmu_idx(s->mmu_idx); + unsigned int index = tlb_index(env, mmu_idx, addr); + CPUTLBEntry *entry = tlb_entry(env, mmu_idx, addr); + + + +Ouch, yes indeed. Will fix. + +Fix commit: 52c01ada8661 ("exec: Fix overlap of PAGE_ANON and PAGE_TARGET_1") + diff --git a/results/classifier/105/instruction/1922887 b/results/classifier/105/instruction/1922887 new file mode 100644 index 00000000..212f2edf --- /dev/null +++ b/results/classifier/105/instruction/1922887 @@ -0,0 +1,60 @@ +instruction: 0.879 +device: 0.665 +graphic: 0.601 +mistranslation: 0.484 +semantic: 0.474 +other: 0.461 +network: 0.395 +socket: 0.385 +vnc: 0.381 +boot: 0.374 +assembly: 0.309 +KVM: 0.265 + +STR in Thumb 32 decode problem + +Hi + +It seems that QEMU does not have a proper check on the STR instruction in Thumb32 mode. + +Specifically, the machine code is 0xf84f0ddd, which is 0b1111 1000 0100 1111 0000 1101 1101 1101. +This is an STR (immediate, Thumb) instruction with a T4 encoding scheme. + +The symbols is + +Rn = 1111 +Rt = 0000 +P = 1 +U = 0 +W = 1 + +The decode ASL is below: + +if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRT; +if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm8 == ‘00000100’ then SEE PUSH; +if Rn == ‘1111’ || (P == ‘0’ && W == ‘0’) then UNDEFINED; +t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8, 32); +index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’); +if t == 15 || (wback && n == t) then UNPREDICTABLE; + +When Rn == 1111, it should be an undefined instruction, which should raise SEGILL signal. However, it seems that QEMU does not check this constraint, which should be a bug. Many thanks + +Regards +Muhui + +NB that for Arm mode the equivalent case is UNPREDICTABLE only in the writeback case (and has defined behaviour for non-writeback), so we need to enforce the UNDEF on rn==15 for Thumb decode only. + + +Patch sent to list: if you could test it against whatever your test case was that would be helpful. +https://<email address hidden>/ + +PS: out of interest, why/how were you checking should-UNDEF cases ? + + +We just test the patched version. It looks well. Now QEMU would raise SEGILL signals, which should be the right behavior. + +We are not checking should-UNDEF cases in particular. This is a case we observed and checked manually when doing a research project with QEMU. + +Patch has been merged: +https://gitlab.com/qemu-project/qemu/-/commit/8196fe9d83d6519128b5 + diff --git a/results/classifier/105/instruction/1923629 b/results/classifier/105/instruction/1923629 new file mode 100644 index 00000000..e51ae1d6 --- /dev/null +++ b/results/classifier/105/instruction/1923629 @@ -0,0 +1,51 @@ +instruction: 0.975 +graphic: 0.795 +device: 0.773 +other: 0.737 +network: 0.736 +socket: 0.730 +mistranslation: 0.690 +semantic: 0.652 +boot: 0.569 +vnc: 0.496 +assembly: 0.459 +KVM: 0.396 + +RISC-V Vector Instruction vssub.vv not saturating + +I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF). + +Here is the bit of the code: + + vmv.v.i v16, 0 + … +8f040457 vssub.vv v8,v16,v8 + +I believe the instruction encoding is correct (vssub.vv with vd = v8, vs2 = v16, rs1 = v8), but the result does not saturate in QEMU. + +I’ve just tested with what I think is the latest branch ( https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still exists. + +Thanks for raising this bug case. A fix should be available soon. + +This should be a quick fix, we will run couple tests again to ensure the fix doesn't break anything. Thanks~ + +This was fixed by commit: + +commit 65606f21243a796537bfe4708720a9bf4bb50169 +Author: LIU Zhiwei <email address hidden> +Date: Fri Feb 12 23:02:21 2021 +0800 + + target/riscv: Fixup saturate subtract function + + The overflow predication ((a - b) ^ a) & (a ^ b) & INT64_MIN is right. + However, when the predication is ture and a is 0, it should return maximum. + + Signed-off-by: LIU Zhiwei <email address hidden> + Reviewed-by: Richard Henderson <email address hidden> + Reviewed-by: Alistair Francis <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Alistair Francis <email address hidden> + + +The fix will be in the QEMU 6.1 release. + diff --git a/results/classifier/105/instruction/1923663 b/results/classifier/105/instruction/1923663 new file mode 100644 index 00000000..6cc49d47 --- /dev/null +++ b/results/classifier/105/instruction/1923663 @@ -0,0 +1,157 @@ +instruction: 0.699 +other: 0.698 +semantic: 0.698 +mistranslation: 0.688 +vnc: 0.669 +graphic: 0.659 +KVM: 0.656 +device: 0.654 +assembly: 0.638 +boot: 0.585 +network: 0.572 +socket: 0.520 + +Can't(?) disable default floppy drive any more in qemu 6.0 + +There's a documented change in qemu 6.0: + +https://qemu-project.gitlab.io/qemu/system/removed-features.html#floppy-controllers-drive-properties-removed-in-6-0 + +where you can't configure floppy controller device properties with -global any more. However, there's a thing you could do with the old parameter which I can't figure out a way to do with the documented replacement. openQA passed exactly this argument: + +-global isa-fdc.driveA= + +and that has the effect of removing/disabling the default floppy drive/controller. If you just run `qemu-system-i686` (no other args) you'll see the VM briefly try to boot from a floppy drive; if you run `qemu-system-i686 -global isa-fdc.driveA=` (with an earlier version of qemu, obviously) you'll see it does not do so. + +I can't see a way to do this with `-device floppy`. Going by the docs, the equivalent should be: + +-device floppy,unit=0,drive= + +but that does not seem to have the same effect. If you run `qemu-system-i686 -device floppy,unit=0,drive=`, it still tries to boot from a floppy drive. + +I see there's a -nodefaults option that disables *all* default devices, but I don't think that's what we want here either. We might want the other default devices, we just don't want the floppy drive. + +I see that Markus Armbruster has responded to the bug on 'qemu-devel' list here: +https://lists.nongnu.org/archive/html/qemu-devel/2021-04/msg02177.html + +Not sure if you (Adam) have noticed, as I don't expect you to subscribe to 'qemu-devel'. So I'm copy/pasting the full comment from Markus here: + +-------------------------------------------------------------------------- += Short answer = + +In my opinion, management applications are better off with -nodefaults. +It's easier to understand than the complicated mess I'm going to +describe under "Long answer" below. + +If you'd prefer not to, try -global isa-fdc.fdtypeA=none. + + += Long answer = + +-global isa-fdc.driveA= worked. Whether it was supported usage or +accidental dirt effect is unclear. Doesn't matter now. + +-nodefaults suppresses a number of backends: + +* Character device backend for a serial device + + Also suppressed when -serial ... or -device isa-serial,... or -global + isa-serial.PROP=VAL is given, or the machine type opts out of this + backend. + + Backend configuration depends on other options; too complicated to + explain here. + +* Character device backend for a parallel device + + Also suppressed when -parallel ... or -device isa-parallel,... or + -global isa-parallel.PROP=VAL is given, or the machine type opts out + of this backend. + + Backend configuration depends on other options; too complicated to + explain here. + +* Block device backend a floppy device + + Also suppressed when -device isa-fdc,... or -global isa-fdc.PROP=VAL + or -device floppy or -global floppy.PROP=VAL is given, or the machine + type opts out of this backend. + +* Block device backend a CD-ROM device + + Also suppressed when -device {ide,scsi}-{cd,hd},... or -global + {ide,scsi}-{cd,hd}.PROP=VAL is given, or the machine type opts out of + this backend. + +* SD card + + Also suppressed when the machine type opts out of this backend. + +When a backend exists, the machine type may + +* Create a frontend (a.k.a. device model) connected to the backend + +* Ignore the backend silently + +* Complain about the useless backend + +-nodefaults additionally suppresses: + +* Default HMP monitor + + Also suppressed when -monitor or -qmp or -qmp-pretty or -mon or + -serial mon:... or -parallel mon:... is given. + + Monitor configuration depends on other options; too complicated to + explain here. + +* Default network frontend (-net nic) and backend (-net user) + + Also suppressed when -netdev or -nic or -net is given. + + Default backend is only done when we have SLIRP. + +* Default VGA type, if any + + Actual type depends on the machine machine type. Set to "none" when + -vga or -device DRV,... or -global DRV.PROP=VAL is given, where DRV is + a VGA device model. + + When the type is not "none", the machine type may: + + * Create a device of that type + + * Ignore the type silently + + * Complain about the type + +* Additional stuff depending on the machine type + + +Questions? +-------------------------------------------------------------------------- + +On Wed, 14 Apr 2021 at 08:07, Markus Armbruster <email address hidden> wrote: +> In my opinion, management applications are better off with -nodefaults. +> It's easier to understand than the complicated mess I'm going to +> describe under "Long answer" below. + +Is there a mechanism to get QEMU to tell me "what are all the +long options I need to specify explicitly now to get the same +behaviour that I had before I started passing -nodefaults" ? +Otherwise it's a pretty painful route to suggest that people +go down (though I agree that for a management app as opposed to +an individual user it's probably a worthwhile route in the long +term). + +-- PMM + + + +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/322 + + diff --git a/results/classifier/105/instruction/1926174 b/results/classifier/105/instruction/1926174 new file mode 100644 index 00000000..abb92b4d --- /dev/null +++ b/results/classifier/105/instruction/1926174 @@ -0,0 +1,61 @@ +instruction: 0.842 +graphic: 0.828 +other: 0.815 +device: 0.807 +mistranslation: 0.639 +semantic: 0.622 +network: 0.591 +vnc: 0.577 +socket: 0.555 +assembly: 0.468 +KVM: 0.458 +boot: 0.447 + +Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM + +This weekend I tried to get a CloudReady (Chrome OS) VM running on qemu 5.2. This seems to wok quite well, performance seems to be great in fact. Only problem is mouse input. + +Using SDL display, there is no visible mouse unless I set "show-cursor=on". After that the mouse pointer flickers a bit and most of the time is displaced so I need to press below a button in order to hit it. After switching to fullscreen and back using ctrl-alt-f this effect seems to be fixed for a while but the mouse pointer does not reach all parts of the emulated screen anymore. + +Using SPICE instead the mouse pointer is drawn, but it is *very* laggy. In fact it is only drawn every few seconds so it is unusable but placement seems to be correct. Text input is instant, so general emulation speed is not an issue here. + +To reproduce, download the free image from https://www.neverware.com/freedownload#home-edition-install + +Then run one of the following commands: + +qemu-system-x86_64 -drive driver=raw,file=cloudready-free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-vga,virgl=on -display sdl,gl=on,show-cursor=on -usb -device usb-mouse -device intel-hda -device hda-duplex + +qemu-system-x86_64 -drive driver=raw,file=cloudready-free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-vga,virgl=on -display spice-app,gl=on -usb -device usb-mouse -device intel-hda -device hda-duplex + +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/105/instruction/1926249 b/results/classifier/105/instruction/1926249 new file mode 100644 index 00000000..1b6f8691 --- /dev/null +++ b/results/classifier/105/instruction/1926249 @@ -0,0 +1,47 @@ +instruction: 0.864 +other: 0.850 +device: 0.844 +KVM: 0.809 +semantic: 0.791 +graphic: 0.775 +socket: 0.715 +mistranslation: 0.608 +vnc: 0.556 +network: 0.545 +boot: 0.538 +assembly: 0.319 + +postcopy migration fails in hirsute (solved) + +FYI: this is an intended change, can be overwritten via config and this bug is mostly to have something puzzled users can find via search engines to explain and solve their issue. + +postcopy migration can in some cases be very useful +=> https://wiki.qemu.org/Features/PostCopyLiveMigration + +But with Hirsute kernel being 5.11 that now contains the following upstream change +=> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0d4730ac2 + +Due to that postcopy migration will fail like: + ++ lxc exec testkvm-focal-from -- virsh migrate --unsafe --live --postcopy --postcopy-after-precopy kvmguest-focal-postcopy qemu+ssh://10.85.93.248/system +error: internal error: unable to execute QEMU command 'migrate-set-capabilities': Postcopy is not supported + +This will also apply to e.g. a Focal-HWE kernel once on v5.11 or to Focal userspaces in a container under a Hirsute kernel (that is the example above). + +This was done for security reasons, if you want/need to re-enable un-limited userfault handling to be able to use postcopy again you'd want/need to set the control knob to one like: +$ sudo sysctl -w "vm.unprivileged_userfaultfd=1" + +Also documented in https://askubuntu.com/questions/1334249/qemu-kvm-postcopy-migration-fails-in-hirsute-v5-11-kernels-solved/1334250 + +Also added as known issue in https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221 + +I hope that this will help the case to be found by affected users. + +juju config live-migration-permit-post-copy on the nova-compute charm, could auto enable vm.unprivileged_userfaultfd=1, or at least state this requirement on it's description. + +I'm assigning this to won't fix based on it being a hirsute issue. Hirsuite is EOL as of January 20, 2022. However, if this is affecting newer releases of Ubuntu then please re-open. thanks. + +Hi @ajkavanagh, this affects focal-hwe, jammy and will affect any new releases unless this sysctl is set to 1. + +Based on @felipe's comment in #4, I'm triaging to medium. A possible fix is to enable the sysctl to be executed if the config option " enable-live-migration" is set to True in the charm. This is relatively easy to do. It should also be documented in the charm-guide if the fix is done. + diff --git a/results/classifier/105/instruction/1926277 b/results/classifier/105/instruction/1926277 new file mode 100644 index 00000000..fdfabcfe --- /dev/null +++ b/results/classifier/105/instruction/1926277 @@ -0,0 +1,227 @@ +instruction: 0.772 +graphic: 0.761 +vnc: 0.691 +KVM: 0.644 +other: 0.627 +device: 0.622 +semantic: 0.619 +mistranslation: 0.588 +socket: 0.577 +assembly: 0.541 +network: 0.480 +boot: 0.457 + +MIPS MT dvpe does not regard VPEConf0.MVP + +Hi, + +According to MIPS32® Architecture for Programmers VolumeIV-f: The MIPS® MT Application-Specific Extension to the MIPS32® Architecture, for instruction: dvpe, evpe: + +If the VPE executing the instruction is not a Master VPE, with the MVP bit of the VPEConf0 register set, the EVP bit is unchanged by the instruction. + +The pseudo code is: + +data ← MVPControl +GPR[rt] ← data +if(VPEConf0.MVP = 1) then + MVPControl.EVP ← sc +endif + +However the helper functions of dvpe, evpe does not regard the VPEConf0.MVP bit, namely, it does not check if the VPE is a master VPE. Code is copied below as: + +target_ulong helper_dvpe(CPUMIPSState *env) +{ + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + + CPU_FOREACH(other_cs) { + MIPSCPU *other_cpu = MIPS_CPU(other_cs); + /* Turn off all VPEs except the one executing the dvpe. */ + if (&other_cpu->env != env) { + other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); + mips_vpe_sleep(other_cpu); + } + } + return prev; +} + +Is this a bug? + +QEMU head commit: 0cef06d18762374c94eb4d511717a4735d668a24 is checked. + +According to the 'MIPS MT Application-Specific Extension' manual: + + If the VPE executing the instruction is not a Master VPE, + with the MVP bit of the VPEConf0 register set, the EVP bit + is unchanged by the instruction. + +Add the VPEConf0.MVP bit and modify the DVPE/EVPE opcodes to only +update the MVPControl.EVP bit if executed on a master VPE. + +Reported-by: Hansni Bu +Buglink: https://bugs.launchpad.net/qemu/+bug/1926277 +Fixes: f249412c749 ("mips: Add MT halting and waking of VPEs") +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- + target/mips/cpu.h | 1 + + target/mips/cp0_helper.c | 32 ++++++++++++++++++-------------- + 2 files changed, 19 insertions(+), 14 deletions(-) + +diff --git a/target/mips/cpu.h b/target/mips/cpu.h +index 075c24abdad..bd22fac6959 100644 +--- a/target/mips/cpu.h ++++ b/target/mips/cpu.h +@@ -114,6 +114,7 @@ struct CPUMIPSMVPContext { + #define CP0MVPC0_PTLBE 16 + #define CP0MVPC0_TCA 15 + #define CP0MVPC0_PVPE 10 ++#define CP0MVPC0_MVP 1 + #define CP0MVPC0_PTC 0 + int32_t CP0_MVPConf1; + #define CP0MVPC1_CIM 31 +diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c +index aae2af6eccc..1e39e28808a 100644 +--- a/target/mips/cp0_helper.c ++++ b/target/mips/cp0_helper.c +@@ -1635,12 +1635,14 @@ target_ulong helper_dvpe(CPUMIPSState *env) + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + +- CPU_FOREACH(other_cs) { +- MIPSCPU *other_cpu = MIPS_CPU(other_cs); +- /* Turn off all VPEs except the one executing the dvpe. */ +- if (&other_cpu->env != env) { +- other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); +- mips_vpe_sleep(other_cpu); ++ if (env->mvp->CP0_MVPConf0 & (1 << CP0MVPC0_MVP)) { ++ CPU_FOREACH(other_cs) { ++ MIPSCPU *other_cpu = MIPS_CPU(other_cs); ++ /* Turn off all VPEs except the one executing the dvpe. */ ++ if (&other_cpu->env != env) { ++ other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); ++ mips_vpe_sleep(other_cpu); ++ } + } + } + return prev; +@@ -1651,15 +1653,17 @@ target_ulong helper_evpe(CPUMIPSState *env) + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + +- CPU_FOREACH(other_cs) { +- MIPSCPU *other_cpu = MIPS_CPU(other_cs); ++ if (env->mvp->CP0_MVPConf0 & (1 << CP0MVPC0_MVP)) { ++ CPU_FOREACH(other_cs) { ++ MIPSCPU *other_cpu = MIPS_CPU(other_cs); + +- if (&other_cpu->env != env +- /* If the VPE is WFI, don't disturb its sleep. */ +- && !mips_vpe_is_wfi(other_cpu)) { +- /* Enable the VPE. */ +- other_cpu->env.mvp->CP0_MVPControl |= (1 << CP0MVPCo_EVP); +- mips_vpe_wake(other_cpu); /* And wake it up. */ ++ if (&other_cpu->env != env ++ /* If the VPE is WFI, don't disturb its sleep. */ ++ && !mips_vpe_is_wfi(other_cpu)) { ++ /* Enable the VPE. */ ++ other_cpu->env.mvp->CP0_MVPControl |= (1 << CP0MVPCo_EVP); ++ mips_vpe_wake(other_cpu); /* And wake it up. */ ++ } + } + } + return prev; +-- +2.26.3 + + + +Hi Philippe, + +Instead of checking with MVPConf0, I think we should check with VPEConf0. + +Oops you are right. The problem is I don't have reproducer, so I rely on your testing :) + +According to the 'MIPS MT Application-Specific Extension' manual: + + If the VPE executing the instruction is not a Master VPE, + with the MVP bit of the VPEConf0 register set, the EVP bit + is unchanged by the instruction. + +Modify the DVPE/EVPE opcodes to only update the MVPControl.EVP bit +if executed on a master VPE. + +Reported-by: Hansni Bu <https://launchpad.net/%7Ehansni/+contactuser> +Buglink: https://bugs.launchpad.net/qemu/+bug/1926277 +Fixes: f249412c749 ("mips: Add MT halting and waking of VPEs") +Signed-off-by: Philippe Mathieu-Daudé <email address hidden> +--- +Supersedes: <email address hidden> +v2: Check VPEConf0.MVP bit (hansni) +--- + target/mips/cp0_helper.c | 32 ++++++++++++++++++-------------- + 1 file changed, 18 insertions(+), 14 deletions(-) + +diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c +index aae2af6eccc..d5f274f5cdf 100644 +--- a/target/mips/cp0_helper.c ++++ b/target/mips/cp0_helper.c +@@ -1635,12 +1635,14 @@ target_ulong helper_dvpe(CPUMIPSState *env) + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + +- CPU_FOREACH(other_cs) { +- MIPSCPU *other_cpu = MIPS_CPU(other_cs); +- /* Turn off all VPEs except the one executing the dvpe. */ +- if (&other_cpu->env != env) { +- other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); +- mips_vpe_sleep(other_cpu); ++ if (env->CP0_VPEConf0 & (1 << CP0VPEC0_MVP)) { ++ CPU_FOREACH(other_cs) { ++ MIPSCPU *other_cpu = MIPS_CPU(other_cs); ++ /* Turn off all VPEs except the one executing the dvpe. */ ++ if (&other_cpu->env != env) { ++ other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); ++ mips_vpe_sleep(other_cpu); ++ } + } + } + return prev; +@@ -1651,15 +1653,17 @@ target_ulong helper_evpe(CPUMIPSState *env) + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + +- CPU_FOREACH(other_cs) { +- MIPSCPU *other_cpu = MIPS_CPU(other_cs); ++ if (env->CP0_VPEConf0 & (1 << CP0VPEC0_MVP)) { ++ CPU_FOREACH(other_cs) { ++ MIPSCPU *other_cpu = MIPS_CPU(other_cs); + +- if (&other_cpu->env != env +- /* If the VPE is WFI, don't disturb its sleep. */ +- && !mips_vpe_is_wfi(other_cpu)) { +- /* Enable the VPE. */ +- other_cpu->env.mvp->CP0_MVPControl |= (1 << CP0MVPCo_EVP); +- mips_vpe_wake(other_cpu); /* And wake it up. */ ++ if (&other_cpu->env != env ++ /* If the VPE is WFI, don't disturb its sleep. */ ++ && !mips_vpe_is_wfi(other_cpu)) { ++ /* Enable the VPE. */ ++ other_cpu->env.mvp->CP0_MVPControl |= (1 << CP0MVPCo_EVP); ++ mips_vpe_wake(other_cpu); /* And wake it up. */ ++ } + } + } + return prev; +-- +2.26.3 + + + + +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/244 + + diff --git a/results/classifier/105/instruction/1926759 b/results/classifier/105/instruction/1926759 new file mode 100644 index 00000000..753b9e4d --- /dev/null +++ b/results/classifier/105/instruction/1926759 @@ -0,0 +1,73 @@ +instruction: 0.938 +semantic: 0.770 +graphic: 0.694 +other: 0.656 +device: 0.644 +vnc: 0.552 +assembly: 0.506 +socket: 0.491 +network: 0.398 +boot: 0.365 +mistranslation: 0.349 +KVM: 0.297 + +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/105/instruction/1955 b/results/classifier/105/instruction/1955 new file mode 100644 index 00000000..17cd3a9d --- /dev/null +++ b/results/classifier/105/instruction/1955 @@ -0,0 +1,39 @@ +instruction: 0.950 +graphic: 0.840 +semantic: 0.801 +device: 0.645 +other: 0.493 +socket: 0.420 +network: 0.394 +mistranslation: 0.346 +boot: 0.280 +vnc: 0.269 +assembly: 0.183 +KVM: 0.107 + +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/105/instruction/1958 b/results/classifier/105/instruction/1958 new file mode 100644 index 00000000..8240e159 --- /dev/null +++ b/results/classifier/105/instruction/1958 @@ -0,0 +1,34 @@ +instruction: 0.931 +mistranslation: 0.877 +graphic: 0.858 +device: 0.805 +vnc: 0.766 +semantic: 0.679 +socket: 0.488 +other: 0.383 +KVM: 0.381 +network: 0.360 +boot: 0.359 +assembly: 0.268 + +PPC msgsnd for DOORBELL CRITICAL masked by MSR[EE] instead of MSR[CE] +Description of problem: +When executing PPC instruction "msgsnd r3. with r3 = 0x08000001" an DOORBELL CRITICAL exception is raised on core number 1. But this exception is masked by MSR\[EE\] bit, the MSR\[EE\] should be set to 1 in core1 to get this exception. But the NXP E500MCRM.pdf reference manual indicates that MSR\[CE\] is the mask bit for DOORBELL_CRITICAL Exception. +Additional information: +In qemu-8.1.2/target/ppc/excp_helper.c i try to change in ppc_next_unmasked_interrupt_generic function: + +``` +if (FIELD_EX64(env->msr, MSR, CE)) { + /* Critical doorbell */ + if (env->pending_interrupts & PPC_INTERRUPT_CDOORBELL) { <- move this part from (async_deliver != 0) + return PPC_INTERRUPT_CDOORBELL; + } + /* External critical interrupt */ + if (env->pending_interrupts & PPC_INTERRUPT_CEXT) { + return PPC_INTERRUPT_CEXT; + } +} +``` + + +And it seems to work in my case. diff --git a/results/classifier/105/instruction/1981 b/results/classifier/105/instruction/1981 new file mode 100644 index 00000000..85caac09 --- /dev/null +++ b/results/classifier/105/instruction/1981 @@ -0,0 +1,23 @@ +instruction: 0.922 +mistranslation: 0.886 +device: 0.862 +graphic: 0.856 +socket: 0.694 +semantic: 0.612 +network: 0.594 +other: 0.557 +vnc: 0.329 +assembly: 0.121 +boot: 0.021 +KVM: 0.011 + +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/105/instruction/1991 b/results/classifier/105/instruction/1991 new file mode 100644 index 00000000..d4a8aed1 --- /dev/null +++ b/results/classifier/105/instruction/1991 @@ -0,0 +1,77 @@ +instruction: 0.942 +boot: 0.912 +graphic: 0.911 +socket: 0.905 +device: 0.895 +mistranslation: 0.792 +semantic: 0.778 +KVM: 0.754 +network: 0.740 +vnc: 0.698 +other: 0.517 +assembly: 0.326 + +error "hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached" in qemu-system-hppa +Description of problem: +The installation phase terminates with a failed assertion in qemu: +``` +... +Rebooting the system +reboot: Restarting system +SeaBIOS wants SYSTEM RESET. +*************************** +** +ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached +Bail out! ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached +Aborted (core dumped) +``` +Steps to reproduce: +``` +PATH=$HOME/inst-qemu/8.2.0-rc0/bin:$PATH +``` + +Create empty disk: +``` +qemu-img create -f qcow2 t2sde.qcow2 10G +``` + +Pull kernel and initrd out of the installation CD: +``` +sudo mount -r -t iso9660 -o loop t2-23.6-hppa-minimal-desktop-gcc-glibc.iso /mnt +mkdir boot-for-install +cp -p /mnt/boot/* boot-for-install/ +sudo umount /mnt +``` + +Run installer: +``` +machine_args="-M C3700 -m 256" +disk_args="-drive file=t2sde.qcow2,format=qcow2,id=hd0" +net_args="" +#display_args="-monitor stdio -display gtk" +display_args="-nographic" +common_args="$machine_args $disk_args $net_args $display_args" +qemu-system-hppa $common_args \ + -kernel boot-for-install/vmlinux-6.3.7-t2 -initrd boot-for-install/initrd-6.3.7-t2 \ + -drive file=t2-23.6-hppa-minimal-desktop-gcc-glibc.iso,if=scsi,bus=0,unit=2,media=cdrom +``` + +``` +Serial terminal: <Enter> or console +# install +Partition: + fdisk + n p 1 <Enter> <Enter> + w +On /dev/sda1: Create filesystem of type ext3 with mount point / +Install the system +Full install (all packages). +Keyboard: us +Root password: t2 +Time zone: Europe/Berlin +Locale: -- +Finally: <Back> +Then: <Exit> +``` +Additional information: + diff --git a/results/classifier/105/instruction/2004 b/results/classifier/105/instruction/2004 new file mode 100644 index 00000000..d6aeebe4 --- /dev/null +++ b/results/classifier/105/instruction/2004 @@ -0,0 +1,46 @@ +instruction: 0.857 +device: 0.815 +other: 0.788 +mistranslation: 0.679 +graphic: 0.669 +semantic: 0.592 +network: 0.583 +socket: 0.523 +vnc: 0.503 +boot: 0.377 +KVM: 0.195 +assembly: 0.160 + +do_guest_openat /proc interposition doesn't work for openat +Description of problem: +For instance, trying with hppa emulated on top of x86: + +``` +$ hppa-linux-gnu-gcc test.c -o test +$ qemu-hppa-static ./test +``` + +One gets the host cpu information: + +``` +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 142 +model name : Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz +[...] +``` + +while we would want to see the guest cpu information, like the test program does when `#if 0` is turned into `#if 1`: + +``` +processor : 0 +cpu family : PA-RISC 1.1e +cpu : PA7300LC (PCX-L2) +capabilities : os32 +model : 9000/778/B160L - Merlin L2 160 QEMU (9000/778/B160L) +``` + +This is because `do_guest_openat` only checks for the path, and does not look at `dirfd`, so it doesn't recognize that `openat(dirfd, "cpuinfo", O_RDONLY)` is actually opening a file in `/proc`. + +We could probably, when `dirfd` is not `AT_FDCWD`, try to `fstat()` it, open `/proc` with `O_DIRECTORY` and `fstat()` that too, and compare their `st_dev` and `st_ino`? diff --git a/results/classifier/105/instruction/2008 b/results/classifier/105/instruction/2008 new file mode 100644 index 00000000..dfcb361e --- /dev/null +++ b/results/classifier/105/instruction/2008 @@ -0,0 +1,25 @@ +instruction: 0.900 +device: 0.831 +graphic: 0.829 +semantic: 0.754 +other: 0.670 +network: 0.550 +vnc: 0.506 +boot: 0.452 +mistranslation: 0.441 +socket: 0.395 +assembly: 0.094 +KVM: 0.047 + +querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry +Description of problem: +Querying the UUID in Powershell with +`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID` +will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present. + +Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part. + +It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS. +Additional information: +Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths): +https://forum.proxmox.com/threads/136942/ diff --git a/results/classifier/105/instruction/203 b/results/classifier/105/instruction/203 new file mode 100644 index 00000000..8a027670 --- /dev/null +++ b/results/classifier/105/instruction/203 @@ -0,0 +1,14 @@ +instruction: 0.859 +device: 0.840 +boot: 0.609 +network: 0.599 +semantic: 0.588 +graphic: 0.449 +mistranslation: 0.445 +other: 0.396 +socket: 0.254 +assembly: 0.250 +vnc: 0.246 +KVM: 0.119 + +move ./scripts/qapi/ to ./python/qemu/qapi/ diff --git a/results/classifier/105/instruction/2039 b/results/classifier/105/instruction/2039 new file mode 100644 index 00000000..8bbab5be --- /dev/null +++ b/results/classifier/105/instruction/2039 @@ -0,0 +1,24 @@ +instruction: 0.923 +device: 0.874 +graphic: 0.850 +mistranslation: 0.766 +network: 0.745 +semantic: 0.741 +other: 0.694 +vnc: 0.656 +boot: 0.626 +socket: 0.433 +KVM: 0.326 +assembly: 0.322 + +there is no 'write' lock checked when exec `qemu-img check lvqcow2` +Description of problem: +There is a difference between a qcow2 file image and a lvqcow2 img. + +'write' lock will be checked when using a normal qcow2-format image (/path/to/img/test.qcow2) to avoid some risky operations. However, when I create a qcow2 img on a lv, there is not any write lock checked when I perform `qemu-img check` on this lvqcow2 even though it was attached to a vm. +Steps to reproduce: +1. create a lvqcow2: `qemu-img create -f qcow2 /path/to/lv xxG` +2. create a vm using this lvqcow2 +3. exec `qemu-img check` on this lvqcow2, there is no any perm (such as 'write' lock) check and notifaction even though this lvqcow2 is using in qemu vm. +Additional information: + diff --git a/results/classifier/105/instruction/2043 b/results/classifier/105/instruction/2043 new file mode 100644 index 00000000..ba5d5acf --- /dev/null +++ b/results/classifier/105/instruction/2043 @@ -0,0 +1,87 @@ +instruction: 0.754 +vnc: 0.742 +other: 0.741 +semantic: 0.729 +device: 0.722 +graphic: 0.710 +assembly: 0.703 +boot: 0.678 +mistranslation: 0.618 +KVM: 0.613 +socket: 0.599 +network: 0.568 + +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/105/instruction/2054889 b/results/classifier/105/instruction/2054889 new file mode 100644 index 00000000..898b7dd9 --- /dev/null +++ b/results/classifier/105/instruction/2054889 @@ -0,0 +1,66 @@ +instruction: 0.889 +device: 0.839 +socket: 0.833 +other: 0.822 +mistranslation: 0.791 +network: 0.776 +semantic: 0.739 +boot: 0.679 +graphic: 0.667 +assembly: 0.659 +vnc: 0.605 +KVM: 0.454 + +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/105/instruction/2074 b/results/classifier/105/instruction/2074 new file mode 100644 index 00000000..475ecd6d --- /dev/null +++ b/results/classifier/105/instruction/2074 @@ -0,0 +1,33 @@ +instruction: 0.908 +graphic: 0.839 +device: 0.680 +boot: 0.672 +semantic: 0.448 +other: 0.389 +mistranslation: 0.233 +vnc: 0.171 +socket: 0.147 +network: 0.129 +assembly: 0.101 +KVM: 0.093 + +riscv64 cannot use the mret instruction to jump to the address corresponding to s mode +Description of problem: +I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800. +and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened. +It shows: +[DEBUG] Exception: Instruction access fault +[DEBUG] Hart ID: 0 +[DEBUG] Previous mode: machine +[DEBUG] Bad instruction pc: 0x8103f7c0 +[DEBUG] Bad address: 0x00000000 +[DEBUG] Stored ra: 0x8103f7b8 +[DEBUG] Stored sp: 0x82032f08 +Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret". +So I can not jump to my kernel's load address. +I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address? +Steps to reproduce: +1.download qemu +2.download coreboot +Additional information: +When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000. diff --git a/results/classifier/105/instruction/2088 b/results/classifier/105/instruction/2088 new file mode 100644 index 00000000..2b030b19 --- /dev/null +++ b/results/classifier/105/instruction/2088 @@ -0,0 +1,34 @@ +instruction: 0.943 +network: 0.903 +graphic: 0.891 +device: 0.858 +socket: 0.787 +mistranslation: 0.784 +vnc: 0.714 +semantic: 0.695 +boot: 0.601 +assembly: 0.530 +other: 0.492 +KVM: 0.146 + +Building qemu fails on Solaris 11.4 +Description of problem: +Building qemu-system-hppa on Solaris 11.4 (details above) fails because in qga/commands-posix.c + +(1) Solaris does not have net/ethernet.h +``` + #if defined(__NetBSD__) || defined(__OpenBSD__) + #include <net/if_arp.h> + #include <netinet/if_ether.h> + #else + #include <net/ethernet.h> + #endif +``` +Solaris *does* have net/if_arp.h and netinet/if_ether.h + +(2) Solaris does not define ETHER_ADDR_LEN, instead it defines ETHERADDRL +Steps to reproduce: +1. '../configure' '--disable-docs' '--disable-rdma' '--target-list=hppa-softmmu' +2. gmake +Additional information: + diff --git a/results/classifier/105/instruction/2089 b/results/classifier/105/instruction/2089 new file mode 100644 index 00000000..4241b84e --- /dev/null +++ b/results/classifier/105/instruction/2089 @@ -0,0 +1,40 @@ +instruction: 0.901 +semantic: 0.855 +graphic: 0.833 +device: 0.746 +vnc: 0.500 +assembly: 0.466 +network: 0.405 +socket: 0.335 +boot: 0.172 +mistranslation: 0.117 +KVM: 0.086 +other: 0.022 + +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/105/instruction/2091 b/results/classifier/105/instruction/2091 new file mode 100644 index 00000000..9b8f80f2 --- /dev/null +++ b/results/classifier/105/instruction/2091 @@ -0,0 +1,16 @@ +instruction: 0.897 +device: 0.876 +boot: 0.868 +network: 0.370 +graphic: 0.349 +mistranslation: 0.298 +semantic: 0.227 +socket: 0.217 +vnc: 0.186 +KVM: 0.159 +other: 0.107 +assembly: 0.031 + +m68k: virt: Pass the configured cpu type via bootinfo instead of the default 68040 +Additional information: + diff --git a/results/classifier/105/instruction/2104 b/results/classifier/105/instruction/2104 new file mode 100644 index 00000000..66bfcf8a --- /dev/null +++ b/results/classifier/105/instruction/2104 @@ -0,0 +1,14 @@ +instruction: 0.842 +device: 0.698 +assembly: 0.459 +KVM: 0.365 +vnc: 0.315 +semantic: 0.309 +boot: 0.200 +graphic: 0.167 +network: 0.113 +other: 0.088 +mistranslation: 0.059 +socket: 0.032 + +source code of function trace_memory_region_ops_write() diff --git a/results/classifier/105/instruction/2111 b/results/classifier/105/instruction/2111 new file mode 100644 index 00000000..aec920e5 --- /dev/null +++ b/results/classifier/105/instruction/2111 @@ -0,0 +1,72 @@ +instruction: 0.773 +network: 0.769 +other: 0.767 +graphic: 0.757 +assembly: 0.750 +mistranslation: 0.743 +KVM: 0.741 +semantic: 0.738 +socket: 0.738 +device: 0.723 +vnc: 0.688 +boot: 0.661 + +Assertion failure with active vhost NIC when snapshot_save_job_bh() is executed as part of a vCPU thread's aio_poll() +Description of problem: +During a `snapshot-save` QMP command the `snapshot_save_job_bh()` bottom half can end up being executed as part of a vCPU thread's `aio_poll()`. This is problematic and can lead to an assertion failure (see below for backtrace) when there is an active vhost network device: + +``` +qemu-system-x86_64: ../hw/net/virtio-net.c:3835: virtio_net_pre_save: Assertion `!n->vhost_started' failed. +``` +Steps to reproduce: +It is very racy and very difficult to reproduce when actually taking snapshots. So the way I can get it pretty reliably is: + +1. Issue `snapshot-save` QMP commands with an invalid device ID in a loop. At the same time, have the guest write to the pflash. +2. In GDB, wait for `snapshot_save_job_bh()` to be hit by a vCPU thread. +3. Manually change the device ID to a valid one (`scsi1` in the example) so that taking a snapshot will actually be attempted. +4. Continue in GDB and the assertion failure will happen. +Additional information: +Full backtrace: + +``` + #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 + #1 0x00007f1de5ae3d9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 + #2 0x00007f1de5a94f32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 + #3 0x00007f1de5a7f472 in __GI_abort () at ./stdlib/abort.c:79 + #4 0x00007f1de5a7f395 in __assert_fail_base (fmt=0x7f1de5bf3a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", + file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:92 + #5 0x00007f1de5a8de32 in __GI___assert_fail (assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, + function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:101 + #6 0x0000563cb8ebf23c in virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3835 + #7 virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3829 + #8 0x0000563cb917515b in vmstate_save_state_v (f=0x7f1dc43aec30, vmsd=0x563cb9e5a580 <vmstate_virtio_net>, opaque=0x563cbbb6eb40, vmdesc=0x7f1dc4080040, version_id=11, errp=0x7f1dcbdf9908) + at ../migration/vmstate.c:359 + #9 0x0000563cb9175d0c in vmstate_save_state_with_err (f=<optimized out>, vmsd=<optimized out>, opaque=<optimized out>, vmdesc_id=<optimized out>, errp=<optimized out>) at ../migration/vmstate.c:347 + #10 0x0000563cb8d9a1b2 in vmstate_save (f=f@entry=0x7f1dc43aec30, se=se@entry=0x563cbbcbdc70, vmdesc=vmdesc@entry=0x7f1dc4080040) at ../migration/savevm.c:1037 + #11 0x0000563cb8d9d6e6 in qemu_savevm_state_complete_precopy_non_iterable (f=f@entry=0x7f1dc43aec30, in_postcopy=in_postcopy@entry=false, inactivate_disks=inactivate_disks@entry=false) + at ../migration/savevm.c:1553 + #12 0x0000563cb8d9daa2 in qemu_savevm_state_complete_precopy (f=f@entry=0x7f1dc43aec30, iterable_only=iterable_only@entry=false, inactivate_disks=inactivate_disks@entry=false) at ../migration/savevm.c:1628 + #13 0x0000563cb8da076e in qemu_savevm_state (errp=0x7f1dc42c59f0, f=0x7f1dc43aec30) at ../migration/savevm.c:1734 + #14 save_snapshot (name=<optimized out>, overwrite=overwrite@entry=false, vmstate=<optimized out>, has_devices=has_devices@entry=true, devices=0x7f1dc4096600, errp=0x7f1dc42c59f0) at ../migration/savevm.c:3131 + #15 0x0000563cb8da0926 in snapshot_save_job_bh (opaque=0x7f1dc42c5930) at ../migration/savevm.c:3430 + #16 0x0000563cb9110036 in aio_bh_poll (ctx=ctx@entry=0x563cba818b40) at ../util/async.c:216 + #17 0x0000563cb90fa09a in aio_poll (ctx=ctx@entry=0x563cba818b40, blocking=blocking@entry=true) at ../util/aio-posix.c:722 + #18 0x0000563cb8fb1015 in bdrv_poll_co (s=0x7f1dcbdf9db0) at /home/febner/repos/qemu/block/block-gen.h:43 + #19 blk_pwrite (blk=<optimized out>, offset=offset@entry=91136, bytes=bytes@entry=512, buf=0x7f1dc9a16400, flags=flags@entry=0) at block/block-gen.c:2012 + #20 0x0000563cb8bb8985 in pflash_update (pfl=pfl@entry=0x563cbaa84bf0, offset=91136, offset@entry=91526, size=size@entry=1) at ../hw/block/pflash_cfi01.c:394 + #21 0x0000563cb8bbacd8 in pflash_write (be=0, width=1, value=63, offset=91526, pfl=0x563cbaa84bf0) at ../hw/block/pflash_cfi01.c:522 + #22 pflash_mem_write_with_attrs (opaque=0x563cbaa84bf0, addr=91526, value=<optimized out>, len=1, attrs=...) at ../hw/block/pflash_cfi01.c:681 + #23 0x0000563cb8f06e2e in access_with_adjusted_size (addr=addr@entry=91526, value=value@entry=0x7f1dcbdf9f58, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, + access_fn=0x563cb8f06710 <memory_region_write_with_attrs_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 + #24 0x0000563cb8f07e59 in memory_region_dispatch_write (mr=mr@entry=0x563cbaa84fb0, addr=addr@entry=91526, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528 + #25 0x0000563cb8f0f43c in flatview_write_continue (fv=fv@entry=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f1de7946028, len=len@entry=1, addr1=<optimized out>, + l=<optimized out>, mr=0x563cbaa84fb0) at ../system/physmem.c:2714 + #26 0x0000563cb8f0f6b3 in flatview_write (fv=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=len@entry=1) at ../system/physmem.c:2756 + #27 0x0000563cb8f12959 in address_space_write (len=1, buf=0x7f1de7946028, attrs=..., addr=4290864518, as=0x563cb9fd8ec0 <address_space_memory>) at ../system/physmem.c:2863 + #28 address_space_rw (as=0x563cb9fd8ec0 <address_space_memory>, addr=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=1, is_write=<optimized out>) at ../system/physmem.c:2873 + #29 0x0000563cb8f64ab8 in kvm_cpu_exec (cpu=cpu@entry=0x563cbac066d0) at ../accel/kvm/kvm-all.c:2915 + #30 0x0000563cb8f65ce5 in kvm_vcpu_thread_fn (arg=arg@entry=0x563cbac066d0) at ../accel/kvm/kvm-accel-ops.c:51 + #31 0x0000563cb90fd1c8 in qemu_thread_start (args=0x563cbaac33c0) at ../util/qemu-thread-posix.c:541 + #32 0x00007f1de5ae2044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 + #33 0x00007f1de5b6261c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/105/instruction/2114 b/results/classifier/105/instruction/2114 new file mode 100644 index 00000000..e447693a --- /dev/null +++ b/results/classifier/105/instruction/2114 @@ -0,0 +1,14 @@ +instruction: 0.907 +device: 0.790 +graphic: 0.471 +network: 0.349 +mistranslation: 0.309 +semantic: 0.241 +vnc: 0.214 +socket: 0.120 +boot: 0.102 +other: 0.092 +assembly: 0.069 +KVM: 0.016 + +hw/char/riscv_htif.c and hw/char/sifive_uart call qemu_chr_fe_write() and ignore return value diff --git a/results/classifier/105/instruction/2118 b/results/classifier/105/instruction/2118 new file mode 100644 index 00000000..1163ceb6 --- /dev/null +++ b/results/classifier/105/instruction/2118 @@ -0,0 +1,14 @@ +instruction: 0.916 +device: 0.836 +network: 0.764 +boot: 0.399 +semantic: 0.391 +mistranslation: 0.383 +vnc: 0.331 +graphic: 0.329 +socket: 0.328 +other: 0.246 +assembly: 0.195 +KVM: 0.004 + +make vm-build-openbsd reinstalls OpenBSD every time diff --git a/results/classifier/105/instruction/2123 b/results/classifier/105/instruction/2123 new file mode 100644 index 00000000..07421831 --- /dev/null +++ b/results/classifier/105/instruction/2123 @@ -0,0 +1,44 @@ +instruction: 0.920 +graphic: 0.818 +semantic: 0.778 +device: 0.724 +vnc: 0.670 +mistranslation: 0.614 +network: 0.574 +boot: 0.489 +socket: 0.376 +other: 0.317 +KVM: 0.046 +assembly: 0.022 + +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/105/instruction/2127 b/results/classifier/105/instruction/2127 new file mode 100644 index 00000000..a43f51ed --- /dev/null +++ b/results/classifier/105/instruction/2127 @@ -0,0 +1,14 @@ +instruction: 0.847 +device: 0.606 +mistranslation: 0.573 +vnc: 0.461 +graphic: 0.365 +boot: 0.336 +semantic: 0.227 +assembly: 0.221 +socket: 0.185 +network: 0.104 +other: 0.027 +KVM: 0.003 + +test-aio-multithread.c:371:test_multi_fair_mutex: assertion failed (counter == atomic_counter): (316636 == 316637) diff --git a/results/classifier/105/instruction/2131 b/results/classifier/105/instruction/2131 new file mode 100644 index 00000000..243b6dd5 --- /dev/null +++ b/results/classifier/105/instruction/2131 @@ -0,0 +1,14 @@ +instruction: 0.680 +device: 0.592 +network: 0.562 +mistranslation: 0.384 +graphic: 0.382 +semantic: 0.310 +KVM: 0.116 +other: 0.110 +boot: 0.063 +socket: 0.033 +assembly: 0.033 +vnc: 0.015 + +tcg mem plugin, udata always zero diff --git a/results/classifier/105/instruction/2140 b/results/classifier/105/instruction/2140 new file mode 100644 index 00000000..0eb791eb --- /dev/null +++ b/results/classifier/105/instruction/2140 @@ -0,0 +1,14 @@ +instruction: 0.377 +mistranslation: 0.342 +graphic: 0.328 +semantic: 0.297 +device: 0.290 +other: 0.249 +network: 0.110 +boot: 0.094 +vnc: 0.032 +socket: 0.018 +assembly: 0.017 +KVM: 0.002 + +Compiling object tests/fp - Can't create tests/fp Is directory Centos 7 diff --git a/results/classifier/105/instruction/2142 b/results/classifier/105/instruction/2142 new file mode 100644 index 00000000..3cae3467 --- /dev/null +++ b/results/classifier/105/instruction/2142 @@ -0,0 +1,14 @@ +instruction: 0.833 +graphic: 0.732 +device: 0.690 +mistranslation: 0.500 +semantic: 0.419 +boot: 0.264 +other: 0.100 +vnc: 0.067 +assembly: 0.039 +socket: 0.034 +network: 0.013 +KVM: 0.007 + +`-machine microvm -cpu host` crashes when guest attempts to check CPUID SGX bits diff --git a/results/classifier/105/instruction/2149 b/results/classifier/105/instruction/2149 new file mode 100644 index 00000000..3e7bd837 --- /dev/null +++ b/results/classifier/105/instruction/2149 @@ -0,0 +1,24 @@ +instruction: 0.809 +other: 0.809 +device: 0.793 +graphic: 0.777 +network: 0.747 +vnc: 0.670 +semantic: 0.610 +mistranslation: 0.535 +socket: 0.532 +KVM: 0.508 +boot: 0.436 +assembly: 0.168 + +Segfault in libvhost-user and libvduse because of invalid pointer arithmetic with indirect read +Description of problem: +Hello, this is my first experience communicating with open-source community. I have already reported the problem and have submitted patches through qemu-devel mailing list https://mail.gnu.org/archive/html/qemu-devel/2024-01/msg02533.html, as instructed in https://www.qemu.org/docs/master/devel/submitting-a-patch.html, albeit getting no response from any maintainer. I know, that everyone are very busy and are spammed everyday from millions of threads, but I am getting very upset, that such a trivial bug lives in code base for many years and even have been copied to "sister"-library without proper review. So, excuse me, if I am taking this issue too personally. + +The problem - when one tries to use libvhost-user\libvduse and triggers for some reason non-zero-copy mode (like pushing a lot of data) of indirect descriptor reading routine `virtqueue_read_indirect_desc`, any time one got to read more than one descriptor - one would overwrite stack and depending on one's luck getting some weird behaviour, or simple crash moments later, when other code tries to access broken data. + +Steps to reproduce are non-trivial, because depends on one's host and VM (one simply gets random crashes here and there, with core dumps pointing somewhere around given libraries), but anyone who can read C code, can clearly see that pointer arithmetic of `struct vring_desc *desc` is wrong. + +Maybe, I got instructions wrong and posted fixes to wrong mailing list, maybe, nobody cares, so thank you for attention. I'll be glad to hear any advice on how can I help with fixing this simple error, besides what has been done already. + +Thank you. diff --git a/results/classifier/105/instruction/2156 b/results/classifier/105/instruction/2156 new file mode 100644 index 00000000..df4634ad --- /dev/null +++ b/results/classifier/105/instruction/2156 @@ -0,0 +1,28 @@ +instruction: 0.910 +device: 0.847 +graphic: 0.813 +semantic: 0.723 +network: 0.631 +vnc: 0.607 +socket: 0.606 +boot: 0.293 +mistranslation: 0.218 +other: 0.141 +KVM: 0.128 +assembly: 0.070 + +Userland QEMU segfaults when emulating itself thrice +Description of problem: +See title. +``` +$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true +qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0} +[1] 15705 segmentation fault (core dumped) qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true +``` +Steps to reproduce: +1. Execute command above +Additional information: +Coredump (~322MB uncompressed) +[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz) + +SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6 diff --git a/results/classifier/105/instruction/2157 b/results/classifier/105/instruction/2157 new file mode 100644 index 00000000..76bc15bc --- /dev/null +++ b/results/classifier/105/instruction/2157 @@ -0,0 +1,56 @@ +instruction: 0.930 +graphic: 0.889 +device: 0.855 +socket: 0.747 +vnc: 0.746 +network: 0.744 +other: 0.567 +semantic: 0.524 +assembly: 0.487 +boot: 0.478 +KVM: 0.367 +mistranslation: 0.349 + +qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB +Description of problem: +`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB +(such as LoongArch, ppc64le, arm64 with 3 level page tables). +Steps to reproduce: +1. Compile x86 binary which makes a single exit(0) syscall: + ``` + cat > exit0.S << EOF + #include <sys/syscall.h> + .text + .global _start + _start: + movl $__NR_exit, %eax + movl $0, %ebx + int $0x80 + EOF + i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S + ``` + Alternatively one might compile it on a x86 host: + ``` + gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S + ``` + and transfer the `exit0` binary to ppc64/LoongArch/arm64 system + + 2. Run the `exit0` binary with `qemu-i386` + ``` + qemu-i386-static ./exit0 + ``` + + # +Additional information: +`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB: +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x08048000 0x08048000 0x00100 0x00100 R 0x1000 + LOAD 0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000 + NOTE 0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R 0x4 + GNU_PROPERTY 0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R 0x4 +``` + +Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch) +alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied. diff --git a/results/classifier/105/instruction/216 b/results/classifier/105/instruction/216 new file mode 100644 index 00000000..dbbcd440 --- /dev/null +++ b/results/classifier/105/instruction/216 @@ -0,0 +1,14 @@ +instruction: 0.697 +device: 0.610 +mistranslation: 0.593 +graphic: 0.379 +network: 0.331 +semantic: 0.321 +boot: 0.280 +assembly: 0.128 +other: 0.099 +vnc: 0.095 +socket: 0.081 +KVM: 0.025 + +qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate" diff --git a/results/classifier/105/instruction/2160 b/results/classifier/105/instruction/2160 new file mode 100644 index 00000000..9623b93d --- /dev/null +++ b/results/classifier/105/instruction/2160 @@ -0,0 +1,14 @@ +instruction: 0.880 +device: 0.862 +network: 0.743 +socket: 0.696 +graphic: 0.549 +semantic: 0.227 +mistranslation: 0.153 +boot: 0.141 +vnc: 0.061 +other: 0.046 +assembly: 0.010 +KVM: 0.002 + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-libusb" diff --git a/results/classifier/105/instruction/2163 b/results/classifier/105/instruction/2163 new file mode 100644 index 00000000..9415fd08 --- /dev/null +++ b/results/classifier/105/instruction/2163 @@ -0,0 +1,14 @@ +instruction: 0.875 +semantic: 0.801 +mistranslation: 0.607 +graphic: 0.548 +device: 0.447 +boot: 0.322 +assembly: 0.123 +other: 0.035 +vnc: 0.032 +network: 0.010 +socket: 0.004 +KVM: 0.001 + +Move architecture specific interruption code around SPARC CPUs from hw/sparc/ to target/sparc/ diff --git a/results/classifier/105/instruction/2175 b/results/classifier/105/instruction/2175 new file mode 100644 index 00000000..874c3bcd --- /dev/null +++ b/results/classifier/105/instruction/2175 @@ -0,0 +1,51 @@ +instruction: 0.883 +device: 0.776 +graphic: 0.745 +assembly: 0.701 +network: 0.686 +vnc: 0.644 +other: 0.619 +socket: 0.611 +mistranslation: 0.593 +KVM: 0.567 +semantic: 0.514 +boot: 0.511 + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/105/instruction/2177 b/results/classifier/105/instruction/2177 new file mode 100644 index 00000000..fa5de826 --- /dev/null +++ b/results/classifier/105/instruction/2177 @@ -0,0 +1,14 @@ +instruction: 0.868 +device: 0.844 +network: 0.739 +graphic: 0.586 +socket: 0.256 +semantic: 0.247 +mistranslation: 0.175 +boot: 0.140 +vnc: 0.069 +other: 0.030 +assembly: 0.007 +KVM: 0.003 + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-dtc" diff --git a/results/classifier/105/instruction/2198 b/results/classifier/105/instruction/2198 new file mode 100644 index 00000000..8d99706c --- /dev/null +++ b/results/classifier/105/instruction/2198 @@ -0,0 +1,38 @@ +instruction: 0.950 +graphic: 0.859 +boot: 0.817 +device: 0.801 +network: 0.799 +semantic: 0.762 +other: 0.678 +mistranslation: 0.644 +socket: 0.613 +vnc: 0.516 +KVM: 0.461 +assembly: 0.181 + +Unable to run OS/2 Warp4.52 +Description of problem: +Operating system crashes upon boot. +Steps to reproduce: +1. Install OS/2 Warp4 +2. Apply Fixpack15 +3. Try to boot the system +Additional information: +This is a very old bug that seems to render a whole family of Operating Systems (OS/2 Warp4 and eComStation) unusable under Qemu. +Warp4 works, in the sense that it does install and run, but just until it is updated to 4.52 (which is necessary to get a useable guest) + +I found traces of its existence as far as: +https://bugs.launchpad.net/qemu/+bug/1743441 +https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg02337.html + +And i found the issue brieffly commented at https://www.os2world.com/forum/index.php?topic=2346.0 +I quote: + +'Regarding QEMU/KVM, OS/2 runs in QEMU mostly fine. Except the trap in os2lvm.dmd and non-working netbeui.os2 and +tcpbeui.os2. The problem with os2lvm.dmd is because QEMU closely follows the intel spec, which is incorrect. The spec says +that 16-bit SGDT instruction behaves the same like in i286 processor. But it's not true, it behaves like i386 instruction. So, QEMU +emulates SGDT 16-bit instruction incorrectly. OS2LVM.DMD uses 16-bit SGDT instruction and it hits the problem.' + +After a brief discussion on the Warp4 group at groups.io where I was told that this is indeed a Qemu bug, I thought someone has +to report on that. diff --git a/results/classifier/105/instruction/2207 b/results/classifier/105/instruction/2207 new file mode 100644 index 00000000..6132db50 --- /dev/null +++ b/results/classifier/105/instruction/2207 @@ -0,0 +1,24 @@ +instruction: 0.950 +graphic: 0.846 +device: 0.791 +semantic: 0.719 +vnc: 0.663 +mistranslation: 0.640 +network: 0.540 +socket: 0.457 +other: 0.378 +boot: 0.326 +assembly: 0.128 +KVM: 0.062 + +WerFault.exe – Application Error. The memory could not be read in Win7 i386 +Description of problem: +WerFault Application Errors always occur when I open IE or even control panel. It's OK on QEMU 7.2 & 8.0 version according to my debug experience about qemu-system-i386 flavor in the last few months. +Steps to reproduce: +1. pulling _tag: v8.2.0_ code +2. emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3. just opening IE for maybe two or three times after the virtual machine has started +Additional information: +The error is displayed by Chinese. It says _WerFault.exe – Application Error. The instruction at 0x779f77b2 referenced memory at 0x6d0f6d20. The memory could not be read._ in English + + diff --git a/results/classifier/105/instruction/2226 b/results/classifier/105/instruction/2226 new file mode 100644 index 00000000..c890b8fe --- /dev/null +++ b/results/classifier/105/instruction/2226 @@ -0,0 +1,69 @@ +instruction: 0.881 +boot: 0.855 +socket: 0.855 +graphic: 0.852 +vnc: 0.795 +device: 0.777 +assembly: 0.722 +network: 0.683 +semantic: 0.609 +KVM: 0.509 +mistranslation: 0.494 +other: 0.426 + +arm HSTR trap settings routed to EL1 instead of EL2 +Description of problem: +ARM's HSTR register is used to trap CP15 access from EL1/0. qemu's implementation seems to be inconsistent with ARM's documentation. + +Take the system register VBAR for example, the following pseudo code is grabbed from ARM DDI 0487J.a ID042523 G8-10651, which is the logics behind when reading VBAR. +``` +if PSTATE.EL == EL0 then + UNDEFINED; +elsif PSTATE.EL == EL1 then + if EL2Enabled() && !ELUsingAArch32(EL2) && HSTR_EL2.T12 == '1' then + AArch64.AArch32SystemAccessTrap(EL2, 0x03); + elsif EL2Enabled() && ELUsingAArch32(EL2) && HSTR.T12 == '1' then + AArch32.TakeHypTrapException(0x03); + elsif HaveEL(EL3) && ELUsingAArch32(EL3) then + R[t] = VBAR_NS; + else + R[t] = VBAR; +elsif PSTATE.EL == EL2 then + if HaveEL(EL3) && ELUsingAArch32(EL3) then + R[t] = VBAR_NS; + else + R[t] = VBAR; +elsif PSTATE.EL == EL3 then + if SCR.NS == '0' then + R[t] = VBAR_S; + else + R[t] = VBAR_NS; +``` + +The main logics in my attached test program are: +1. Setting EL2 and EL1's exception table +2. Set HSTR.T12 +3. ERET to EL1, and read VBAR from EL1 + +As the document mentions, when CPU running on EL1 && HSTR.T12 is set, HypTrapException 0x3 should be taken, which is EL2. But the test program shows, on such circumstances, CPU is being routed to EL1's undefined exception. +Steps to reproduce: +1. Clone this repo https://github.com/roolrz/reproduce-qemu-arm-hstr-issue +2. Use make to build the test program +3. Use following command to launch it +``` +qemu-system-arm \ + -nographic \ + -cpu cortex-a7 \ + -M virt,virtualization=on \ + -m 1G \ + -kernel el2.elf +``` +4. The following message is printed by the program, problem reproduced +``` +EL2 Booted +Jumping to el1 +el1 reached, triggering trap +EL1 undefined sync triggered +``` +Additional information: + diff --git a/results/classifier/105/instruction/2248 b/results/classifier/105/instruction/2248 new file mode 100644 index 00000000..ae3a6196 --- /dev/null +++ b/results/classifier/105/instruction/2248 @@ -0,0 +1,49 @@ +instruction: 0.883 +graphic: 0.837 +assembly: 0.815 +device: 0.776 +vnc: 0.746 +network: 0.743 +socket: 0.741 +other: 0.592 +boot: 0.547 +semantic: 0.539 +KVM: 0.475 +mistranslation: 0.466 + +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/105/instruction/2250 b/results/classifier/105/instruction/2250 new file mode 100644 index 00000000..308cc99f --- /dev/null +++ b/results/classifier/105/instruction/2250 @@ -0,0 +1,57 @@ +instruction: 0.927 +mistranslation: 0.876 +device: 0.836 +KVM: 0.821 +other: 0.792 +graphic: 0.776 +semantic: 0.760 +vnc: 0.733 +network: 0.711 +socket: 0.675 +boot: 0.562 +assembly: 0.492 + +FEAT_RME: NS EL1/0 Address Translation from EL3 fails +Description of problem: +I'm playing around with the QEMU RME Stack (TF-A, TF-RMM, Linux/KVM) for a research project. +For this I want to access some virtual normal world memory address from within EL3. +To translate the address to the physical address I use the `AT` instructions (e.g., `ats1e2r`). +If the NW memory is initially mapped in the GPT as `GPT_GPI_ANY`, this works fine, however, if the NW memory is mapped as `GPT_GPI_NS` the address translation fails with the error `0b100101`/GPT on PTW. +However, EL3/Root World should be able to access memory from all PAS, and therefore, if I understand the ARM documentation correctly, should also be able to execute a PTW for an address marked NS in the GPT. +Steps to reproduce: +1. Setup GPT with some memory marked as `GPT_GPI_NS` +2. Forward some NW virtual address from the kernel to EL3 +3. Execute a PTW on this address via the `AT` instructions. +Additional information: +I also took a look into the QEMU source code and potentially found the issue. +When executing a PTW we execute `target/arm/ptw.c:granule_protection_check`. +The function extracts the target page's GPI (`ptw.c:440'): +```c + switch (gpi) { + case 0b0000: /* no access */ + break; + case 0b1111: /* all access */ + return true; + case 0b1000: + case 0b1001: + case 0b1010: + case 0b1011: + if (pspace == (gpi & 3)) { + return true; + } + break; + default: + goto fault_walk; /* reserved */ + } +``` +The if statement checks if the current `pstate` (previously set to `ptw->in_space`) is the same security state as the one contained in the GPI. +If this is not the case, we generate a GPF. +However, I think the code misses the fact, that EL3/Root world can access memory from each PAS, meaning that the if statement should be something like +```c +if (pspace == (gpi & 3) || (pspace == ARMSS_Root)) { + return true; +} +``` +Additionally, as both Secure and Realm World can also access Normal World memory, similar checks should also be added in such cases. + +I have a patch prepared for this, however, I first want to check in if I'm in line with the Arm ARM or if I'm missing something and EL3 is indeed not supposed to execute PTWs for NS memory. diff --git a/results/classifier/105/instruction/2287 b/results/classifier/105/instruction/2287 new file mode 100644 index 00000000..65b3a101 --- /dev/null +++ b/results/classifier/105/instruction/2287 @@ -0,0 +1,42 @@ +instruction: 0.772 +other: 0.762 +semantic: 0.752 +device: 0.720 +mistranslation: 0.717 +assembly: 0.696 +vnc: 0.691 +graphic: 0.691 +KVM: 0.681 +boot: 0.666 +socket: 0.617 +network: 0.616 + +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/105/instruction/2300 b/results/classifier/105/instruction/2300 new file mode 100644 index 00000000..d1fab193 --- /dev/null +++ b/results/classifier/105/instruction/2300 @@ -0,0 +1,14 @@ +instruction: 0.725 +device: 0.644 +graphic: 0.473 +mistranslation: 0.400 +other: 0.377 +assembly: 0.317 +semantic: 0.312 +KVM: 0.119 +network: 0.104 +socket: 0.055 +boot: 0.049 +vnc: 0.048 + +Unintialized variable in double_cpdo.c diff --git a/results/classifier/105/instruction/2302 b/results/classifier/105/instruction/2302 new file mode 100644 index 00000000..dd607123 --- /dev/null +++ b/results/classifier/105/instruction/2302 @@ -0,0 +1,38 @@ +instruction: 0.900 +graphic: 0.787 +device: 0.692 +assembly: 0.569 +socket: 0.543 +semantic: 0.466 +vnc: 0.348 +network: 0.348 +mistranslation: 0.316 +other: 0.274 +boot: 0.240 +KVM: 0.084 + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/105/instruction/2317 b/results/classifier/105/instruction/2317 new file mode 100644 index 00000000..0acfd457 --- /dev/null +++ b/results/classifier/105/instruction/2317 @@ -0,0 +1,51 @@ +instruction: 0.951 +device: 0.841 +socket: 0.672 +graphic: 0.665 +vnc: 0.650 +network: 0.620 +semantic: 0.613 +assembly: 0.550 +boot: 0.545 +mistranslation: 0.480 +other: 0.332 +KVM: 0.048 + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/105/instruction/2318 b/results/classifier/105/instruction/2318 new file mode 100644 index 00000000..3defce0d --- /dev/null +++ b/results/classifier/105/instruction/2318 @@ -0,0 +1,47 @@ +instruction: 0.871 +device: 0.679 +graphic: 0.495 +assembly: 0.485 +vnc: 0.479 +semantic: 0.460 +boot: 0.291 +socket: 0.281 +network: 0.239 +other: 0.133 +mistranslation: 0.100 +KVM: 0.006 + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/105/instruction/232 b/results/classifier/105/instruction/232 new file mode 100644 index 00000000..f1f862d0 --- /dev/null +++ b/results/classifier/105/instruction/232 @@ -0,0 +1,14 @@ +instruction: 0.846 +device: 0.846 +network: 0.566 +socket: 0.518 +graphic: 0.368 +vnc: 0.197 +other: 0.127 +semantic: 0.109 +mistranslation: 0.064 +boot: 0.063 +KVM: 0.016 +assembly: 0.010 + +I/O write make QXL abort in qxl_set_mode() diff --git a/results/classifier/105/instruction/2328 b/results/classifier/105/instruction/2328 new file mode 100644 index 00000000..eec5f0b6 --- /dev/null +++ b/results/classifier/105/instruction/2328 @@ -0,0 +1,14 @@ +instruction: 0.843 +network: 0.500 +device: 0.499 +socket: 0.471 +boot: 0.362 +vnc: 0.312 +KVM: 0.306 +graphic: 0.249 +semantic: 0.219 +mistranslation: 0.192 +assembly: 0.190 +other: 0.127 + +sha1.c:161:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 diff --git a/results/classifier/105/instruction/2342 b/results/classifier/105/instruction/2342 new file mode 100644 index 00000000..0aa83e75 --- /dev/null +++ b/results/classifier/105/instruction/2342 @@ -0,0 +1,14 @@ +instruction: 0.843 +device: 0.608 +semantic: 0.474 +graphic: 0.387 +mistranslation: 0.344 +other: 0.235 +vnc: 0.216 +network: 0.135 +assembly: 0.123 +socket: 0.110 +boot: 0.091 +KVM: 0.021 + +DEREF_OF_NULL.RET in qdev-clock.c diff --git a/results/classifier/105/instruction/2377 b/results/classifier/105/instruction/2377 new file mode 100644 index 00000000..3270de41 --- /dev/null +++ b/results/classifier/105/instruction/2377 @@ -0,0 +1,38 @@ +instruction: 0.929 +graphic: 0.873 +device: 0.844 +other: 0.795 +semantic: 0.784 +mistranslation: 0.503 +boot: 0.476 +network: 0.457 +socket: 0.360 +vnc: 0.303 +assembly: 0.095 +KVM: 0.073 + +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/105/instruction/2386 b/results/classifier/105/instruction/2386 new file mode 100644 index 00000000..96e88af3 --- /dev/null +++ b/results/classifier/105/instruction/2386 @@ -0,0 +1,56 @@ +instruction: 0.967 +graphic: 0.899 +socket: 0.812 +device: 0.808 +vnc: 0.803 +network: 0.759 +assembly: 0.688 +mistranslation: 0.640 +semantic: 0.624 +other: 0.616 +boot: 0.615 +KVM: 0.565 + +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/105/instruction/2388 b/results/classifier/105/instruction/2388 new file mode 100644 index 00000000..2c8780f7 --- /dev/null +++ b/results/classifier/105/instruction/2388 @@ -0,0 +1,30 @@ +instruction: 0.921 +graphic: 0.784 +device: 0.653 +semantic: 0.477 +boot: 0.312 +vnc: 0.306 +mistranslation: 0.236 +socket: 0.188 +network: 0.152 +other: 0.056 +assembly: 0.022 +KVM: 0.006 + +NVMe SQ processing gets stuck when IO queue size is small (for example 4) +Steps to reproduce: +1. Get OSv repo with the NVMe driver and build OSv with the 'Hello World' example: +``` +git clone https://github.com/wkozaczuk/osv.git +cd osv +git checkout nvme_refined +git submodule update --init --recursive +./scripts/setup.py +./scripts/build image=native-example fs=zfs -j$(nproc) +``` +2. Run OSv with NVme on and point to your version of QEMU built with tracing enabled: +``` +./scripts/run.py --qemu-path /home/wkozaczuk/projects/qemu/build/qemu-system-x86_64 --nics=0 --nvme -c 1 --pass-arg "--trace pci_nvme_*" +``` +Additional information: +I am adding both full QEMU logs with NVMe tracing enabled and diff of my changes to QEMU code to add extra logging. diff --git a/results/classifier/105/instruction/2390 b/results/classifier/105/instruction/2390 new file mode 100644 index 00000000..eda35d2d --- /dev/null +++ b/results/classifier/105/instruction/2390 @@ -0,0 +1,76 @@ +instruction: 0.873 +graphic: 0.869 +other: 0.867 +socket: 0.840 +boot: 0.803 +device: 0.794 +network: 0.766 +vnc: 0.720 +mistranslation: 0.564 +assembly: 0.553 +semantic: 0.532 +KVM: 0.406 + +linux-user: Qemu handles `getsockopt` with NULL `optval` incorrectly +Description of problem: +In short call to `getsockopt(_, SOL_TCP, TCP_KEEPIDLE, NULL, _)` behaves differently on RISC-V Qemu than on x64 Linux. +On Linux syscall returns 0, but on Qemu it fails with `"Bad address"`. +Apparently Qemu `getsockopt` implementation is more conservative about NULL `optval` argument than kernel implementation. However man permits passing NULL [link](https://man7.org/linux/man-pages/man2/setsockopt.2.html): + +> For getsockopt(), optlen is a value-result argument, initially + containing the size of the buffer pointed to by optval, and + modified on return to indicate the actual size of the value + returned. **If no option value is to be supplied** or returned, + **optval may be NULL.**" + +For me it sounds like accepting NULL without error (and x64 confirms that interpretation). +Steps to reproduce: +1. Use below toy program `getsockopt.c` and compile it without optimizations like: +``` + gcc -Wall -W -std=gnu11 -pedantic getsockopt.c -o getsockopt +``` + +``` +#include <stdlib.h> +#include <unistd.h> +#include <errno.h> +#include <stdio.h> +#include <netinet/in.h> +#include <sys/socket.h> +#include <netinet/tcp.h> + +static void fail_on_error(int error, const char *msg) { + if (error < 0) { + perror(msg); + exit(errno); + } +} + +int main(int argc, char **argv) { + int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP); + fail_on_error(socketfd, "socket error"); + uint8_t *option_value = NULL; + int32_t len = 0; + int32_t *option_len = &len; + socklen_t opt_len = (socklen_t)*option_len; + int status = getsockopt(socketfd, SOL_TCP, TCP_KEEPIDLE, option_value, &opt_len); + fail_on_error(status, "getsockopt error"); + return 0; +} +``` + + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@57646f544f3a:/runtime/programs# ./getsockopt-x64 +root@57646f544f3a:/runtime/programs# ./getsockopt-riscv +getsockopt error: Bad address +``` +Additional information: +I don't think issue is platform specific assuming Qemu `getsockopt` implementation that is actually running is here: +[link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2522) + +Looking at sources, I'm not sure why Qemu can't simply forward everything to kernel space +instead doing extra sanity checks together with `optval` dereference attempt that eventually fails in one of `put_user*_` function: [link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2753) + +Anyway, I think that interpretation of man quote is rather straightforward and Qemu `getsockopt` implementation should follow it. diff --git a/results/classifier/105/instruction/2397 b/results/classifier/105/instruction/2397 new file mode 100644 index 00000000..ad2b4624 --- /dev/null +++ b/results/classifier/105/instruction/2397 @@ -0,0 +1,14 @@ +instruction: 0.725 +device: 0.585 +mistranslation: 0.381 +network: 0.373 +semantic: 0.314 +graphic: 0.254 +vnc: 0.229 +boot: 0.194 +socket: 0.108 +assembly: 0.102 +other: 0.093 +KVM: 0.067 + +Restrict qemu_file_set_error_obj() to migration/ diff --git a/results/classifier/105/instruction/2402 b/results/classifier/105/instruction/2402 new file mode 100644 index 00000000..1bbe8c49 --- /dev/null +++ b/results/classifier/105/instruction/2402 @@ -0,0 +1,37 @@ +instruction: 0.687 +device: 0.651 +boot: 0.586 +vnc: 0.581 +graphic: 0.538 +socket: 0.453 +other: 0.379 +semantic: 0.369 +mistranslation: 0.299 +network: 0.195 +KVM: 0.130 +assembly: 0.122 + +WHPX accelerator run with edk2 EFI fails to process the reboot signal from guest OS +Description of problem: +Qemu freezes any time WHPX-accelerated guest Windows 11 sends a reboot signal to Qemu while running on edk2 EFI. At rare cases, Qemu errors out with `qemu: WHPX: Unexpected VP exit code 4` +Steps to reproduce: +1. Grab Windows 11 23H2 ISO from https://www.microsoft.com/en-Us/software-download/windows11 using either Media Creation Tool or directly and save it under C:\\windows11_23H2.iso +2. Download QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe and install it into C:\\Program Files\\qemu +3. Make one merged EFI file from two ones bundled in QEMU 9.0 (merged EFI is the only working option for edk2 EFI on windows host): `cd /d C:\Program Files\qemu\share` + +`copy /B edk2-i386-vars.fd + edk2-x86_64-code.fd edk2-x86_64.fd` + +4. Run this command: + +`qemu-system-x86_64.exe -accel whpx -bios share\edk2-x86_64.fd -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom C:\windows11_23H2.iso` + +5. Press any key once you see "Press any key to boot from CD..." and wait until Windows Setup suggests to opt for language and currency. +6. Click red "X" close button inside Windows Setup and confirm your choice when Windows Setup asks you to. + +Windows Setup sends a reboot signal to the underlying hardware and Qemu freezes. +Additional information: +If `-bios share\edk2-x86_64.fd` switch is omitted, this command works ok: + +`qemu-system-x86_64 -accel whpx -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -machine q35 -m 4096 -cdrom D:\originalWindows11_23H2.iso` + +This bug seems to be closely related to this one: https://gitlab.com/qemu-project/qemu/-/issues/2042 - Not able to reboot Linux guest on Windows host diff --git a/results/classifier/105/instruction/2419 b/results/classifier/105/instruction/2419 new file mode 100644 index 00000000..9f67ffef --- /dev/null +++ b/results/classifier/105/instruction/2419 @@ -0,0 +1,31 @@ +instruction: 0.733 +device: 0.662 +graphic: 0.619 +semantic: 0.503 +mistranslation: 0.492 +other: 0.305 +network: 0.294 +vnc: 0.286 +socket: 0.282 +boot: 0.232 +assembly: 0.166 +KVM: 0.040 + +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/105/instruction/2423 b/results/classifier/105/instruction/2423 new file mode 100644 index 00000000..64c2f36c --- /dev/null +++ b/results/classifier/105/instruction/2423 @@ -0,0 +1,47 @@ +instruction: 0.874 +graphic: 0.868 +other: 0.796 +device: 0.779 +semantic: 0.674 +vnc: 0.508 +socket: 0.498 +network: 0.492 +boot: 0.448 +mistranslation: 0.400 +KVM: 0.264 +assembly: 0.145 + +`qemu -serial stdio` leaves stdout in non-blocking mode +Description of problem: +When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout. +Steps to reproduce: +Run the following script: + +``` +#!/usr/bin/env bash + +qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio & +PID="$!" +sleep 5 +kill "$PID" +wait "$PID" +echo "EXITING $?" + +sleep 5 +seq 1 400000 +``` + +The seq command will be interrupted prematurely: + +``` +... +5143 +5144 +5145⏎ wResource temporarily unavailable +write: Resource temporarily unavailable +write: Resource temporarily unavailable +``` + +When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600). +Additional information: +Expect a patch from me soon. diff --git a/results/classifier/105/instruction/2452 b/results/classifier/105/instruction/2452 new file mode 100644 index 00000000..e57913b0 --- /dev/null +++ b/results/classifier/105/instruction/2452 @@ -0,0 +1,14 @@ +instruction: 0.899 +device: 0.890 +network: 0.421 +graphic: 0.321 +vnc: 0.310 +boot: 0.288 +semantic: 0.165 +socket: 0.147 +assembly: 0.135 +mistranslation: 0.081 +other: 0.019 +KVM: 0.000 + +memory allocation for AMDVIIOTLBEntry in amdvi_update_iotlb() diff --git a/results/classifier/105/instruction/246 b/results/classifier/105/instruction/246 new file mode 100644 index 00000000..7ee54592 --- /dev/null +++ b/results/classifier/105/instruction/246 @@ -0,0 +1,14 @@ +instruction: 0.691 +graphic: 0.683 +assembly: 0.613 +device: 0.561 +network: 0.367 +mistranslation: 0.249 +KVM: 0.216 +semantic: 0.205 +socket: 0.192 +vnc: 0.180 +other: 0.137 +boot: 0.019 + +Build fails with 64 bits time_t diff --git a/results/classifier/105/instruction/2466 b/results/classifier/105/instruction/2466 new file mode 100644 index 00000000..e13bb7f4 --- /dev/null +++ b/results/classifier/105/instruction/2466 @@ -0,0 +1,37 @@ +instruction: 0.900 +other: 0.803 +graphic: 0.794 +semantic: 0.757 +assembly: 0.709 +device: 0.665 +vnc: 0.645 +network: 0.592 +mistranslation: 0.473 +socket: 0.465 +KVM: 0.463 +boot: 0.459 + +I'm not sure. But I Think I could cause the err(include/qemu/queue.h). +Description of problem: +At file "include/qemu/queue.h", Maybe I Think QTAILQ_REMOVE could cause a Error. + +``` +#define QTAILQ_REMOVE(head, elm, field) do { \ + if (((elm)->field.tqe_next) != NULL) \ + (elm)->field.tqe_next->field.tqe_circ.tql_prev = \ + (elm)->field.tqe_circ.tql_prev; \ + else \ + (head)->tqh_circ.tql_prev = (elm)->field.tqe_circ.tql_prev; \ + (elm)->field.tqe_circ.tql_prev->tql_next = (elm)->field.tqe_next; \ + (elm)->field.tqe_circ.tql_prev = NULL; \ + (elm)->field.tqe_circ.tql_next = NULL; \ + (elm)->field.tqe_next = NULL; \ +} while (/*CONSTCOND*/0) +``` +If the length of the que is one, line 7 cause a segmentation fault. +Steps to reproduce: +1. Create a Que with QTAILQ_INIT +2. Add one element to que. +3. Remove the element with QTAILQ_REMOVE +Additional information: +queue.h file is located at "inclue/qemu/queue.h" diff --git a/results/classifier/105/instruction/2497 b/results/classifier/105/instruction/2497 new file mode 100644 index 00000000..ccc110c5 --- /dev/null +++ b/results/classifier/105/instruction/2497 @@ -0,0 +1,16 @@ +instruction: 0.895 +device: 0.848 +graphic: 0.685 +semantic: 0.655 +network: 0.531 +boot: 0.293 +socket: 0.291 +assembly: 0.286 +vnc: 0.283 +other: 0.236 +mistranslation: 0.145 +KVM: 0.015 + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/105/instruction/2499 b/results/classifier/105/instruction/2499 new file mode 100644 index 00000000..18531c3e --- /dev/null +++ b/results/classifier/105/instruction/2499 @@ -0,0 +1,43 @@ +instruction: 0.895 +semantic: 0.735 +graphic: 0.664 +device: 0.625 +socket: 0.554 +vnc: 0.546 +network: 0.485 +other: 0.335 +assembly: 0.322 +mistranslation: 0.198 +boot: 0.138 +KVM: 0.120 + +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/105/instruction/2500 b/results/classifier/105/instruction/2500 new file mode 100644 index 00000000..4939d31c --- /dev/null +++ b/results/classifier/105/instruction/2500 @@ -0,0 +1,17 @@ +instruction: 0.946 +graphic: 0.818 +device: 0.817 +semantic: 0.810 +assembly: 0.807 +mistranslation: 0.739 +network: 0.738 +other: 0.715 +socket: 0.510 +boot: 0.257 +vnc: 0.154 +KVM: 0.115 + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/105/instruction/2501 b/results/classifier/105/instruction/2501 new file mode 100644 index 00000000..13c4f128 --- /dev/null +++ b/results/classifier/105/instruction/2501 @@ -0,0 +1,14 @@ +instruction: 0.453 +device: 0.425 +semantic: 0.298 +graphic: 0.224 +mistranslation: 0.196 +network: 0.077 +assembly: 0.038 +other: 0.024 +boot: 0.023 +vnc: 0.020 +socket: 0.007 +KVM: 0.004 + +compile qemu as a shared library diff --git a/results/classifier/105/instruction/2506 b/results/classifier/105/instruction/2506 new file mode 100644 index 00000000..bc2b81ab --- /dev/null +++ b/results/classifier/105/instruction/2506 @@ -0,0 +1,71 @@ +instruction: 0.936 +graphic: 0.910 +device: 0.822 +network: 0.784 +vnc: 0.723 +socket: 0.668 +KVM: 0.656 +semantic: 0.641 +boot: 0.565 +mistranslation: 0.538 +assembly: 0.498 +other: 0.452 + +LC_RPATH stripped despite setting INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE +Description of problem: +When I try to run qemu, I get the following output: +> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib +> Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64 +> Reason: no LC_RPATH's found +Steps to reproduce: +If the qemu-9.0.2 folder is present, remove it: +``` +$ rm -rf qemu-9.0.2 +``` +Create the source folder: +``` +$ tar xzf qemu-9.0.2.tar.xz +$ cd qemu-9.0.2 +``` + +Make sure the following environment variables are set: +``` +$ export CC=clang +$ export LDFLAGS="-rpath $HOME/local/lib" +$ export INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE +``` + +Configure as follows: +``` +$ ./configure --prefix=$HOME/local --disable-sdl --enable-slirp --enable-fdt=internal --enable-spice +``` + +Build +``` +$ make -j 10 +``` + +Note there are a large number of linker warnings like this: +> ld: warning: duplicate -rpath '/Users/mj/local/lib' ignored + +Execute this: +``` +$ otool -l build/qemu-system-aarch64 | grep LC_RPATH -A2 +``` + +See this output +> cmd LC_RPATH +> cmdsize 32 +> path /Users/mj/local/lib (offset 12) + +Change directory to $HOME/local/bin & execute: +``` +$ otool -l qemu-system-aarch64 | grep LC_RPATH -A2 +``` + +The output is now empty - the LC_RPATH has been stripped by the install. This results in the failure to execute the resulting binary. Note, I tried using install_name_tool to add the RPATH, but it warned me this changed the signature of the file, and it would not run. + +Executing qemu-system-aarch64 produces the following: +> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib +> Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64 +> Reason: no LC_RPATH's found diff --git a/results/classifier/105/instruction/2522 b/results/classifier/105/instruction/2522 new file mode 100644 index 00000000..288cc7d0 --- /dev/null +++ b/results/classifier/105/instruction/2522 @@ -0,0 +1,30 @@ +instruction: 0.813 +device: 0.745 +vnc: 0.721 +graphic: 0.690 +network: 0.573 +semantic: 0.486 +socket: 0.383 +boot: 0.366 +KVM: 0.300 +other: 0.150 +assembly: 0.109 +mistranslation: 0.039 + +[9.0.2] PPC: incorrect name filed in vmstate_tlbemb_entry, broken snapshot replay +Description of problem: +Fix commit: a90db15 +When using the Record/replay feature on ppc emulation (qemu-system-ppc binary), an error occurred during loading: +``` +qemu-system-ppc: Missing section footer for cpu +qemu-system-ppc: Error -22 while loading VM state +qemu-system-ppc: Could not load snapshot for icount replay +``` +I found a typo that led to this error + +more info in https://lists.nongnu.org/archive/html/qemu-devel/2024-08/msg02951.html +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: +Use this example [ppc-e500.zip](/uploads/04e47528c74ed9a564c212a17c480a1d/ppc-e500.zip) diff --git a/results/classifier/105/instruction/2525 b/results/classifier/105/instruction/2525 new file mode 100644 index 00000000..d1711fbe --- /dev/null +++ b/results/classifier/105/instruction/2525 @@ -0,0 +1,14 @@ +instruction: 0.747 +device: 0.733 +network: 0.634 +graphic: 0.381 +boot: 0.308 +vnc: 0.246 +socket: 0.179 +semantic: 0.178 +assembly: 0.124 +mistranslation: 0.076 +KVM: 0.040 +other: 0.022 + +bFLT triggers accel/tcg/user-exec.c:505: page_set_flags: Assertion `have_mmap_lock()' failed. diff --git a/results/classifier/105/instruction/2531 b/results/classifier/105/instruction/2531 new file mode 100644 index 00000000..b6cbcfa8 --- /dev/null +++ b/results/classifier/105/instruction/2531 @@ -0,0 +1,73 @@ +instruction: 0.919 +device: 0.898 +graphic: 0.729 +boot: 0.699 +vnc: 0.681 +socket: 0.656 +semantic: 0.625 +other: 0.534 +network: 0.501 +KVM: 0.353 +mistranslation: 0.347 +assembly: 0.191 + +QEMU internal SIGSEGV when creating an x86_64 Debian chroot from an aarch64 host. +Description of problem: +When I try to create a x86_64 Debian chroot using debootstrap from an aarch64 host system, QEMU segfaults causing the process to fail. +Steps to reproduce: +1. Run `sudo apt install debootstrap qemu-user-static binfmt-support` +2. Run `sudo debootstrap --arch amd64 bookworm debian_chroot http://deb.debian.org/debian/` +Additional information: +End of deboostrap output: +``` +I: Configuring dash... +I: Configuring libpam-modules:amd64... +I: Configuring grep... +I: Configuring perl-base... +I: Configuring gzip... +I: Configuring passwd... +I: Configuring login... +I: Configuring apt... +I: Configuring adduser... +I: Configuring libc-bin... +W: Failure while configuring required packages. +W: See /home/allen/debian_chroot/debootstrap/debootstrap.log for details (possibly the package passwd is at fault) +``` + +End of debootstrap log: +``` +$ tail /home/allen/debian_chroot/debootstrap/debootstrap.log -n30 +Setting up grep (3.8-5) ... +Setting up perl-base (5.36.0-7+deb12u1) ... +Setting up gzip (1.12-1) ... +Setting up passwd (1:4.13+dfsg1-1+b1) ... +x86_64-binfmt-P: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +groupadd: group 'shadow' already exists +Group ID 42 has been allocated for the shadow group. You have either +used 42 yourself or created a shadow group with a different ID. +Please correct this problem and reconfigure with dpkg --configure passwd''. + +Note that both user and group IDs in the range 0-99 are globally +allocated by the Debian project and must be the same on every Debian +system. +dpkg: error processing package passwd (--configure): + installed passwd package post-installation script subprocess returned error exit status 1 +Setting up libpam-runtime (1.5.2-6+deb12u1) ... +Setting up login (1:4.13+dfsg1-1+b1) ... +dpkg: apt: dependency problems, but configuring anyway as you requested: + apt depends on adduser. + +Setting up apt (2.6.1) ... +dpkg: adduser: dependency problems, but configuring anyway as you requested: + adduser depends on passwd; however: + Package passwd is not configured yet. + +Setting up adduser (3.134) ... +Processing triggers for libc-bin (2.36-9+deb12u7) ... +Errors were encountered while processing: + passwd +``` + +Full debootstrap log: +[debootstrap.log](/uploads/4eb24abd98a647e08bd03deea897b9dd/debootstrap.log) diff --git a/results/classifier/105/instruction/2537 b/results/classifier/105/instruction/2537 new file mode 100644 index 00000000..e73428f7 --- /dev/null +++ b/results/classifier/105/instruction/2537 @@ -0,0 +1,14 @@ +instruction: 0.932 +device: 0.755 +assembly: 0.591 +vnc: 0.492 +network: 0.476 +semantic: 0.458 +graphic: 0.438 +mistranslation: 0.397 +boot: 0.301 +socket: 0.206 +other: 0.165 +KVM: 0.138 + +Hang in Cocoa_SetWindowSize() diff --git a/results/classifier/105/instruction/2554 b/results/classifier/105/instruction/2554 new file mode 100644 index 00000000..d4a8ecb4 --- /dev/null +++ b/results/classifier/105/instruction/2554 @@ -0,0 +1,24 @@ +instruction: 0.956 +graphic: 0.801 +device: 0.707 +mistranslation: 0.695 +vnc: 0.643 +network: 0.564 +semantic: 0.519 +assembly: 0.432 +boot: 0.382 +socket: 0.368 +KVM: 0.182 +other: 0.170 + +qemu-system-arm: thumb2: vector table branch instruction not followed +Description of problem: +When an undefined instruction is hit and causes an exception that causes a jump to the undef vector at 0x04; translation of the branch instruction found there appears to fail since instead of branching to the handler it steps to the next instruction - the next entry in the vector table, translates that, and on stepping once again moves to the next entry in the vector table. Eventually it steps out of the table and (re)enters the _start subroutine pointed to by vector 0x0. +Steps to reproduce: +This is related to issue #2542 in as much as I am hunting down failures in the picolibc 1.8.6 test suite on Debian. After fixing issues such as the failure to enable the MMU and some others via incorporating upstream commits I'm left with 10 tests, all for exception handling, that result in meson (build system) TIMEOUT instead of EXPECTEDFAIL. All of these tests should fail instantly and cause Qemu to exit but it continues - apparently spinning in an endless loop as described above until meson kills it. + +Creating a small reproducer has proved challenging and nigh impossible (for me) - even identifying the crux as described here has taken 4 days. However with the help of `qemu-system-arm -d in_asm,op,out_asm ...` and `gdb-multiarch` I believe I may have produced a focused report that will help figure this out. + +# +Additional information: +Since this is hard to debug I can give remote ssh access via `tmate` to directly control the debug session if necessary. diff --git a/results/classifier/105/instruction/2563 b/results/classifier/105/instruction/2563 new file mode 100644 index 00000000..7b73d0de --- /dev/null +++ b/results/classifier/105/instruction/2563 @@ -0,0 +1,223 @@ +instruction: 0.886 +other: 0.883 +vnc: 0.881 +graphic: 0.881 +network: 0.880 +boot: 0.879 +socket: 0.854 +device: 0.837 +semantic: 0.820 +mistranslation: 0.817 +KVM: 0.816 +assembly: 0.793 + +W64 build referenced to by https://www.qemu.org/download/#windows fails to run with GTK and 3D but cross-build for W64 works ok with GTK and 3d +Description of problem: +Qemu W64 build referenced to by https://www.qemu.org/download/#windows (https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe) crashes with aforementioned command line, leaving 0xc0000005 exception in Windows event log. But a custom cross-compiled build at least boots into default qemu BIOS. See steps below to cross-compile qemu with GTK + OpenGL +VirGL support. +Steps to reproduce: +1. `wget https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe`, install it, run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch immediate qemu crash. + 2. Prepare cross-compilation build of qemu 9.1.0 using following steps: + 3. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. + 4. `wget https://download.qemu.org/qemu-9.1.0.tar.xz`\ + `tar xvJf qemu-9.1.0.tar.xz`\ + `cd qemu-9.1.0` + 5. Run `sudo yum install git meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-glib2 mingw64-pkg-config mingw64-pixman mingw64-gtk3 mingw64-SDL2 mingw64-libepoxy mingw64-librsvg2` in virtual Fedora. `mingw64-librsvg2` is optional, see step #14 + 6. `git clone https://gitlab.freedesktop.org/slirp/libslirp.git` (e61dbd45 as of 04 August 2024) `git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git` (3d82ed86 as of 03 September 2024) + 7. create file x86_64-w64-mingw32.txt in qemu-9.1.0 directory with the content as follows:\ + `[binaries]`\ + `c = '/usr/bin/x86_64-w64-mingw32-gcc'`\ + `cpp = '/usr/bin/x86_64-w64-mingw32-g++'`\ + `ar = '/usr/bin/x86_64-w64-mingw32-ar'`\ + `strip = '/usr/bin/x86_64-w64-mingw32-strip'`\ + `pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'`\ + `exe_wrapper = 'wine'`\ + \ + `[host_machine]`\ + `system = 'windows'`\ + `cpu_family = 'x86_64'`\ + `cpu = 'i686'`\ + `endian = 'little'` + 8. Make a directory to which QEMU dependencies will be installed after compilation from git: `export CROSS_QEMU_DEPS="/home/cross-qemu-deps"`\ + `sudo mkdir -p $CROSS_QEMU_DEPS` + 9. Install libslirp so that future qemu binaries can have internet access via -netdev user\ + ` cd libslirp`\ + \ + ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\ + ` meson compile -C build-mingw`\ + ` cd build-mingw`\ + ` ninja install` +10. Install virgl to have 3D hardware acceleration\ + ` cd ../../`\ + ` cd virglrenderer`\ + \ + ` meson setup --cross-file ../x86_64-w64-mingw32.txt --prefix "$CROSS_QEMU_DEPS" build-mingw/`\ + ` meson compile -C build-mingw`\ + ` cd build-mingw`\ + ` ninja install` +11. Set three environment variables for cross-compilation: + + `sudo find / -type f -name '*.pc'` and make sure all mingw \*.pc files live in `/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig/` and `/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/`. Correct these paths in PKG_CONFIG_PATH if you see they were altered by mingw or package contributors.\ + \ + `export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/:$PKG_CONFIG_PATH"` + + \ + `export PKG_CONFIG_LIBDIR="${CROSS_QEMU_DEPS}/lib/pkgconfig/:$PKG_CONFIG_LIBDIR"` + + \ + `export PKG_CONFIG_SYSROOT_DIR=""` +12. <span dir="">Configure Qemu makefile:</span> + + `cd ../../` + + `./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-opengl --enable-virglrenderer --enable-slirp --enable-debug` + + and make sure you see this in the output of configure: + + `Compilation`\ + `host CPU : x86_64`\ + `host endianness : little`\ + `C compiler : x86_64-w64-mingw32-gcc -m64`\ + `Host C compiler : cc` + + and this one: + + `Checking whether type "struct virgl_renderer_resource_info_ext" has member "d3d_tex2d" with dependency virglrenderer: YES` +13. Cross-compile qemu: `` make -j`nproc` `` +14. \[optional step to get rid of "**Gtk-WARNING \*\*: 19:22:02.461: Could not load a pixbuf**"\] + + **Copy gdk-pixbuf-query-loaders.exe** from `/usr/x86_64-w64-mingw32/sys-root/mingw/bin/`\ + to\ + `./qemu-9.1.0/build/qemu-bundle/qemu`**\ + \ + `mkdir -p ./qemu-9.1.0/build/qemu-bundle/qemu/lib`\ + \ + copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/lib/gdk-pixbuf-2.0** to `./qemu-9.1.0/build/qemu-bundle/qemu/lib` + + **`mkdir -p ./qemu-9.1.0/build/qemu-bundle/qemu/share`**\ + \ + **copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/share/icons** to `./qemu-9.1.0/build/qemu-bundle/qemu/share` + + **copy recursively /usr/x86_64-w64-mingw32/sys-root/mingw/share/themes** to `./qemu-9.1.0/build/qemu-bundle/qemu/share` + + Run `gdk-pixbuf-query-loaders.exe --update-cache` on host right before step 17. +15. Copy all dll files from + + `/usr/x86_64-w64-mingw32/sys-root/mingw/bin/`\ + to\ + `./qemu-9.1.0/build/qemu-bundle/`**`qemu`** + + Copy libvirglrenderer-1.dll and libslirp-0.dll from `$CROSS_QEMU_DEPS` directory exported above to + + `./qemu-9.1.0/build/qemu-bundle/`**`qemu`** +16. Copy this **`qemu`** folder from the previous step to Windows machine using ssh or whatever else\ + E.g. by doing\ + ` sudo yum install openssh-server`\ + ` sudo systemctl start sshd`\ + ` sudo systemctl status sshd`\ + on guest OS (provided you have launched guest Fedora qemu with `-nic user,hostfwd=tcp::8888-:22` command line parameter for ssh) + + and then + + `scp.exe -P 8888 -r virtual_machine_user@127.0.0.1:/home/virtual_machine_user/qemu-9.1.0/build/qemu-bundle/qemu C:\downloads\qemu`\ + on host OS +17. `cd` to that `qemu` folder and run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch qemu booting into BIOS. + +<details> +<summary>Previous version</summary> + +1\. \`wget https://qemu.weilnetz.de/w64/qemu-w64-setup-20240903.exe\\\\\\\\\\\\\\\`, install it, run \`qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl\` and watch immediate qemu crash. 2. Prepare cross-compilation build of qemu 9.1.0 using following steps: 3. Download official Fedora workstation 40 x86_64 ISO and install it to a virtual disk and boot that disk. 4. Run \`sudo yum install meson ninja-build python3-sphinx python3-sphinx_rtd_theme gcc mingw64-gcc mingw64-glib2 mingw64-pkg-config mingw64-pixman mingw64-gtk3 mingw64-SDL2 mingw64-libepoxy\` in virtual Fedora. 5. \`wget https://download.qemu.org/qemu-9.1.0.tar.xz\\\\\\\\\\\\\\\\\\\\\\\` + +``` +`tar xvJf qemu-9.1.0.tar.xz`\ +`cd qemu-9.1.0` +``` + + 6. `git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git` (3d82ed86 as of 03 September 2024)\ + `cd virglrenderer` + 7. create file x86_64-w64-mingw32.txt in virglrenderer directory with the content as follows:\ + `[binaries]`\ + `c = '/usr/bin/x86_64-w64-mingw32-gcc'`\ + `cpp = '/usr/bin/x86_64-w64-mingw32-g++'`\ + `ar = '/usr/bin/x86_64-w64-mingw32-ar'`\ + `strip = '/usr/bin/x86_64-w64-mingw32-strip'`\ + `pkg-config = '/usr/bin/x86_64-w64-mingw32-pkg-config'`\ + `exe_wrapper = 'wine'`\ + \ + `[host_machine]`\ + `system = 'windows'`\ + `cpu_family = 'x86_64'`\ + `cpu = 'i686'`\ + `endian = 'little'` + 8. Run `meson setup --cross-file x86_64-w64-mingw32.txt build-mingw`\ + `meson compile -C build-mingw`\ + `cd build-mingw`\ + `ninja install` + 9. Set pkgconfig for virglrenderer: `export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/home/your_user/virglrenderer/build-mingw/meson-private`\ + (replace /home/your_user/virglrenderer/build-mingw/meson-private with path containing virglrenderer.pc file from output of `sudo find / -type f -name 'virglrenderer.pc'` command) +10. Run confugure: \ + `cd ../../`\ + `./configure --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-opengl --enable-virglrenderer --enable-debug`\ + \ + and make sure you see this in the output of configure:\ + `Compilation`\ + `host CPU : x86_64`\ + `host endianness : little`\ + `C compiler : x86_64-w64-mingw32-gcc -m64`\ + `Host C compiler : cc`\ + \ + run\ + `export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"` +11. Run this command to see where x86_64-w64-mingw32-pkg-config will look for virglrenderer.h: + + `/usr/bin/x86_64-w64-mingw32-pkg-config --cflags virglrenderer`\ + \> -I/usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/virgl (possible result) +12. Copy folder containing virglrenderer.h to that one to satisfy mingw expectations: + + `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/`\ + `sudo cp -r /usr/local/include/virgl /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` +13. Run search `sudo find / -type f -name 'libvirglrenderer.dll.a'` and satisfy mingw's expectation for libvirglrenderer.dll.a:\ + `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/`\ + `sudo ln -s /usr/local/lib/libvirglrenderer.dll.a /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a` +14. Cross-compile qemu: \ + `make -j4`\ + \* if you see "/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lvirglrenderer: No such file or directory" then most likely Qemu's makefile was confused by libvirglrenderer.dll.a path; check `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` output to find out path of libvirglrenderer.dll.a file it cannot find +15. copy all dll files from \ + /usr/x86_64-w64-mingw32/sys-root/mingw/bin/\ + to\ + ./qemu-9.1.0-rc4/**build** +16. copy libvirglrenderer-1.dll from /usr/local/bin to\ + ./qemu-9.1.0-rc4/**build** +17. copy this **build** folder to Windows machine using ssh or whatever else +18. `cd` to that **build** folder and run `qemu-system-x86_64.exe -display gtk,gl=on -device virtio-vga-gl` and watch qemu booting into BIOS. + +</details> +Additional information: +P.S. Cross-compilation on Fedora build machine for Windows target usually requires installing pre-compiled binary packages along with libslirp and libvirglrenderer from git. Almost all of them include \*.pc files (pkg-config files) needed by mingw to find .h headers and .dll.a library files. Normally, it's not necessarry to add extra include paths using something like CFLAGS="-I/include_headers_path" or LDFLAGS="-L/path_to_dll_a_lib". The commands from above must produce a fully working windows build. But, just in case someone damages packages in Fedora repository or libslirp or virglrenderer in their git, here are some ideas how to fix broken links between files: + +- First, make sure you have enumerated all .pc folders from Fedora repository packages in PKG_CONFIG_PATH= and all .pc folders built from source in PKG_CONFIG_LIBDIR=, as it was shown at Step 11. If you see a message saying something like "virglrenderer.h not found", run this command to see where x86_64-w64-mingw32-pkg-config will look for virglrenderer.h: `/usr/bin/x86_64-w64-mingw32-pkg-config --cflags virglrenderer` + +> \-I/usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/virgl (possible result) + +- Then copy folder containing virglrenderer.h (for example, /usr/local/include/virgl) to that one to satisfy mingw expectations: + + `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` `sudo cp -r /usr/local/include/virgl /usr/x86_64-w64-mingw32/sys-root/mingw/usr/local/include/` +- If you see "/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lvirglrenderer: No such file or directory" then most likely Qemu's makefile was confused by libvirglrenderer.dll.a path; check `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` output to find out path of libvirglrenderer.dll.a file it cannot find +- For example, `/usr/x86_64-w64-mingw32/bin/ld -lvirglrenderer --verbose` shows that build script tries to find .dll.a file under /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a and `find / -type f -name 'libvirglrenderer.dll.a'` shows that file is in /usr/local/lib/libvirglrenderer.dll.a +- Then satisfy mingw's expectation for libvirglrenderer.dll.a: `sudo mkdir -p /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/`\ + `sudo ln -s /usr/local/lib/libvirglrenderer.dll.a /usr/x86_64-w64-mingw32/sys-root/usr/local/lib/libvirglrenderer.dll.a` + +Upd: I was able to refine instructions on how to cross-compile Qemu's dependencies thanks to these references: + +https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/52: + +> PKG_CONFIG_SYSROOT_DIR blindly prepend the sysroot to all paths. I made a MR that add PKG_CONFIG_SYSROOT_MAP to get smarter mapping from pcfiledir-\>sysroot. !7. I generally discontinued the use of PKG_CONFIG_SYSROOT_DIR and switched to merely using PKG_CONFIG_LIBDIR. That way I got absolute paths everyehere which at least was consistent and could be postprocessed if needed. + +https://forum.qt.io/topic/88946/qt5-10-1-cross-compile-configure-errors/9: + +> WARNING: Disabling pkg-config since PKG_CONFIG_LIBDIR is not set and the host's .pc files would be used (even if you set PKG_CONFIG_PATH). Set this variable to the directory that contains target .pc files for pkg-config to function correctly when cross-compiling or use -pkg-config to override this test. + +https://cmake.org/pipermail/cmake/2008-November/025050.html: + +> The situation is as follows: PKG_CONFIG_PATH is searched before PKG_CONFIG_LIBDIR for the desired \*.pc file. (The man page doesn't say which is searched first, but my tests reveal that is the order at least for the present version of pkg-config.) Cross-compiling users should avoid using native paths in PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR. Furthermore, cross-compiling users should always specify PKG_CONFIG_LIBDIR (with or without PKG_CONFIG_PATH) since use of PKG_CONFIG_LIBDIR supresses appending default native paths to whatever is specified in PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR. +> +> In sum, for cross-compilation purposes you should always use PKG_CONFIG_LIBDIR (with or without PKG_CONFIG_PATH) and make sure there are no native paths in it (or in PKG_CONFIG_PATH). If you follow those rules you should get a good cross-compilation result, otherwise not. diff --git a/results/classifier/105/instruction/2577 b/results/classifier/105/instruction/2577 new file mode 100644 index 00000000..cdae790a --- /dev/null +++ b/results/classifier/105/instruction/2577 @@ -0,0 +1,14 @@ +instruction: 0.915 +graphic: 0.856 +device: 0.802 +assembly: 0.760 +mistranslation: 0.331 +KVM: 0.276 +semantic: 0.160 +boot: 0.117 +network: 0.105 +socket: 0.084 +vnc: 0.067 +other: 0.052 + +buildx: Illegal instruction, exit code: 132 diff --git a/results/classifier/105/instruction/2583 b/results/classifier/105/instruction/2583 new file mode 100644 index 00000000..df36fe4c --- /dev/null +++ b/results/classifier/105/instruction/2583 @@ -0,0 +1,38 @@ +instruction: 0.911 +device: 0.863 +graphic: 0.846 +boot: 0.840 +vnc: 0.803 +KVM: 0.759 +socket: 0.717 +semantic: 0.657 +network: 0.599 +other: 0.514 +assembly: 0.459 +mistranslation: 0.366 + +libvfio-user.so.0 missing in /lib/x86_64-linux-gnu/ in fresh install of 9.1.50 +Description of problem: +Library libvfio-user.so.0 is missing from /lib/x86_64-linux-gnu. qemu-system-x86_64 does not start due to missing library. + +```` +root@jpbdeb:~# ls -al /usr/local/bin/qemu-system-x86_64 +-rwxr-xr-x 1 root root 81734576 Sep 21 21:48 /usr/local/bin/qemu-system-x86_64 +root@jpbdeb:~# ldd /usr/local/bin/qemu-system-x86_64 + linux-vdso.so.1 (0x00007fff511de000) + libvfio-user.so.0 => not found + libslirp.so.0 => /lib/x86_64-linux-gnu/libslirp.so.0 (0x00007f73eba33000) + libxenctrl.so.4.17 => /lib/x86_64-linux-gnu/libxenctrl.so.4.17 (0x00007f73eba09000) + libxenstore.so.4 => /lib/x86_64-linux-gnu/libxenstore.so.4 (0x00007f73eb9fe000) + libxenforeignmemory.so.1 => /lib/x86_64-linux-gnu/libxenforeignmemory.so.1 (0x00007f73eb9f9000) + ... +```` +Steps to reproduce: +1. Fresh OS install, including all packages necessary to build from source. +2. Download source from gitlab and proceed with documented build instructions. +3. make install +4. Attempt to run /usr/local/bin/qemu-system-x86_64 fails, due to missing library. +Additional information: +Adding the link to the library that exists in /usr/lib/x86_64-linux-gnu resolves the issue: + +(as root) ln -s /usr/local/lib/x86_64-linux-gnu/libvfio-user.so.0 /lib/x86_64-linux-gnu/libvfio-user.so.0 diff --git a/results/classifier/105/instruction/2592 b/results/classifier/105/instruction/2592 new file mode 100644 index 00000000..20921898 --- /dev/null +++ b/results/classifier/105/instruction/2592 @@ -0,0 +1,50 @@ +instruction: 0.830 +semantic: 0.672 +graphic: 0.667 +device: 0.611 +mistranslation: 0.490 +network: 0.448 +socket: 0.434 +other: 0.433 +vnc: 0.426 +boot: 0.287 +KVM: 0.218 +assembly: 0.173 + +qemu-aarch64 cannot properly support some python functions from the `time` module +Description of problem: +When a function is run in python (for example, `time.time()`), python returns the following error: +``` +Traceback (most recent call last): + File "<string>", line 1, in <module> +OSError: [Errno 0] Error +``` +I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem. +Steps to reproduce: +Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts. +1. Create a simple codespace environment. +2. Run the following commands through the terminal: +``` +git clone https://github.com/termux-pacman/glibc-packages +cd glibc-packages +./get-build-package.sh +sudo mkdir /data +sudo chown codespace /data +sudo chgrp codespace /data +sudo apt update +sudo apt install patchelf +./scripts/setup-cgct.sh +``` +3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete. +``` +./build-package.sh -I -w --library glibc gpkg/gobject-introspection +``` +4. Install standard qemu via apt. +5. Run the following command: +``` +qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()" +``` +Additional information: +- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur. + - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502. +For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35. diff --git a/results/classifier/105/instruction/2598 b/results/classifier/105/instruction/2598 new file mode 100644 index 00000000..82f74dcf --- /dev/null +++ b/results/classifier/105/instruction/2598 @@ -0,0 +1,14 @@ +instruction: 0.805 +device: 0.597 +network: 0.554 +graphic: 0.458 +boot: 0.385 +semantic: 0.274 +mistranslation: 0.234 +other: 0.023 +vnc: 0.017 +socket: 0.010 +assembly: 0.008 +KVM: 0.001 + +linux-user on riscv64 host: Unable to find a guest_base to satisfy all guest address mapping requirements 00000000-ffffffff diff --git a/results/classifier/105/instruction/2619 b/results/classifier/105/instruction/2619 new file mode 100644 index 00000000..7004a3e5 --- /dev/null +++ b/results/classifier/105/instruction/2619 @@ -0,0 +1,14 @@ +instruction: 0.623 +semantic: 0.532 +device: 0.507 +network: 0.491 +graphic: 0.396 +mistranslation: 0.238 +socket: 0.062 +assembly: 0.059 +vnc: 0.057 +boot: 0.048 +other: 0.017 +KVM: 0.015 + +INTEGER_OVERFLOW in nios2.c diff --git a/results/classifier/105/instruction/2628 b/results/classifier/105/instruction/2628 new file mode 100644 index 00000000..403f2e4b --- /dev/null +++ b/results/classifier/105/instruction/2628 @@ -0,0 +1,33 @@ +instruction: 0.855 +device: 0.823 +graphic: 0.766 +semantic: 0.746 +socket: 0.669 +vnc: 0.661 +boot: 0.634 +mistranslation: 0.544 +network: 0.518 +other: 0.404 +assembly: 0.227 +KVM: 0.057 + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines +Description of problem: +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version + +dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped +Steps to reproduce: +1. debootstrap --arch=arm64 stable /scratch/debian-stable +2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version +Additional information: +Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU + +chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes diff --git a/results/classifier/105/instruction/263 b/results/classifier/105/instruction/263 new file mode 100644 index 00000000..4bb17d60 --- /dev/null +++ b/results/classifier/105/instruction/263 @@ -0,0 +1,14 @@ +instruction: 0.886 +device: 0.824 +network: 0.601 +graphic: 0.316 +socket: 0.277 +semantic: 0.233 +other: 0.231 +boot: 0.221 +vnc: 0.193 +mistranslation: 0.107 +assembly: 0.039 +KVM: 0.009 + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host diff --git a/results/classifier/105/instruction/2641 b/results/classifier/105/instruction/2641 new file mode 100644 index 00000000..66bcf1cf --- /dev/null +++ b/results/classifier/105/instruction/2641 @@ -0,0 +1,14 @@ +instruction: 0.802 +graphic: 0.349 +mistranslation: 0.243 +semantic: 0.242 +device: 0.234 +other: 0.089 +vnc: 0.050 +KVM: 0.041 +socket: 0.040 +network: 0.025 +boot: 0.017 +assembly: 0.003 + +Possible DEREF_OF_NULL in linux-user/syscall.c diff --git a/results/classifier/105/instruction/2647 b/results/classifier/105/instruction/2647 new file mode 100644 index 00000000..83b2e82e --- /dev/null +++ b/results/classifier/105/instruction/2647 @@ -0,0 +1,60 @@ +instruction: 0.844 +graphic: 0.799 +mistranslation: 0.733 +device: 0.552 +semantic: 0.419 +assembly: 0.408 +other: 0.342 +network: 0.333 +socket: 0.311 +vnc: 0.281 +boot: 0.243 +KVM: 0.218 + +A code error in accel/tcg/user-exec.c +Description of problem: +accel/tcg/user-exec.c: +``` +static int probe_access_internal(CPUArchState *env, vaddr addr, + int fault_size, MMUAccessType access_type, + bool nonfault, uintptr_t ra) +{ + int acc_flag; + bool maperr; + + switch (access_type) { + case MMU_DATA_STORE: + acc_flag = PAGE_WRITE_ORG; + break; + case MMU_DATA_LOAD: + acc_flag = PAGE_READ; + break; + case MMU_INST_FETCH: + acc_flag = PAGE_EXEC; + break; + default: + g_assert_not_reached(); + } + + if (guest_addr_valid_untagged(addr)) { + int page_flags = page_get_flags(addr); + if (page_flags & acc_flag) { + if ((acc_flag == PAGE_READ || acc_flag == PAGE_WRITE) + && cpu_plugin_mem_cbs_enabled(env_cpu(env))) { + return TLB_MMIO; + } + return 0; /* success */ + } + maperr = !(page_flags & PAGE_VALID); + } else { + maperr = true; + } + + if (nonfault) { + return TLB_INVALID_MASK; + } + + cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra); +} +``` +The conditional judgment "acc_flag == PAGE_WRITE" seems to have an issue, because acc_flag can only be PAGE_WRITE_ORG, PAGE_READ or PAGE_EXEC from the previous code. diff --git a/results/classifier/105/instruction/2655 b/results/classifier/105/instruction/2655 new file mode 100644 index 00000000..9c12d4fd --- /dev/null +++ b/results/classifier/105/instruction/2655 @@ -0,0 +1,52 @@ +instruction: 0.685 +device: 0.619 +graphic: 0.557 +socket: 0.437 +other: 0.428 +assembly: 0.389 +vnc: 0.343 +network: 0.294 +semantic: 0.265 +mistranslation: 0.195 +boot: 0.192 +KVM: 0.124 + +A problem in target/riscv/vector_helper.c: vext_ldff() +Description of problem: +I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c: +``` +static inline void +vext_ldff(...) +{ +... + for (i = env->vstart; i < env->vl; i++) { +... + if (i == 0) { + probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD); + } else { +... + flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD, + mmu_index, true, &host, 0); +... + if (flags & ~TLB_WATCHPOINT) { + vl = i; + goto ProbeSuccess; + } +... + } + } +ProbeSuccess: +... +} +``` +If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist. + +In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? + +This problem occurred in both linux-user mode and full-system mode. + +Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions. +Steps to reproduce: +1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests. +2. Write a plugin to add memory callbacks. +3. Observe the behavior of the function. diff --git a/results/classifier/105/instruction/2662 b/results/classifier/105/instruction/2662 new file mode 100644 index 00000000..3a175088 --- /dev/null +++ b/results/classifier/105/instruction/2662 @@ -0,0 +1,24 @@ +instruction: 0.899 +device: 0.692 +semantic: 0.503 +graphic: 0.441 +other: 0.366 +mistranslation: 0.348 +network: 0.311 +socket: 0.173 +boot: 0.155 +vnc: 0.151 +assembly: 0.054 +KVM: 0.025 + +powerpc: MSR_ILE bit must not be restored in rfi +Description of problem: +On processors that implement the MSR_ILE bit (that is, G4 and prior), the MSR_ILE bit is not restored by the `rfi` instruction. + +qemu, however, does restore this bit from `srr1`. + +Some ppcel operating systems rely on MSR_ILE not being restored by `rfi`, for example, Windows NT when taking a syscall. +Additional information: +Patch provided: [rfi_msr_ile.patch](/uploads/aa661fc8bcbb47585ff63f8e4ebb38ba/rfi_msr_ile.patch) + +The correct behaviour for G4 and prior is performed for later processors too. Given PPC970 and later have that bit documented as reserved, this should not be a problem. diff --git a/results/classifier/105/instruction/2669 b/results/classifier/105/instruction/2669 new file mode 100644 index 00000000..233f0413 --- /dev/null +++ b/results/classifier/105/instruction/2669 @@ -0,0 +1,31 @@ +instruction: 0.888 +graphic: 0.871 +device: 0.818 +vnc: 0.742 +semantic: 0.726 +boot: 0.676 +mistranslation: 0.625 +socket: 0.557 +assembly: 0.524 +network: 0.494 +KVM: 0.471 +other: 0.422 + +CPU Hotplug (Host Model) Causes the Windows VM to BSOD +Description of problem: +The QEMU runs on a host with the Intel(R) Xeon(R) CPU E3-1230 v6 CPU which supports Software Guard Extension (SGX). I start a VM with Windows Server 2019 inside and with `-cpu host,...`. When I attempts to hotplug additional CPU (when the VM is running), the OS issues a bug check 0x3e (`MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED`). The problem is that the newly hotplugged CPU is not evaluated as "equivalent enough" compared to the already present CPUs. I did some more digging and reverse engineering and it looks like the CPU being hotplugged has SGX turned off. This seems to be fixed when the VM reboots. + +I tried to disable SGX through `-cpu host,-sgx` which helps (the VM successfully accepts the hotplugged CPU), however, `+sgx` does not help (seems to have no effect on the CPU being hotplugged). + +My goal is to be able to hotplug CPUs even when the host CPU supports SGX. + +I tested with QEMU 8.0.0, 9.1.0, 9.1.1 and 9.1.50 (current master) but with no luck. +Steps to reproduce: +1. Create a simple Windows VM, +2. start the VM, +3. use `qpm-shell` to hotplug a CPU (https://www.qemu.org/docs/master/system/cpu-hotplug.html). + +I can provide you the VM as well but its image (QCOW2) has around 10G in size. + +Best regards +Martin Dráb diff --git a/results/classifier/105/instruction/268 b/results/classifier/105/instruction/268 new file mode 100644 index 00000000..db02b85b --- /dev/null +++ b/results/classifier/105/instruction/268 @@ -0,0 +1,14 @@ +instruction: 0.929 +device: 0.877 +other: 0.707 +vnc: 0.435 +assembly: 0.414 +semantic: 0.374 +graphic: 0.346 +network: 0.323 +boot: 0.289 +socket: 0.125 +mistranslation: 0.120 +KVM: 0.103 + +arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N") diff --git a/results/classifier/105/instruction/2683 b/results/classifier/105/instruction/2683 new file mode 100644 index 00000000..efa92bdc --- /dev/null +++ b/results/classifier/105/instruction/2683 @@ -0,0 +1,52 @@ +instruction: 0.908 +graphic: 0.841 +semantic: 0.795 +other: 0.784 +device: 0.758 +mistranslation: 0.728 +network: 0.714 +vnc: 0.685 +socket: 0.632 +KVM: 0.630 +assembly: 0.629 +boot: 0.479 + +TCG: probe_access() has inconsistent behavior +Description of problem: +In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO. + +accel/tcg/cputlb.c: probe_access_internal() +``` + if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED)) + || (access_type != MMU_INST_FETCH && force_mmio)) { + *phost = NULL; + return TLB_MMIO; + } +``` +But in linux-user mode, it will return correct address when the flag is TLB_MMIO. + +accel/tcg/user-exec.c: probe_access() +``` + return size ? g2h(env_cpu(env), addr) : NULL; +``` +This will lead to some different behaviors, like cbo.zero in RISC-V. + +target/riscv/op_helper.c: helper_cbo_zero() +``` + mem = probe_write(env, address, cbozlen, mmu_idx, ra); + + if (likely(mem)) { + memset(mem, 0, cbozlen); + } else { + for (int i = 0; i < cbozlen; i++) { + cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra); + } + } +``` +When the current instruction has memory callback by plugin: + +Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly. + +Linux-user mode uses fast-path(memset) and doesn't inject callbacks. + +To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode. diff --git a/results/classifier/105/instruction/2696 b/results/classifier/105/instruction/2696 new file mode 100644 index 00000000..79acc2cf --- /dev/null +++ b/results/classifier/105/instruction/2696 @@ -0,0 +1,25 @@ +instruction: 0.967 +device: 0.919 +graphic: 0.893 +network: 0.832 +vnc: 0.783 +socket: 0.735 +mistranslation: 0.701 +boot: 0.690 +semantic: 0.660 +other: 0.463 +KVM: 0.229 +assembly: 0.174 + +qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction +Description of problem: +``` +❯ cat start.s +.globl _start +_start: .word 0 +❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld +❯ qemu-hexagon ./a.out +** +ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +``` diff --git a/results/classifier/105/instruction/273 b/results/classifier/105/instruction/273 new file mode 100644 index 00000000..54671301 --- /dev/null +++ b/results/classifier/105/instruction/273 @@ -0,0 +1,14 @@ +instruction: 0.886 +device: 0.808 +network: 0.594 +boot: 0.435 +graphic: 0.407 +socket: 0.401 +mistranslation: 0.390 +vnc: 0.318 +semantic: 0.300 +other: 0.101 +assembly: 0.068 +KVM: 0.025 + +xhci_find_stream: Assertion `streamid != 0' failed. diff --git a/results/classifier/105/instruction/2747 b/results/classifier/105/instruction/2747 new file mode 100644 index 00000000..a8b5af92 --- /dev/null +++ b/results/classifier/105/instruction/2747 @@ -0,0 +1,22 @@ +instruction: 0.811 +device: 0.784 +network: 0.734 +graphic: 0.706 +semantic: 0.458 +other: 0.449 +vnc: 0.444 +mistranslation: 0.410 +boot: 0.311 +socket: 0.254 +KVM: 0.158 +assembly: 0.115 + +External snapshots are created world-readable when connecting via qemu+ssh://root +Description of problem: +External snapshots are created with world-readable permissions when connecting via `qemu+ssh://root`. +Steps to reproduce: +1. Create a VM over `qemu+ssh://root@$SERVER/system` +2. Create an external snapshot via virt-manager or with `virsh snapshot-create-as --domain testvm --name test --disk-only --diskspec vda,file=/var/lib/libvirt/images/test.qcow2 --atomic` +3. `ls -l /var/lib/libvirt/images/test.qcow2` +Additional information: +Issue doesn't seem to go away by adding `umask 077` in `$HOME/.profile` diff --git a/results/classifier/105/instruction/275 b/results/classifier/105/instruction/275 new file mode 100644 index 00000000..29a96388 --- /dev/null +++ b/results/classifier/105/instruction/275 @@ -0,0 +1,14 @@ +instruction: 0.767 +device: 0.720 +network: 0.467 +graphic: 0.438 +vnc: 0.395 +boot: 0.318 +semantic: 0.167 +KVM: 0.138 +other: 0.123 +mistranslation: 0.123 +socket: 0.082 +assembly: 0.022 + +Error in user-mode calculation of ELF aux vector's AT_PHDR diff --git a/results/classifier/105/instruction/2750 b/results/classifier/105/instruction/2750 new file mode 100644 index 00000000..ca0fdd92 --- /dev/null +++ b/results/classifier/105/instruction/2750 @@ -0,0 +1,24 @@ +instruction: 0.890 +graphic: 0.881 +device: 0.854 +vnc: 0.576 +boot: 0.488 +semantic: 0.465 +network: 0.368 +socket: 0.348 +mistranslation: 0.092 +other: 0.080 +assembly: 0.043 +KVM: 0.022 + +Data race in the goflag global variable in the rcutorture test. +Description of problem: +A data race involving the `goflag` global variable in `tests/unit/rcutorture.c` was identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/rcutorture +MALLOC_PERTURB_=194 G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_SRCDIR=$QEMU_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/rcutorture --tap -k +``` diff --git a/results/classifier/105/instruction/2755 b/results/classifier/105/instruction/2755 new file mode 100644 index 00000000..cb5ef356 --- /dev/null +++ b/results/classifier/105/instruction/2755 @@ -0,0 +1,24 @@ +instruction: 0.851 +device: 0.839 +graphic: 0.676 +vnc: 0.599 +network: 0.413 +semantic: 0.409 +boot: 0.357 +socket: 0.260 +mistranslation: 0.121 +KVM: 0.070 +assembly: 0.050 +other: 0.021 + +shrink attached rbd size is not allowed by default +Description of problem: + +Steps to reproduce: +1. attach a disk with size 100GiB to a running vm +2. writing some data to the attached disk +3. executing block_resize command and shrink the size to 1GiB + +the result is virtual disk is resized successfully and causing data lost. +Additional information: +Tested QEMU version is 4.2 diff --git a/results/classifier/105/instruction/276 b/results/classifier/105/instruction/276 new file mode 100644 index 00000000..34145660 --- /dev/null +++ b/results/classifier/105/instruction/276 @@ -0,0 +1,14 @@ +instruction: 0.703 +device: 0.701 +graphic: 0.487 +network: 0.237 +boot: 0.194 +vnc: 0.182 +semantic: 0.172 +other: 0.131 +KVM: 0.079 +mistranslation: 0.078 +socket: 0.072 +assembly: 0.003 + +Error in user-mode calculation of ELF program's brk diff --git a/results/classifier/105/instruction/2761 b/results/classifier/105/instruction/2761 new file mode 100644 index 00000000..4f28f575 --- /dev/null +++ b/results/classifier/105/instruction/2761 @@ -0,0 +1,21 @@ +instruction: 0.867 +graphic: 0.781 +device: 0.776 +vnc: 0.553 +boot: 0.549 +semantic: 0.519 +mistranslation: 0.418 +network: 0.343 +socket: 0.221 +other: 0.145 +KVM: 0.027 +assembly: 0.008 + +Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements" +Description of problem: +Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements" + +``` +file /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash +/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped +``` diff --git a/results/classifier/105/instruction/2764 b/results/classifier/105/instruction/2764 new file mode 100644 index 00000000..95cd1ea0 --- /dev/null +++ b/results/classifier/105/instruction/2764 @@ -0,0 +1,60 @@ +instruction: 0.912 +device: 0.838 +graphic: 0.815 +mistranslation: 0.780 +socket: 0.775 +network: 0.744 +semantic: 0.737 +vnc: 0.601 +other: 0.512 +boot: 0.473 +KVM: 0.290 +assembly: 0.274 + +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/105/instruction/2771 b/results/classifier/105/instruction/2771 new file mode 100644 index 00000000..1470a25d --- /dev/null +++ b/results/classifier/105/instruction/2771 @@ -0,0 +1,14 @@ +instruction: 0.896 +device: 0.564 +mistranslation: 0.419 +graphic: 0.401 +assembly: 0.287 +semantic: 0.243 +vnc: 0.228 +network: 0.211 +socket: 0.160 +boot: 0.124 +KVM: 0.063 +other: 0.036 + +qemu-system-x86_64: ../block/block-backend.c:1290: blk_in_drain: Assertion `qemu_in_main_thread()' failed. diff --git a/results/classifier/105/instruction/2802 b/results/classifier/105/instruction/2802 new file mode 100644 index 00000000..0abc4f37 --- /dev/null +++ b/results/classifier/105/instruction/2802 @@ -0,0 +1,39 @@ +instruction: 0.952 +device: 0.799 +assembly: 0.702 +network: 0.623 +vnc: 0.598 +socket: 0.510 +semantic: 0.449 +graphic: 0.427 +boot: 0.402 +other: 0.300 +KVM: 0.247 +mistranslation: 0.236 + +Sparc: fdtox/fqtox instructions incorrectly select destination register +Description of problem: +This bug report is mostly for informational purposes as I will be posting a fix for the bug. + +The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. +Steps to reproduce: +1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) +2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` +3. Run the test program using `qemu-sparc64-static ./test_program` +4. Expected output is 60. Prints 0 instead. +Additional information: +Test program to test the issue: + +```c +#include <stdio.h> + +int main(int argc, char** argv) { + long long truncated = 0; + __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); + __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); + printf("%lld\n", truncated); + return 0; +} +``` + +The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/results/classifier/105/instruction/2809 b/results/classifier/105/instruction/2809 new file mode 100644 index 00000000..a94b09f8 --- /dev/null +++ b/results/classifier/105/instruction/2809 @@ -0,0 +1,24 @@ +instruction: 0.864 +graphic: 0.846 +device: 0.807 +vnc: 0.524 +semantic: 0.440 +network: 0.377 +boot: 0.371 +socket: 0.335 +mistranslation: 0.084 +other: 0.067 +assembly: 0.028 +KVM: 0.028 + +Data races in TestBlockJob fields in test-block-iothread +Description of problem: +A data race in the access of `TestBlockJob` fields in `tests/unit/test-block-iothread.c` was identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-block-iothread +MALLOC_PERTURB_=67 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-block-iothread --tap -k +``` diff --git a/results/classifier/105/instruction/2817 b/results/classifier/105/instruction/2817 new file mode 100644 index 00000000..55f396c9 --- /dev/null +++ b/results/classifier/105/instruction/2817 @@ -0,0 +1,64 @@ +instruction: 0.930 +device: 0.806 +graphic: 0.777 +network: 0.771 +socket: 0.713 +semantic: 0.699 +vnc: 0.686 +assembly: 0.607 +other: 0.579 +boot: 0.560 +mistranslation: 0.520 +KVM: 0.260 + +Strange floating-point behaviour under Windows with some CPU models +Description of problem: +I'm encountering a very weird bug with some floating-point maths code, but only under very specific configurations. First I thought it was a Clang bug, but then further digging eventually showed it to only occur under Windows VMs with specific QEMU CPU options, I'm not certain whether it is a QEMU/KVM bug or a Windows bug, but thought starting here would be easiest. + +When compiled under MSVC Clang with modern CPU instructions disabled (e.g. `-march=pentium3` or `-march=pentium-mmx`), the `floorf()` call in the following program always returns 0.0, while the truncation works correctly: + +``` +#include <math.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char **argv) +{ + float n = atof(argv[1]); + printf("n = %f\n", n); + + float f = floorf(n); + printf("f = %f\n", f); + + float c = (int)(n); + printf("c = %f\n", c); + + return 0; +} +``` + +Example output on an affected VM: + +``` +C:\Users\Administrator> floorf-p3.exe 10 +n = 10.000000 +f = 0.000000 +c = 10.000000 + +C:\Users\Administrator> floorf-p4.exe 10 +n = 10.000000 +f = 10.000000 +c = 10.000000 +``` + +(`floorf-p3.exe` was compiled with `-march=pentium3` and `floorf-p4.exe` with `-march=pentium4` above) + +I've tried a few QEMU CPU models on a variety of Intel/AMD VM hosts and two different Windows versions (10 and Server 2022), and observed the following: + +* `host-passthrough` - works (on AMD and Intel hosts) +* `qemu64` - broken +* `EPYC-Milan` - works +* `Westmere` - works +* `Penryn` - broken + +(I also reported this via the mailing list, but I think it might've swallowed my post) diff --git a/results/classifier/105/instruction/2820 b/results/classifier/105/instruction/2820 new file mode 100644 index 00000000..d28f4b81 --- /dev/null +++ b/results/classifier/105/instruction/2820 @@ -0,0 +1,40 @@ +instruction: 0.905 +semantic: 0.882 +graphic: 0.848 +mistranslation: 0.827 +vnc: 0.800 +other: 0.786 +network: 0.773 +device: 0.745 +socket: 0.645 +assembly: 0.588 +KVM: 0.569 +boot: 0.509 + +STOPI CSR Incorrect Value for Virtual Supervisor External Interrupt in QEMU (AIA Extension) +Description of problem: +We are developing a RISC-V core and have implemented tests for the AIA extension. One of these tests reveals a bug when running in QEMU in a bare-metal environment. The issue relates to the value of the STOPI CSR. Although the CSR behaves correctly in most cases, when a virtual supervisor external interrupt is generated using the IMSIC (i.e., both hip.vseip and hie.vseip are set to 1) while executing in supervisor mode with hideleg.vseip set to 0, the STOPI CSR always returns the value 0. However, according to the specifications, it should return 10, which is the major identity number for the virtual supervisor external interrupt. + +According to the RISC-V specs: + +> The value of stopi is zero unless: (a) there is an interrupt that is both pending in sip and enabled in +sie, or, if the hypervisor extension is implemented, both pending in hip and enabled in hie; and (b) +the interrupt is not delegated to a lower privilege level (by hideleg, if the hypervisor extension is +implemented). When there is a pending-and-enabled major interrupt for supervisor level, field IID is +the major identity number of the highest-priority interrupt, and field IPRIO indicates its priority. + +Upon reviewing the QEMU AIA code, I found the following snippet in `qemu/target/riscv/cpu_helper.c` that might be causing the problem: +``` +int riscv_cpu_sirq_pending(CPURISCVState *env) +{ + uint64_t irqs = riscv_cpu_all_pending(env) & env->mideleg & + ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP); + uint64_t irqs_f = env->mvip & env->mvien & ~env->mideleg & env->sie; + + return riscv_cpu_pending_to_irq(env, IRQ_S_EXT, IPRIO_DEFAULT_S, + irqs | irqs_f, env->siprio); +} +``` +It appears that virtual supervisor (VS) interrupts are being masked (via the `~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP)` operation) when they likely should not be, which could explain why the STOPI CSR does not reflect the correct value. + +Thank you for your time, and please let me know if any details require further clarification or if my interpretation is incorrect. diff --git a/results/classifier/105/instruction/2833 b/results/classifier/105/instruction/2833 new file mode 100644 index 00000000..03103507 --- /dev/null +++ b/results/classifier/105/instruction/2833 @@ -0,0 +1,32 @@ +instruction: 0.928 +graphic: 0.853 +device: 0.838 +boot: 0.835 +vnc: 0.813 +socket: 0.768 +other: 0.760 +network: 0.745 +mistranslation: 0.724 +semantic: 0.723 +KVM: 0.660 +assembly: 0.586 + +Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET +Description of problem: +In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says: +> Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field. +> +> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0. + + +> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values. + +In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows. + +The HPET should show that it works with more than just IRQ 2. +Steps to reproduce: +1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859 +2. `nix develop` +3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int` +Additional information: + diff --git a/results/classifier/105/instruction/2854 b/results/classifier/105/instruction/2854 new file mode 100644 index 00000000..5c472ce9 --- /dev/null +++ b/results/classifier/105/instruction/2854 @@ -0,0 +1,37 @@ +instruction: 0.911 +graphic: 0.820 +device: 0.751 +semantic: 0.745 +other: 0.701 +network: 0.686 +vnc: 0.469 +socket: 0.447 +mistranslation: 0.414 +boot: 0.297 +assembly: 0.172 +KVM: 0.124 + +https://www.qemu.org/ is missing chance to provide (or at least link) some starting guide +Description of problem: +as a completely new (potential) user https://www.qemu.org/ main page is missing chance to easily link some hello world documentation +Steps to reproduce: +1. open https://www.qemu.org/ +2. try to click "Full-system emulation" with hope that it will link some starting hello world how to do so +Additional information: +On https://www.qemu.org/ you can click "support" + +Then you can click "documentation" + +Then "main documentation section" + +Then "system emulation" + +Then "introduction" + +At this point you have something that sort-of is viable as hello world. + +Maybe link https://www.qemu.org/docs/master/system/introduction.html from main page ("Full-system emulation")? + +Unless there is a better documentation? + +Though maybe someone who will not go through this link maze should not try to use QEMU at all? diff --git a/results/classifier/105/instruction/2855 b/results/classifier/105/instruction/2855 new file mode 100644 index 00000000..ea929ed5 --- /dev/null +++ b/results/classifier/105/instruction/2855 @@ -0,0 +1,42 @@ +instruction: 0.508 +device: 0.456 +graphic: 0.315 +other: 0.291 +network: 0.239 +socket: 0.212 +semantic: 0.204 +mistranslation: 0.202 +boot: 0.160 +vnc: 0.158 +assembly: 0.151 +KVM: 0.121 + +masking mode field in mepc before mret +Description of problem: +I thought I found a bug in OpenSBI (https://github.com/riscv-software-src/opensbi/issues/391) but it actually is a QEMU bug. +It is described here: https://lists.infradead.org/pipermail/opensbi/2025-March/008166.html +Steps to reproduce: +1. use an application with vectored mode enabled (The RISC-V Instruction Set Manual: Volume II: Privileged Architecture / chapter 10.1.2) in QEMU +2. trigger an illegal instruction interrupt (handle it in machine mode - not by medeleg) +3. in a machine mode trap: Store STVEC in MEPC. +4. do a mret +5. the first bits of mepc are not masked so the address in mepc (comming from (v)stvec) will be false after mret +Additional information: +My guess is that the instructions from the following quote (masking of lower bits in mepc) from the official spec must be implemented here: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/op_helper.c?ref_type=heads#L387 +Maybe also somewhere else. + +> 3.1.14. Machine Exception Program Counter (mepc) +> +> mepc is an MXLEN-bit read/write register formatted as shown in Figure 21. The low bit of mepc +> (mepc[0]) is always zero. On implementations that support only IALIGN=32, the two low bits +> (mepc[1:0]) are always zero. +> +> If an implementation allows IALIGN to be either 16 or 32 (by changing CSR misa, for example), then, +> whenever IALIGN=32, bit mepc[1] is masked on reads so that it appears to be 0. This masking occurs +> also for the implicit read by the MRET instruction. Though masked, mepc[1] remains writable when +> IALIGN=32. +> +> mepc is a WARL register that must be able to hold all valid virtual addresses. It need not be capable of +> holding all possible invalid addresses. Prior to writing mepc, implementations may convert an invalid +> address into some other invalid address that mepc is capable of holding. diff --git a/results/classifier/105/instruction/2861 b/results/classifier/105/instruction/2861 new file mode 100644 index 00000000..7c97d7ae --- /dev/null +++ b/results/classifier/105/instruction/2861 @@ -0,0 +1,20 @@ +instruction: 0.941 +device: 0.877 +graphic: 0.860 +network: 0.814 +vnc: 0.739 +socket: 0.687 +other: 0.667 +mistranslation: 0.667 +semantic: 0.467 +boot: 0.421 +KVM: 0.335 +assembly: 0.180 + +hw/pci-host/designware.c incorrect write to DESIGNWARE_PCIE_ATU_UPPER_TARGET register +Description of problem: +I think this is a obvious bug + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/designware.c?ref_type=heads#L374 + +Write to register DESIGNWARE_PCIE_ATU_UPPER_TARGET, val should be shifted left to update upper 32 bit part. diff --git a/results/classifier/105/instruction/2865 b/results/classifier/105/instruction/2865 new file mode 100644 index 00000000..993bac92 --- /dev/null +++ b/results/classifier/105/instruction/2865 @@ -0,0 +1,65 @@ +instruction: 0.901 +assembly: 0.741 +mistranslation: 0.694 +device: 0.653 +graphic: 0.618 +socket: 0.439 +vnc: 0.390 +network: 0.364 +other: 0.326 +boot: 0.235 +semantic: 0.210 +KVM: 0.187 + +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/105/instruction/2883 b/results/classifier/105/instruction/2883 new file mode 100644 index 00000000..783758aa --- /dev/null +++ b/results/classifier/105/instruction/2883 @@ -0,0 +1,14 @@ +instruction: 0.958 +device: 0.727 +network: 0.376 +vnc: 0.374 +graphic: 0.357 +boot: 0.357 +mistranslation: 0.173 +KVM: 0.143 +semantic: 0.136 +other: 0.121 +socket: 0.114 +assembly: 0.084 + +Advice regarding implementation of smooth scrolling diff --git a/results/classifier/105/instruction/2891 b/results/classifier/105/instruction/2891 new file mode 100644 index 00000000..7e14cd3d --- /dev/null +++ b/results/classifier/105/instruction/2891 @@ -0,0 +1,14 @@ +instruction: 0.883 +device: 0.872 +network: 0.736 +graphic: 0.483 +socket: 0.390 +semantic: 0.346 +assembly: 0.235 +boot: 0.232 +other: 0.118 +mistranslation: 0.115 +vnc: 0.057 +KVM: 0.005 + +qemu-system-x86_64 segfaults when executing ipxe selftests diff --git a/results/classifier/105/instruction/2900 b/results/classifier/105/instruction/2900 new file mode 100644 index 00000000..bea00bd2 --- /dev/null +++ b/results/classifier/105/instruction/2900 @@ -0,0 +1,24 @@ +instruction: 0.891 +device: 0.837 +graphic: 0.816 +vnc: 0.528 +boot: 0.477 +network: 0.438 +semantic: 0.396 +socket: 0.297 +mistranslation: 0.135 +other: 0.049 +assembly: 0.026 +KVM: 0.019 + +Data races in test-bdrv-drain test +Description of problem: +Data races in the access of `Job` fields in the `test-bdrv-drain` test were identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-bdrv-drain +MALLOC_PERTURB_=186 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-bdrv-drain --tap -k +``` diff --git a/results/classifier/105/instruction/2903 b/results/classifier/105/instruction/2903 new file mode 100644 index 00000000..168935e8 --- /dev/null +++ b/results/classifier/105/instruction/2903 @@ -0,0 +1,24 @@ +instruction: 0.800 +graphic: 0.757 +device: 0.725 +semantic: 0.357 +vnc: 0.154 +boot: 0.138 +mistranslation: 0.086 +socket: 0.031 +network: 0.021 +assembly: 0.020 +other: 0.014 +KVM: 0.001 + +Data Race in assertion in aio-posix.c +Description of problem: +Potential data races in the assertion in `test-aio-multithread` were identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-bdrv-drain +MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k +``` diff --git a/results/classifier/105/instruction/2907 b/results/classifier/105/instruction/2907 new file mode 100644 index 00000000..33e995bf --- /dev/null +++ b/results/classifier/105/instruction/2907 @@ -0,0 +1,14 @@ +instruction: 0.959 +device: 0.916 +network: 0.815 +vnc: 0.700 +socket: 0.673 +boot: 0.488 +graphic: 0.386 +assembly: 0.307 +semantic: 0.281 +mistranslation: 0.101 +other: 0.078 +KVM: 0.007 + +replay_mutex_unlock() assertion on macOS diff --git a/results/classifier/105/instruction/2946 b/results/classifier/105/instruction/2946 new file mode 100644 index 00000000..1f775a8f --- /dev/null +++ b/results/classifier/105/instruction/2946 @@ -0,0 +1,23 @@ +instruction: 0.889 +graphic: 0.762 +network: 0.728 +device: 0.599 +other: 0.554 +semantic: 0.394 +vnc: 0.305 +mistranslation: 0.217 +socket: 0.194 +boot: 0.090 +KVM: 0.056 +assembly: 0.018 + +crypto/aes.c (used for emulating aes instructions) has a timing side-channel +Description of problem: +https://gitlab.com/qemu-project/qemu/-/blob/a9cd5bc6399a80fcf233ed0fffe6067b731227d8/crypto/aes.c#L1021 + +much of the code in crypto/aes.c accesses memory arrays where the array index is based on the secret data being encrypted/decrypted. because of cpu caches and other things that can delay memory accesses based on their address, this is a timing side-channel, potentially allowing leaking secrets over a network based on timing how long cryptography operations take. + +compare to openssl which uses an algorithm where its execution time doesn't depend on the data being processed: +https://github.com/openssl/openssl/commit/0051746e03c65f5970d8ca424579d50f58a877e0 + +I initially reported this as a security issue, but was told that since it's only used by TCG, it isn't a security issue, since TCG isn't considered secure. diff --git a/results/classifier/105/instruction/2958 b/results/classifier/105/instruction/2958 new file mode 100644 index 00000000..cb3c52fb --- /dev/null +++ b/results/classifier/105/instruction/2958 @@ -0,0 +1,31 @@ +instruction: 0.879 +graphic: 0.862 +device: 0.856 +socket: 0.806 +mistranslation: 0.799 +network: 0.747 +semantic: 0.610 +other: 0.423 +boot: 0.273 +vnc: 0.230 +assembly: 0.076 +KVM: 0.053 + +Vvfat crashes in WinXP-64 installation. +Description of problem: + +Steps to reproduce: +1. Download ISO (see above) +2. Set up qemu +3. Run command above + +Termux output: +qemu-system-x86_64: Slirp: Failed to send packet, ret: -1 [repeated] + +../block/vvfat.c:105: void *array_get(array_t *, unsigned int): assertion "index < array->next" failed +Aborted +~ $ +Additional information: +This was extremely annoying because the total abort occurs far into the installation, while setting up the network. The devices (presumably including the vvfat) had been installed OK. The XP installation can be restarted without the CD but starts at the beginning, needing location, passwords, licence key etc. all over again! I have XP64 installed now, without vvfat which is a marvellously convenient way of transferring files. + +BTW "vfat" usually means extended FAT, handling files over 4GB but vvfat does not. Can you fix that? diff --git a/results/classifier/105/instruction/2971 b/results/classifier/105/instruction/2971 new file mode 100644 index 00000000..2ee49f8b --- /dev/null +++ b/results/classifier/105/instruction/2971 @@ -0,0 +1,57 @@ +instruction: 0.834 +vnc: 0.780 +device: 0.770 +assembly: 0.671 +network: 0.667 +socket: 0.623 +graphic: 0.579 +semantic: 0.515 +boot: 0.473 +other: 0.425 +KVM: 0.396 +mistranslation: 0.282 + +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/105/instruction/2980 b/results/classifier/105/instruction/2980 new file mode 100644 index 00000000..d3e31827 --- /dev/null +++ b/results/classifier/105/instruction/2980 @@ -0,0 +1,277 @@ +instruction: 0.836 +graphic: 0.821 +vnc: 0.818 +KVM: 0.816 +device: 0.806 +semantic: 0.805 +other: 0.797 +assembly: 0.794 +socket: 0.781 +boot: 0.774 +mistranslation: 0.757 +network: 0.732 + +QEMU Crashes During Snapshot: bdrv_co_write_req_prepare Assertion child->perm & BLK_PERM_WRITE Failed +Description of problem: +After taking a external snapshot (w/ memory state) with libvirt, the QEMU process crashed with an assertion + +``` +qemu-system-x86_64: ../block/io.c:2052: bdrv_co_write_req_prepare: Assertion `child->perm & BLK_PERM_WRITE` failed. +``` +Steps to reproduce: +1. Start the qemu process +2. Take an external (w/ memory) snapshot by libvirt Python API + + ```python + domain.snapshotCreateXML(<xml_string>, + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC | + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT | + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_LIVE) + ``` + +3. The qemu process crashed by hitting the assertion +Additional information: +Libvirt domain XML +```xml +<domain type='kvm'> + <name>1a3dabc5-c33b-4308-acc5-2245f3b64163</name> + <uuid>1a3dabc5-c33b-4308-acc5-2245f3b64163</uuid> + <metadata xmlns:qvs="http://www.qnap.com/schemas/qvs/1.0"> + </metadata> + <memory unit='KiB'>16777216</memory> + <currentMemory unit='KiB'>16777216</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static' cpuset='0-23'>5</vcpu> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>qemu</entry> + <entry name='product'>qemu</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-7.0'>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='no'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='1' dies='1' cores='5' threads='1'/> + <numa> + <cell id='0' cpus='0-4' memory='16777216' unit='KiB' memAccess='private'/> + </numa> + </cpu> + <clock offset='localtime'/> + <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>/QVS/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='writeback'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747803601' startupPolicy='optional'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747630800'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747371601'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747198801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747026001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746594001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746421201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745557200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745211600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1744174801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743570001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743138001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742965201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742360400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742187600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741928400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741755601'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741323600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740718800'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740546000'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740373200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740114000'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739941201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739768400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739509200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739336400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739163600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738904400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738558801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724816945'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724045214_1'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1721622169'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.img'/> + <backingStore/> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + <target dev='vdb' bus='virtio'/> + <serial>1a3dabc5c33b4308ac01</serial> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source startupPolicy='optional'/> + <target dev='hda' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0' model='nec-xhci' ports='6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:a2:a4:e3'/> + <source bridge='qvs0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <channel type='unix'> + <source mode='bind' path='/QVS/var/lib/libvirt/qemu/1a3dabc5-c33b-4308-acc5-2245f3b64163.agent'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <tpm model='tpm-tis'> + <backend type='emulator' version='2.0'/> + </tpm> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' keymap='en-us'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <graphics type='spice' autoport='yes' listen='127.0.0.1' keymap='en-us'> + <listen type='address' address='127.0.0.1'/> + <image compression='off'/> + <jpeg compression='never'/> + <zlib compression='never'/> + <playback compression='off'/> + <streaming mode='all'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </memballoon> + </devices> +</domain> +``` diff --git a/results/classifier/105/instruction/300 b/results/classifier/105/instruction/300 new file mode 100644 index 00000000..3c56af76 --- /dev/null +++ b/results/classifier/105/instruction/300 @@ -0,0 +1,14 @@ +instruction: 0.909 +device: 0.870 +network: 0.805 +graphic: 0.579 +boot: 0.465 +socket: 0.400 +semantic: 0.194 +mistranslation: 0.184 +vnc: 0.169 +assembly: 0.158 +other: 0.062 +KVM: 0.009 + +qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again diff --git a/results/classifier/105/instruction/301 b/results/classifier/105/instruction/301 new file mode 100644 index 00000000..ec82e18b --- /dev/null +++ b/results/classifier/105/instruction/301 @@ -0,0 +1,14 @@ +instruction: 0.983 +semantic: 0.715 +device: 0.671 +network: 0.513 +graphic: 0.300 +socket: 0.244 +assembly: 0.240 +mistranslation: 0.173 +vnc: 0.101 +boot: 0.084 +other: 0.015 +KVM: 0.007 + +Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk diff --git a/results/classifier/105/instruction/306 b/results/classifier/105/instruction/306 new file mode 100644 index 00000000..e306ce42 --- /dev/null +++ b/results/classifier/105/instruction/306 @@ -0,0 +1,14 @@ +instruction: 0.664 +device: 0.559 +semantic: 0.537 +graphic: 0.376 +mistranslation: 0.346 +boot: 0.342 +other: 0.285 +vnc: 0.163 +KVM: 0.105 +assembly: 0.019 +network: 0.013 +socket: 0.013 + +Option to constrain linux-user exec() to emulated CPU only diff --git a/results/classifier/105/instruction/312 b/results/classifier/105/instruction/312 new file mode 100644 index 00000000..f359c52b --- /dev/null +++ b/results/classifier/105/instruction/312 @@ -0,0 +1,14 @@ +instruction: 0.929 +device: 0.884 +graphic: 0.407 +mistranslation: 0.153 +other: 0.111 +semantic: 0.109 +network: 0.075 +boot: 0.029 +socket: 0.028 +assembly: 0.009 +vnc: 0.009 +KVM: 0.000 + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/105/instruction/333 b/results/classifier/105/instruction/333 new file mode 100644 index 00000000..dd064c08 --- /dev/null +++ b/results/classifier/105/instruction/333 @@ -0,0 +1,14 @@ +instruction: 0.914 +device: 0.837 +network: 0.605 +mistranslation: 0.332 +graphic: 0.311 +boot: 0.304 +other: 0.261 +vnc: 0.119 +socket: 0.060 +semantic: 0.050 +assembly: 0.010 +KVM: 0.001 + +random errors on aarch64 when executing __aarch64_cas8_acq_rel diff --git a/results/classifier/105/instruction/355 b/results/classifier/105/instruction/355 new file mode 100644 index 00000000..5c0ca256 --- /dev/null +++ b/results/classifier/105/instruction/355 @@ -0,0 +1,14 @@ +instruction: 0.685 +graphic: 0.527 +device: 0.499 +network: 0.493 +vnc: 0.228 +assembly: 0.219 +boot: 0.185 +KVM: 0.148 +semantic: 0.086 +other: 0.039 +mistranslation: 0.038 +socket: 0.021 + +A possible divide by zero bug in get_whole_cluster diff --git a/results/classifier/105/instruction/361 b/results/classifier/105/instruction/361 new file mode 100644 index 00000000..ee26ed4b --- /dev/null +++ b/results/classifier/105/instruction/361 @@ -0,0 +1,14 @@ +instruction: 0.829 +mistranslation: 0.634 +semantic: 0.465 +graphic: 0.432 +vnc: 0.253 +device: 0.243 +boot: 0.163 +KVM: 0.134 +other: 0.106 +assembly: 0.014 +network: 0.006 +socket: 0.006 + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/105/instruction/366 b/results/classifier/105/instruction/366 new file mode 100644 index 00000000..1161aa4f --- /dev/null +++ b/results/classifier/105/instruction/366 @@ -0,0 +1,14 @@ +instruction: 0.928 +device: 0.714 +assembly: 0.562 +semantic: 0.428 +mistranslation: 0.361 +network: 0.348 +graphic: 0.331 +other: 0.148 +boot: 0.145 +vnc: 0.141 +socket: 0.047 +KVM: 0.008 + +How to make OVMF diff --git a/results/classifier/105/instruction/381 b/results/classifier/105/instruction/381 new file mode 100644 index 00000000..facd6c79 --- /dev/null +++ b/results/classifier/105/instruction/381 @@ -0,0 +1,14 @@ +instruction: 0.812 +mistranslation: 0.762 +device: 0.709 +graphic: 0.505 +vnc: 0.440 +semantic: 0.427 +network: 0.333 +other: 0.314 +socket: 0.242 +assembly: 0.202 +KVM: 0.198 +boot: 0.153 + +ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached diff --git a/results/classifier/105/instruction/390 b/results/classifier/105/instruction/390 new file mode 100644 index 00000000..61671b82 --- /dev/null +++ b/results/classifier/105/instruction/390 @@ -0,0 +1,14 @@ +instruction: 0.961 +assembly: 0.706 +device: 0.526 +graphic: 0.370 +semantic: 0.361 +boot: 0.196 +KVM: 0.175 +mistranslation: 0.162 +vnc: 0.116 +network: 0.058 +socket: 0.029 +other: 0.019 + +target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/105/instruction/417 b/results/classifier/105/instruction/417 new file mode 100644 index 00000000..f9f4c57c --- /dev/null +++ b/results/classifier/105/instruction/417 @@ -0,0 +1,14 @@ +instruction: 0.778 +device: 0.672 +network: 0.475 +mistranslation: 0.437 +semantic: 0.427 +boot: 0.350 +graphic: 0.305 +vnc: 0.262 +other: 0.196 +assembly: 0.134 +socket: 0.088 +KVM: 0.078 + +allow qemu_thread_create to return with error diff --git a/results/classifier/105/instruction/424450 b/results/classifier/105/instruction/424450 new file mode 100644 index 00000000..97acb931 --- /dev/null +++ b/results/classifier/105/instruction/424450 @@ -0,0 +1,38 @@ +instruction: 0.899 +device: 0.832 +mistranslation: 0.740 +vnc: 0.739 +semantic: 0.676 +socket: 0.656 +network: 0.616 +graphic: 0.600 +other: 0.575 +boot: 0.509 +assembly: 0.288 +KVM: 0.262 + +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/105/instruction/440 b/results/classifier/105/instruction/440 new file mode 100644 index 00000000..b46fbabc --- /dev/null +++ b/results/classifier/105/instruction/440 @@ -0,0 +1,14 @@ +instruction: 0.457 +graphic: 0.288 +device: 0.252 +mistranslation: 0.249 +semantic: 0.171 +network: 0.063 +boot: 0.035 +vnc: 0.027 +socket: 0.016 +assembly: 0.013 +KVM: 0.008 +other: 0.004 + +/usr/share/applications/qemu.desktop should have an "Exec=" key. diff --git a/results/classifier/105/instruction/442 b/results/classifier/105/instruction/442 new file mode 100644 index 00000000..f6aa5867 --- /dev/null +++ b/results/classifier/105/instruction/442 @@ -0,0 +1,14 @@ +instruction: 0.836 +graphic: 0.799 +device: 0.748 +semantic: 0.171 +network: 0.126 +boot: 0.095 +mistranslation: 0.091 +other: 0.029 +vnc: 0.017 +socket: 0.011 +assembly: 0.010 +KVM: 0.001 + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error diff --git a/results/classifier/105/instruction/447 b/results/classifier/105/instruction/447 new file mode 100644 index 00000000..4c9db7c6 --- /dev/null +++ b/results/classifier/105/instruction/447 @@ -0,0 +1,14 @@ +instruction: 0.889 +device: 0.776 +network: 0.658 +vnc: 0.417 +assembly: 0.402 +graphic: 0.398 +other: 0.371 +socket: 0.361 +boot: 0.308 +mistranslation: 0.208 +semantic: 0.183 +KVM: 0.003 + +qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) diff --git a/results/classifier/105/instruction/459 b/results/classifier/105/instruction/459 new file mode 100644 index 00000000..f6874936 --- /dev/null +++ b/results/classifier/105/instruction/459 @@ -0,0 +1,48 @@ +instruction: 0.931 +assembly: 0.840 +graphic: 0.796 +socket: 0.793 +vnc: 0.767 +device: 0.758 +other: 0.756 +semantic: 0.754 +network: 0.649 +mistranslation: 0.591 +boot: 0.579 +KVM: 0.504 + +bcm2835_aux (raspi3) fails when the receive FIFO fills up +Description of problem: +When a bare-metal application on the `raspi3` board reads the `AUX_MU_STAT_REG` MMIO register while the device's buffer is at full receive FIFO capacity (i.e. `s->read_count == BCM2835_AUX_RX_FIFO_LEN`) the assertion `assert(s->read_count < BCM2835_AUX_RX_FIFO_LEN)` fails. + +The assertion in question is currently in line 141 of `hw/char/bcm2835_aux.c`: https://gitlab.com/qemu-project/qemu/-/blob/9c2647f75004c4f7d64c9c0ec55f8c6f0739a8b1/hw/char/bcm2835_aux.c#L141 +but in my current QEMU version, it seems that it was in line 140, but I don't think that has any implication on this error. If the below steps to reproduce are followed, the full output of a normal QEMU (no debugging output or anything) is simply: + +```text +$ echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio +qemu-system-aarch64: /build/qemu-71DV4m/qemu-4.2/hw/char/bcm2835_aux.c:140: bcm2835_aux_read: Assertion `s->read_count < BCM2835_AUX_RX_FIFO_LEN' failed. +Aborted (core dumped) +``` + +Notice, that there is nothing really wrong with the implementation, if for instance an application that uses the `AUX_MU_LSR_REG` instead to check whether input is available, everything works as expected. It really seems that just this assertion is wrong. Also notice that the [BCM2835 manual](https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf) (page 18) explicitly allows values inclusive 8. +Steps to reproduce: +1. write a minimal bare-metal application for aarch64 using below main file +2. compile it with a decent aarch64 compiler, linker script and entry assembly as `kernel8.elf` +3. `echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio` +4. QEMU crashes with the above state assertion error +Additional information: +Minimal bare-metal application (`main.c`): + +```c +#define MMIO_BASE 0x3F000000 +#define AUX_MU_STAT ((volatile unsigned int*)(MMIO_BASE+0x00215064)) + +void main() { + while (1) { + // Just read STAT register to trigger the assertion error + *AUX_MU_STAT; + } +} +``` + +Also see [kernel8.elf.zip](/uploads/b12ae2750d2df1bb8db2701f3145f653/kernel8.elf.zip) for a precompiled version of the above application. diff --git a/results/classifier/105/instruction/462 b/results/classifier/105/instruction/462 new file mode 100644 index 00000000..3b16ff34 --- /dev/null +++ b/results/classifier/105/instruction/462 @@ -0,0 +1,56 @@ +instruction: 0.551 +graphic: 0.540 +assembly: 0.519 +device: 0.516 +mistranslation: 0.486 +network: 0.479 +semantic: 0.479 +vnc: 0.429 +socket: 0.417 +KVM: 0.402 +boot: 0.375 +other: 0.271 + +mirror: the block-job-cancel command can put qemu to the endless error loop +Description of problem: +If the destination VM will crash (or network is down) right before the completion of the block device mirroring job (`block-job-cancel`), then there will be a possibility to put QEMU in the error loop. +Steps to reproduce: +1. Run both QEMU VMs: source + target. +2. On the target side prepare NBD server for blockdev mirroring process by using QMP commands similar to the one below: +``` +{"execute": "nbd-server-start", "arguments": { "addr": { "data": { "host": "::", "port": "49153" }, "type": "inet" } } } +{ "execute": "nbd-server-add", "arguments": { "device": "drive_main01", "writable": true } } +``` +3. On the source side, prepare VM for the migration and start driver mirror job: +``` +{"execute":"migrate-set-capabilities","arguments":{"capabilities":[{"capability":"pause-before-switchover","state":true}]}} +{ "execute": "drive-mirror", "arguments": { "device": "drive_main01", "mode": "existing", "job-id": "job0", "target": "nbd:127.0.0.1:49153:exportname=drive_main01", "sync": "top", "on-source-error": "stop", "on-target-error": "stop", "format": "raw", "speed": 0 } } +``` +4. On the source side wait for the `BLOCK_JOB_READY` event: +``` +{"timestamp": {"seconds": 1625586327, "microseconds": 833805}, "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 21474836480, "offset": 21474836480, "speed": 0, "type": "mirror"}} +``` +5. Start migration on the source side: +``` +{ "execute": "migrate", "arguments": { "uri": "tcp:127.0.0.1:8091" } } +``` +6. Wait for the `pre-switchover` state of the migration: +``` +{ "execute": "query-migrate" } +{"return": {"expected-downtime": 300, "status": "pre-switchover", "setup-time": 3, "total-time": 11343, "ram": {"total": 8725020672, "postcopy-requests": 0, "dirty-sync-count": 2, "multifd-bytes": 0, "pages-per-second": 39550, "page-size": 4096, "remaining": 2871296, "mbps": 1073.7734399999999, "transferred": 963647065, "duplicate": 1899491, "dirty-pages-rate": 84, "skipped": 0, "normal-bytes": 944705536, "normal": 230641}}} +``` +7. Kill target QEMU to reproduce an issue. +8. Cancel the job on the source side: +``` +{ "execute": "block-job-cancel", "arguments": { "device": "job0" } } +``` + +Got the endless errror loop: +``` +... +{"timestamp": {"seconds": 1625586487, "microseconds": 413847}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413865}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +{"timestamp": {"seconds": 1625586487, "microseconds": 413885}, "event": "BLOCK_JOB_ERROR", "data": {"device": "job0", "operation": "write", "action": "stop"}} +... +``` +Source qemu could be stopped only by using SIGKILL. diff --git a/results/classifier/105/instruction/481 b/results/classifier/105/instruction/481 new file mode 100644 index 00000000..29a88671 --- /dev/null +++ b/results/classifier/105/instruction/481 @@ -0,0 +1,14 @@ +instruction: 0.966 +device: 0.920 +network: 0.681 +mistranslation: 0.564 +assembly: 0.427 +graphic: 0.352 +semantic: 0.205 +boot: 0.040 +other: 0.034 +socket: 0.016 +vnc: 0.015 +KVM: 0.003 + +Implement I2C for BCM2835 (raspi) diff --git a/results/classifier/105/instruction/483 b/results/classifier/105/instruction/483 new file mode 100644 index 00000000..75015fc5 --- /dev/null +++ b/results/classifier/105/instruction/483 @@ -0,0 +1,38 @@ +instruction: 0.948 +graphic: 0.881 +network: 0.859 +semantic: 0.850 +device: 0.840 +socket: 0.720 +vnc: 0.706 +assembly: 0.589 +other: 0.557 +mistranslation: 0.452 +KVM: 0.378 +boot: 0.332 + +qemu doesn't process -object secret when read from a config file +Description of problem: +Qemu doesn't process -object secret lines when read from a config file. This results in the new spice password-secret option failing with error: No secret with id '\<theid\>' +Steps to reproduce: +1. Create a password file +``` +printf "password" > passfile.pw +``` +2. Start qemu with command line options and also write to a config file +``` +qemu-system-x86_64 \ + -object secret,id=spicepwd,format=raw,file=passfile.pw \ + -spice port=5901,password-secret=spicepwd \ + -writeconfig qemu.cfg +``` +3. Optional: Connect using spice client and password: "password" +4. Exit qemu and cat qemu.cfg and verify it looks okay with equivalent options to what was specified on the command line +5. Now attempt to start qemu and read the options using the config file +``` +qemu-system-x86_64 -readconfig qemu.cfg +``` +6. This fails with an error: +``` +qemu-system-x86_64: No secret with id 'spicepwd' +``` diff --git a/results/classifier/105/instruction/485 b/results/classifier/105/instruction/485 new file mode 100644 index 00000000..80ffae86 --- /dev/null +++ b/results/classifier/105/instruction/485 @@ -0,0 +1,14 @@ +instruction: 0.695 +device: 0.666 +graphic: 0.520 +semantic: 0.338 +mistranslation: 0.333 +network: 0.311 +boot: 0.213 +assembly: 0.143 +vnc: 0.095 +other: 0.047 +KVM: 0.029 +socket: 0.005 + +Failed to restore domain - error load load virtio-balloon:virtio diff --git a/results/classifier/105/instruction/493 b/results/classifier/105/instruction/493 new file mode 100644 index 00000000..d5c483ec --- /dev/null +++ b/results/classifier/105/instruction/493 @@ -0,0 +1,20 @@ +instruction: 0.857 +graphic: 0.849 +device: 0.810 +semantic: 0.644 +vnc: 0.466 +other: 0.461 +socket: 0.369 +mistranslation: 0.368 +network: 0.353 +boot: 0.272 +assembly: 0.130 +KVM: 0.064 + +RISC-V: Setting mtimecmp to -1 immediately triggers an interrupt +Description of problem: +When setting mtimecmp to -1, which should set a timer infinitely far in the future, a timer interrupt is triggered immediately. This happens for most values over 2^61. It is the same for both 32-bit and 64-bit, and for M-mode writing to mtimecmp directly and S-mode using OpenSBI. + +I have looked through the source code, and the problem is in the function `sifive_clint_write_mtimecmp`, in the file `/hw/intc/sifive_clint.c`. First, the muldiv64 multiplies diff with 100, causing an overflow (at least for -M virt, other machines might use a different timebase_freq). Then, the unsigned `next` is passed to `timer_mod`, which takes a signed integer. In `timer_mod_ns_locked` the value is set to `MAX(next, 0)`, which means that if the MSB of `next` was set, the interrupt happens immediately. This means that it is impossible to set timers more than 2^63 nanoseconds in the future. + +This problem basically only affects programs which disable timer interrupts by setting the next one infinitely far in the future. However, the SBI doc specifically says that this is a valid approach, so it should be supported. Using the MSB doesn't work without changing code functionality in QEMU, but it should be sufficient to cap `next` at the maximum signed value. diff --git a/results/classifier/105/instruction/498417 b/results/classifier/105/instruction/498417 new file mode 100644 index 00000000..5eeeffbc --- /dev/null +++ b/results/classifier/105/instruction/498417 @@ -0,0 +1,53 @@ +instruction: 0.551 +other: 0.524 +device: 0.451 +assembly: 0.427 +graphic: 0.413 +semantic: 0.411 +vnc: 0.385 +network: 0.363 +socket: 0.350 +mistranslation: 0.337 +KVM: 0.291 +boot: 0.268 + +cache=writeback on disk image doesn't do write-back + +I noticed that qemu seems to have poor disk performance. Here's a test that has miserable performance but which should be really fast: + +- Configure qemu to use the disk image with cache=writeback +- Configure a 2GiB Linux VM on an 8GiB Linux host +- In the VM, write a 4GiB file (dd if=/dev/zero of=/tmp/x bs=4K count=1M) +- In the VM, read it back (dd if=/tmp/x of=/dev/null bs=4K count=1M) + +With writeback, the whole file should end up in the host pagecache. So when I read it back, there should be no I/O to the real disk, and it should be really fast. Instead, I see disk activity through the duration of the test, and the performance is roughly the native hard disk throughput (somewhat slower). + +I'm using version 0.11.1, and this is my command line: + +qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -enable-kvm & + +Can you please try reproducing with 0.12.1? + +I'm using 0.12.1.2. With this command line: + +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 & + +Here's what I'm seeing: + +With "dd if=/dev/zero of=./x bs=1024k count=1024", I get at best 29 MiB/sec. + +This fits in the VM, so with "dd if=/dev/zero of=./x bs=1024k count=1024", which spills into the host, I get at best 25 MiB/sec. (I am aware that with the expanding qcow2 disk image, there's also some overhead for allocating space during the write, so I run the same test multiple times and report the best result.) + +Since I'm using writeback, I would expect to see much faster write performance. This is slower than the host's disk performance with fsync involved. Is there an fsync going on here? Is dd doing an fsync? That should sync the VM's disk. But then is there an ATA command to sync the drive that qemu interprets as a request to sync the disk image? It would be "safe" to take this hint, but since I'm explicitly requesting writeback, I'm not expecting "safe". I'm intentionally defeating "safe" for the sake of performance, with full knowledge of the risks. + +With "dd if=./x of=/dev/null bs=1024k count=1024", it varies a LOT, but I've gotten as much as 4.9GiB/sec and as little as 2.5GiB/sec. This is WAY better than what I was getting with 0.11.1. + +With "dd if=./x of=/dev/null bs=1024k count=4096", the best I get is 460MiB/sec. That's still very good. Could be better, but the overhead of emulating SATA has got to be really high under any circumstances. + +Using a VM imposes a lot of overhead that makes the guest OS quite a bit slower than running it directly on the hardware. I'm trying to make up for this by using the rest of my hosts RAM (more or less) as a huge disk cache. + + +QEMU 0.11 / 0.12 is pretty much outdated nowadays ... 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/105/instruction/50773216 b/results/classifier/105/instruction/50773216 new file mode 100644 index 00000000..1b6ac4ad --- /dev/null +++ b/results/classifier/105/instruction/50773216 @@ -0,0 +1,118 @@ +instruction: 0.768 +device: 0.764 +other: 0.737 +graphic: 0.723 +semantic: 0.669 +vnc: 0.656 +socket: 0.652 +mistranslation: 0.652 +boot: 0.637 +assembly: 0.623 +network: 0.606 +KVM: 0.601 + +[Qemu-devel] Can I have someone's feedback on [bug 1809075] Concurrency bug on keyboard events: capslock LED messing up keycode streams causes character misses at guest kernel + +Hi everyone. +Can I please have someone's feedback on this bug? +https://bugs.launchpad.net/qemu/+bug/1809075 +Briefly, guest OS loses characters sent to it via vnc. And I spot the +bug in relation to ps2 driver. +I'm thinking of possible fixes and I might want to use a memory barrier. +But I would really like to have some suggestion from a qemu developer +first. For example, can we brutally drop capslock LED key events in ps2 +queue? +It is actually relevant to openQA, an automated QA tool for openSUSE. +And this bug blocks a few test cases for us. +Thank you in advance! + +Kind regards, +Gao Zhiyuan + +Cc'ing Marc-André & Gerd. + +On 12/19/18 10:31 AM, Gao Zhiyuan wrote: +> +Hi everyone. +> +> +Can I please have someone's feedback on this bug? +> +https://bugs.launchpad.net/qemu/+bug/1809075 +> +Briefly, guest OS loses characters sent to it via vnc. And I spot the +> +bug in relation to ps2 driver. +> +> +I'm thinking of possible fixes and I might want to use a memory barrier. +> +But I would really like to have some suggestion from a qemu developer +> +first. For example, can we brutally drop capslock LED key events in ps2 +> +queue? +> +> +It is actually relevant to openQA, an automated QA tool for openSUSE. +> +And this bug blocks a few test cases for us. +> +> +Thank you in advance! +> +> +Kind regards, +> +Gao Zhiyuan +> + +On Thu, Jan 03, 2019 at 12:05:54PM +0100, Philippe Mathieu-Daudé wrote: +> +Cc'ing Marc-André & Gerd. +> +> +On 12/19/18 10:31 AM, Gao Zhiyuan wrote: +> +> Hi everyone. +> +> +> +> Can I please have someone's feedback on this bug? +> +> +https://bugs.launchpad.net/qemu/+bug/1809075 +> +> Briefly, guest OS loses characters sent to it via vnc. And I spot the +> +> bug in relation to ps2 driver. +> +> +> +> I'm thinking of possible fixes and I might want to use a memory barrier. +> +> But I would really like to have some suggestion from a qemu developer +> +> first. For example, can we brutally drop capslock LED key events in ps2 +> +> queue? +There is no "capslock LED key event". 0xfa is KBD_REPLY_ACK, and the +device queues it in response to guest port writes. Yes, the ack can +race with actual key events. But IMO that isn't a bug in qemu. + +Probably the linux kernel just throws away everything until it got the +ack for the port write, and that way the key event gets lost. On +physical hardware you will not notice because it is next to impossible +to type fast enough to hit the race window. + +So, go fix the kernel. + +Alternatively fix vncdotool to send uppercase letters properly with +shift key pressed. Then qemu wouldn't generate capslock key events +(that happens because qemu thinks guest and host capslock state is out +of sync) and the guests's capslock led update request wouldn't get into +the way. + +cheers, + Gerd + diff --git a/results/classifier/105/instruction/509 b/results/classifier/105/instruction/509 new file mode 100644 index 00000000..a8656fca --- /dev/null +++ b/results/classifier/105/instruction/509 @@ -0,0 +1,14 @@ +instruction: 0.807 +device: 0.545 +graphic: 0.357 +other: 0.245 +mistranslation: 0.121 +boot: 0.095 +semantic: 0.064 +network: 0.047 +vnc: 0.033 +assembly: 0.030 +socket: 0.024 +KVM: 0.012 + +Atomic test-and-set instruction does not work on qemu-user diff --git a/results/classifier/105/instruction/514 b/results/classifier/105/instruction/514 new file mode 100644 index 00000000..f973fe24 --- /dev/null +++ b/results/classifier/105/instruction/514 @@ -0,0 +1,38 @@ +instruction: 0.922 +device: 0.778 +graphic: 0.745 +semantic: 0.631 +mistranslation: 0.623 +vnc: 0.549 +assembly: 0.514 +boot: 0.468 +socket: 0.457 +network: 0.427 +other: 0.370 +KVM: 0.335 + +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/105/instruction/516 b/results/classifier/105/instruction/516 new file mode 100644 index 00000000..d6f6ef7e --- /dev/null +++ b/results/classifier/105/instruction/516 @@ -0,0 +1,55 @@ +instruction: 0.850 +device: 0.747 +other: 0.673 +semantic: 0.614 +socket: 0.577 +boot: 0.564 +mistranslation: 0.563 +graphic: 0.560 +vnc: 0.548 +network: 0.545 +KVM: 0.469 +assembly: 0.425 + +Configure option `--enable-plugins` makes modules in shared library not loadable on macOS +Description of problem: +The title mentions `--enable-plugins` option, however as it's enabled by default, not providing `--disable-plugins` would also cause this to happen. + +If TCG plugin support is enabled, symbols in `qemu-system-*` binaries will be missing, and module libraries would fail to load as they expect those symbols to exist in the main binary. + +Configure options used: `STRIP="strip -x" ./configure --enable-user --enable-tools --enable-parallels --enable-libxml2 --enable-spice --enable-hvf --enable-cocoa --enable-guest-agent --enable-curses --enable-plugins --enable-modules --objcc=gcc --enable-libusb --enable-usb-redir` + +After inspecting the compiler command line, I've found the linker option `-Wl,-exported_symbols_list,qemu-plugins-ld64.symbols` is causing this to happen: only symbols listed in `qemu-plugins-ld64.symbols` would be kept in `qemu-system-*` binaries and all other symbols will be hidden. + +Note that this is not caused by stripping (although I had to use custom strip command line on macOS to successfully compile qemu); the option `-exported_symbols_list` works by only exposing the provided symbols and treating all other symbols as `visibility=hidden`. + +Replacing `--enable-plugins` to `--disable-plugins` in the above configure command line would "fix" it, although it means TCG plugins will not be supported. +Steps to reproduce: +1. Build QEMU on macOS with plugin support enabled +2. Try to use modules in shared library like qxl +Additional information: +Some examples: + +``` +$ qemu-system-x86_64 -device qxl +Failed to open module: dlopen(/usr/local/bin/../lib/qemu/ui-spice-core.dylib, 10): Symbol not found: __TRACE_QEMU_SPICE_ADD_MEMSLOT_DSTATE + Referenced from: /usr/local/bin/../lib/qemu/ui-spice-core.dylib + Expected in: flat namespace + in /usr/local/bin/../lib/qemu/ui-spice-core.dylib +Failed to open module: dlopen(/usr/local/bin/../lib/qemu/hw-display-qxl.dylib, 2): Symbol not found: __TRACE_QXL_CLIENT_MONITORS_CONFIG_CAPPED_DSTATE + Referenced from: /usr/local/bin/../lib/qemu/hw-display-qxl.dylib + Expected in: flat namespace + in /usr/local/bin/../lib/qemu/hw-display-qxl.dylib +qemu-system-x86_64: -device qxl: 'qxl' is not a valid device model name +``` + +``` +$ qemu-system-x86_64 -spice port=5901 +Failed to open module: dlopen(/usr/local/bin/../lib/qemu/ui-spice-core.dylib, 10): Symbol not found: __TRACE_QEMU_SPICE_ADD_MEMSLOT_DSTATE + Referenced from: /usr/local/bin/../lib/qemu/ui-spice-core.dylib + Expected in: flat namespace + in /usr/local/bin/../lib/qemu/ui-spice-core.dylib +qemu-system-x86_64: -spice port=5901: spice support is disabled +``` + +After disabling plugin support I could run virtual machines locally through libvirt with full spice and qxl video support. diff --git a/results/classifier/105/instruction/521 b/results/classifier/105/instruction/521 new file mode 100644 index 00000000..df0c1b95 --- /dev/null +++ b/results/classifier/105/instruction/521 @@ -0,0 +1,14 @@ +instruction: 0.941 +semantic: 0.897 +mistranslation: 0.802 +device: 0.563 +other: 0.439 +graphic: 0.262 +assembly: 0.205 +boot: 0.164 +network: 0.123 +socket: 0.055 +vnc: 0.036 +KVM: 0.022 + +Assert mr != NULL through megaraid diff --git a/results/classifier/105/instruction/533 b/results/classifier/105/instruction/533 new file mode 100644 index 00000000..b25888c0 --- /dev/null +++ b/results/classifier/105/instruction/533 @@ -0,0 +1,14 @@ +instruction: 0.848 +network: 0.830 +device: 0.604 +mistranslation: 0.450 +graphic: 0.384 +semantic: 0.283 +boot: 0.215 +vnc: 0.157 +assembly: 0.059 +socket: 0.037 +other: 0.024 +KVM: 0.016 + +Assertion failure in vmxnet3_get_next_body_rx_descr: d->btype == VMXNET3_RXD_BTYPE_BODY diff --git a/results/classifier/105/instruction/543 b/results/classifier/105/instruction/543 new file mode 100644 index 00000000..c9f43625 --- /dev/null +++ b/results/classifier/105/instruction/543 @@ -0,0 +1,14 @@ +instruction: 0.975 +device: 0.828 +network: 0.750 +semantic: 0.705 +graphic: 0.595 +mistranslation: 0.574 +boot: 0.401 +vnc: 0.314 +assembly: 0.141 +other: 0.079 +socket: 0.040 +KVM: 0.009 + +virtio-blk: ASSERT: !s->dataplane_started diff --git a/results/classifier/105/instruction/544 b/results/classifier/105/instruction/544 new file mode 100644 index 00000000..ac8f41a0 --- /dev/null +++ b/results/classifier/105/instruction/544 @@ -0,0 +1,14 @@ +instruction: 0.908 +network: 0.820 +device: 0.796 +semantic: 0.610 +mistranslation: 0.588 +graphic: 0.401 +assembly: 0.342 +vnc: 0.156 +boot: 0.149 +socket: 0.105 +other: 0.054 +KVM: 0.043 + +Assert xfer->packet.status != USB_RET_NAK in xhci diff --git a/results/classifier/105/instruction/545 b/results/classifier/105/instruction/545 new file mode 100644 index 00000000..6b4bf246 --- /dev/null +++ b/results/classifier/105/instruction/545 @@ -0,0 +1,14 @@ +instruction: 0.874 +mistranslation: 0.705 +graphic: 0.635 +device: 0.400 +semantic: 0.329 +boot: 0.291 +assembly: 0.133 +network: 0.050 +other: 0.042 +vnc: 0.037 +KVM: 0.021 +socket: 0.016 + +Abort in ohci_frame_boundary diff --git a/results/classifier/105/instruction/551 b/results/classifier/105/instruction/551 new file mode 100644 index 00000000..e0b11e35 --- /dev/null +++ b/results/classifier/105/instruction/551 @@ -0,0 +1,14 @@ +instruction: 0.926 +graphic: 0.600 +device: 0.526 +assembly: 0.189 +other: 0.090 +semantic: 0.082 +boot: 0.061 +vnc: 0.058 +network: 0.053 +mistranslation: 0.052 +socket: 0.022 +KVM: 0.007 + +Null-ptr dereference in megasas_command_complete diff --git a/results/classifier/105/instruction/584 b/results/classifier/105/instruction/584 new file mode 100644 index 00000000..d9e7972f --- /dev/null +++ b/results/classifier/105/instruction/584 @@ -0,0 +1,56 @@ +instruction: 0.943 +device: 0.886 +graphic: 0.866 +semantic: 0.726 +vnc: 0.713 +other: 0.692 +mistranslation: 0.690 +network: 0.658 +boot: 0.632 +socket: 0.595 +assembly: 0.390 +KVM: 0.244 + +qemu-system-ppc: extra IPI interrupt on core0 +Description of problem: +When I try to emit an IPI interrupt from core0 to another core via the MPIC controller(IPIDR1—Interprocessor interrupt dispatch register 1), core0 itself generates an unwanted IPI interrupt. +Steps to reproduce: +1. Prepare ISR routine, something like: + + void ipi_handler (void) + { + int core_id = CORE_ID_GET(); + myprintf("\n IPI interrupt triggered on core:%d\n",core_id); + } +2. Create a task and bind it to core0. This task is mainly to write the MPIC controller to emit IPI interrupts to other cores. + MPIC_REG_WRITE(MPIC_BASE + IPIDR1, **0xe**); + +3. run the test task +Additional information: +/* Below test was tested on Qemu6.1 */ + +IPI interrupts are emitted by core:0 + +**IPI interrupt triggered on core:0** /* it's a bug, it should not trigger on core 0. */ + +IPI interrupt triggered on core:1 + +IPI interrupt triggered on core:2 + +IPI interrupt triggered on core:3 + + +This bug only occurs when "emitting an IPIDR1 interrupt from **core0**". + +------------ + + +/* Below test was tested on real board(fsl_p4080ds) */ + +IPI interrupts are emitted by core:0 + +IPI interrupt triggered on core:1 + +IPI interrupt triggered on core:2 + +IPI interrupt triggered on core:3 diff --git a/results/classifier/105/instruction/597575 b/results/classifier/105/instruction/597575 new file mode 100644 index 00000000..5b2ade44 --- /dev/null +++ b/results/classifier/105/instruction/597575 @@ -0,0 +1,50 @@ +instruction: 0.711 +boot: 0.698 +graphic: 0.678 +KVM: 0.677 +device: 0.648 +other: 0.600 +mistranslation: 0.581 +vnc: 0.576 +semantic: 0.563 +network: 0.561 +assembly: 0.546 +socket: 0.542 + +Hangs on HTTP errors when using the curl block driver + +Hi, + +It seems that qemu-kvm does not handle HTTP errors gracefully when using the curl block driver and a synchronous request is made (i.e. one using bdrv_read_em() for example). In these cases, if an HTTP error (such as 404 or 416) is returned, the aio thread exits but the main thread never finishes waiting for I/O completion, thus freezing KVM. + +Versions affected: +At least 0.11.1 and 0.12.4 were tested and found to be affected. + +How to reproduce: +Simply specify a non-existing path for an HTTP URL as a CDROM drive. +kvm -drive file=test.img,format=qcow2,if=ide,index=0,boot=on -drive file=http://127.0.0.1/static/test1.iso,media=cdrom,index=2,if=ide -boot c + +qemu-kvm will hang on boot using 100% cpu as it will try to open the block device. At that point, the backtrace is (qemu-kvm-0.12.4): + +#0 0x000000000047aaaf in qemu_aio_wait () at aio.c:163 +#1 0x000000000047a055 in bdrv_read_em (bs=0x1592320, sector_num=0, buf=0x7fffcf7e9ae0 "¨\237~Ïÿ\177", nb_sectors=4) + at block.c:1939 +#2 0x0000000000479c0e in bdrv_pread (bs=0x1592320, offset=<value optimized out>, buf=0x7fffcf7e9ae0, count1=2048) + at block.c:716 +#3 0x000000000047a862 in bdrv_open2 (bs=0x1591a30, filename=0x1559f00 "http://127.0.0.1/static/test1.iso", + flags=0, drv=0x84eca0) at block.c:316 +#4 0x000000000040dcb4 in drive_init (opts=0x1559e60, opaque=<value optimized out>, fatal_error=0x7fffcf7ea494) + at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2471 +#5 0x000000000040e086 in drive_init_func (opts=0x155db00, opaque=0x0) + at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2488 +#6 0x0000000000475421 in qemu_opts_foreach (list=<value optimized out>, func=0x40e070 <drive_init_func>, + opaque=0x8495e0, abort_on_failure=12) at qemu-option.c:817 +#7 0x000000000040e9af in main (argc=7, argv=0x7fffcf7ea838, envp=<value optimized out>) + at /build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:6011 + +Thanks + +QEMU 0.11 / 0.12 are pretty much outdated nowadays ... 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/105/instruction/60 b/results/classifier/105/instruction/60 new file mode 100644 index 00000000..b1ebd851 --- /dev/null +++ b/results/classifier/105/instruction/60 @@ -0,0 +1,14 @@ +instruction: 0.698 +device: 0.602 +network: 0.504 +graphic: 0.481 +assembly: 0.372 +socket: 0.141 +semantic: 0.134 +vnc: 0.122 +boot: 0.090 +mistranslation: 0.044 +other: 0.029 +KVM: 0.001 + +qemu-system-aarch64 (tcg): cval + voff overflow not handled, causes qemu to hang diff --git a/results/classifier/105/instruction/613 b/results/classifier/105/instruction/613 new file mode 100644 index 00000000..f3ec7a0a --- /dev/null +++ b/results/classifier/105/instruction/613 @@ -0,0 +1,14 @@ +instruction: 0.952 +device: 0.892 +graphic: 0.550 +mistranslation: 0.440 +boot: 0.406 +network: 0.197 +semantic: 0.191 +assembly: 0.142 +other: 0.127 +vnc: 0.069 +socket: 0.044 +KVM: 0.001 + +ARM cortex-m55 LOB instructions make QEMU crash diff --git a/results/classifier/105/instruction/616769 b/results/classifier/105/instruction/616769 new file mode 100644 index 00000000..7f27e60e --- /dev/null +++ b/results/classifier/105/instruction/616769 @@ -0,0 +1,52 @@ +instruction: 0.846 +graphic: 0.711 +semantic: 0.660 +device: 0.634 +network: 0.524 +other: 0.502 +mistranslation: 0.497 +boot: 0.456 +socket: 0.453 +vnc: 0.424 +KVM: 0.299 +assembly: 0.151 + +interrupt problem x86_64 + +Hello. +I'm studing the x86_64 arch to port colinux to this new architecture. + +For who does not know, colinux is a port of linux that runs on windows NATIVELY. Colinux is +1) a small windows driver +2) a kernel patched +3) some windows user-space application that talk with linux kernel (network, console, ...) + +I have written the more internal part of colinux, that is the code that switch between windows and linux. +This is done saving and restore the machine state : +1) CR3 +2) IDT +3) registers + +The problem I see is that after the switch I see the reboot of my virtual machine. +I would say that the new IDT and/or CR3 is not flushed. +My code is written in asm/C so I can follow the code step by step. +I can say exactly the instruction that is broken. + +All my code runs nicely on bochs. +I don't have an x86_64 real PC. + +If someone wants to repair this bug .... I'm here. + +Paolo Minazzi + +Which version of QEMU did you use when you encountered this problem? Can you still reproduce this issue with the latest version of QEMU? + +Hello Thomas, +it happens some years ago and now I'm not able to reproduce it. +I'm sorry, +thanks again, +Paolo + + +OK, thanks a lot for your response ... so let's close this bug now. + diff --git a/results/classifier/105/instruction/619 b/results/classifier/105/instruction/619 new file mode 100644 index 00000000..35fa85f1 --- /dev/null +++ b/results/classifier/105/instruction/619 @@ -0,0 +1,14 @@ +instruction: 0.725 +mistranslation: 0.415 +device: 0.342 +graphic: 0.308 +semantic: 0.223 +KVM: 0.094 +boot: 0.084 +other: 0.063 +vnc: 0.060 +network: 0.056 +assembly: 0.042 +socket: 0.019 + +Move TCGCPUOps::fake_user_exception() to linux-user/i386/cpu_loop.c diff --git a/results/classifier/105/instruction/62 b/results/classifier/105/instruction/62 new file mode 100644 index 00000000..4c435dd0 --- /dev/null +++ b/results/classifier/105/instruction/62 @@ -0,0 +1,14 @@ +instruction: 0.952 +device: 0.765 +assembly: 0.599 +boot: 0.530 +network: 0.471 +graphic: 0.419 +semantic: 0.146 +mistranslation: 0.140 +vnc: 0.047 +other: 0.029 +KVM: 0.016 +socket: 0.015 + +[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines diff --git a/results/classifier/105/instruction/625 b/results/classifier/105/instruction/625 new file mode 100644 index 00000000..7aa1c0ce --- /dev/null +++ b/results/classifier/105/instruction/625 @@ -0,0 +1,36 @@ +instruction: 0.832 +graphic: 0.799 +device: 0.746 +mistranslation: 0.424 +vnc: 0.371 +semantic: 0.360 +assembly: 0.279 +boot: 0.198 +network: 0.176 +socket: 0.152 +KVM: 0.149 +other: 0.074 + +qemu-hppa floating point POWER function is incorrect +Description of problem: +The floating point power function produces incorrect values, and possibly stack misshapes as well. +Steps to reproduce: +1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static +2. $ qemu-hppa pow +3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45 +Additional information: +Example C source to reproduce, pow.c: +``` +#include <stdio.h> +#include <math.h> +int main() +{ + double base, expo, res; + base=10.0; + expo=6.0; + // res sould be 1e+6 + res = pow(base, expo); + printf("%.1lf^%.1lf = %.2lf\n", base, expo, res); + return 0; +} +``` diff --git a/results/classifier/105/instruction/632 b/results/classifier/105/instruction/632 new file mode 100644 index 00000000..eb6e54f7 --- /dev/null +++ b/results/classifier/105/instruction/632 @@ -0,0 +1,14 @@ +instruction: 0.924 +semantic: 0.793 +mistranslation: 0.753 +device: 0.659 +assembly: 0.544 +graphic: 0.474 +network: 0.469 +other: 0.376 +vnc: 0.294 +boot: 0.291 +socket: 0.250 +KVM: 0.250 + +We should document "make install DESTDIR=wherever" diff --git a/results/classifier/105/instruction/63565653 b/results/classifier/105/instruction/63565653 new file mode 100644 index 00000000..f8eda550 --- /dev/null +++ b/results/classifier/105/instruction/63565653 @@ -0,0 +1,57 @@ +instruction: 0.905 +other: 0.898 +device: 0.889 +boot: 0.889 +network: 0.861 +KVM: 0.827 +semantic: 0.825 +socket: 0.745 +graphic: 0.734 +vnc: 0.588 +assembly: 0.571 +mistranslation: 0.462 + +[Qemu-devel] [BUG]pcibus_reset assertion failure on guest reboot + +Qemu-2.6.2 + +Start a vm with vhost-net , do reboot and hot-unplug viritio-net nic in short +time, we touch +pcibus_reset assertion failure. + +Here is qemu log: +22:29:46.359386+08:00 acpi_pm1_cnt_write -> guest do soft power off +22:29:46.785310+08:00 qemu_devices_reset +22:29:46.788093+08:00 virtio_pci_device_unplugged -> virtio net unpluged +22:29:46.803427+08:00 pcibus_reset: Assertion `bus->irq_count[i] == 0' failed. + +Here is stack info: +(gdb) bt +#0 0x00007f9a336795d7 in raise () from /usr/lib64/libc.so.6 +#1 0x00007f9a3367acc8 in abort () from /usr/lib64/libc.so.6 +#2 0x00007f9a33672546 in __assert_fail_base () from /usr/lib64/libc.so.6 +#3 0x00007f9a336725f2 in __assert_fail () from /usr/lib64/libc.so.6 +#4 0x0000000000641884 in pcibus_reset (qbus=0x29eee60) at hw/pci/pci.c:283 +#5 0x00000000005bfc30 in qbus_reset_one (bus=0x29eee60, opaque=<optimized +out>) at hw/core/qdev.c:319 +#6 0x00000000005c1b19 in qdev_walk_children (dev=0x29ed2b0, pre_devfn=0x0, +pre_busfn=0x0, post_devfn=0x5c2440 ... +#7 0x00000000005c1c59 in qbus_walk_children (bus=0x2736f80, pre_devfn=0x0, +pre_busfn=0x0, post_devfn=0x5c2440 ... +#8 0x00000000005513f5 in qemu_devices_reset () at vl.c:1998 +#9 0x00000000004cab9d in pc_machine_reset () at +/home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/i386/pc.c:1976 +#10 0x000000000055148b in qemu_system_reset (address@hidden) at vl.c:2011 +#11 0x000000000055164f in main_loop_should_exit () at vl.c:2169 +#12 0x0000000000551719 in main_loop () at vl.c:2212 +#13 0x000000000041c9a8 in main (argc=<optimized out>, argv=<optimized out>, +envp=<optimized out>) at vl.c:5130 +(gdb) f 4 +... +(gdb) p bus->irq_count[0] +$6 = 1 + +Seems pci_update_irq_disabled doesn't work well + +can anyone help? + diff --git a/results/classifier/105/instruction/636095 b/results/classifier/105/instruction/636095 new file mode 100644 index 00000000..00b1294b --- /dev/null +++ b/results/classifier/105/instruction/636095 @@ -0,0 +1,62 @@ +instruction: 0.765 +vnc: 0.554 +device: 0.458 +semantic: 0.435 +network: 0.428 +assembly: 0.351 +socket: 0.320 +other: 0.249 +mistranslation: 0.238 +graphic: 0.216 +boot: 0.121 +KVM: 0.098 + +tap downscript is not executed when exiting qemu through "quit" monitor command + +When you tell qemu to shutdown using the "quit" monitor command, the downscript of the tap interface is not executed. + + +To reproduce: + + +Create the test script /tmp/qemu-ifdown-test.sh : + +== +#!/bin/bash + +touch /tmp/is_this_working +== + +Run: + +== +# chmod +x /tmp/qemu-ifdown-test.sh +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# nc -U /tmp/monitor.socket +QEMU 0.12.5 monitor - type 'help' for more information +(qemu) quit +quit +# ls /tmp/is* +ls: cannot access /tmp/is*: No such file or directory + +== + +If I quit qemu by sending a SIGTERM instead of using the "quit" command, the downscript does get executed: + +== +# qemu-system-x86_64 -daemonize -net nic -net tap,script=/etc/qemu-ifup,downscript=/tmp/qemu-ifdown-test.sh -monitor unix:/tmp/monitor.socket,nowait,server +VNC server running on `127.0.0.1:5900' +# killall qemu-system-x86_64 +# ls /tmp/is* +/tmp/is_this_working +== + +Issue occurs with both 0.12.3 and 0.12.5 + +Have you reported this to QEMU developers' mailing list? + +Thanks for providing instructions on how to reproduce this bug. I ran your instructions on qemu.git/master and the issue does not occur. + +QEMU 0.12.x is old, please try the latest stable release 0.15.0 or qemu.git/master. + diff --git a/results/classifier/105/instruction/643 b/results/classifier/105/instruction/643 new file mode 100644 index 00000000..5f654b3f --- /dev/null +++ b/results/classifier/105/instruction/643 @@ -0,0 +1,14 @@ +instruction: 0.826 +assembly: 0.503 +device: 0.451 +socket: 0.285 +network: 0.247 +graphic: 0.211 +semantic: 0.179 +vnc: 0.176 +boot: 0.112 +mistranslation: 0.096 +other: 0.073 +KVM: 0.004 + +how to add include path and library path when building qemu-4.1.1 diff --git a/results/classifier/105/instruction/646 b/results/classifier/105/instruction/646 new file mode 100644 index 00000000..8e9c27a1 --- /dev/null +++ b/results/classifier/105/instruction/646 @@ -0,0 +1,31 @@ +instruction: 0.840 +device: 0.832 +graphic: 0.723 +network: 0.717 +socket: 0.713 +vnc: 0.701 +other: 0.618 +boot: 0.543 +semantic: 0.541 +KVM: 0.334 +assembly: 0.243 +mistranslation: 0.230 + +Infinite loop in xhci_ring_chain_length() in hw/usb/hcd-xhci.c (CVE-2020-14394) +Description of problem: +An infinite loop issue was found in the USB xHCI controller emulation of QEMU. Specifically, function `xhci_ring_chain_length()` in hw/usb/hcd-xhci.c may get stuck while fetching empty TRBs from guest memory, since the exit conditions of the loop depend on values that are fully controlled by guest. A privileged guest user may exploit this issue to hang the QEMU process on the host, resulting in a denial of service. +Steps to reproduce: +Build and load `xhci.ko` from within the guest: + +1) make +2) insmod xhci.ko + +[Makefile](/uploads/98dbf7b4facc9b100817b3c8f63b5cb2/Makefile) + +[usb-xhci.h](/uploads/f225524b1553d8cf6c1dfa89369b6edc/usb-xhci.h) + +[xhci.c](/uploads/c635f742d12a2bba6ea472ddfe006d56/xhci.c) +Additional information: +This issue was reported by Gaoning Pan (Zhejiang University) and Xingwei Li (Ant Security Light-Year Lab). + +RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1908004. diff --git a/results/classifier/105/instruction/652 b/results/classifier/105/instruction/652 new file mode 100644 index 00000000..0b16ca48 --- /dev/null +++ b/results/classifier/105/instruction/652 @@ -0,0 +1,41 @@ +instruction: 0.838 +device: 0.704 +mistranslation: 0.698 +semantic: 0.665 +graphic: 0.640 +vnc: 0.474 +network: 0.429 +socket: 0.426 +boot: 0.382 +other: 0.306 +KVM: 0.266 +assembly: 0.207 + +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/105/instruction/657329 b/results/classifier/105/instruction/657329 new file mode 100644 index 00000000..5a2fb71e --- /dev/null +++ b/results/classifier/105/instruction/657329 @@ -0,0 +1,66 @@ +instruction: 0.698 +device: 0.693 +graphic: 0.618 +semantic: 0.569 +other: 0.482 +socket: 0.261 +mistranslation: 0.208 +vnc: 0.204 +boot: 0.182 +network: 0.160 +assembly: 0.122 +KVM: 0.105 + +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/105/instruction/664 b/results/classifier/105/instruction/664 new file mode 100644 index 00000000..c5aef0e9 --- /dev/null +++ b/results/classifier/105/instruction/664 @@ -0,0 +1,27 @@ +instruction: 0.918 +device: 0.790 +graphic: 0.737 +mistranslation: 0.722 +vnc: 0.678 +socket: 0.655 +network: 0.641 +semantic: 0.561 +boot: 0.533 +other: 0.512 +KVM: 0.489 +assembly: 0.277 + +hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID +Description of problem: +When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors. +Steps to reproduce: +This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines: +``` +[Kernel]: CPU[0]: Physical address bit width: 36 +[Kernel]: CPU[0]: Virtual address bit width: 32 +``` +But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001. +Additional information: +The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values. + +NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information. diff --git a/results/classifier/105/instruction/670 b/results/classifier/105/instruction/670 new file mode 100644 index 00000000..81783734 --- /dev/null +++ b/results/classifier/105/instruction/670 @@ -0,0 +1,23 @@ +instruction: 0.842 +boot: 0.811 +device: 0.780 +other: 0.740 +graphic: 0.723 +mistranslation: 0.613 +semantic: 0.608 +socket: 0.513 +vnc: 0.483 +network: 0.446 +assembly: 0.217 +KVM: 0.031 + +qemu x86_64 for microsoft windows hangs when booting a Debian Live 11.1 iso file +Description of problem: +qemu displays the boot screen from the live linux iso and starts the boot, but no more display is performed even when waiting for approximately 30 minutes +Steps to reproduce: +1. Get hold of a Live Linux iso from Debian 11.1 +2. Set up the Microsoft Windows version of qemu from https://qemu.weilnetz.de/ +3. Attempt to boot the Live Linux iso +Additional information: +I also tested older versions of QEMU from the Weilnetz web site. 6.0.0 and 5.2.0 are bad; 5.1.0 and older are good. I then tested the same command line ( no acceleration ) under Linux Tumbleweed 20211014 with qemu 6.1.0 and the iso booted successfully. I have not tried with isos from distributions other than Debian 11.1 . So there is a bug with the Microsoft Windows-specific code in qemu. +If you need the specific Live Linux that I was using, let me know and I will get it to you somehow. It is several GB in size so I cannot upload it anywhere conveniently. diff --git a/results/classifier/105/instruction/674740 b/results/classifier/105/instruction/674740 new file mode 100644 index 00000000..98352df5 --- /dev/null +++ b/results/classifier/105/instruction/674740 @@ -0,0 +1,35 @@ +instruction: 0.656 +device: 0.573 +graphic: 0.562 +semantic: 0.485 +mistranslation: 0.466 +other: 0.376 +network: 0.376 +socket: 0.215 +vnc: 0.206 +boot: 0.092 +KVM: 0.068 +assembly: 0.059 + +qemu segfaults when security_model=none using virtio-9p-pci driver + +qemu version: 0.13 +commit-id: 6ed912999d6ef636a5be5ccb266d7d3c0f0310b4 + +example invocation: +$ qemu -virtfs local,path=/tmp,security_model=none,mount_tag=mmm r.img +one of the following must be specified as thesecurity option: + security_model=passthrough + security_model=mapped +Segmentation fault + +Patch is attached. Also attached is a patch that addes the space between 'the' and 'security' in 'thesecurity'. + +Does not affect trunk. + + + +Add the space in 'thesecurity'. + +Current QEMU 2.7 does not segfault here anymore, and the "thesecurity" problem is also not available in the sources anymore ==> I think this can be closed nowadays. + diff --git a/results/classifier/105/instruction/682326 b/results/classifier/105/instruction/682326 new file mode 100644 index 00000000..0a2c00dc --- /dev/null +++ b/results/classifier/105/instruction/682326 @@ -0,0 +1,31 @@ +instruction: 0.466 +device: 0.459 +graphic: 0.414 +network: 0.208 +semantic: 0.178 +socket: 0.107 +other: 0.055 +mistranslation: 0.052 +boot: 0.048 +vnc: 0.028 +assembly: 0.025 +KVM: 0.011 + +linux-user/mmap exhaustion + +Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page. + +The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range. + +Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging. + +Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of). + +This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me. + + + +Triaging old bug tickets ... do you still have this issue with the latest version of QEMU? If so, could you please discuss the patch on the qemu-devel mailing list? (since we do not take patches from the bugtracker) + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/682360 b/results/classifier/105/instruction/682360 new file mode 100644 index 00000000..fe6cf0ee --- /dev/null +++ b/results/classifier/105/instruction/682360 @@ -0,0 +1,42 @@ +instruction: 0.892 +boot: 0.839 +graphic: 0.756 +other: 0.743 +device: 0.738 +semantic: 0.686 +vnc: 0.685 +socket: 0.563 +assembly: 0.543 +mistranslation: 0.413 +network: 0.279 +KVM: 0.112 + +Unaccessible memory + +Hello, + +I'm trying to develop a OS over L4/X2 microkernel and I use Linux debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my kernel boots fine. If I modify this command line with -m 384M (for example), my kernel is loaded but enter in a deadlock. I have found a bug in my code until I have tried to use the _same_ disk image under virtualbox and it works without any trouble. I runs fine on a real PC also. + +I have bissected my code and qemu stops (maybe in a deadlock) when I try to access to memory : +%MEM-I-VM_ALLOC, adding $0000000000045000 - $0000000000108FFF to VM allocator +%MEM-I-VM_ALLOC, adding $000000000010B000 - $00000000003F2FFF to VM allocator +%MEM-I-VM_ALLOC, adding $000000000040C000 - $0000000000FFFFFF to VM allocator +%MEM-I-VM_ALLOC, adding $000000000100F000 - $FFFFFEFFFFFFFFFF to VM allocator +%MEM-I-ACCMAP, accepting mapping +%MEM-I-ACCMAP, virtual $FFFF000000000000 - $FFFF000000000FFF +%MEM-I-ACCMAP, physical $000000000009E000 - $000000000009EFFF + +Note that qemu doesn't crash. It only stops. My virtual memory subsystem maps $FFFF000000000000 in physical memory ($9E000). And when I try to initialize this memory, qemu enters in deadlock. + +A disk image to reproduce this bug is available at http://www.systella.fr/~bertrand/freevms.img.bz2 + +Regards, + +JKB + +This is a qemu emulator problem, whould qemu stop when the memory is larger than 128M? You can try set the memory 256 to start vm. + +QEMU 0.13 is pretty much outdated nowadays ... 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/105/instruction/690 b/results/classifier/105/instruction/690 new file mode 100644 index 00000000..44efefeb --- /dev/null +++ b/results/classifier/105/instruction/690 @@ -0,0 +1,32 @@ +instruction: 0.895 +other: 0.861 +device: 0.851 +graphic: 0.838 +semantic: 0.720 +vnc: 0.621 +network: 0.605 +socket: 0.603 +boot: 0.521 +mistranslation: 0.469 +assembly: 0.172 +KVM: 0.086 + +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/105/instruction/697 b/results/classifier/105/instruction/697 new file mode 100644 index 00000000..ae52f1f1 --- /dev/null +++ b/results/classifier/105/instruction/697 @@ -0,0 +1,14 @@ +instruction: 0.706 +device: 0.517 +boot: 0.423 +semantic: 0.378 +graphic: 0.230 +socket: 0.154 +other: 0.137 +KVM: 0.125 +mistranslation: 0.111 +vnc: 0.108 +network: 0.057 +assembly: 0.037 + +linux-user create default CPU type before parsing the ELF header for specific CPU type diff --git a/results/classifier/105/instruction/701 b/results/classifier/105/instruction/701 new file mode 100644 index 00000000..ee7fc3aa --- /dev/null +++ b/results/classifier/105/instruction/701 @@ -0,0 +1,14 @@ +instruction: 0.750 +device: 0.705 +semantic: 0.418 +mistranslation: 0.366 +boot: 0.304 +network: 0.257 +graphic: 0.204 +vnc: 0.176 +other: 0.139 +socket: 0.042 +KVM: 0.042 +assembly: 0.033 + +Setup a gitlab shared runner for linux-user testing diff --git a/results/classifier/105/instruction/703 b/results/classifier/105/instruction/703 new file mode 100644 index 00000000..4cbec61b --- /dev/null +++ b/results/classifier/105/instruction/703 @@ -0,0 +1,30 @@ +instruction: 0.883 +device: 0.834 +boot: 0.718 +semantic: 0.652 +vnc: 0.623 +socket: 0.586 +graphic: 0.586 +KVM: 0.574 +network: 0.507 +mistranslation: 0.299 +other: 0.236 +assembly: 0.156 + +Resizable BAR (ReBAR) support on VFIO +Additional information: +Currently `vfio_add_ext_cap()` doesn't pass ReBAR support option to VFIO. + +There was a report that removing the line you see below makes it boot, but the system is not stable. +Needs investigation. + +[https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089](https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089) +``` switch (cap_id) { + case 0: /* kernel masked capability */ + case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */ + case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */ + case PCI_EXT_CAP_ID_REBAR: /* Can't expose read-only */ + trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next); +``` + +[Discussion link](https://forum.level1techs.com/t/smart-access-memory-vs-qemu-kvm/169447) diff --git a/results/classifier/105/instruction/70868267 b/results/classifier/105/instruction/70868267 new file mode 100644 index 00000000..1fd40dec --- /dev/null +++ b/results/classifier/105/instruction/70868267 @@ -0,0 +1,48 @@ +instruction: 0.778 +graphic: 0.706 +device: 0.643 +semantic: 0.635 +mistranslation: 0.537 +socket: 0.418 +network: 0.411 +assembly: 0.240 +other: 0.236 +vnc: 0.227 +boot: 0.197 +KVM: 0.167 + +[Qemu-devel] [BUG] Failed to compile using gcc7.1 + +Hi all, + +After upgrading gcc from 6.3.1 to 7.1.1, qemu can't be compiled with gcc. + +The error is: + +------ + CC block/blkdebug.o +block/blkdebug.c: In function 'blkdebug_refresh_filename': +block/blkdebug.c:693:31: error: '%s' directive output may be truncated +writing up to 4095 bytes into a region of size 4086 +[-Werror=format-truncation=] +"blkdebug:%s:%s", s->config_file ?: "", + ^~ +In file included from /usr/include/stdio.h:939:0, + from /home/adam/qemu/include/qemu/osdep.h:68, + from block/blkdebug.c:25: +/usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' +output 11 or more bytes (assuming 4106) into a destination of size 4096 +return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + __bos (__s), __fmt, __va_arg_pack ()); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make: *** [/home/adam/qemu/rules.mak:69: block/blkdebug.o] Error 1 +------ + +It seems that gcc 7 is introducing more restrict check for printf. +If using clang, although there are some extra warning, it can at least +pass the compile. +Thanks, +Qu + diff --git a/results/classifier/105/instruction/729 b/results/classifier/105/instruction/729 new file mode 100644 index 00000000..bc479388 --- /dev/null +++ b/results/classifier/105/instruction/729 @@ -0,0 +1,47 @@ +instruction: 0.833 +semantic: 0.823 +graphic: 0.783 +vnc: 0.625 +device: 0.600 +mistranslation: 0.561 +other: 0.519 +assembly: 0.417 +socket: 0.387 +network: 0.379 +boot: 0.290 +KVM: 0.260 + +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/105/instruction/744 b/results/classifier/105/instruction/744 new file mode 100644 index 00000000..f355495e --- /dev/null +++ b/results/classifier/105/instruction/744 @@ -0,0 +1,16 @@ +instruction: 0.961 +graphic: 0.796 +device: 0.786 +socket: 0.707 +vnc: 0.665 +network: 0.630 +assembly: 0.593 +boot: 0.509 +semantic: 0.394 +mistranslation: 0.299 +other: 0.136 +KVM: 0.081 + +ppc64: Implement the remaining PowerISA v3.1 instructions +Additional information: +[PowerISA_public.v3.1.pdf](https://wiki.raptorcs.com/w/images/f/f5/PowerISA_public.v3.1.pdf) diff --git a/results/classifier/105/instruction/750 b/results/classifier/105/instruction/750 new file mode 100644 index 00000000..22c47420 --- /dev/null +++ b/results/classifier/105/instruction/750 @@ -0,0 +1,46 @@ +instruction: 0.930 +graphic: 0.887 +network: 0.874 +semantic: 0.865 +vnc: 0.858 +device: 0.816 +socket: 0.737 +mistranslation: 0.616 +boot: 0.528 +other: 0.505 +assembly: 0.262 +KVM: 0.113 + +/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/105/instruction/754635 b/results/classifier/105/instruction/754635 new file mode 100644 index 00000000..178b72d0 --- /dev/null +++ b/results/classifier/105/instruction/754635 @@ -0,0 +1,83 @@ +instruction: 0.933 +semantic: 0.926 +graphic: 0.919 +device: 0.919 +other: 0.907 +socket: 0.876 +mistranslation: 0.834 +assembly: 0.810 +network: 0.802 +boot: 0.750 +KVM: 0.737 +vnc: 0.726 + +-d option outs wrong info about sections + +For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file: +$ cat /tmp/qemu.log | grep -A7 guest +Relocating guest address space from 0x08048000 to 0x8048000 +guest_base 0x0 +start end size prot +00048000-0005f000 00017000 r-x +0005f000-00069000 0000a000 rw- +00040000-00041000 00001000 --- +00041000-00041800 00000800 rw- +00041800-0005d800 0001c000 r-x +0005d800-0005f800 00002000 rw- + +But such command in 0.12.5 release outs this: +$ cat /tmp/qemu.log | grep -A7 guest +guest_base 0x0 +start end size prot +00f38000-00f39000 00001000 --- +08048000-0805f000 00017000 r-x +0805f000-08061000 00002000 rw- +40000000-40080000 00080000 rw- +40080000-40081000 00001000 --- +40081000-4009d000 0001c000 r-x + +It looks correct. +I received such differences and with qemu-microblaze. + +After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c: +in 0.12.5: +end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS); + +in 0.14.0: +int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, + +V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22 + +I make this changes: +$ diff -up qemu-0.14.0/exec.c exec.c +--- qemu-0.14.0/exec.c 2011-04-08 17:26:00.524464002 +0400 ++++ exec.c 2011-04-08 17:26:09.800464003 +0400 +@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk + data.prot = 0; + + for (i = 0; i < V_L1_SIZE; i++) { +- int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, ++ int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS), + V_L1_SHIFT / L2_BITS - 1, l1_map + i); + if (rc != 0) { + return rc; + +After this outputs looks correct. + +I don't know code base good, and think what may to do more general corrections. +Host system: linux i386 + +Hi, + +Thanks for reporting this issue, and the investigation. I don't really understand the rationale for the change, so I can't help much. + +This change appears to be from 5cd2c5b6ad75c46d40118ac67c0c09d4e7930a65. I think input from Richard Henderson (the author of the change) would be very useful. + +Brad + + +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/105/instruction/760976 b/results/classifier/105/instruction/760976 new file mode 100644 index 00000000..c017f73f --- /dev/null +++ b/results/classifier/105/instruction/760976 @@ -0,0 +1,42 @@ +instruction: 0.806 +boot: 0.721 +device: 0.694 +graphic: 0.632 +semantic: 0.582 +other: 0.506 +network: 0.472 +socket: 0.469 +vnc: 0.338 +mistranslation: 0.258 +assembly: 0.205 +KVM: 0.102 + +Nexenta 3.0.1 fails to install + +The latest git version of qemu (commit 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1. I don't know if this is a bug in nextenta, or in QEMU or both. + +You can obtain a bootable image of Nextenta from http://www.nexenta.org/releases/nexenta-core-platform_3.0.1-b134_x86.iso.zip + +Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-thread --enable-kvm + +qemu-img create nexenta3.0.1 3G +qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d -k en-us -m 256 + +Boots to grub OK, but when you hit install you get panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0): bad free. + +You get the same error with or without -enable-kvm + + + +I have found that I can get to the installer if I give the -no-acpi argument. + +As others have noted, Netexnta is very slow. To get any sort of speed I used the 32-bit version and disabled QEMU disc caching, thus: + +qemu -drive file=nexenta3.0.1,index=0,media=disk,cache=unsafe -cdrom nexenta-core-platform_3.0.1-b134_x86.iso -boot d -k en-us -m 512 -enable-kvm -no-acpi + +Even then, performance is painful. + +Triaging old bug tickets ... Is this issue still reproducible with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/781 b/results/classifier/105/instruction/781 new file mode 100644 index 00000000..6a1177d1 --- /dev/null +++ b/results/classifier/105/instruction/781 @@ -0,0 +1,14 @@ +instruction: 0.945 +mistranslation: 0.666 +network: 0.621 +assembly: 0.544 +device: 0.525 +graphic: 0.398 +semantic: 0.346 +KVM: 0.224 +boot: 0.214 +socket: 0.156 +vnc: 0.140 +other: 0.028 + +Assertion `addr < cache->len && 2 <= cache->len - addr' failed in address_space_stw_le_cached diff --git a/results/classifier/105/instruction/789652 b/results/classifier/105/instruction/789652 new file mode 100644 index 00000000..02ddd74f --- /dev/null +++ b/results/classifier/105/instruction/789652 @@ -0,0 +1,29 @@ +instruction: 0.318 +mistranslation: 0.316 +semantic: 0.154 +device: 0.107 +graphic: 0.089 +network: 0.086 +other: 0.080 +socket: 0.076 +vnc: 0.034 +KVM: 0.031 +boot: 0.023 +assembly: 0.011 + +Cannot confirm email address on QEMU Wiki + +Cannot confirm email address on QEMU Wiki + +http://wiki.qemu.org/Special:ConfirmEmail + +--- + +Confirm e-mail address + +QEMU could not send your confirmation mail. Please check your e-mail address for invalid characters. + +Mailer returned: mailer error + +QEMU Wiki does not use e-mail addresses, so this is not a bug + diff --git a/results/classifier/105/instruction/796480 b/results/classifier/105/instruction/796480 new file mode 100644 index 00000000..1cb0d318 --- /dev/null +++ b/results/classifier/105/instruction/796480 @@ -0,0 +1,63 @@ +instruction: 0.837 +graphic: 0.704 +device: 0.655 +assembly: 0.454 +mistranslation: 0.398 +semantic: 0.373 +other: 0.354 +vnc: 0.337 +socket: 0.200 +boot: 0.116 +network: 0.110 +KVM: 0.093 + +Addresses with 4GB differences are consider as one single address in QEMU + +THIS IS THE ISSUE OF USER MODE EMULATION +Information about guest and host +********************************** +guest: 64 bit x86 user mode binary +host: 32 bit Linux OS +uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP +architecture: intel64 +Bug Description +**************** +for memory reference instructions, suppose I have two addresses in guest address space(64 bit) +0x220000000 +0x320000000 +as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) +in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. +here is the program which i used to test: +#include <stdio.h> +#include <stdlib.h> +#include <limits.h> +#define SIZE 4294967298 /* 4Gib*/ + +int main() { + char *array; + unsigned int i; + + array = malloc(sizeof(char) * SIZE); + if(array == NULL) { + fprintf(stderr, "Could not allocate that much memory"); + return 1; } + array[0] = 'a'; + array[SIZE-2] = 'z'; + printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); + return 0; +} +I have 8 gib RAM +I compiled this program on 64 bit linux and run this on 32 bit linux with qemu +QEMU command line and output +********************************** +$x86_64-linux-user/qemu-x86_64 ~/ar_x86 +output: array[SIZE-1] = z,array[0] = z +Release information +******************** +x86_64 binary is tested with latest release : qemu-0.14.1 +and with current development tree as well( live code of QEMU using git) + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/799 b/results/classifier/105/instruction/799 new file mode 100644 index 00000000..b6de1812 --- /dev/null +++ b/results/classifier/105/instruction/799 @@ -0,0 +1,60 @@ +instruction: 0.871 +graphic: 0.858 +assembly: 0.798 +device: 0.740 +vnc: 0.609 +socket: 0.576 +network: 0.552 +other: 0.445 +boot: 0.333 +semantic: 0.288 +mistranslation: 0.231 +KVM: 0.164 + +TCG Optimizer crashes on AArch64 SVE2 instruction +Description of problem: +QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: +``` +Unrecognized operation 145 in do_constant_folding. +../tcg/optimize.c:458: tcg fatal error +``` +Steps to reproduce: +1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) +```asm +.org 0x0 +entry: + mrs x1, cptr_el3 + orr x9, x1, #0x100 + msr cptr_el3, x9 + + msr cptr_el2, xzr + + mov x1, #0x3 + mrs x9, cpacr_el1 + bfi x9, x1, #16, #2 + bfi x9, x1, #20, #2 + msr cpacr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el2, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el3, x9 + + uqxtnt z11.s, z22.d +``` +2. Execute it using the command line given above. +Additional information: +I tested latest master as well, and the problem persists. diff --git a/results/classifier/105/instruction/802 b/results/classifier/105/instruction/802 new file mode 100644 index 00000000..c8ad8542 --- /dev/null +++ b/results/classifier/105/instruction/802 @@ -0,0 +1,39 @@ +instruction: 0.679 +device: 0.598 +graphic: 0.554 +network: 0.482 +semantic: 0.388 +boot: 0.130 +other: 0.126 +KVM: 0.119 +mistranslation: 0.105 +socket: 0.085 +vnc: 0.061 +assembly: 0.027 + +Devices created using '-device' JSON syntax don't emit DEVICE_DELETED when unplugged +Description of problem: +Run the following sequence: + +``` + $ ./qemu-system-x86_64 -qmp stdio \ + -device '{"driver": "virtio-mouse-pci", "id": "dev0"}' \ + -device virtio-mouse-pci,id=dev1 +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 6}, "package": "v6.2.0-105-g7494244ffc-dirty"}, "capabilities": ["oob"]}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev0"} } +{"return": {}} +{ "execute": "device_del", "arguments": { "id": "dev1"} } +{"return": {}} +{ "execute": "system_reset" } +{"return": {}} +{"timestamp": {"seconds": 1641385071, "microseconds": 120178}, "event": "RESET", "data": {"guest": false, "reason": "host-qmp-system-reset"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121431}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev1/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 121684}, "event": "DEVICE_DELETED", "data": {"device": "dev1", "path": "/machine/peripheral/dev1"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 122297}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/dev0/virtio-backend"}} +{"timestamp": {"seconds": 1641385071, "microseconds": 198581}, "event": "RESET", "data": {"guest": true, "reason": "guest-reset"}} + + ``` + +Notice the lack of a "DEVICE_DELETED" event with path "/machine/peripheral/dev0" - the device created with JSON syntax diff --git a/results/classifier/105/instruction/813 b/results/classifier/105/instruction/813 new file mode 100644 index 00000000..b7f62a35 --- /dev/null +++ b/results/classifier/105/instruction/813 @@ -0,0 +1,28 @@ +instruction: 0.858 +graphic: 0.857 +device: 0.825 +semantic: 0.486 +vnc: 0.483 +boot: 0.467 +other: 0.427 +mistranslation: 0.410 +socket: 0.404 +network: 0.268 +assembly: 0.203 +KVM: 0.164 + +On windows, preallocation=full qcow2 not creatable, qcow2 not resizable +Description of problem: +Not possible to create a fixed-virtual-disk qcow as one may do on linux. +One sometimes may want to create a fixed size qcow2, as can be done with the fixed variants of VHDX, VMDK, VDI, + +The advantage of a fixed virtual-disk format, such as fixed-VHDX, fixed-VMDK, fixed-VDI is that it keeps the disk-meta-data as a header bundled along with that is essentially a raw image, allowing for seamless tooling and management of virtual-disks + +Workaround use a raw file as diskimage. (see workaround given below) + +To be very general, the implementation of this may need to factor in what underlying operations (fallocate, fallocate_punchhole, truncate, sparse) are supported by what filesystems (NTFS, ExFAT, ext4), choice of filesystem-driver (sometimes the driver may not have yet implemented an underlying operation), and operating systems (Linux/Win), and possible workarounds to achieve the same effect in the absence of underlying-operation. +Steps to reproduce: +1. open command shell +2. run the qemu-img command. In my case, qcow2 file is attempted to be created on a drive with ExFAT filesystem. +Additional information: + diff --git a/results/classifier/105/instruction/817 b/results/classifier/105/instruction/817 new file mode 100644 index 00000000..9ba8dc42 --- /dev/null +++ b/results/classifier/105/instruction/817 @@ -0,0 +1,14 @@ +instruction: 0.742 +mistranslation: 0.544 +device: 0.478 +semantic: 0.402 +network: 0.362 +graphic: 0.246 +other: 0.164 +boot: 0.115 +socket: 0.076 +vnc: 0.048 +KVM: 0.045 +assembly: 0.043 + +linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero diff --git a/results/classifier/105/instruction/824 b/results/classifier/105/instruction/824 new file mode 100644 index 00000000..cf779516 --- /dev/null +++ b/results/classifier/105/instruction/824 @@ -0,0 +1,25 @@ +instruction: 0.888 +graphic: 0.848 +device: 0.834 +mistranslation: 0.623 +vnc: 0.563 +semantic: 0.474 +socket: 0.455 +assembly: 0.442 +network: 0.345 +other: 0.321 +boot: 0.225 +KVM: 0.024 + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/105/instruction/825776 b/results/classifier/105/instruction/825776 new file mode 100644 index 00000000..2c51811e --- /dev/null +++ b/results/classifier/105/instruction/825776 @@ -0,0 +1,30 @@ +instruction: 0.794 +device: 0.767 +graphic: 0.562 +other: 0.470 +socket: 0.469 +semantic: 0.423 +boot: 0.399 +mistranslation: 0.394 +vnc: 0.273 +network: 0.101 +KVM: 0.078 +assembly: 0.078 + +-boot -hda //.//physicaldrivex does not work if it is USB drive + +qemu-system-x86_64.exe -L . -name "RMPrepUSB Emulation Session" -boot c -m 500 -hda //./PhysicalDrive1 + +just opens a blank QEMU window (no BIOS POSt messages) and does nothing + +qemu v 0.15.0 +Under Windows 7 64-bit +drive1 is a USB Flash drive + +Previous version of x86_64 (Jan 2010) works fine. If replace with new version (or RC2 version) then does not work. + +if use harddisk.img raw file instead of USB physical device then I get BIOS POST messages and it boots to image OK. +So appears to be USB or physicaldisk support issue??? + +All working now, I think some BIOS files were missing. Please close this bug report. + diff --git a/results/classifier/105/instruction/826 b/results/classifier/105/instruction/826 new file mode 100644 index 00000000..3ef3962e --- /dev/null +++ b/results/classifier/105/instruction/826 @@ -0,0 +1,29 @@ +instruction: 0.989 +graphic: 0.822 +device: 0.639 +mistranslation: 0.592 +network: 0.489 +other: 0.438 +assembly: 0.432 +semantic: 0.404 +vnc: 0.261 +socket: 0.178 +boot: 0.132 +KVM: 0.015 + +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/105/instruction/842290 b/results/classifier/105/instruction/842290 new file mode 100644 index 00000000..dcc92880 --- /dev/null +++ b/results/classifier/105/instruction/842290 @@ -0,0 +1,30 @@ +instruction: 0.913 +device: 0.861 +socket: 0.702 +graphic: 0.673 +network: 0.654 +mistranslation: 0.638 +boot: 0.637 +vnc: 0.621 +semantic: 0.543 +assembly: 0.519 +other: 0.333 +KVM: 0.322 + +MIPS Malta mini-bootloader print function has bad jump instruction + +One of the hardcoded bootloader library instructions in the MIPS Malta mini-bootloader's print function is: + +stl_raw(p++, 0x08000205); /* j 814 */ + +Since this function is loaded at 0xbfc00808, this jump jumps to the middle of nowhere. The properly-encoded instruction is: + +stl_raw(p++, 0x0bf00205); /* j 814 */ + +With this patch, the print function behaves as expected. + + + +Looks like this has been finally fixed by this commit here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7f81dbb9a0e89b53 + diff --git a/results/classifier/105/instruction/885 b/results/classifier/105/instruction/885 new file mode 100644 index 00000000..eb3baa97 --- /dev/null +++ b/results/classifier/105/instruction/885 @@ -0,0 +1,14 @@ +instruction: 0.896 +device: 0.883 +network: 0.812 +mistranslation: 0.788 +boot: 0.534 +socket: 0.527 +graphic: 0.419 +semantic: 0.262 +other: 0.207 +vnc: 0.203 +KVM: 0.041 +assembly: 0.018 + +linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int` diff --git a/results/classifier/105/instruction/891 b/results/classifier/105/instruction/891 new file mode 100644 index 00000000..8b741ff4 --- /dev/null +++ b/results/classifier/105/instruction/891 @@ -0,0 +1,14 @@ +instruction: 0.950 +device: 0.690 +semantic: 0.474 +graphic: 0.411 +mistranslation: 0.292 +boot: 0.275 +assembly: 0.111 +other: 0.090 +network: 0.064 +vnc: 0.017 +KVM: 0.008 +socket: 0.003 + +how to know jpeg-wan-compression is in force diff --git a/results/classifier/105/instruction/891002 b/results/classifier/105/instruction/891002 new file mode 100644 index 00000000..bd874423 --- /dev/null +++ b/results/classifier/105/instruction/891002 @@ -0,0 +1,57 @@ +instruction: 0.659 +semantic: 0.523 +device: 0.455 +graphic: 0.374 +boot: 0.318 +network: 0.316 +other: 0.294 +vnc: 0.246 +socket: 0.239 +mistranslation: 0.234 +KVM: 0.202 +assembly: 0.096 + +windows mingw compiled qemu-system-x86_64 crash on startup + +qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +$3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} + +it's compiled on windows 2003 and using mingw gcc version 4.6.1 + + +On Wed, Nov 16, 2011 at 7:01 AM, humeafo <email address hidden> wrote: +> Public bug reported: +> +> qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +> $3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} + +Kevin: Is this similar to the issue you found with your mingw cross-compiler? + +Stefan + + +Am 16.11.2011 11:35, schrieb Stefan Hajnoczi: +> On Wed, Nov 16, 2011 at 7:01 AM, humeafo <email address hidden> wrote: +>> Public bug reported: +>> +>> qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +>> $3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} +> +> Kevin: Is this similar to the issue you found with your mingw cross-compiler? + +The symptoms were different. I didn't get a broken TCG state but some +internals of the Fiber used for coroutines must have been corrupted +(SwitchFiber() crashed when dereferencing a null pointer, but the +externally visible pointer that qemu passed to it was still ok). + +Maybe both could be symptoms of the same kind of memory corruption. + +Kevin + + +maybe it's caused by mingw/gcc? the same binary runs well on win7-x64, but not on win2003-32 bit I'll do more test, if I've time, i'd debug it and try to find the reason + +after some debugging I confirmed that this is caused by a mingw gcc 4.6.1-2 optiomization bug, gcc generated optimized code that used ebp to store some results , while later ebp is used in setjmp and longjmp, so a beiju occurred. mingw gcc 4.5.2works well. the bug should be closed. + +Closing according to comment #5. + diff --git a/results/classifier/105/instruction/899664 b/results/classifier/105/instruction/899664 new file mode 100644 index 00000000..1126fee4 --- /dev/null +++ b/results/classifier/105/instruction/899664 @@ -0,0 +1,120 @@ +instruction: 0.919 +vnc: 0.915 +socket: 0.913 +KVM: 0.909 +graphic: 0.908 +assembly: 0.903 +other: 0.901 +device: 0.899 +mistranslation: 0.889 +boot: 0.885 +semantic: 0.882 +network: 0.871 + +Bad internet performance for Host to Guest or Guest to Host + +Hi, +Internet performance for Host to Quest is low. +The speed Guest to same Guest is 11.3 Gbits/sec +The speed Host to same Host is similar (9.8-11 Gbits/sec) + +But the speed from Guest to Host is slow and around 1Gbit/sec. +In the reality traffic never leave a Host. I expected that in this case speed should be close to Host to Host. +It is important for virtual infrastructure when you have several Guests on a same Host. Guest to Guest on a same host has speed around 1 Gbits/sec too. + +Below you can find testes and additional information: + +========================================================================= +biouml@biouml-db:~$ iperf -c 192.168.2.31 -t 30 #Guest to Guest +------------------------------------------------------------ +Client connecting to 192.168.2.31, TCP port 5001 +TCP window size: 49.7 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.31 port 52170 connected with 192.168.2.31 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 39.6 GBytes 11.3 Gbits/sec +============================================================================ +biouml@biouml-db:~$ iperf -c 192.168.2.11 -t 30 # Guest to Host +------------------------------------------------------------ +Client connecting to 192.168.2.11, TCP port 5001 +TCP window size: 43.4 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.31 port 47148 connected with 192.168.2.11 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 3.69 GBytes 1.06 Gbits/sec +biouml@biouml-db:~$ +============================================================================ +root@s2-8core:~# iperf -c 192.168.2.30 -t 30 #host to guest +------------------------------------------------------------ +Client connecting to 192.168.2.30, TCP port 5001 +TCP window size: 16.0 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.11 port 57403 connected with 192.168.2.30 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 5.47 GBytes 1.57 Gbits/sec + +========================================================================== +root@s2-8core:~# iperf -c 192.168.2.11 -t 30 #host to host +------------------------------------------------------------ +Client connecting to 192.168.2.11, TCP port 5001 +TCP window size: 49.7 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.2.11 port 38313 connected with 192.168.2.11 port 5001 +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-30.0 sec 34.5 GBytes 9.87 Gbits/sec +root@s2-8core:~# +======================================================================== + +I am using virtio drivers and virtual machine was started with following parameters: + +/usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 -name one-25 -uuid d1e125ee-d692-4598-3a75-441cd79a513a -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-25.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/var/lib/one/OpenNebula/var//25/images/disk.0,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/one/OpenNebula/var//25/images/disk.1,if=none,id=drive-virtio-disk3,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk3,id=virtio-disk3 -netdev tap,fd=19,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:02,bus=pci.0,addr=0x3 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:98 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 +============================================================================= +Qemu version: +root@s2-8core:~# /usr/bin/kvm --version +QEMU emulator version 0.15.92, Copyright (c) 2003-2008 Fabrice Bellard + +root@s2-8core:~# ls -la /usr/bin/kvm +lrwxrwxrwx 1 root root 27 2011-11-07 17:34 /usr/bin/kvm -> /usr/bin/qemu-system-x86_64 + +========================================================================== +Bridge configuration: + +root@s2-8core:~# cat /etc/network/interfaces +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet manual + +auto eth1 +iface eth1 inet manual + +auto br0 +iface br0 inet static + address 192.168.2.11 + network 192.168.2.0 + netmask 255.255.255.0 + broadcast 192.168.2.255 + gateway 192.168.2.1 + bridge_ports eth0 + bridge_stp on + bridge_fd 0 + bridge_maxwait 0 +root@s2-8core:~# + +root@s2-8core:~# brctl show +bridge name bridge id STP enabled interfaces +br0 8000.001e8cec6113 yes eth0 + vnet0 +virbr0 8000.000000000000 yes + +root@s2-8core:~# brctl --version +bridge-utils, 1.5 +=============================================================== +root@s2-8core:~# uname -a +Linux s2-8core 3.0.0-13-server #22-Ubuntu SMP Wed Nov 2 15:09:08 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/105/instruction/91 b/results/classifier/105/instruction/91 new file mode 100644 index 00000000..c3d1abf8 --- /dev/null +++ b/results/classifier/105/instruction/91 @@ -0,0 +1,14 @@ +instruction: 0.867 +device: 0.819 +network: 0.559 +boot: 0.387 +socket: 0.346 +graphic: 0.261 +mistranslation: 0.237 +assembly: 0.197 +vnc: 0.176 +semantic: 0.165 +other: 0.117 +KVM: 0.041 + +RFE: Implement support for SMBIOS Type 41 structures diff --git a/results/classifier/105/instruction/925 b/results/classifier/105/instruction/925 new file mode 100644 index 00000000..8d42ab6d --- /dev/null +++ b/results/classifier/105/instruction/925 @@ -0,0 +1,31 @@ +instruction: 0.864 +graphic: 0.770 +device: 0.746 +network: 0.517 +other: 0.426 +assembly: 0.416 +vnc: 0.416 +socket: 0.394 +semantic: 0.338 +boot: 0.325 +KVM: 0.311 +mistranslation: 0.233 + +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/105/instruction/927 b/results/classifier/105/instruction/927 new file mode 100644 index 00000000..3fcbc188 --- /dev/null +++ b/results/classifier/105/instruction/927 @@ -0,0 +1,45 @@ +instruction: 0.889 +graphic: 0.708 +device: 0.635 +semantic: 0.493 +vnc: 0.388 +network: 0.231 +other: 0.223 +socket: 0.181 +mistranslation: 0.166 +assembly: 0.124 +boot: 0.120 +KVM: 0.042 + +linux-user: openat on /proc/self/exe can return a closed file descriptor +Description of problem: +`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval. + +When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. + +`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem. +Steps to reproduce: +This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user). + +```c +#include <fcntl.h> +#include <stdio.h> + +int main(int argc, char **argv) { + int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC); + if (selfexe < 0) { + perror("open self"); + return 1; + } + + int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC); + if (devnull < 0) { + perror("open devnull"); + return 1; + } + + printf("%d %d\n", selfexe, devnull); +} +``` +Additional information: +Thanks to @pm215 for helping me pinpoint the exact issue I was encountering. diff --git a/results/classifier/105/instruction/929 b/results/classifier/105/instruction/929 new file mode 100644 index 00000000..64733a8d --- /dev/null +++ b/results/classifier/105/instruction/929 @@ -0,0 +1,46 @@ +instruction: 0.889 +graphic: 0.770 +device: 0.680 +semantic: 0.663 +network: 0.521 +vnc: 0.482 +socket: 0.465 +mistranslation: 0.434 +boot: 0.362 +other: 0.303 +assembly: 0.210 +KVM: 0.077 + +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/105/instruction/947 b/results/classifier/105/instruction/947 new file mode 100644 index 00000000..1f05f0e3 --- /dev/null +++ b/results/classifier/105/instruction/947 @@ -0,0 +1,26 @@ +instruction: 0.931 +graphic: 0.863 +semantic: 0.820 +device: 0.758 +other: 0.683 +vnc: 0.678 +network: 0.668 +socket: 0.595 +boot: 0.527 +mistranslation: 0.335 +KVM: 0.302 +assembly: 0.260 + +TCG AARCH64 Segmentation fault when helper function is called +Description of problem: +Segmentation fault in the TCG thread. +The issue occurs in the generated code when branching to (helper)lookup_tb_ptr (see op longs). +It seems that the generated instruction don't load the upper32 of the address of lookup_tb_ptr in the register before branching to it. According to LLDB, the program tries to access 0x1cffe060 while the right address 0x7ff71cffe060 (see debugger logs). +Additional information: +The issue seems to be located at https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/aarch64/tcg-target.c.inc#L1091 +`t2 = t1 & ~(0xffffUL << s1);`. +The fix would be `t2 = t1 & ~(0xffffULL << s1);` + + +[lldb.log](/uploads/6a1d57eaecae4a375c6ada7384489876/lldb.log) +[qemu_segmentation.log](/uploads/e3c2d6d42291ff7d1ff8d37341e3da1d/qemu_segmentation.log) diff --git a/results/classifier/105/instruction/953 b/results/classifier/105/instruction/953 new file mode 100644 index 00000000..45504b81 --- /dev/null +++ b/results/classifier/105/instruction/953 @@ -0,0 +1,14 @@ +instruction: 0.850 +network: 0.815 +device: 0.813 +assembly: 0.460 +socket: 0.431 +boot: 0.331 +semantic: 0.290 +vnc: 0.274 +graphic: 0.240 +mistranslation: 0.114 +other: 0.087 +KVM: 0.020 + +qemu-system-aarch64 asserts trying to execute STXP on hosts without HAVE_CMPXCHG128 diff --git a/results/classifier/105/instruction/974958 b/results/classifier/105/instruction/974958 new file mode 100644 index 00000000..8dd40022 --- /dev/null +++ b/results/classifier/105/instruction/974958 @@ -0,0 +1,26 @@ +instruction: 0.790 +mistranslation: 0.788 +graphic: 0.593 +other: 0.549 +device: 0.491 +semantic: 0.447 +network: 0.290 +socket: 0.230 +vnc: 0.153 +boot: 0.111 +KVM: 0.023 +assembly: 0.013 + +It dumps when following this tutorial on hello world os + +http://mikeos.berlios.de/write-your-own-os.html + + +Following the steps, + +it works on ubuntu, + +but on osx, it ALWAYS dumps. + +The referenced website is no longer available, thus setting this ticket to INVALID. Please feel free to re-open it if the information is available somewhere else and you can reproduce it with the latest version of QEMU. + diff --git a/results/classifier/105/instruction/982 b/results/classifier/105/instruction/982 new file mode 100644 index 00000000..08785ba5 --- /dev/null +++ b/results/classifier/105/instruction/982 @@ -0,0 +1,50 @@ +instruction: 0.888 +device: 0.761 +semantic: 0.651 +vnc: 0.537 +graphic: 0.527 +assembly: 0.499 +network: 0.432 +mistranslation: 0.366 +boot: 0.362 +socket: 0.269 +KVM: 0.221 +other: 0.087 + +linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine +Description of problem: +With `--strace`, the arguments to `writev` appear to be decoded incorrectly. +The syscall still succeeds and has the expected effects. +Steps to reproduce: +``` +$ cat main.c +#include <sys/uio.h> + +int main(void) { + struct iovec iov; + iov.iov_base = "hello, world!\n"; + iov.iov_len = 14; + return writev(1, &iov, 1); +} + +$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c + +$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c + +$ i686-pc-linux-gnu-gcc -static -o i686-main main.c + +$ ./i686-main +hello, world! + +$ strace ./i686-main |& grep writev +writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! + +$ qemu-i386 --strace ./i686-main |& grep writev +21953 writev(1,0x407ffe54,0x1) = 14 + +$ qemu-x86_64 --strace ./x86_64-main |& grep writev +22218 writev(1,(nil),0x407ffcc0) = 14 + +$ qemu-aarch64 --strace ./aarch64-main |& grep writev +22523 writev(1,(nil),0x407ffcc8) = 14 +``` diff --git a/results/classifier/105/instruction/984 b/results/classifier/105/instruction/984 new file mode 100644 index 00000000..0458e275 --- /dev/null +++ b/results/classifier/105/instruction/984 @@ -0,0 +1,36 @@ +instruction: 0.978 +device: 0.870 +semantic: 0.790 +network: 0.753 +socket: 0.751 +vnc: 0.711 +graphic: 0.657 +boot: 0.586 +assembly: 0.462 +other: 0.443 +KVM: 0.336 +mistranslation: 0.140 + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 diff --git a/results/classifier/105/instruction/984516 b/results/classifier/105/instruction/984516 new file mode 100644 index 00000000..a8931ac2 --- /dev/null +++ b/results/classifier/105/instruction/984516 @@ -0,0 +1,82 @@ +instruction: 0.630 +graphic: 0.616 +semantic: 0.599 +other: 0.590 +device: 0.537 +network: 0.466 +mistranslation: 0.427 +socket: 0.426 +vnc: 0.416 +assembly: 0.396 +boot: 0.357 +KVM: 0.334 + +should use sdl-config for static build not pkg-config + +In the configure script when a user wants to compile a static QEMU and enable SDL support (i.e. ./configure --static --enable-sdl): + +pkg-config does not have an option "--static-libs". For correct results (to find the static archive libSDL.a) you need to use sdl-config --static-libs. + + +This is how I get it to work for me anyway: + + +diff --git a/configure b/configure +index 2d62d12..3de4c9b 100755 +--- a/configure ++++ b/configure +@@ -1548,7 +1548,7 @@ int main( void ) { return SDL_Init (SDL_INIT_VIDEO); } + EOF + sdl_cflags=`$sdlconfig --cflags 2> /dev/null` + if test "$static" = "yes" ; then +- sdl_libs=`$sdlconfig --static-libs 2>/dev/null` ++ sdl_libs=`${SDL_CONFIG-${cross_prefix}sdl-config} --static-libs` + else + sdl_libs=`$sdlconfig --libs 2> /dev/null` + fi + +Sorry, I stripped out the "2>/dev/null" when I was debugging and forgot to add it back in: + + +diff --git a/configure b/configure +index 2d62d12..3de4c9b 100755 +--- a/configure ++++ b/configure +@@ -1548,7 +1548,7 @@ int main( void ) { return SDL_Init (SDL_INIT_VIDEO); } + EOF + sdl_cflags=`$sdlconfig --cflags 2> /dev/null` + if test "$static" = "yes" ; then +- sdl_libs=`$sdlconfig --static-libs 2>/dev/null` ++ sdl_libs=`${SDL_CONFIG-${cross_prefix}sdl-config} --static-libs 2>/dev/null` + else + sdl_libs=`$sdlconfig --libs 2> /dev/null` + fi + + +pkg-config supports --static, and QEMU uses it. + +Please try whether + + pkg-config --libs --static sdl + +gives the correct flags with your distribution. If not, that distribution is buggy. + +you are correct, can we switch the parameter from "--static-libs" to "--libs --static" ? + +diff --git a/configure b/configure +index 2d62d12..b0cedd2 100755 +--- a/configure ++++ b/configure +@@ -1548,7 +1548,7 @@ int main( void ) { return SDL_Init (SDL_INIT_VIDEO); } + EOF + sdl_cflags=`$sdlconfig --cflags 2> /dev/null` + if test "$static" = "yes" ; then +- sdl_libs=`$sdlconfig --static-libs 2>/dev/null` ++ sdl_libs=`$sdlconfig --libs --static 2>/dev/null` + else + sdl_libs=`$sdlconfig --libs 2> /dev/null` + fi + +Finally fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=5f37e6d4a7b22ccf1bb8fa4 + |